Divisão de tarefas em um time ágil: uma tarefa por desenvolvedor ou vários desenvolvedores por tarefa?

Em nosso ambiente de desenvolvimento geralmente precisamos tomar algumas decisões com relação ao fluxo de desenvolvimento das atividades de nosso backlog. Trabalho puxado ou empurrado, paralelização de atividades, etc.

Uma escolha importante (que pode ser alterada freqüentemente) é se o time irá atacar um item de cada vez ou se cada desenvolvedor (ou par) ficará responsável por uma única funcionalidade.

Normalmente, prefiro ter mais de um desenvolvedor em uma única tarefa por alguns motivos que considero interessantes. Vou comentá-los abaixo.

Limitação do WIP

Com o crescimento da adoção do método Kanban, muito tem sido falado na comunidade sobre limitar o Work in Progress (WIP). Trata-se de limitar a quantidade de tarefas sendo executadas pelo time, aumentando o foco nas atividades sendo executadas.

Entregas e feedback antecipado

Imaginando 3 atividades de 18 horas cada e um time de 3 desenvolvedores que trabalham 6 horas por dia, se cada um iniciasse uma atividade hoje teríamos as 3 atividades prontas somente no terceiro dia de desenvolvimento (caso não houvesse atraso em nenhuma delas). Até o terceiro dia, não teríamos nada pronto e utilizável para o cliente (apenas aqueles percentuais de conclusão que não servem para nada).

Tarefas sendo executadas em paralelo por três desenvolvedores

As três atividades sendo executadas em paralelo aumentam a necessidade de gerência/liderança.

Por outro lado, se tivéssemos os três desenvolvedores atuando na mesma atividade teríamos tal tarefa finalizada ao final do primeiro dia (ou no segundo dia, em caso de atraso).

Tarefas compartilhadas entre 3 desenvolvedores

Assim, teríamos feedback logo no primeiro dia e o cliente já poderia ver algo efetivamente pronto em um tempo menor. Poderíamos nos beneficiar do feedback recebido para melhorar as próximas atividades.

Vale lembrar que feedback nesse caso não é necessariamente do cliente. Podemos ter feedback sobre a qualidade do código (com as análises de código de um servidor de integração contínua, por exemplo), arquitetura, etc…

Claro que nem sempre será possível agir rigorosamente dessa forma. Nem sempre juntar três grávidas irá nos dar o bebê em apenas 3 meses…

Aumento do caos e interação entre a equipe

Quando desenvolvedores compartilham a mesma tarefa é gerado um caos momentâneo  e isso necessariamente aumenta a interação entre os envolvidos. Um começa a reclamar da classe criada pelo outro, da pitaco nos métodos, pacotes, etc.

Isso é bom! Por mais que no início gere um pouco mais de esforço de liderança para controlar os ânimos e ajuda em algumas decisões, com o tempo o próprio time aprende a resolver seus problemas.

O resultado dessa maior interação normalmente é:

• propriedade coletiva de código
• maior reaproveitamento de código
• código mais padronizado
• peer review
• integração mais freqüente (já que um depende do código do outro)
• redução de ilhas de conhecimento e aquela história de “essa funcionalidade é do Fulano e só ele saberá resolver esse problema”

Um arquiteto/líder técnico atento pode tirar bastante proveito dessa situação. Uma revisão técnica após terminar uma funcionalidade pode evoluir a arquitetura da aplicação e mover a estrutura para uma posição melhor, de mais qualidade, ainda na primeira interação, beneficiando a entrega das próximas funcionalidades.

Claro que nem sempre será possível organizar o time dessa forma. Em alguns momentos precisamos respeitar dependências (mesmo que elas raramente existam de fato).

Um outro fator importante a ser analisado é o Custo/Benefício do Atraso (Cost and Benefit of Delay). Quando não há custo em atrasar o início de determinada atividade, postergar o início pode garantir maiores informações no momento certo, por exemplo. O mesmo pode acontecer ao atrasar a entrega de atividades como falado no exemplo anterior.

Por fim, como sabemos, não há bala de prata, mas compartilhar tarefas entre desenvolvedores é, em minha opinião, uma boa idéia e pode trazer vantagens interessantes.

Aqui, tem um post interessante sobre Benefit of Delay e Last Responsible Moment