Existem algumas diretrizes simples para estimar a velocidade inicial da sua equipe Scrum antes da conclusão da primeira iteração (veja as perguntas frequentes abaixo), mas, após esse ponto, você deve usar métricas históricas comprovadas para o planejamento de funcionalidades. Em pouco tempo, a velocidade normalmente se estabiliza e fornece uma base sólida para melhorar a precisão e a confiabilidade do planejamento de curto e longo prazo dos seus projetos Agile. Entrega ágil Os ciclos são muito curtos, portanto a velocidade surge rapidamente e pode ser validada logo no início de um projeto, podendo então ser utilizada para melhorar a previsibilidade do projeto.
Será que a velocidade é realmente tão simples assim?
SimNão tente complicar demais a velocidade – na verdade, é um conceito simples e grande parte do seu valor reside justamente nessa simplicidade. Muitos gerentes e equipes que estão começando a trabalhar com velocidade podem se sentir perdidos. métodos Agile As pessoas tendem a analisar demais o conceito de velocidade e a criar muita complexidade em torno dele. Depois de alguns meses de experiência com projetos Agile, a maioria terá um momento de "eureka" com a velocidade, livrando-se de qualquer preconceito que tenham associado a ela e apreciando sua simplicidade e valor intrínseco.
Gráficos de velocidade
Juntamente com os gráficos de burndown de releases e iterações, medir a velocidade das equipes Agile tem se mostrado uma ferramenta valiosa para fornecer insights e visibilidade sobre o progresso e o status do projeto. Um gráfico de velocidade mostra a soma das estimativas do trabalho entregue em todas as iterações. Normalmente, a velocidade se estabiliza ao longo da vida útil de um projeto, a menos que a composição da equipe varie significativamente ou a duração da iteração se altere. Dessa forma, a velocidade pode ser usada para planejamento futuro. Embora geralmente seja confiável para algumas iterações à frente, se considerarmos que prioridades, objetivos e equipes podem mudar com o tempo e, consequentemente, o nível de confiança em uma iteração futura também, a velocidade pode ser usada para planejar releases com muito mais antecedência.
Inicialmente, equipes que estão começando a usar o desenvolvimento ágil de software devem simplesmente mergulhar de cabeça e selecionar uma velocidade inicial usando as diretrizes e informações disponíveis. Rapidamente (já na próxima iteração), a velocidade pode ser medida e ajustada. A velocidade, juntamente com funcionalidades detalhadas (como histórias de usuário, backlog, requisitos etc.) e estimativas de alto nível e/ou relativas (em termos de pontos, dias ideais ou até mesmo horas), simplifica e acelera enormemente todo o processo de planejamento, estimativa, acompanhamento do status e geração de relatórios do projeto.
Perguntas frequentes sobre Agile Scrum
Como é a velocidade de um desenvolvimento ágil a equipe calculou?
A velocidade é a soma das estimativas de funcionalidades entregues (ou seja, aceitas) por iteração.
Qual unidade é usada para medir a velocidade?
A velocidade é medida nas mesmas unidades que as estimativas de funcionalidades, sejam elas pontos de história, dias, dias ideais ou horas que a equipe Scrum entrega – todas consideradas aceitáveis.
Como é estimada a velocidade da primeira iteração?
Para a primeira iteração de uma equipe ágil, uma diretriz geral é planejar a velocidade inicial em um terço do tempo disponível. Se você estiver estimando o tempo ideal de um programador, isso inclui reuniões, e-mails, design, documentação, retrabalho, colaboração, pesquisa, etc. Por exemplo, com seis programadores e iterações de duas semanas, um total de 60 dias de programador (6 programadores x 10 dias) estão disponíveis. Nessa situação, um bom ponto de partida seria planejar o equivalente a 20 dias ideais de trabalho na iteração. Se estiver usando o tempo real, inclua uma margem de segurança suficiente para compensar 1) a sobrecarga padrão do projeto e 2) a imprecisão da estimativa. Além disso, lembre-se de que a velocidade surgirá rapidamente durante a primeira iteração. Se subestimada, a velocidade na primeira iteração aumentará à medida que novos recursos forem incluídos; e se superestimada, a velocidade diminuirá à medida que recursos forem removidos. Para a segunda iteração, a equipe Scrum deve usar a primeira iteração como referência.
Reuniões, telefonemas e e-mails são incluídos no cálculo da velocidade de processamento?
Isso depende se esses itens são estimados e incluídos no planos de iteraçãoNormalmente, não são incluídos – um dos objetivos da velocidade é a consistência e previsibilidade relativas entre as iterações em termos da capacidade de uma equipe ágil de entregar resultados.
A velocidade deve ser acumulada em todas as equipes ou projetos de desenvolvimento ágil?
A velocidade é uma medida bastante localizada. Além dos diferentes membros da equipe com suas "personalidades", os projetos normalmente possuem características únicas em termos de técnicas de estimativa, processos detalhados, tecnologia, envolvimento do cliente, etc. Como resultado, isso pode tornar a análise em toda a organização muito imprecisa. Se, por outro lado, todas as suas equipes estimam exatamente da mesma forma, desenvolvem exatamente da mesma forma, testam exatamente da mesma forma e monitoram exatamente da mesma forma, então, sem dúvida, vocês são a exceção.
E se a velocidade oscilar?
A velocidade normalmente flutua dentro de uma faixa razoável, o que é perfeitamente normal. Se a velocidade flutuar muito por mais de uma ou duas iterações, a equipe Scrum pode precisar reestimar e/ou renegociar o cronograma. plano de lançamento.
Quanto tempo leva para a velocidade se estabilizar?
Para a maioria das equipes de desenvolvimento ágil, a velocidade normalmente se estabiliza entre 3 e 6 iterações.
Como faço para estimar as iterações futuras?
As iterações futuras utilizam o histórico comprovado da equipe para determinar o quanto ela é capaz de realizar. Portanto, a velocidade é a métrica adequada para o planejamento de iterações futuras.
Como posso estimar a velocidade se as equipes do projeto mudarem de tamanho?
A velocidade depende da consistência da equipe para ser mais eficaz. Se sua equipe ágil sofrer alterações, use o bom senso ao planejar as iterações futuras. Se 20% da sua equipe estiver indisponível por algumas iterações, reduza a velocidade planejada em cerca de 20%. Se isso incluir alguns membros-chave da equipe, em particular um cliente que possa estar menos disponível, reduza a estimativa um pouco mais. Bastará a duração da próxima iteração para entender melhor o que a equipe pode entregar e, consequentemente, sua nova velocidade.
Velocidade máxima significa produtividade máxima?
Absolutamente não. Na tentativa de maximizar a velocidade, uma equipe pode, na verdade, alcançar o oposto. Se solicitada a maximizar a velocidade, uma equipe pode negligenciar os testes unitários ou de aceitação, reduzir a colaboração com o cliente, deixar de corrigir bugs, minimizar a refatoração ou muitos outros benefícios importantes das diversas práticas de desenvolvimento ágil. Embora possa oferecer uma melhoria a curto prazo (se é que podemos chamar assim), haverá um impacto negativo a longo prazo. O objetivo não é a velocidade máxima, mas sim a velocidade ideal ao longo do tempo, que leva em consideração muitos fatores, incluindo a qualidade do produto final.
Como podemos medir a velocidade se o comprimento de nossas iterações mudar?
Não, pelo menos não tão facilmente. O valor da velocidade reside na sua consistência inerente. Uma duração fixa para cada iteração ajuda a impulsionar o ritmo confiável de um projeto. Sem esse ritmo, você está constantemente revisando, reestimando e conciliando, e a capacidade de prever o futuro é minimizada devido a resultados inconsistentes. Se, por outro lado, quase todos estiverem de folga por uma semana devido aos feriados ou por alguns dias para reuniões da empresa, então, sem dúvida, basta usar o bom senso e adaptar as datas das iterações ou a velocidade de acordo. Como a maioria das práticas Agile, estas são diretrizes, não regras.
