Estimando o final de projectos scrum com números de fibonacci e pontos da história
Estimar o esforço envolvido no desenvolvimento de requisitos Product Backlog é um processo contínuo. A sequência de Fibonacci é uma técnica de colagem excelente para estimar relativa. Com Fibonacci, se algo é maior, você ter uma idéia de quanto maior ele é. Os dois últimos números na sequência são adicionadas em conjunto para criar o número seguinte. Parece que este:
Conteúdo
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, e assim por diante
Como a numeração progride, a distância entre os números aumenta. Utilize-o para reconhecer o menor grau de precisão na previsão de pedaços maiores de trabalho.
UMA ponto da história é o número de Fibonacci atribuído a uma exigência individual (isto é, uma história de usuário).
, requisitos de alto nível iniciais são estimadas ao nível roteiro produto:
Para as equipes de scrum, as equipes de desenvolvimento entende que os requisitos com estimativas de números de Fibonacci de 1 a 8 pode ser levado para um sprint. Este nível de refinamento geralmente resulta em uma história de usuário.
Requisitos com estimativas numeradas de 13 a 34 são aqueles que você deixaria em um lançamento, mas precisa ser dividido ainda mais antes de você deixá-los em um sprint.
Requisitos de 55 através de 144 são grandes demais para um lançamento, mas são estimáveis no nível roteiro do produto da ordem de grandeza. Esses requisitos normalmente refletem características.
Video: Sequência de Fibonacci e Razão de Ouro
Requisitos maiores do que 144 precisam ser quebrados para baixo antes de a equipe de desenvolvimento pode dar qualquer aparência de uma estimativa precisa, por isso não estimar acima 144. Estes podem representar temas mais amplos.
Seja qual for o número de Fibonacci, apenas os cartões de maior prioridade se dividido em tamanhos de nível de sprint (que não deve ser superior a 8). Então, se você tem uma exigência de alta prioridade com um número 21 Fibonacci atribuído a ele, ele precisa ser dividido em requisitos menores antes que ele possa entrar em um sprint.
Com os tamanhos estabelecida, você pode aplicar algumas técnicas para estimar as exigências:
Quando você tem listas mais curtos de requisitos, começar com o poker estimativa.
Quando você tem centenas de requisitos, comece com estimativa de afinidade.
No processo de estimação com projetos menores, têm a equipe de desenvolvimento de sentar-se com sua pilha de requisitos escritos para fora em 3 × 5 cartões. Em seguida, pedir-lhes para escolher uma exigência de que todos eles podem concordar tem um nível de esforço de 5. Isso cria um ponto de referência.
Então eles têm que escolher um outro cartão, e com base na primeira sendo a 5, perguntar-lhes o número do próximo seria. Se for maior do que a 5, é um 8? a 13? um 21? Este processo continua até que alguns tamanhos de representação foram estabelecidas. Agora você está pronto para o poker estimativa.
pôquer estimativa
Uma maneira popular de requisitos estimativa é através de uma variação de poker.
Você vai precisar de um baralho de cartões estimativa de poker como a mostrada. (Você também pode baixar o aplicativo estimativa de poker para o iPhone e / ou Android através de pesquisa Platinum Borda Estimativa Poker.) Você também pode fazer o seu próprio deck com cartões de índice e um marcador.
Porque só a equipe de desenvolvimento decide quanto vai demorar para desenvolver uma exigência, somente a equipe de desenvolvimento joga. O Scrum Master facilita e o proprietário do produto lê os requisitos e fornece detalhes dos requisitos, mas nenhum dos dois dá estimativas. É assim que funciona:
O proprietário do produto lê um requisito alvejado a equipe de desenvolvimento.
A equipe de desenvolvimento faz perguntas e obtém quaisquer esclarecimentos necessários.
Video: Pato Donald e a sequencia de fibonacci (Regra de ouro)
Cada membro da equipe de desenvolvimento pega de seu convés um cartão com sua estimativa da dificuldade da exigência.
A estimativa é de acordo com a definição completa de fazer, não apenas para escrever código. Membros não mostram qualquer outra pessoa os seus cartões, porque você não quer que os outros a ser influenciado.
Depois de todos terem escolhido um número, simultaneamente, os membros da equipe mostrar as suas cartas.
Se todo mundo tem a mesma estimativa, nada é deixado para discutir. Atribuir a exigência de que estimar e passar para a próxima exigência.
Se existirem diferenças nas estimativas, aqueles com as estimativas mais altas e mais baixas são convidados a explicar. Mais esclarecimentos do proprietário do produto é dada como necessário.
Com o aumento do conhecimento, todo mundo pega um novo número para esse requisito, repetindo as etapas 3-4.
Normalmente, você faz até três rodadas de pôquer estimativa para cada requisito para obter os pressupostos fundamentais sobre a mesa e esclarecido e, nesse ponto, geralmente têm as estimativas em um cluster com mais força dos números.
Se todos os desenvolvedores estão de acordo sobre um único número após três rodadas, você está pronto para passar para o próximo requisito. Mas você não vai ter sempre todos os desenvolvedores em acordo sobre um único número após três rodadas. Neste ponto, ir para uma técnica de construção de consenso chamado punho de cinco.
Punho de cinco
Um método rápido e eficiente de chegar a um consenso, o punho de cinco pode ser usado sozinho ou como um adendo para o poker estimativa. O objetivo do punho de cinco é encontrar rapidamente uma estimativa de consenso de que todos os membros da equipe pode, pelo menos apoio.
Talvez alguns membros da equipe têm dado um requisito a 5, e outros deram-lhe um 8.
Ela começa com o mestre scrum segurando o cartão de exigência em causa e dizendo, por exemplo, “Como confortável você estaria com este como um 8?” Cada membro da equipe de desenvolvimento mantém-se o número de dedos associados ao seu nível de conforto. Se todo mundo está segurando três, quatro ou cinco dedos, está resolvido.
Se alguns desenvolvedores ainda estão segurando-se um ou dois dedos, semelhante à estimativa de poker, os valores atípicos seriam convidados a explicar, e mais informações seria atraído, se necessário. O punho de cinco seria realizada novamente. Continue com esse processo até que todos os membros da equipe pode dar o número, pelo menos a 3 (isto é, “eu não amo ele, mas eu posso apoiá-lo”).
Com o punho de cinco concluído e necessidades estimadas, você está pronto para mover-se para liberar ou planejamento do sprint.