Existem algumas diretrizes simples para estimar a velocidade inicial de sua equipe scrum antes de concluir a primeira iteração (consulte as perguntas frequentes abaixo), mas depois desse ponto você deve usar medidas históricas comprovadas para recursos de planejamento. Dentro de um curto período de tempo, a velocidade normalmente se estabiliza e fornece uma excelente base para melhorar a precisão e a confiabilidade do planejamento de curto prazo e de longo prazo de seus projetos Agile. Os ciclos de entrega ágil são muito pequenos, então a velocidade surge rapidamente e pode ser validada muito cedo em um projeto e, em seguida, usada para melhorar a previsibilidade do projeto.
A velocidade é assim tão simples?
Sim. Não tente não complicar demais a velocidade – é realmente um conceito simples e grande parte do seu valor reside na sua simplicidade inerente. Muitos gerentes e equipes novos métodos Agile tendem a analisar demais o conceito de velocidade e a acumular muita complexidade em torno dele. Depois de alguns meses de experiência em projetos Agile, a maioria das pessoas experimentará um momento “ah ha” com velocidade, descartando qualquer bagagem associada a ele e apreciando sua simplicidade e valor intrínseco.
Gráficos de velocidade
Juntamente com release e gráficos de burndown de iteração, medindo a velocidade das equipes Agile provou fornecer uma visão/visibilidade tremenda 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 estabilizará ao longo da vida de um projeto, a menos que a composição da equipe do projeto varie muito ou a duração da iteração mude. Como tal, a velocidade pode ser usada para fins de planejamento futuro. Embora normalmente confiável para algumas iterações, se você aceitar que as prioridades, metas e equipes podem mudar com o tempo e, portanto, o nível de confiança de uma iteração no futuro distante, a velocidade pode ser usada para planejar releaseestá muito mais longe no futuro.
Inicialmente, as equipes novas no desenvolvimento ágil de software devem apenas mergulhar e selecionar uma velocidade inicial usando as diretrizes e informações disponíveis. Muito rapidamente (tão rápido quanto na próxima iteração), a velocidade pode ser medida e ajustada. A velocidade, juntamente com recursos granulares (por exemplo, histórias de usuários, lista de pendências, requisitos, etc.) e estimativa de alto nível e/ou relativa (em termos de pontos, dias ideais ou mesmo horas), simplifica e acelera tremendamente todo o planejamento do projeto , estimativa, rastreamento de status e processo de geração de relatórios.
Perguntas frequentes do Agile Scrum
Como é a velocidade de um desenvolvimento ágil equipe calculou?
A velocidade é a soma das estimativas de recursos entregues (isto é, aceitos) por iteração.
Que unidade é usada para medir a velocidade?
A velocidade é medida nas mesmas unidades que as estimativas de recursos, sejam pontos de história, dias, dias ideais ou horas que a equipe de scrum entrega – todos considerados aceitáveis.
Como a velocidade da primeira iteração é estimada?
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ê está estimando o tempo ideal do programador, isso leva em consideração reuniões, e-mail, 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 x10 dias) estão disponíveis. Nessa situação, um bom começo seria planejar 20 dias ideais de trabalho na iteração. Se estiver usando o tempo real, inclua um buffer suficiente para contabilizar o projeto padrão 1) sobrecarga e 2) 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 os recursos forem removidos. Para a segunda iteração, a equipe scrum deve usar a primeira iteração como diretriz.
Reuniões, telefonemas, e-mail são incluídos na velocidade?
Isso depende se esses itens são estimados e incluídos no planos de iteração. Eles normalmente não são incluídos – uma meta de velocidade é a relativa consistência e previsibilidade entre as iterações em termos da capacidade de entrega de uma equipe ágil.
A velocidade deve ser acumulada em todas as equipes ou projetos de desenvolvimento ágil?
A velocidade é uma medida muito localizada. Além de diferentes membros da equipe com diferentes “personalidades”, os projetos geralmente possuem características únicas em termos de técnicas de estimativa, processo detalhado, 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 o mesmo, desenvolvem exatamente o mesmo, testam exatamente o mesmo e monitoram exatamente o mesmo, então talvez você seja a exceção.
E se a velocidade flutuar?
A velocidade normalmente flutua dentro de uma faixa razoável, o que é perfeitamente aceitável. Se a velocidade flutuar amplamente por mais de uma ou duas iterações, a equipe scrum pode precisar reestimar e/ou renegociar o release plano.
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 iterações futuras?
As iterações futuras usam o histórico comprovado da equipe para determinar o quanto a equipe pode fazer. Portanto, a velocidade é a medida certa a ser usada para planejar iterações futuras.
Como faço para estimar a velocidade se as equipes de projeto mudarem de tamanho?
A velocidade depende da consistência da equipe para ser mais valiosa. Se sua equipe ágil mudar, use o bom senso ao planejar iterações futuras. Se 20% de sua equipe estiver indisponível por algumas iterações, reduza a velocidade planejada em 20% ou mais. Se isso incluir alguns participantes importantes, em particular um cliente que pode estar menos disponível, reduza a estimativa um pouco mais. Levará apenas a duração da próxima iteração para entender melhor o que a equipe pode oferecer e, portanto, sua nova velocidade.
Velocidade máxima significa produtividade máxima?
Absolutamente não. Na tentativa de maximizar a velocidade, uma equipe pode, de fato, conseguir o oposto. Se solicitado a maximizar a velocidade, uma equipe pode economizar em testes de unidade ou aceitação, reduzir a colaboração do cliente, pular a correção de bugs, minimizar a refatoração ou muitos outros benefícios importantes das várias práticas de desenvolvimento ágil. Embora potencialmente ofereça melhorias a curto prazo (se é que você pode chamar assim), haverá um impacto negativo a longo prazo. O objetivo não é a velocidade maximizada, mas sim a velocidade ideal ao longo do tempo, que leva em consideração muitos fatores, incluindo a qualidade do produto final.
Como medimos a velocidade se nossos comprimentos de iteração mudam?
Você não, pelo menos não tão facilmente. O valor do Velocity vem de sua consistência inerente. Um comprimento de iteração fixo ajuda a conduzir o ritmo confiável de um projeto. Sem esse ritmo, você está constantemente revisando, reestimando e reconciliando, e a capacidade de prever o futuro é minimizada devido a resultados inconsistentes. Se, por outro lado, quase todo mundo vai ficar fora uma semana para os feriados ou alguns dias para reuniões em toda a empresa, então simplesmente use o bom senso e adapte as datas de iteração ou a velocidade de acordo. Como a maioria das práticas Agile, essas são diretrizes, não regras.
