Eu vou passar dois caminhos possíveis, o primeiro é a equipe após quebrar a História em tarefas chega a um consenso de quantas horas são necessárias por tarefas. Este consenso pode ser realizado de varias maneiras, inclusive com a utilização do mesmo baralho da técnica do planning poker de esforço. Também podemos utilizar as mãos para substituir o baralho, o que faz com que a execução da estimativa fique mais rápida.
Utilizando as Mãos para Estimar Horas
Uma segunda técnica é para os projetos que possuem a necessidade de modelagem em UML da História. Uma vez realizado a modelagem a estimativa em horas fica mais assertiva, pois a equipe possuem uma visualização de todas as classes necessárias e métodos necessários para a implementação da tarefa.
Figura 1 mostra que temos que realizar o ciclo completo do nosso processo de desenvolvimento de software dentro da Sprint, isto é, se existe a necessidade de Use Cases, UML, Casos de Testes, etc tudo deve ser realizado dentro da Sprint e as estimativas devem prever todos os trabalhos que o nosso processo determina.
Figura 1
Figura 2 mostra a metodologia de analise orientada a objetos ICONIX, onde um requisito é modelado com diagramas de UML, para que a equipe tenha a visão do “como” o requisito vai ser implementado. Nesta figura o interessante é que uma funcionalidade de “consultar” mostra os objetos que devemos acessar e os métodos a ser utilizado, isso facilita muito o processo de estimativa.
Figura 2
Figura 3
Figura 4
Figura 4 mostra um exemplo de diagrama de seqüencias, onde cada bloco do diagrama de seqüencia representa uma funcionalidade a ser implementada. A funcionalidade aqui é a nossa tarefa, identificada pela equipe nos Cartões de História.
Mas fica uma observação, mesmo não utilizando UML para facilitar o entendimento da estratégia de como vamos atender a necessidade do requisito, isto é, a primeira técnica, após algumas Sprint’s a equipe fica muito assertiva na estimativa, mesmo não tendo ferramentas de apoio como a modelagem. Isso ocorre pelo faço do negocio começar a fazer mais sentido para a equipe, a equipe aprender a trabalhar cada vez melhor como um “Time”, o framework, bibliotecas, linguagem de programação, modelagem de banco de dados, etc ser cada vez mais dominado pela equipe.
Baralho
Abraços,
Abu
Postagens
Nenhum comentário:
Postar um comentário