Quebrando em Tarefas!

By Lucas Menezes

Quando levantamos nossas funcionalidades, utilizamos roteiros de usuários ou histórias do usuário (user stories) para conhecer o nosso provável escopo do projeto. As histórias são representadas com um simples cartão que contém informações como título da funcionalidade, uma breve descrição, um campo para colocarmos nossa estimativa de tempo e um espaço para o cliente dar uma prioridade. No entanto, para começarmos a execução do projeto precisamos de um pouco mais.

Fonte: Scrum e XP direto das Trincheiras

Uma história (funcionalidade) pode ser quebrada em diversas tarefas menores, mantendo assim um controle melhor do andamento do projeto, já que o gráfico burndown é atualizado com mais precisão (a cada tarefa concluída). Com isso o Líder de Projeto tem um feedback mais rápido e pode interferir antes que a coisa realmente fique feia.

Assim como nossas histórias de usuário tiveram estimativas, as tarefas também podem ser estimadas.

Mas como?

Da mesma maneira, ou seja, Planning Poker. Com isso a nossa confiança no tempo previsto para realizar uma determinada história aumenta, já que a soma das estimativas das tarefas deve ser igual a estimativa da história a qual pertencem. Caso o número não bata, não se desespere. O fato de ter dividido as funcionalidades em pequenos pedaços nos permite ir encaixando aqui e ali conforme vai sobrando um tempo já que dificilmente nossas iterações serão cem por centro preenchidas.

Fonte: Scrum e XP direto das Trincheiras

O ideal é que a quebra em tarefas seja feita quando estamos estimando o prazo total do projeto para o usuário, porém nem sempre temos tempo para isso. Neste caso os roteiros de usuário são suficientes para que possamos organizar nossas iterações. Uma divisão a nível de tarefas faz com que não precisemos ignorar uma história de usuário inteira que depende de outra, pois sempre há alguma tarefa dela que pode ser adiantada.

Pegar todas as tarefas de um roteiro ou pegar uma de cada?

A resposta é quase sempre a mesma. Bom senso! Pode ser que algumas histórias tenham uma forte dependência de outro, nesse caso seria bom terminá-lo por inteiro logo. E como trabalhamos com iterações curtas o que vale mais para o cliente, duas funcionalidades pela metade ou uma funcionando?

Aparentemente é melhor pegar as tarefas de uma única história, mas se uma tarefa não pode ser executada antes da outra então é melhor dar outras tarefas para os desenvolvedores.

Este post foi escrito com base na leitura do livro Use a Cabeça: Desenvolvimento de Software e continua…

Lucas Menezes

Postagens Relacionadas:

• Terminando a tempo!
• Todos de pé!
• Quanto tempo leva? – Planning Poker
• Desenvolvimento de Software não é especulação!
• Controle de Versões – Rapidinho
• PMBOK 4ª edição – Rapidinho