Gerando métricas ágeis a partir de informações do Jira
A CWI vem incentivando fortemente o uso de métricas ágeis em seus projetos e elas estão permeando cada vez mais a cultura da empresa. Primeiramente é importante deixar claro que as métricas ágeis não são ou não devem ser utilizadas para controle e microgerenciamento, mas sim visando a previsibilidade, visibilidade, identificação de gargalos e oportunidades de melhoria em seus projetos e times. Pensando nisso, a CWI selecionou um conjunto de métricas recomendadas, das quais destacamos um conjunto como foco nesse artigo.
As métricas citadas no artigo foram extraídas com informações do Jira Server (uma solução auto gerenciada da ferramenta) e o framework utilizado é o Scrum.
Todas as métricas que falaremos neste artigo, são geradas diretamente no Jira ou no Excel a partir de dados exportados pela ferramenta, a integração direta do Excel com o Jira não está disponível para o Jira Server.
As métricas abaixo, fazem parte de um conjunto sugerido pela CWI, mas que são justificadas a partir da necessidade de tomar uma decisão. No cenário em que foram utilizadas, os objetivos eram acompanhar a assertividade das estimativas, melhoria de qualidade e produtividade, são elas:
- Previsto x Realizado
- Quantidade de defeitos em homologação
- Quantidade de defeitos em produção
- Taxa de entrega de atividades por período (Througput)
- CFD
Configuração do Jira
A configuração do Jira pode variar de acordo com a necessidade do processo, não existe uma “receita de bolo” e é importante ter isso em mente. A configuração a seguir foi utilizada em um cliente. No entanto, para que as informações geradas estejam corretas, alguns pontos devem ser considerados:
- Unidade de medida — Considerada estimativa de esforço em horas para todas as Issue Types.
- Throughput — As issues somente são consideradas como entregue, após atenderem os itens previstos no DoD (O que é "Definition of Done" DOD), dessa forma transitam para a etapa final do fluxo “Done”, esta etapa agrupa itens em ambos status “Teste M3” e “Done” para o fluxo de valor do cliente. Itens entregues em homologação (Test M3) já podem ser considerados concluídos e contabilizados no throughput, bem como itens parcialmente construídos não contabilizam.
- Planejamento — Ao planejar uma atividade é considerado a estimativa total do item, mesmo que já iniciado na Sprint anterior, dessa forma é possível garantir que somente itens concluídos sejam considerados no throughput, contabilizando somente na Sprint em que foram finalizados.
Na imagem acima, que apesar da estimativa estar configurada para contabilizar a partir do tempo original estimado, também foi habilitado o Time Tracking baseado no tempo restante, isso habilita um burndown adicional que é sensibilizado conforme o time vai evoluindo na(s) atividade(s), mas isso pode ser material para outro artigo.
Workflow
Apesar de estarmos utilizado o Scrum, o workflow completo emprega o conceito de upstream e downstream oriundo do Kanban para a representação do seu lead time, porém neste artigo iremos focar somente no downstream para a extração das métricas.
Abaixo o fluxo de trabalho completo:
Board Downstream
Conforme citado acima, a parte do fluxo que as métricas são extraídas é visível em “Downstream Cycle Time”, o mesmo pode ser visto mais detalhadamente em “Sprint Backlog”, onde é demonstrado o fluxo por tipo de item. De acordo com o detalhamento acima, considere:
- Story: principal issue type do workflow, representa entregas de valor para o negócio e considera fortemente o conceito de INVEST (Como escrever as melhores User Stories com INVEST), passa integralmente por todas as etapas do fluxo e é liberado pelo PO, responsável pela homologação.
- Task: issue type criada para itens que não trazem diretamente valor para o negócio, nesse caso os itens são liberados diretamente em homologação (Test M3);
- Bug Versão: bugs abertos e fechados dentro da própria Sprint;
- Bug HML: bugs identificados no ambiente de homologação, originados a partir de uma Story ou Task já consideradas entregue ao cliente. Estes são estimados e incluídos no Sprint Backlog.
Jira Query Language (JQL)
A forma mais eficaz de extrair informações do Jira é a partir de uma JQL, portanto para cada métrica é necessário uma ou mais JQL’s. Existem também plugins para o Excel e Google Sheets que integram diretamente com o Jira.
Previsto x Realizado
Visando demonstrar a eficiência em estimativas e entregas, esta métrica baseia-se em comparar duas série de dados, estimativas originais (original estimate) e tempo gasto (time spent), para o cálculo de estimativas originais considera-se somente o próprio item, porém para o cálculo de tempo gasto, é necessário computar todos os bugs gerados, pois eles fazem parte do esforço desprendido para a conclusão do item.
Abaixo, uma visão agrupada por sprints, mostrando a evolução de 2020 a 2022
Outras visões também podem ser facilmente geradas utilizando o mesmo conjunto de informações de origem, ex.: mensalmente, por componente e por épico.
Quantidade de defeitos por ambiente
Gerado em visões de quantidade e esforço, é possível configurar de acordo com o ano, ambiente e período desejado. Este gráfico já satisfaz duas métricas técnicas citadas na introdução, "Quantidade de defeitos em homologação" e "Quantidade de defeitos em produção", além de também exibir defeitos encontrados durante a etapa de desenvolvimento.
Taxa de entrega de atividades por período (Througput)
O Througput tem o objetivo de demonstrar o rendimento a partir do número de itens concluídos por unidade de tempo. No gráfico abaixo, foi gerada uma visão da taxa mensal, dos anos de 2020, 2021 e 2022 (parcial). Essa visão pode ter o período ajustado para uma melhor visualização.
Diagrama de Fluxo cumulativo (CFD)
O CFD (cumulative flow diagram) é gerado pelo próprio Jira e nesta visão está considerando o fluxo completo, upstream e downstream, compreendendo o período que os itens integram o backlog do produto até sua liberação em produção.
Além de possibilitar identificação de riscos e impedimentos, o CFD também fornece outros indicadores, como throughput, cycle time, lead time e work in progress.
Conclusão
As métricas no Jira, podem ser facilmente exibidas em diversas visões e de acordo com a necessidade, já para as métricas que precisam ser geradas externamente, basta salvar a JQL utilizada para a geração do relatório e este pode ser exportado em forma de arquivo sempre que se desejar métricas atualizadas. No caso do Jira Cloud, o Excel pode ler diretamente a JQL.
A geração e análise das métricas no projeto em questão, possibilitou identificar algumas deficiências e trabalhar algumas ações, onde por meio da melhoria contínua se obteve um significativo aumento da maturidade do time, resultando em melhor assertividade das estimativas e aumento de qualidade e produtividade nas entregas.
No próximo artigo, será demonstrado como integrar o Excel diretamente com o Jira Cloud.
Gostou do artigo? Me procure e vamos falar sobre outras métricas que podem ser geradas diretamente pelo Jira.
