A importância da análise do throughput e do trabalho em progresso
Por: Mariana Cazita | Jan, 2023
Dando continuidade ao aprendizado compartilhado no artigo Uso de métricas ágeis como ferramenta de empoderamento do time, recebi algumas sugestões para falar com mais detalhes sobre WIP (Work in Progress ou trabalho em progresso) e throughput (calma que irei explicar melhor do que se trata). Aproveitarei para explorar um pouco mais os gargalos que podem ser mapeados, as possíveis soluções e como tudo isso nos leva a uma maior previsibilidade das entregas.
É importante reforçar que o objetivo de medir e acompanhar as métricas de um time não é gerenciar individualmente a produtividade e desempenho de um integrante do time e sim, entender os pontos de melhoria do processo de desenvolvimento e com isto, possibilitar a tão sonhada previsibilidade. Não estou dizendo que será fácil, mas entender o que impacta as métricas, com certeza já traz mais transparência e visibilidade para todos. E não compare as métricas entre equipes, as pessoas são diferentes, os contextos distintos e a experiência também, será um equívoco que pode gerar frustração e mal estar entre os times.
O que é esse tal de Throughput?
O throughput é uma medida que determina a capacidade de processamento do fluxo de trabalho. Ele indica a cadência de entrega, ou seja, o quanto de trabalho é concluído em determinado período de tempo. É importante que o período analisado seja constante para todas as medições analisadas. O throughput não considera o tamanho do item e sim a quantidade total de itens que entraram e saíram de um fluxo.
Falando um pouco da análise do throughput na prática, quando começamos a visualizá-lo no time percebemos que chegamos ao fim de várias sprints entregando muito menos do que tínhamos planejado. Era considerado como entregue, os itens liberados em produção, então começamos a identificar que muitos itens tinham o desenvolvimento “finalizado”, mas ficavam aguardando a revisão de código, aguardando teste e a publicação em outros ambientes até que pudesse ir para produção.
Mas o que gerava esses gargalos nestas etapas? Eram diversos fatores, inclusive fatores externos ao time, como dependência de atuação de outras áreas, questões de ambiente e configuração, além de dúvidas de regras. Definimos um rito, no caso a review, para analisar esses fatores e entender como mitigar esses riscos para conseguirmos chegar ao final do ciclo com itens de fato entregues e sem transbordamento entre sprints.
Analisar e delimitar o trabalho em progresso foi uma estratégia que nos auxiliou na melhoria do processo, como explicado a seguir.
Falando de WIP (Work In Progress) — Trabalho em progresso
Todo item que passa pelo fluxo de trabalho, seja uma estória, uma tarefa ou um bug, precisa ser analisado e trabalhado por um integrante do time, considerando todas as etapas deste fluxo, até que sua conclusão seja atingida. Por isso, para conseguir acompanhar o quanto de trabalho está em progresso é muito importante ter as etapas do fluxo bem definidas.
Um item que entra no fluxo de trabalho demanda tempo e atenção do time, por isso considero todos eles (estórias, tarefas e bugs) na contagem de trabalho em progresso. Um ponto importante é que itens de tipos diferentes podem possuir granularidades distintas, com isto, é necessário entender o quanto de trabalho em progresso cabe em um ciclo, considerando esta granularidade. Por exemplo, uma estória tende a ter complexidade maior que um bug, mas pode variar também entre estórias de tamanhos distintos.
Aplicamos o WIP de duas formas no time, a primeira foi delimitando no Kanban, em determinadas colunas, o trabalho em andamento:
Toda vez que o número de itens na coluna com WIP era ultrapassado, analisávamos o que poderia ter gerado o gargalo e isso nos ajudava a entender melhor os fatores que poderiam ter gerado o problema.
Posteriormente, começamos a limitar o WIP antes que os itens entrassem na sprint. Com base nas sprints anteriores, sabíamos que o time tinha capacidade de entregar até x estórias em x dias, assim tínhamos tempo de atender nosso critério de “done”, disponibilizando a feature em produção. Definimos como critério de “done” os itens disponibilizados no ambiente produtivo para uso, mas este critério pode variar por definição de cada time.
Esses acompanhamentos nos ajudaram a reduzir transbordamento de itens entre sprints, ter maior previsibilidade do que seria entregue no ciclo e ainda gerenciar a frustração ao fim da sprint, por não entregar o que foi planejado. Também facilitou a gestão de gargalos, por focarmos no que estava em andamento, fazendo a revisão do código (code review) e ajustes de bugs identificados pelo processo de qualidade.
Analisar o throughput e o trabalho em progresso ajuda a esteira do processo fluir para atingirmos entregas consistentes que atendam aos critérios definidos. Vale aplicar estes conceitos e acompanhar a evolução sprint a sprint do seu time para que os benefícios sejam colhidos.
