Métricas em Projetos Ágeis
Para inicio de conversa, vamos observar que existem dois tipos de Métricas em Projetos Ágeis, as métricas de Negócios e as Métricas de Projetos.
1 – Métricas em Projetos Ágeis: Métricas de Negócios
Em suma, elas devem ser compreensíveis e ser uma relação. Ou seja, serem representadas por razões ou taxas. Dessa forma, serão comparativas, e por tanto, auxiliarão a tomar melhores decisões.
Elas ajudarão o time quando estiverem discutindo sobre priorização para a solução. Ou seja, ajudarão a identificar quais funcionalidades trarão mais resultados para o negócio,
Ex: Retorno sobre o investimento (ROI), Custo de atraso, Potencial de geração de Receita ou Potencial Geração de Economia, criticidade para o negócio etc
Qualitativas
Em síntese, é normalmente originadas de conversas com clientes, e elas geram informações sobre percepção, interesse e motivações.
Ex: Desejo de Crescimento de usuários ativos diários.
Quantitativas
Em conclusão, agora que você já descobriu métricas qualitativamente, você deverá prova-las quantitativamente.
Ex: Ao desenvolver uma determinada funcionalidade, podemos trazer uma tendências de crescimento na porcentagem de usuários ativos diários,
2 – Métricas em Projetos Ágeis: Métricas de Projetos
WIP (Work in Progress)
O WIP é definido para criar limites explícitos da quantidade máxima, de itens de trabalho, que estarão em progresso. Isso pode ser por etapa ou pelo fluxo de trabalho como um todo.
Assim, o WIP representa o esforço e energia que ainda não foram validadas, pois estão no meio do processo. Quanto mais tempo no WIP, menos feedback o projeto estará recebendo. Assim, mais lento o processo de validação das hipóteses, correndo risco de perder oportunidades de mercado.
Desmistificando um Paradigma:
Com o framework SCRUM, o time pode trabalhar com todas as demandas do Sprint Backlog ao mesmo tempo sim. Mas como assim? E a limitação do WIP?
Meus amigos, cada Sprint tem um escopo e tempo fixo. Esse é o limite implícito de trabalho, esse é o WIP no SCRUM. Ele esta limitando o fluxo de trabalho como um todo por Sprint.
O SCRUM limita o WIP indiretamente por unidade de tempo, diferente do KANBAN que limita diretamente por etapa do fluxo de trabalho.
Mas, usando o Scrum, se achar necessário, podemos sim limitar ainda mais o WIP conforme o método KANBAN. Ou seja, alem de limitar o fluxo de trabalho como um todo por tempo, pode-se limitar também por etapa.
De antemão, informo que, o limite do WIP de uma etapa não é o total de pessoas que trabalharão nela. Pois em algum momento, algum membro do time pode precisar parar o que esta fazendo. Pois, existirão demandas de maior prioridade, que precisarão de ajuda.
Lembre-se: Pare de começar e comece a terminar
Antecipadamente, informo que, não existe uma fórmula mágica para se definir o quanto um time pode processar em um sistema de trabalho, como um todo ou em partes. Enfim, a literatura no assunto é limitada.
Então amigos, assim como no SCRUM, usamos o empirismo, a melhor forma de limitar o WIP, também é usando o empirismo segundo Brodzinski 2009.
Ou seja, “teste e adeque”, Redefina o WIP se for preciso, após o monitoramento da média do número de itens que passam por cada etapa do processo, durante algumas semanas ou Sprints.
Quanto mais trabalho colocamos no fluxo de desenvolvimento do time, menor será a qualidade. E não sou eu quem esta dizendo, é o David Anderson.
Limitar o WIP, pode resultar a não inclusão de novas demandas no fluxo de desenvolvimento, o que pode levar a ter membros ociosos na equipe.
O WIP é como um inventário em um armazém, quanto mais você o carrega, mas difícil será para responder as mudanças, pois todos estarão muito ocupados.
Logo, estimule os membros do time, a entenderem que, eles não estão parados. Eles estão com tempo e aptos a colocar o esforço disponível, em algum lugar que necessita de apoio.
O desafio aqui são os stakeholders, que ficam no pé do Scrum Master, achando isso ou aquilo.
WIP (Work in Progress) = Total de itens que podem ficar em andamento na coluna, é o limite de capacidade de trabalho.
WIP aumentando = excesso de itens em aberto.
Antes de querer ir para as próxima etapas e tirar conclusões com as métricas Lead time ou Throughput, verifique a eficiência do seu fluxo. Tem espaço para melhorias? O processo esta estável? Se sim, siga adiante.
Lead time
Quando chegar a hora de analisar Lead time, a dica é: não usar a média, use a Mediana, Percentil 75 e Percentil 95 . A média, pode por vezes, não ser uma boa referência, pois seu valor pode ser distorcido por discrepâncias. A mediana é menos sensível a casos extremos.
Lead time alto = Podem ser demandas mal definidas. Podem ser demandas complexas, que deveriam ter sido melhor quebradas. Ou ter gargalo em alguma etapa do processo.
Dica: Quando partimos a incerteza, quebrando User Stories, estamos reduzindo riscos, o que de fato é entrega de valor.
Lead Time = A diferença entre o momento que a tarefa é considerada “em progresso” até o momento que ela entra em seu estado final.
Throughput
Assim como foi dito anteriormente, quando chegar a hora de analisar o Throughput, fica a mesma dica: não usar a média. Use a Mediana, Percentil 75 e Percentil 95 . A média, pode por vezes ,não ser uma boa referência, pois seu valor pode ser distorcido por discrepâncias. A mediana é menos sensível a casos extremos.
Outra dica: Analisar o Throughput por tipo de demanda: Bug, Stories, Melhorias técnicas etc.
Throughput = Quantidade média de itens que ficam prontos num período de tempo (semanas/meses)
Throughput baixo = falta de cadência de entrega.
Gráfico CDF (Cumulative Flow Diagram)
Esse gráfico mostra, o quanto de trabalho foi realizado (throughput ), em determinado tempo (Leadtime). O quanto de trabalho esta em progresso (WIP) e o quanto de trabalho ainda precisa ser feito.
Frequentemente, conseguiremos visualizar potencias ou reais problemas. Um exemplo, é quando ele mostra uma alta variabilidade no Lead time na etapa de codificação.
Gráfico de Burnup
Enfim, esse gráfico mostra o total de Histórias de usuários previstas no escopo, e o número de Histórias de usuários entregues.
A diferença desse gráfico para o BurnDown, é que nesse conseguimos dar transparência caso aconteça algum aumento de escopo. Conseguimos identificar e tratar. Em fim, na vida real, aparecem demandas emergenciais e coisas não previstas.
OBS: No inicio do projeto é normal que o escopo cresça, a equipe ainda esta se familiarizando com o produto a ser construído, após isso não.
Eu confesso que sempre usei o gráfico de BurnDown, mas, a primeira vista, eu estou vendo mais valor no Burnup. Vou analisar se na prática isso se confirmará.
Fonte: Livro Métricas Ágeis de Raphael Albino
Informações sobre a autora: Jacqueline Viana é Scrum Master e é apaixonada por agilidade.
