Techniques for Estimating (anotações) - 3layer - 3PUP - 3layer Tecnologia - Confluence
Techniques for Estimating (anotações)
Created by Marcelo Mrack, last modified on Jul 09, 2008
O artigo http://www.infoq.com/articles/agile-estimation-techniques também é muito bom.
do livro Agile Estimating and Planning, de Mike Cohn - Adisson Wesley 2005
Capítulo 6 (Anexo)
Estimativas (tamanho)
1, 2, 3, 5, 8, 13, 21 ... > Fibonacci sequence é a base para a criacao de estimativas ao longo do tempo.
Em outras palavras, quanto mais para frente uma estimativa, maior a variacao nela. Por exemplo, se um projeto (ou tarefa) for estimado em 1 semana, entao ele pode variar ate 2; se ele for estimado em 5, pode variar entre 3 e 8; se for estimado em 13, significa que pode variar entre 13 e 21.
Usar um nivel de magnitude (1 a 8, por exemplo) é a premissa. Assim, nao é interessante ter coisas estimadas entre 1 e 8 convivendo com coisas estimadas entre 13 ou mais, por exemplo.
User Story = uma necessidade de negocio que traz valor para o cliente e tem limites explicitos. Na FDD, uma user story nao pode demorar mais de duas semanas para ser concluida. Na FDD, uma user story pode ser vistou como uma atividade que sera contemplada pelo software num fluxo de processos. Na PU (e PU Agil) a user story pode ser um caso de uso.
Epic = 1 user story fora de escala (muito grande), usado geralmente para evitar um detalhamento muito grande das user stories no inicio do projeto.
Theme = conjunto de user story. Na PU (e PU Agil) pode ser um Cenario
Usar epics e themes pode ajudar a reduzir o custo de estimar um projeto user stories para os proximos releases (milestones, versions) deveriam ser estimadas novamente para se adequar a um nivel de magnitude que caiba no milestone, ou entao ser fragmentada.
Epics e Themes tendem a viver para milestones mais distantes e quando chegarem a vez de serem construidos, deve(ria)m ser restimados e tornarem-se user stories.
Estimativas (tecnicas)
Tres formas: Opiniao de especialista, Analogia e Fragmentacao (disaggregation)
A opinicao de especialistas eh interessante. Entretanto, dificilmente ter-se-ao especialistas para todas as areas (disciplinas) do projeto. Por exemplo, em times tradicionais, geralmente o especialista é o "analista de negocio mais graduado" e ele estima baseado nas suas conviccoes. Mas esse analista conhece os tempos de projeto tecnico, empacotamento de aplicacoes, construcao de arquivos de build, montagem de ambientes de teste, criacao de testes unitarios, integrados, geracao de bases fake, refatoracao, instalacao e integracao de ferramentas, plugins, etc? Por isso se diz que dificilmente uma estimativa de *um* especialista por si so nao eh conclusiva.
Usar analogia eh interessante, e da bons resultados quando...temos estimativas anteriores ou em execucao que sao reais. Olhar o passado eh bom, mas o passado tem de ter sido bom.
Fragmentar vem do "dividir e conquistar" e torna mais obvio e equalizadas as coisas. Assim, se temos a quase totalidade das user stories no sistema esta entre 5 e 8 (dias, por exemplo) e aparece com 100, eh dificil saber se ela esta correta (seria ela um epic). Assim, quebra-se ela em menores (sempre lembrando a sequencia acima) e estimando-se as partes, chega-se ao total. Lembrando que esse total deve(ria) ser ajustado para entrar na sequencia (assim, ao inves de 100, teriamos algo como entre 89 e 144)
Para estimar, coloque toda a equipe na sala para discutir (arquitetos, engenheiros, testadores, estagiarios, programadores, analistas, dbas, etc, etc, etc).
Equipes ageis nao excedem 10 pessoas. 9 eh um bom numero
Se tiver muitas equipes, elega 1 ou 2 pessoas de cada equipe e forme uma "equipe da equipe" e assim sucessivamente para essas discussoes. Nesses casos, busque perfis complementares ou niveis diferentes de atuacao ou experiencia (por exemplo, leve um arquiteto e um estagiario, ou um analista e um testador, ou um programador e um dba - geralmente eles tem visoes conflitantes...e logo, complementares ) - veja XXX para mais detalhes boa ideia separar em duas equipes e cada uma estimar sozinha, sendo que depois os resultados sao comparados entre si e ajustados (fazendo uma media, por exemplo) o "product owner" (ou cliente) deveria participar dessas reunioes de estimativas, mesmo como ouvinte. E essa eh uma tecnica para "o cliente abracar a causa" (embrace), vendo que nao eh facil fazer software...
A tecnica do "planning poker": no inicio da reuniao, cada participante "estimador" (nem todos os integrantes sao estimadores, mas sim os que tem conhecimento/subsidios para tal) pega uma conjunto de cartoes (lembrando que cada cartao contem uma user story, e no cartao esta o "subject" da issue na frente. Tambem, um conjunto de valores validos para estimativas é dado (lembrando a sequencia acima). Entao, cada integrante que vai estimar, associa um valor a user story. O mediador (gerente ou outro qualquer) itera sobre cada user story, dando detalhes sobre ela. O product owner (ou outro analista) complementa e retira duvidas nesse interim. Depois disso, cada "estimador" da seu voto para uma user story (escrevendo a sua estimativa no cartao) de forma secreta. Isso é importante para nao poluir as coisas. De forma unica, todos os estimadores mostram suas cartas para uma user story. Grandes divergencias podem surgir, e assim, o maior e menor estimadores apresentam seus argumentos. O mediador deve evitar conflitos nesse momento, buscando sim, salientar o porque das diferencas e entao resolve-las em conjunto e opinao de todos os integrantes. Depois disso, uma nova rodada de estimativas (um novo round, como em um combate) ocorre para a user story. A tendencia é a estimativa equalizar. Se isso nao ocorrer, as rodadas se repetem ate que a user story tenha um valor de convergencia unico que possa ser usado.
O planning poker geralmente eh feito em dois momentos: no inicio do projeto, nas primeiras interacoes para dar um "norte" para as coisas. outro momento eh durante uma interacao, quando surgem novas user stories, ou elas se modificam devido aos requisitos mutatantes. esse segundo caso eh feito com reunioes pequenas no grupo que tratara as user stories naquela iteracao.
O planning poker é bom (1) quando multiplos perfis podem interagir/ser usados no projeto (ou seja, deixar somente Analistas de negocio ou somente gerentes nele nao adianta). Tambem (2) o planning poker deve ser pessoal, ao vivo (e nao via emails ou forum de discussao) - reunioes virtuais sao validas, mas uma presenca fisica eh de maior valor, sempre. E (3), fazer estimativas de user stories uma a uma e depois calcular o total eh melhor do que estimar um total e dividir ao final.
O planning poker tambem motiva a interacao da equipe (e tambem do cliente), a osmose do conhecimento e a "quebra" de tabus.