Toda vez que penso em indicadores e métricas ágeis para projetos, recordo‐me de uma frase de um autor americano especialista em gestão de processos: H. James Harrington, que diz: “Metrificar é o primeiro passo para o controle e eventualmente para a melhoria. Se você não consegue medir algo, você não consegue entendê-lo. Se você não […]
Toda vez que penso em indicadores e métricas ágeis para projetos, recordo‐me de uma frase de um autor americano especialista em gestão de processos: H. James Harrington, que diz:
“Metrificar é o primeiro passo para o controle e eventualmente para a melhoria. Se você não consegue medir algo, você não consegue entendê-lo. Se você não consegue capturá-lo, você não consegue controlá-lo e se você não consegue controlá-lo, você não consegue melhorá-lo”.
Antes que você pense que estou fazendo qualquer apologia à cultura do comando e controle, gostaria de compartilhar que, para mim, controle é a capacidade que uma equipe tem de manusear e desenvolver ferramentas que promovam um ambiente de auto gestão.
Desde que eu comecei a trabalhar como Gerente de Projetos, tenho lidado com dois pontos de vista quanto às métricas:
1. No primeiro, as métricas são aplicadas como ferramentas que buscam simplificar a equipe em números, e a única razão para coletá‐las visa exigir respostas das pessoas e criar conflitos perigosos. Exemplos deste tipo de métricas são número de testes unitários escritos por desenvolvedor, velocidade individual etc.
2. No segundo, as métricas são utilizadas com o intuito de promover ações de melhoria contínua e, a partir das respectivas visualizações, trazem visibilidade sobre a saúde do processo ao time. Além disso, sua análise promove um ambiente em que os cenários dos prazos de entrega são projetados a partir de uma base consciente (interpretação) e consistente (histórico real da equipe). Dado que estamos em um meio onde queremos entregar melhores produtos de software para os clientes e usuários, incluir em nosso repertório formas de monitorar a eficiência do processo de construção de software se torna algo relevante.
Trabalhar com o desenvolvimento de software é um grande desafio. Afinal, temos de lidar diariamente com incertezas, mudanças, pessoas, expectativas, dependências, restrições etc.
Mapear um fluxo que garanta o desenvolvimento de software em um ritmo sustentável, ou até mesmo que proteja as equipes das incessantes demandas geradas por diferentes facetas envolvidas na construção de um produto ou projeto, é um dos grandes desafios de Gestores, Agile Coaches, Scrum Masters e time.
Com as etapas do fluxo de desenvolvimento estruturadas, as demandas (como funcionalidades, bugs etc.) passam a ser construídas seguindo a lógica pensada para o processo. E é aí que passam a surgir gargalos, alto tempo de entrega e baixa sensação de progresso. Se você faz parte de uma equipe que possui um fluxo de desenvolvimento, em algum momento do seu dia a dia, você se deparará com a seguinte questão: como eu posso dar visibilidade de como está a saúde do meu projeto?
Algumas técnicas ajudam os gestores e times a mensurarem sua performance e entregas durante a execução dos projetos:
– WIP (Work in progress) – Qualquer trabalho que não tenha sido concluído, mas que já tenha incorrido em um custo de capital para a organização. Medir o WIP é um dos trabalhos mais importantes no monitoramento da saúde do processo de desenvolvimento de software, pois, ele é um dos preditores do desempenho geral do fluxo de desenvolvimento. Gerenciando o WIP, garantimos um controle na cadência das entregas e impactamos o tempo que uma demanda passará pelo fluxo de desenvolvimento.
– Lead time – Se quisermos responder aos nossos clientes quando um item de trabalho estará pronto, antes de iniciarmos o desenvolvimento, precisaremos ter como referência lead times de demandas que passaram pelo processo de desenvolvimento.
Para a indústria, lead time representa a latência entre a iniciação e a execução de um processo. No contexto de desenvolvimento de software, podemos considerar o lead time como sendo o número de dias entre o início e o fim do processo de entrega de um item de trabalho (por exemplo, história do usuário, bugs etc.).
– Throughput – Nada mais é do que uma medida que determina quantas unidades de trabalho foram completadas em uma unidade de tempo. Olhando pela perspectiva de vazão (ou saída), é possível afirmar que o throughput é uma medida que determina quanto o meu fluxo é capaz de processar. Vale destacar que não há uma unidade de tempo universal para medir o throughput, portanto, caberá a você ou a sua equipe defini‐la. Existem contextos em que faz sentido medir o throughput por dia, semana, iteração (sprint) etc.
– Gráficos de burndown e burn-up – Os gráficos de burndown e burnup são tipos de visualizações que gestores e equipes utilizam para monitorar e comunicar o progresso de uma entrega. O gráfico de burndown mostra quanto trabalho está faltando ser concluído em um espaço de tempo (semana, quinzena, trimestre etc.). Já o gráfico de burnup apresenta quanto de trabalho foi feito e o total de trabalho necessário para a entrega. Tais gráficos são usualmente utilizados por equipes que trabalham com frameworks como Scrum ou algum tipo de metodologia ágil.
– Simulação de Monte Carlo – É uma técnica estatística que tem como objetivo estimar a probabilidade de um certo resultado por meio da geração de centenas ou milhares de cenários baseados em números aleatórios para as entradas em um sistema. Para o contexto de projetos, podemos pensar em um algoritmo de simulação com o objetivo de determinar a probabilidade da finalização do escopo de um projeto em um certo momento de tempo (semana, mês, etc).
Reforço aqui a importância em se medir, analisar e aplicar mudanças no processo, e não nas pessoas. É importante que você tenha um ambiente no qual as pessoas sejam estimuladas a criar, que tenham autonomia e que estejam engajadas no propósito do ambiente em que elas se encontram. Se você está interessado em medir quantas linhas de código um desenvolvedor criou na semana ou quantas funcionalidades um testador validou na última iteração, seu foco passa a ser a cobrança de performance, a comparação de desempenho e o microgerenciamento.
Tenha em mente a todo momento que as métricas serão úteis para evoluir o processo, compreender o contexto, gerenciar os riscos, analisar tendências, trabalhar com possibilidades e aumentar a visibilidade. Ao construir ou analisar uma métrica, se questione: estou avaliando de fato algo que ajudará a evoluir o meu processo, ou estou querendo analisar o desempenho de uma pessoa? Elimine qualquer tipo de controle que seja inútil no seu objetivo de trazer visibilidade e previsibilidade para o fluxo de desenvolvimento da sua equipe. Em hipótese alguma utilize as métricas como forma de comparar equipes. O motivo é simples: contexto.
Metrificar para compreender o admirável mundo do processo de desenvolvimento de software. Incorporar uma cultura de captação, análise e controle de dados trará para sua equipe visibilidade do progresso para quaisquer interessados no que está sendo construído ou mantido.
Além disso, propor melhorias baseadas em dados é um bom caminho para a remoção de análises subjetivas e, até certo ponto, vazias. Estimule as pessoas a utilizarem menos o recurso do feeling quando estiverem analisando o comportamento de uma equipe
Por fim, metrificar é uma ótima forma de buscar previsibilidade quando estamos construindo um produto incerto.
Métricas devem ser utilizadas para o bem e não para gerar cobranças e comparações. Devem ser usadas para evoluir os processos.
Números sem contextos são perigosos, portanto, ao analisá‐los, tenha em mente a realidade que está envolta daquela unidade de medida.
Procure tendências e fuja da precisão. Dada a complexidade que é criar um produto de software, não busque determinismo em um mundo receptivo por natureza a uma realidade totalmente provável.
Por Viviane Otaviano
Gerente de Projetos da Flux-It
