Uso de métricas ágeis como ferramenta de empoderamento do time: um estudo de caso
Por: Mariana Cazita | Set, 2022
Gerenciar o fluxo de desenvolvimento de uma equipe não é uma tarefa simples, mas começar coletando algumas métricas pode ajudar bastante. As métricas de um time auxiliam na conscientização dos pontos de gargalo do processo e nos ajudam a descobrir problemas. A partir dessas percepções, em fatos, conseguimos analisar possíveis melhorias.
Antes que possamos discutir sobre a importância de medir algo, vale entender que é interessante existir um processo de trabalho básico para servir de início, mesmo que tenha etapas mínimas, isto ajudará a ter algo a se analisar, validar, testar e principalmente, evoluir. Então, a indicação é que você comece por um método ou framework ágil que mais lhe agrade.
É importante que fique claro que não se trata de um gerenciamento individual dos integrantes do time, nem tão pouco um esforço em medir seu desempenho. O objetivo é dar ao time o poder de controlar a qualidade de suas entregas e de conseguir ter previsibilidade destas. E nem preciso citar que tudo isso só se faz necessário para que sejam entregues produtos que gerem resultados e valor para os clientes.
Neste artigo, irei falar um pouco sobre o acompanhamento do Lead Time e Cycle Time em um time de desenvolvimento de software. Neste estudo, o Lead Time foi considerado como o tempo que leva para uma solicitação passar por todas as etapas de um processo, desde o pedido até chegar ao estado de “entregue”. Já o Cycle Time, como o tempo em que a equipe responsável de fato está trabalhando na tarefa.
Sobre o processo
Não entrarei em pormenores sobre o manifesto ágil, sobre frameworks ou metodologias específicas. A essência da agilidade está em seus valores, fortalecendo a entrega de resultados de valor aos clientes, acima de tudo. O importante a se destacar é que a agilidade permitiu que equipes pudessem pensar nas motivações que levam a construção de um produto e nos resultados que se espera, tendo em vista a possibilidade de oferecer entregas frequentes e de qualidade, com boas práticas de engenharia, mas isso é uma tarefa desafiadora, complexa e algumas vezes dolorida.
Para ajudar nesse desafio é importante olhar para o fluxo de trabalho do time e entender as etapas, entender o quanto de trabalho está em progresso (WIP), inclusive em cada etapa, e quanto de trabalho fica engargalado nelas.
Com base nos dados de evolução do time ao longo de 19 sprints analisadas, trarei as dificuldades e evoluções atingidas ao longo deste período. O time em questão contava com 3 desenvolvedores backend de senioridade diferentes, 1 tech lead, 1 pessoa de produto e uma pessoa de testes (QA). O processo de trabalho seguia o SCRUM, com sprints de 2 semanas (considerando apenas dias úteis) e inicialmente o time não realizava a pontuação de tarefas, sendo adotado o conceito de tamanho único. Contudo, é importante ressaltar que já eram aplicadas técnicas maduras de desenvolvimento, com a criação de testes unitários e um processo de deploy, além de ambientes de desenvolvimento e validação estáveis. A gestão das sprints era feita por meio do software Jira.
Passamos a analisar os dados coletados em cada Sprint Review. Foram definidas algumas premissas e regras para a coleta de dados:
- Critério de pronto: história liberada em produção.
- Tipo de item: História. Os bugs e tarefas menores eram analisados à parte, isto porque muitas vezes eram itens relacionados à própria história que já estava em andamento na sprint.
- Pontos fora da curva: no início do processo de acompanhamento tínhamos muitos itens que ficavam bloqueados, por diversos motivos, ou itens que entravam na sprint como apoio a outros times e isto gerava uma discrepância que, para nós naquele momento, não era o foco da análise.
- A coleta ocorria no último dia da sprint, antes do rito de sprint review.
Sobre a coleta e análise dos dados
Para coletar o Lead Time e o Cycle Time eram utilizados alguns relatórios prontos na ferramenta Jira. O “Relatório de Sprint” com informações de throughput, itens planejados e não planejados. Também era utilizado o “Control Chart”, onde era possível extrair a média móvel do Lead Time e do Cycle Time, a partir de refinamentos dos dados, por filtros. A medição teve início a partir da sprint 67, os dados das sprints anteriores foram coletados como histórico para estudo. Na primeira análise já entendemos que estávamos com um alto volume de stories não planejados, como visto no Gráfico 1, a seguir:
Além disso, estávamos chegando ao final da sprint com poucos itens concluídos (em produção), o que fazia com que muitos transbordassem para a próxima sprint. Chegamos a algumas conclusões iniciais:
- Problemas não esperados estavam gerando demandas não planejadas (mas será que precisavam ser resolvidos na sprint em andamento?)
- Precisávamos de refinamentos recorrentes para estressar as histórias ou tarefas a serem desenvolvidas na sprint.
- As histórias eram muito grandes, pois muitas não eram concluídas na sprint.
- Tínhamos gargalos nas etapas do processo, principalmente em code review e deploy.
Começamos deixando o objetivo da sprint mais claro para todo o time e disponível de forma fácil para que toda vez que uma demanda fora do planejado chegasse pensássemos duas vezes se que aquilo impactaria nosso objetivo final. Obviamente, que havia casos em que era preciso incluir o novo item na sprint, porém era algo feito com a consciência da mudança e entendendo que alguma tarefa precisaria ser despriorizada.
Marcamos refinamentos recorrentes a cada 15 dias, antes do início de uma nova sprint, mas que não passavam de 10% do tempo da sprint para não comprometê-la, seguindo os ensinamentos do SCRUM. Com esses refinamentos, e mesmo na planning, começamos a atentar para o escopo de cada história. Além disso, implantamos uma planning técnica para que o time pudesse quebrar a história em tarefas técnicas. Essas etapas nos ajudaram a quebrar melhor as histórias e diminuir o transbordamento de itens de uma sprint para a outra.
Quanto aos gargalos identificados, fizemos o que a regra manda, focamos nos itens da direita, seguindo uma das ideias do Kanban “parar de começar e começar a terminar”. Parece óbvio, já que é uma orientação no SCRUM, mas não era tão óbvio quanto parece, porque não bastava saber que haviam muitos itens nestas etapas e sim o que estava causando bloqueios e atrasos na liberação dos itens. Este foi um outro ponto que precisamos explorar ao fim de cada sprint para entender a origem dos problemas.
Também começamos a pontuar as histórias a partir da sprint 73 de forma bem simplificada, utilizando o conceito de tamanho de camisa, porém apenas 3 tamanhos P (até 1 dia), M (de 1 a 3 dias) e G (mais de 3 dias), o que nos ajudou a quebrar ainda melhor o tamanho das histórias.
Nosso Cycle time melhorou consideravelmente desde a primeira sprint analisada, como é possível verificar no Gráfico 2, mas sabemos que ainda há espaço para melhorar ainda mais o processo de trabalho.
Sobre as conclusões
Note que tudo foi um processo, tivemos que identificar os pontos de melhoria e aplicá-las sprint a sprint até atingirmos os pontos de evolução desejados.
Deixo algumas sugestões fundamentais se você deseja iniciar a coleta e análise de métricas ágeis com o time do qual faz parte:
- Identifique os gargalos, dentro e fora da sprint, existem fatores externos que podem impactar, como excesso de reuniões, dependências externas (de outros times ou serviços), mudanças de contexto (carga cognitiva) e vários outros.
- Sempre leve os pontos para discussão com o time, eles sabem a origem de muitos problemas e são fundamentais para entender essas dores e sugerir soluções.
- Permita-se começar, mesmo que não pontue as histórias, mesmo que o fluxo de trabalho esteja falho.
- Vocês vão continuar errando por muito tempo, isso é normal, o importante é enxergar onde existe possibilidade de melhoria e aplicar essas melhorias gradativamente.
No final, os resultados e os feedbacks gerados servem de gás para continuarmos, isto gera engajamento e empoderamento do time que consegue enxergar como e onde pode melhorar.
