Identificando o tempo para a entrega de uma demanda
Motivação
Meu intuito com esta primeira publicação é explicar e explorar o Lead Time. Passaremos pela discussão sobre o que é o Lead Time, como utilizá-lo, as formas de medí-lo, entre outros aspectos.
O interesse pelo assunto e por compartilhar os conceitos surgiram com o estudo de métricas ágeis e, principalmente, com a leitura do livro Métricas Ágeis de Raphael Donaire Albino.
Devo levar em consideração e alertar ao leitor ou à leitora, que presumo posse de alguma bagagem sobre Metodologia Ágil para leitura deste artigo. Eventualmente, algum elemento mais teórico pode ficar sem a devida explicação por não considerá-lo cabível neste artigo.
Outra premissa que peço ao leitor ou à leitora: nada do que direi aqui é verdade absoluta. Leia com criticidade e atenção.
Definindo Lead Time
Eventualmente, você pode ter aberto este artigo para saber, de forma rápida e direta, a definição de Lead Time. Pois bem:
É a metrificação (em qualquer unidade de tempo) para completar um ciclo de desenvolvimento de algum item, seja ele uma tarefa, uma história, um épico ou qualquer outro elemento que tenha um ciclo de desenvolvimento.
Como calcular o Lead Time?
Esse período de tempo deve ser calculado no que chamarei de Janela Efetiva de Desenvolvimento. Nela está contido o conjunto de status pertinentes ao desenvolvimento, em um determinado ciclo, em uma determinada equipe.
Imagine duas equipes, A e B. Ambas utilizam o Trello como gerenciador de tarefas. Na equipe A temos o seguinte board:
Na equipe B, por uma peculiaridade do projeto, decidiu-se que seria melhor, antes de iniciar o desenvolvimento da tarefa, de fato, realizar três processos para garantir a confiabilidade dos detalhes descritos. Portanto, o board da equipe B ficou assim:
Vamos supor, também, que ambas as equipes determinaram que estarão efetivamente desenvolvendo as tarefas quando elas estiverem em ToDo e Doing. Logo essa será o que chamo de Janela Efetiva de Desenvolvimento. É dentro dessa janela que o Lead Time será computado. Todos os outro processos não importam para o Lead Time de uma forma efetiva.
Por exemplo, na Equipe A e na Equipe B, a contagem será iniciada quando a tarefa for colocada em ToDo e finalizada quando ela for removida de Doing (lembrando que, nesse caso, os cards andam sempre da esquerda para a direita).
Antes dessa janela (e depois, dependendo do seu fluxo), podemos considerar que não há desenvolvimento de código, propriamente dito.
Listo, ainda, alguns status genéricos que, particularmente, tendo a considerar dentro da Janela Efetiva de Desenvolvimento:
- ToDo (Quando a tarefa já foi refinada, pensada, discutida e está clara para o início do desenvolvimento)
- Doing (Quando a tarefa está em desenvolvimento)
- Review (Quando ela está disponível para revisão pelos outros membros da equipe)
- To Quality Assurance (Quando ela foi revisada e aprovada. Agora, ela pode ser enviada para o controle de qualidade)
- Quality Assurance (Quando ela passa pelo controle de qualidade)
- To Production (Quando ela está pronta para subir ao ambiente de produção)
Mas qual a utilidade do Lead Time?
Esta é a pergunta mais importante desta publicação. Afinal, tecnologia por tecnologia ou métrica por métrica, não faz sentido algum.
A primeira utilidade que vejo para o Lead Time é a capacidade de predizer em quanto tempo uma tarefa qualquer será entregue (de acordo com a unidade de tempo adotada no seu Lead Time).
Ainda, aqui podemos fazer um paralelo com o conceito de Machine Learning, em que quanto mais o sistema roda, mais ele será preciso, até um certo limite de otimicidade. Ou seja, quanto mais Sprints a equipe tiver, quanto mais tarefas entrando e saindo da Janela Efetiva de Desenvolvimento, maior será a capacidade de predizer em quanto tempo qualquer demanda será entregue.
Extrapolando um pouco mais o pensamento, podemos utilizar da estatística para gerar dados mais realísticos. Supondo que até a Sprint 5, 10% das tarefas foram entregues em 2 dias, 75% das tarefas foram entregues em 10 dias e 98% delas foram entregue em 15 dias.
Seria plausível afirmar:
- Que é pouco provável que vamos entregar qualquer tarefa em 2 dias.
- Temos uma boa confiança que entregaremos qualquer tarefa em 10 dias
- É bem possível, e podemos, praticamente, garantir que qualquer tarefa não passará de 15 dias.
Nesse ponto, peço que pare e analise. Olhe como é fundamental o Lead Time para o planejamento de um projeto e a tranquilidade dos Stakeholders. Além de influir em toda uma questão psicológica e de segurança da equipe.
Outra utilidade que vejo no Lead Time é a possibilidade de detectar gargalos na Janela Efetiva de Desenvolvimento. Ou seja, suponha o cenário em que a equipe está em um ritmo bom, com inércia no processo. Estamos com um Lead Time médio de 3 dias. No final da última Sprint, detectamos que o Lead Time médio subiu para 9 dias e algumas tarefas ainda estão na Janela Efetiva de Desenvolvimento. É o primeiro indício de que devemos ficar alertas e investigar mais a fundo o motivo do aumento. Tivemos dependências de terceiros? Alguém da equipe não está bem (tanto no sentido físico, quanto psicológico)? As tarefas foram mal planejadas?
Uma outra analogia seria quando uma pessoa vai ao médico ou à médica com queixas de cansaço e sono excessivo. É um primeiro alerta de que deve ser feito uma investigação mais a fundo nesse(a) paciente.
Mais uma utilidade é a detecção da saúde das demandas descritas. Ou seja, podemos responder a pergunta: “Nossas demandas estão uniformemente dividas?”.
Vejamos: se há diferenças gritantes de Lead Time entre as demandas devemos suspeitar, entre outros aspectos, se as tarefas estão bem definidas e divididas. Será que não deixamos algumas demandas muito grandes? Ou algumas muito pequenas? Idealmente, se queremos determinar métricas que nos ajudem a predizer algo, é interessante a maior homogeneidade possível.
Observe o exemplo abaixo:
O Lead Time Saudável, apresenta menos picos que o Não Saudável. Com isso, é mais fácil predizer o tempo de entrega de uma tarefa para os Lead Times mais homogêneos . Um dos pontos importantes que permitem tal constância é a quebra das demandas de forma mais uniforme.
O item acima, corrobora para a importância de processos como Refinamento e Planejamento da Sprint.
Essas são algumas utilidades mais importantes que vejo na utilização do Lead Time. Há outras mais abstratas que, de uma certa forma, estão contidas nessas acima. Por exemplo, a determinação de incertezas no projeto, identificar casos extremos de gargalos, etc.
Eficiência do Fluxo com Lead Time
Este item poderia entrar como utilidade do Lead Time na sessão anterior. Porém, é um tópico deveras curioso e decidi discutí-lo em uma sessão a parte.
Vimos que o Lead Time é o tempo que uma tarefa permaneceu na Janela Efetiva de Desenvolvimento, e sabemos que podem ocorrer bloqueios nessas tarefas (seja por bug, um computador quebrado, enfim, qualquer motivo)
Pense agora que temos o Lead Time, o tempo em que essa tarefa ficou bloqueada e o tempo em que ela de fato ficou em desenvolvimento. Podemos calcular qual foi a eficiência dessa tarefa:
O cálculo base é bem simples:
Da análise de eficiência podemos tirar um fato muito interessante. Observe a tarefa 2 na tabela de eficiência. Ela foi, efetivamente, desenvolvida em 2 dias. Os outros 7 dias foram de bloqueio.
Nessa análise, posso afirmar que qualquer correção de processo seria focado nesses 7 dias de bloqueio. Considere que nossa equipe está engajada com o projeto e que o desenvolvimento efetivo ocorre no menor tempo possível. Portanto, será muito mais efetivo as correções e buscar entender o motivo desses bloqueios.
Devemos eliminar um bloqueio?
Nem sempre é compensador a investigação de um certo bloqueio. Na tarefa 1 (da sessão anterior), por exemplo, a investigação e correção do bloqueio, elevaria a eficiência em 12%, aproximadamente. Dependendo do projeto e dos problemas que o englobam, não faz sentido disperdiçar tempo e recurso para elevar uma taxa tão baixa da eficiência. Talvez, um bloqueio tão pequeno possa ser encarado como parte do fluxo normal de desenvolvimento.
Ou seja, devemos, sim, eliminar todos os bloqueios e falhas no processo de desenvolvimento, buscando a maior eficiência possível, mas cabe uma análise se será de fato compensador tal gasto de energia.
Evidentemente que os sete dias de bloqueios da tarefa 2 deve ser investigado e mitigado de forma muito mais priotária que o bloqueio da tarefa 1.
Não compare Lead Time de equipes diferentes
Somos pessoas. E cada equipe é formada por um conjunto de pessoas com suas peculiaridades. Cada equipe tem seu tempo, seu ritmo, seu processo. Não é justo e não faz sentido, matematicamente, a comparação entre Lead Time de duas equipes. A equipe A pode ter três pessoas sêniores, enquanto a equipe B pode ter uma sênior e duas júniores, e consequentemente, não faz sentido a comparação de Lead Time.
Essa comparação pode (e te garanto que vai) gerar uma pressão desnecessária nas equipes. Portanto, compare Lead Time da mesma equipe em Sprints diferentes e nunca Lead Time de equipes diferentes.
Não confunda Lead Time com Cycle Time
Por fim, mas não menos importante, vale comentar sobre uma confusão comumente feita. Lead Time não é Cycle Time e vice-versa. A diferença fundamental começa na unidade de medida:
- Lead Time é medido em tempo (minuto, segundo, dia, hora, semana, etc.).
- Cycle Time é medido em tempo por unidade (Horas por Membro da Equipe, Dias por Projeto, etc). Ele é o tempo médio disponível por demanda.
Ou seja, supondo que uma equipe irá desenvolver 10 tarefas em 20 horas, o Cycle Time da equipe será de 2 horas por tarefa.
A origem do Cycle Time vem dos processos de manufatura da Toyota:
Cycle time is computed by dividing operating hours by the quantity required per day. Even when Cycle Time is determined this way, individual times may differ. Ohno (1988), p. 22
Há, porém, uma diferença curiosa entre a relação do Cycle Time e do Lead Time na prática e na teoria. O Jira, por exemplo, nomeia o que, neste artigo, chamamos de Lead Time como Cycle Time. Não está errado, mas não segue uma visão purista do conceito.
Por fim
Em suma, o Lead Time é uma ótima métrica para verificar a saúde constante do projeto e dos processos, bem como garantir entregas fiéis aos prazos estipulados entre Equipe de Desenvolvimento e seus Stakeholders.
Use o Lead Time sem parcimônia.
Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.
