Processo
Tome decisões baseadas em dados para melhoria contínua
5 minutos de leitura
W.E Deming, professor e estatístico norte americano, disse em uma de suas frases célebres que “se algo não pode ser medido, então não pode ser gerenciado”. Quando trabalhamos em um time ágil, somos (ou deveríamos ser) obcecados pela melhoria contínua do time e, para sabermos as áreas prioritárias onde precisamos realizar esforços de melhoria, precisamos ter uma boa base de dados para embasar nossas decisões e concentrar nossa dedicação.
Adotamos há alguns meses, em um time de desenvolvimento, algumas métricas ágeis com objetivo de termos uma visão realista baseada em números do nosso processo de desenvolvimento, dentre as quais destacam-se as métricas abaixo:
WIP (Work In Progress): Média da quantidade total de itens que estão sendo processados em paralelo no seu sistema em um período de tempo.
Tempo de Ciclo (Cycle Time): Tempo médio em que um item de trabalho leva para passar pelo sistema desde o início do desenvolvimento até sua entrega para o cliente.
Throughput (Vazão): Quantidade média de itens que saíram do sistema em um determinado período de tempo.
WIP: Trabalho em progresso
Após alguns meses alimentando nossa base de dados estatística, notamos alguns padrões que afetam significativamente nosso time. Vamos iniciar pelo nosso trabalho em progresso, conforme imagem abaixo:
Vejam que o gráfico mostra que nossa quantidade diária de trabalho em progresso sempre esteve acima de 50 itens/dia. Se tivéssemos uma equipe de mais de 50 pessoas talvez isso não fosse um problema, porém somos uma equipe de 16 pessoas, o que representa, certamente, mais de 4 itens por pessoa em média! Diversos estudos apontam os problemas do paralelismo e o quanto são prejudiciais em equipes de software¹, devido à perda de foco e as trocas de contexto, perdendo produtividade do time. Mas por que isso acontece? Vamos analisar mais alguns dados para se ter uma visão mais clara do problema…
Heat Map: Visualização de itens por estágio de processo
Se sabemos a quantidade de itens que temos por dia em determinado estágio do nosso processo de desenvolvimento, podemos monitorar se estamos tendo algum gargalo no nosso fluxo, ou seja, onde temos itens que ficam parados em algum estágio fazendo subir nosso WIP. Veja o gráfico abaixo, chamado de Heat Map:
É possível perceber com clareza que a área roxa (Ready To Version-QA) e a área verde oliva (Ready-QA) criavam uma barriga justamente no período onde tínhamos o WIP mais alto! Obviamente esses itens parados são um problema, pois além de com o tempo perderem seu valor, impedem o prosseguimento dos testes e ainda atrapalham o foco do time.
Após análise dos itens que estavam parados, o time verificou que se tratava de um projeto que estava sendo desenvolvido em paralelo, e como tínhamos apenas um ambiente de testes, não era possível colocá-los juntos com outras demandas desenvolvidas, deixando-os aguardando a liberação das demais demandas para serem testados. Com essa informação em mãos, o time é capaz de decidir as ações para resolver o problema, seja criando um novo ambiente de testes, revendo o Git Flow, ou até mesmo remanejando as demandas! Mas isso ainda não explica por completo nosso alto WIP, não é mesmo?
Throughput e Taxa de Entrada
Vamos analisar mais dois gráficos que representam duas métricas ágeis, throughput e taxa de entrada de itens:
Com esse gráfico conseguimos saber nossa mediana de quantos itens de backlog são criados por dia em um período de meses. Nossa mediana é de 3,38 novos itens por dia.
Mediana é o valor que separa um conjunto de dados ao meio. Optamos por usá-la para não termos os dados influenciados por outliers (valores muito discrepantes dos demais) e assim ter dados mais fidedignos.
Analisando o gráfico de throughput, percebemos que nossa mediana é de 2,86 itens entregues/dia. Se compararmos com a taxa de entrada, temos 0,52 itens a mais no nosso backlog por dia. Com esses dados em mãos, podemos perceber que o nosso processo de desenvolvimento se encontra pressionado acima da capacidade de entrega. Dado que temos problemas de gargalos e que criamos mais backlog do que entregamos, é fácil perceber que o time “puxa” mais trabalho do que é capaz de processar, além de pouca eficiência em remover itens bloqueados no processo. Limitando nosso trabalho em progresso (WIP), poderíamos ter muitos benefícios, pois diminuindo nossos gargalos, teríamos um time mais focado, uma cadência mais estável e com isso, como Dr. John Little demonstrou em seus estudos sobre filas e a famosa “Lei de Little”, teríamos uma diminuição no tempo médio que os itens passam pelo nosso processo até chegar em produção (Lead Time). Quem sabe adotamos o Kanban então em que uma das prescrições é limitar o progresso?
A Lei de Little resumidamente diz que as três variáveis Lead Time, WIP e Throughput tem uma forte correlação e em um sistema estável, alterando qualquer uma dessas variáveis, impactará nas outras duas.
Cycle Time
Para finalizar, vamos mostrar como ficou nosso tempo de ciclo ao longo dos meses:
Percebam que existe uma alta variação do tempo de ciclo do time, demonstrando um processo instável (com muitos gargalos) e que nos meses de agosto, setembro e outubro há um aumento alto de tempo de ciclo. Isso se deve ao fato de que esses meses foram os meses com o maior WIP do período, impactando diretamente nessa métrica — já ouviu falar na Lei de Little?
O que aproveitamos disso tudo?
Com os dados em mãos, conseguimos planejar várias ações para o time:
· Rever nosso gitflow, tornando mais flexível nossos deploys nos ambientes e diminuindo os gargalos;
· Criação de um novo ambiente de testes;
· Treinar e conscientizar o time para uso do Kanban;
· Limitar o trabalho em progresso;
· Melhorar nossa engenharia e arquitetura para deixá-la mais ágil.
Conclusão
Como mostrado acima, é perceptível o quão benéfico é para um time ágil a extração e monitoramento de métricas ágeis para o bom funcionamento e auxílio à melhoria contínua. O uso de métricas ágeis permitem os times terem uma visão clara dos problemas que impedem a produtividade, além de dar insights baseados em dados e não apenas em “achismos”, que muitas vezes acabam guiando o time para atacar problemas inexistentes ou menos prioritários, devido a visão distorcida dos fatos. Vamos usar mais métricas ágeis e monitorar nossos times?
