No atual cenário de negócios competitivo, no qual os projetos críticos de negócios são cruciais para o progresso sustentável de uma organização, as métricas são fundamentais para medir e acompanhar o progresso do projeto.
Em muitas ocasiões, você participou de um projeto em que não havia rastreamento de dados e era difícil para um gerente de projeto dizer se a equipe estava em andamento ou se era eficiente quando se dava bem com o trabalho.
Além disso, em poucas ocasiões havia dados rastreados desde o início e eram usados como armas para justificar que mais trabalho era obrigatório. Portanto, existe uma relação de amor/ódio quando se trata de métricas ligadas à entrega do projeto.
As métricas ágeis não precisam ser assim. Rastreando e compartilhando métricas ágeis, reduzirá a confusão e fornecerá uma visão geral do progresso e dos contratempos da equipe ao longo do ciclo de vida do projeto.
Entenda o objetivo do negócio:
A "Conclusão do projeto" apresenta apenas metade da imagem, o mais importante é a construção do software/produto certo, no momento certo, para um mercado específico. Manter-se no caminho durante todo o ciclo de vida do projeto significa coletar dados em conjunturas cruciais e analisá-los.
De fato, em qualquer projeto ágil é de extrema importância rastrear e validar as métricas de negócios e as métricas ágeis. Normalmente, aquelas se concentram no fato de o produto estar atendendo às demandas do mercado, enquanto as métricas ágeis tratam de medir os aspectos críticos do processo de desenvolvimento.
Cada iniciativa de projeto/programa no roteiro terá diferentes indicadores chave de desempenho (KPIs) que mapeiam os objetivos do projeto. Além disso, haverá poucos critérios de sucesso para cada um dos requisitos do produto, que incluem a taxa de adoção pelos usuários e a porcentagem de código concluída por testes automatizados/manuais.
Além disso, todos esses critérios de sucesso são usados nas métricas ágeis do projeto. Com isso, as equipes aprenderão mais e estarão mais bem equipadas para se adaptar e evoluir ao longo do ciclo de vida do projeto.
As 5 principais métricas ágeis usadas para otimizar a entrega do projeto:
As métricas ágeis discutidas abaixo se concentram na entrega de software. Independentemente da equipe a que você pertence no Scrum ou no Kanban, essas métricas ágeis ajudarão a equipe a obter uma compreensão abrangente do processo de desenvolvimento e tornar o lançamento muito mais fácil.
Métrica Burndown da Sprint:
As equipes de Scrum trabalham no desenvolvimento por meio de vários sprints. No início destes, a equipe determinará a quantidade de trabalho a acontecer em um determinado sprint. Uma métrica de burndown da sprint ajudará a acompanhar a conclusão do trabalho do sprint. O diagrama abaixo mencionado lhe dará uma ideia clara de como o trabalho previsto será concluído dentro do sprint.
Diagrama Burndown da Sprint
Um Scrum ou uma equipe Kanban que cumpra regularmente sua previsão fornece um claro endosso da capacidade da organização em projetos/programas ágeis. Esse relatório burndown da sprint rastreia a conclusão do trabalho ao longo da sprint e é uma das métricas ágeis comuns usadas.
Você também precisa procurar alguns dos possíveis antipadrões na forma de:
-
- A equipe termina o trabalho logo após cada sprint, porque eles não estão comprometendo o trabalho o suficiente em primeiro lugar;
- Equipe perde sua previsão em cada sprint, porque eles estão se comprometendo com muito trabalho;
- A linha de burndown tem quedas íngremes do que burndown gradual como o trabalho não foi dividido em pedaços granulares;
- Há uma mudança no escopo no meio da sprint.
Métrica Burndown Épico e Release:
Os diagramas burndown épico e de lançamento (ou versão) acompanham o progresso feito sobre o desenvolvimento com grande quantidade de trabalho do que a burndown da sprint.
Como os sprints contêm trabalhos de vários épicos e versões, é de suma importância acompanhar o progresso de ambos os sprints individuais, juntamente com épicos e versões.
A fluência de escopo geralmente acontece em épicos e versões do que em sprints. Se está acontecendo durante sprints, então isso é uma prática ruim.
À medida que a equipe avança no ciclo de vida do projeto, o gerente de projeto pode adicionar ou remover o trabalho, dependendo do que a equipe está aprendendo. Os gráficos épicos e de versão burndown manterão todos em sintonia com o fluxo de trabalho dentro dos épicos e versões.
Você também precisa procurar alguns dos possíveis anti padrões na forma de:
-
- Falha ao atualizar as previsões épicas/de lançamentos regularmente;
- Há pouco ou nenhum progresso feito mesmo após várias iterações;
- Escopo persistente - o proprietário do produto não conseguiu entender o problema;
- O escopo continua crescendo independentemente de a equipe poder ou não absorvê-lo;
- A equipe é incapaz de fornecer liberações incrementais durante o desenvolvimento de épicos.
Velocidade da equipe:
Velocidade em termos ágeis significa a quantidade média de trabalho que uma equipe pode concluir em uma sprint. Ela pode ser medida na forma de pontos da história ou horas e é muito útil para a previsão.
O gerente de projeto ou o proprietário do produto pode usar essa velocidade e determinar a rapidez com que a equipe pode trabalhar em backlog, pois o relatório de velocidade rastreia o trabalho previsto e concluído em várias iterações.
Por exemplo, o proprietário do produto deseja concluir 400 pontos de história no backlog. Através da métrica de velocidade, pode-se supor que a equipe geralmente completa 40 pontos de história em uma única iteração. Assim, o proprietário do produto pode assumir que a equipe pode precisar de cerca de 10 iterações para concluir o backlog.
A velocidade é errática por um longo período, se apega às práticas de estimativa da equipe e aborda a mesma em uma reunião retrospectiva, fazendo algumas perguntas importantes como:
-
- Existe uma pressão inerente ao negócio que estica a equipe além de seus limites?
- Houve algum desafio imprevisto, que não consideramos durante a estimativa?
- Estamos sendo otimistas demais ao prever o sprint?
A última coisa que você gostaria de fazer é comparar diferentes equipes e sua velocidade. Cada equipe é única e sua velocidade também. Por exemplo, se a equipe A tiver uma velocidade de 40 e a equipe B tiver 60, isso não significa que o time B tenha um rendimento maior.
Cada equipe tem uma cultura de estimativa única e sua velocidade será também. Meça a velocidade da equipe determinando o esforço e a saída e sua representação dos pontos da história.
Usando gráficos de controle:
Na métrica ágil, gráficos de controle de desenvolvimento são usados para determinar o tempo de ciclo dos problemas – do status “em andamento” até o status “concluído”. Equipes ágeis com tempos de ciclo mais curtos terão um resultado maior e equipes com tempos de ciclo consistentes terão uma entrega de trabalho previsível.
A medição desses tempos de ciclo é uma maneira de melhorar os processos de trabalho da equipe, pois as mudanças são visíveis quase que imediatamente, o que ajudará a equipe a fazer ajustes imediatamente. O objetivo final é ter tempos de ciclo consistentes e curtos, independentemente do tipo de trabalho.
Diagrama de controle de gráficos
Você pode achar que os gráficos de controle são irregulares no começo. No entanto, você precisa procurar tendências e duas áreas principais a serem observadas:
-
- Aumentando o tempo de ciclo: Se houver um aumento no tempo de ciclo, isso enfraquece totalmente a equipe de sua agilidade suada. Durante a reunião retrospectiva, tente entender o aumento. Há uma exceção, porém, onde a definição da equipe de “concluído” foi expandida, então o tempo de ciclo também se expandirá;
- Tempo de ciclo irregular: como proprietário de um produto, se você estiver encontrando tempos de ciclo inconsistentes para pontos de história semelhantes (seja pequeno ou grande), gaste tempo em retrospectiva para examinar a causa raiz e melhorar as estimativas futuras.
Diagrama de Fluxo Cumulativo:
Este diagrama de fluxo cumulativo é um recurso crítico para equipes Kanban do que para equipes scrum. Esse diagrama ajudará a garantir que o fluxo de trabalho na equipe seja uniforme.
No diagrama abaixo, o número de problemas está no eixo Y e o tempo está no eixo X, além de que as cores diferentes indicam vários estados do fluxo de trabalho, o qual aponta as deficiências e os gargalos com relação aos limites de “trabalho em andamento”.
Todo o diagrama deve parecer suave da esquerda para a direita. Se houver alguma lacuna ou bolha em qualquer cor, há gargalos e escassez. Então, procure maneiras de suavizar as faixas de cores no gráfico.
Diagrama de Fluxo Cumulativo
Você também precisa procurar alguns dos possíveis antipadrões na forma de:
-
- Ao bloquear problemas, cria grandes backups em algumas partes e nada nos outros;
- Crescimento do backlog que não é atendido. Isso geralmente acontece quando os proprietários de produtos não encerram problemas desatualizados ou de baixa prioridade.
Todas essas métricas, juntamente com o gerenciamento ágil de projetos, ajudam a construir a cultura de uma equipe. Eles fornecem os insights certos sobre o desempenho de uma equipe e os ajudam a fornecer metas mensuráveis. No entanto, não fique obcecado com métricas, pois ouvir sua equipe durante as retrospectivas é igualmente importante para entender os problemas do mundo real. Isso cria confiança e ajuda a equipe a obter melhor qualidade e ser mais produtiva em sprints, épicos e versões durante a entrega do projeto.
