Equipes multifuncionais no Scrum

Written by Ralph Jocham
21/03/2012 at 10:20
0

Tradução feita por Luca Bastos do original de Ralph Jocham em Cross-Functionality in Scrum

Scrum recomenda que uma equipe deve possuir todas as habilidades necessárias para fazer o release da iteração do produto até o final do Sprint.

Por que é uma boa coisa ter todas as habilidades necessárias? Por causa das dependências. Tentamos projetar nossos sistemas de software para serem flexíveis e altamente coesos. Os mesmos princípios se aplicam a composição da equipe. Queremos que a nossa equipe seja como uma unidade especial, auto-suficiente e capaz de cumprir a missão escolhida.

O que acontecerá se uma habilidade importante faltar na equipe?

A equipe terá forte dependência externa e precisará pedir apoio de fontes externas. Este é um risco enorme. Será que a equipe terá acesso à tal pessoa de fora no momento certo pelo tempo necessário? Isto cria um atrito adicional e afeta o prazo de entrega ou reduz o âmbito de aplicação do produto a ser entregue.

Scrum não exige equipes multifuncionais, apenas recomenda tê-las. Na prática, isso tem mostrado ser um impulso significativo para a produtividade. Especialmente em combinação com auto-organização.

Muitas vezes há um mau entendimento de que a equipe ser multifuncional significa que qualquer pessoa da equipe deve ser capaz de fazer todo o trabalho futuro. Isso está errado. A unidade que precisa ser multifuncional é a equipe de desenvolvimento como um todo. É ela que tem a responsabilidade de se auto-organizar, a fim de maximizar o uso das suas competências. Assim, a equipe pode ser composta por especialistas apenas. A união das habilidades dos indivíduos necessita abranger todas as capacidades requeridas.

No entanto, como descrito acima, se você tiver apenas especialistas, terá equipes bem grandes. Para qualquer característica do sistema que depende de uma determinada área de conhecimento, você vai precisar de pelo menos um desenvolvedor. Isso fará as equipes serem maiores do que o necessário e provavelmente teremos todos os outros tipos de problemas: membros da equipe em tempo parcial medidos com base em FTE (full-time equivalent”), trabalho organizado por atividade e não por features, estimativas ruins feitas por gente “não qualificada”, etc..

Portanto, equipes ágeis favorecem desenvolvedores generalistas, desenvolvedores com um conjunto de habilidades arredondado e versátil. Eu gosto de usar os termos generalistas especializados, todos polivalentes mas com uma área de topo em que são especialmente fortes.