Kanban 2.0 — usando métricas de código para antecipar insights e melhorias do flow.
Vou compartilhar neste artigo, como estamos utilizando uma ferramenta de instrumentação e monitoramento dos Pull Requests, e todos os dados que permeiam o código desde o inicio até o fim da construção de software, para melhorarmos nossas métricas, através de insights antecipados dentro do fluxo de trabalho das equipes. Existem várias ferramentas destas no mercado como Velocity da Code Climate ( esta é a que utilizamos ) e o GitPrime…
Dentro destas ferramentas existem várias informações que ajudam os time de engenharia e os gestores a entenderem possíveis desvios no fluxo de trabalho e definir limites / metas de atuação com os pull requests que refletem diretamente no resultado das entregas, sendo visualizados melhoras no quadro de Kanban inclusive.
No livro do David Anderson, Kanban: Mudança Evolucionaria de Sucesso Para Seu Negocio de Tecnologia, no capitulo 3, receita de sucesso, ele traz um tópico que cita Entregas Frequentes, constroem confiança. Este tipo de ferramenta ajuda a fazer entregas menores e frequentes. No começo do livro ele cita que software com mais qualidade, tem entregas mais frequentes e previsíveis, outro ponto que este tipo de software ajuda a dar visibilidade.
Na Resultados Digitais juntamos os times de engenharia para escolher algumas métricas e estamos trabalhando nesse momento, no monitoramento e na sugestões de ações de melhoria, empoderando os times a usarem os números ao seu favor.
As seguintes métricas foram escolhidas para atuarmos nesse momento (números fictícios):
1- Dias de Codificação na Semana: Utilizamos essa métrica para observar quanto do nosso trabalho do dia a dia está sendo impactado por atividades importantes, porém que não entregam software diretamente, como reuniões da organização, tempo de atendimento e suporte a outras áreas, reuniões do time de planejamento ou acompanhamento. Aqui trabalhamos para reorganizar a agenda do time, conseguindo deixar o time durante toda manhã ou toda a tarde focado. Direcionando as reuniões para algum dia especifico, ou direcionando uma pessoa especifica por semana para realizar os atendimentos externos. Sozinha esta métrica não entrega valor, pois posso codar todo dia, se tiver um volume de retrabalhos alto, não vou entregar valor ao mercado.
2- Tamanho do Pull Request: Já estamos controlando o tamanho dos PR's desde o ano passado, com incrível melhora no flow do time e aumento de tasks entregues pelos time ao longo das semanas, um artigo que aprofundou isso é o do Rodrigo Miguel no seguinte link https://medium.com/rd-shipit/o-tamanho-do-pull-request-%C3%A9-mais-importante-do-que-voc%C3%AA-pensa-a9cd1df2a0b0
3- Ciclos de Review: Este item está relacionado diretamente a qualidade e velocidade. Um time com muitos ciclos de review, provavelmente entrega com mais qualidade, mas o ideal é ter ações que reduzam a quantidade de ciclos de review e que mantenham a qualidade, ou seja antecipando as ações para o momento que o DEV está programando a primeira vez. o Ciclo de Review é contado cada vez que volta para o DEV que iniciou a task fazer correções.
4- PR's Não Revisados: essa é uma métrica simples de qualidade, liberar PR's com aprovação do próprio que fez a task tem alto risco de conter erros ou ocasionar erros em produção, nossa tolerância é zero para este indicador.
5- Cycle Time: Por fim o Cycle time, que é o tempo que a task fica aberta desde o inicio até ser entregue. este indicador é um termômetro para avaliar se o DEV está dedicado a só uma task por vez, se ele inicia e começa a task dentro do período estimado e se os ciclos de review estão eficientes.
Estamos atuando com estas métricas levar o nosso time de engenharia para o próximo nível de maturidade, experiencia e velocidade, acreditamos que o que já está bom pode ficar ainda melhor, tendo entregas e resultados mais rápidos e melhores.
Estas métricas tem relação direta com o Kanban, pois conseguimos ver reflexo de bons números aqui, diretamente no nosso quadro de Kanban, e o contrário também é verdadeiro, além disso com isso conseguimos antecipar e ter insights em tempo de desenvolvimento, sem necessitar esperar a semana ou as tasks finalizarem.
As nossas retrospectivas tem ficado mais ricas, pois tem mais detalhes para observarmos e discutirmos, no que podemos atuar para melhorar o fluxo de trabalho.
Nos próximos meses vou escrever sobre os resultados que estamos colhendo e como estamos atuando para melhorar ainda mais os resultados analisando estas métricas.
Fique ligado.
