Velocidade e melhores métricas: entrevista com Doc Norton

A velocidade não é boa para previsões ou diagnósticos, argumentou Doc Norton na Experience Agile 2019. É um indicador retardatário de um sistema complexo que é volátil demais para saber qual será o desempenho futuro, não é estável o suficiente para ser usado de maneira confiável.

Norton definiu velocidade como unidades de trabalho ao longo do tempo em direção à entrega de valor. Precisa de direção para ser uma medida sensata. Mas, mesmo quando a velocidade está conectada à implantação ou entrega real, ela ainda não informa nada sobre o processo. Com apenas essa medida, não podemos dizer se uma equipe está indo bem ou não, disse ele.

Para obter previsões de probabilidade mais altas, você precisa conhecer seu histórico de velocidade, tamanho do backlog, data de início, e a taxa de divisão, que é um indicador do crescimento do seu backlog. Norton mostrou como usar a simulação de Monte Carlo para prever quando uma equipe seria capaz de entregar. Dependendo do nível de confiança que se deseja, a equipe precisará de mais tempo até que possa entregar.

Para o diagnóstico, Norton mostrou como usar diagramas de fluxo cumulativo. Eles podem ajudar a rastrear a quantidade de trabalho realizado e não realizado ao longo do tempo, ver as mudanças no escopo, e identificar onde estão os gargalos.

Doc Norton, coach ágil e líder de equipes, falou sobre o uso da velocidade e outras métricas na Experience Agile 2019, e o InfoQ fez uma entrevista com ele.

InfoQ: Como você define velocidade?

Doc Norton: Velocidade, na sua forma mais simples, são unidades de trabalho ao longo do tempo em direção ao valor. Na maioria dos lugares, são simplesmente unidades de trabalho ao longo do tempo, mas isso não é velocidade, pois não tem uma direção clara. Isso é apenas velocidade. A velocidade é um vetor, precisa de uma direção, e é por isso que adicionamos "em direção ao valor". Isso faz lembrar que se está indo em uma direção específica. Valor, a meu ver, é aprendizado, redução de risco, ou maior utilidade.

Para mim, não se conta a velocidade até que se perceba o valor. Se a equipe aprendeu algo como se o novo tratamento aumenta ou não a interação, ou se definitivamente reduziu um risco, como provar que a nova técnica de armazenamento em cache funciona quando um sistema instável do qual dependemos cai, ou forneceu algo útil, como um recurso que os usuários estão realmente envolvidos, então consideramos a história concluída e a adicionamos à velocidade. Em muitos lugares, a velocidade é contada quando o desenvolvimento é concluído. Se a história nunca for publicada, eles ainda a contam como velocidade. Eu acho que eles estão perdendo um ponto-chave.

Em um nível mais profundo, a velocidade também é um indicador atrasado de um sistema complexo. Como acontece com todos os indicadores retardatários, eles não são muito úteis para prever o futuro, mas são bons para confirmar tendências e padrões. Pense nas vendas trimestrais em grande parte do espaço de varejo - o quarto trimestre não é um indicador de quais serão as vendas do próximo primeiro trimestre, mas pode confirmar a tendência geral de que as vendas sejam mais altas no final de cada ano.

InfoQ: Você afirmou em sua palestra que a velocidade é quase inútil. Poderia elaborar mais sobre isso?

Norton: Eu já fiz pesquisa com mais de mil pessoas em conferências ágeis. Aproximadamente 90% dos respondentes têm baixa confiança em sua velocidade, não veem correlação entre velocidade e implantação, ou não podem projetar com segurança uma grande parte do trabalho usando apenas a velocidade.

Apenas 10% dos agilistas pesquisados consideram a velocidade útil para realmente medir e projetar quando o trabalho será feito e na produção. Planejamento e previsão é o objetivo da velocidade.

Com base nesses dados, acho justo dizer que a velocidade é quase inútil

InfoQ: Alguns dizem que a velocidade é algo que pode ser manipulado pelas equipes. Qual a sua opinião sobre isso?

Norton: Essa é uma perspectiva perigosa, especialmente se você estiver no gerenciamento. Um líder que culpa os atores está perdendo a visão geral e não consegue ver o papel que desempenham na criação dos resultados.

Todo sistema é perfeito, produz o resultado exato que foi projetado para produzir. Se o sistema em vigor está produzindo resultados errados, é menos culpa dos atores dentro do sistema e mais culpa do próprio sistema. Podemos advertir as pessoas por não serem melhores atores, ou insistir que eles devem se comportar de maneira diferente com base em algum conjunto de crenças ou regras sobre os seres humanos - em algumas expectativas morais ou éticas, mas um fator chave em todo comportamento humano é o sistema ou contexto em que eles estão operando. Um indivíduo perfeitamente racional que deseja fazer um bom trabalho inflará estimativas ou reduzirá custos de qualidade em um ambiente que promove e recompensa mais a velocidade do que a segurança. Isso não é uma verdade universal, alguns insistirão na segurança sobre velocidade. Mas é verdade o suficiente para ter um impacto na maioria das equipes na maioria das empresas.

Portanto, quando a gerência enfatiza a velocidade ou, pior ainda, estabelece metas para a velocidade, o comportamento resultante dos atores é uma consequência natural. Não é o time que joga com o sistema, é o criador do sistema que cria o jogo.

InfoQ: E se as equipes quiserem usar a velocidade para ver se estão melhorando, isso é possível?

Norton: Talvez, mas não a melhor forma. Antes de tudo, como a velocidade é tipicamente pontos da história por iteração, e os pontos da história são abstratos e estimados pela equipe, a velocidade está altamente sujeita a desvios.

Desvios são mudanças sutis que aumentam com o tempo. Geralmente não se nota isso em pequenas coisas, mas compare isso a um horizonte temporal mais amplo, e se tornará óbvio. Pegue uma equipe que saiba que eles devem aumentar sua velocidade ao longo do tempo. Com certeza, o farão, e provavelmente, veremos que eles estão agregando mais valor. Mas quanto mais? Como se ter certeza?

Em muitos casos, se você pegar um conjunto de histórias de alguns anos atrás e pedir à equipe para reestimá-las, eles fornecerão um número geral maior do que as estimativas originais. Minha premissa é que isso ocorre porque nossas estimativas costumam subir mais ao longo do tempo. A tendência para estimativas maiores não é perceptível de iteração para iteração, mas ao longo de trimestres ou anos. Pode-se usar histórias de referência para ajudar a reduzir esse desvio, mas não sei se você pode eliminá-lo.

Segundo, mesmo que se possa provar que as estimativas não mudaram, ainda estará medindo apenas uma dimensão: taxa de entrega. Para saber se está melhorando, pode ser necessário conhecer também a qualidade do código, a adoção do cliente, a retenção do cliente, e o desempenho do sistema, por exemplo.

A velocidade não informa nada sobre a integridade do sistema, da equipe, ou da empresa. Na verdade, nem fala sobre a qualidade da entrega. É muito difícil determinar se está melhorando com tão pouca informação.

InfoQ: Quais são as suas sugestões para usar a velocidade para prever quando algo será feito?

Norton: Uma previsão é tão boa quanto os dados e a técnica usada para criá-la. Para a maioria das equipes, estimar com velocidade significa que você tem aproximadamente 50/50 de chance de concluir antes ou na data prevista. Pense nisso - você está usando uma média e uma extrapolação - é claro que sua previsão estará no meio do leque de possibilidades. Isso também significa que você tem pouca ou nenhuma ideia de quanto pode errar o alvo. O intervalo de datas possíveis de entrega é de alguns dias, algumas semanas ou alguns meses? Com base na técnica que se usou, pode ser que não dê para saber isso

Eu costumava aplicar um desvio padrão em relação à média para obter um intervalo. Então percebi que muitas distribuições de velocidade não são gaussianas, são deslocadas. Portanto, o desvio padrão não é matematicamente correto. E era difícil explicar o alcance em termos de probabilidade.

A técnica mais confiável que conheço até agora é executar simulações de Monte Carlo. O pessoal do Focused Objective possui uma planilha que faz isso por você: é chamada de Throughput Forecaster e você pode baixá-la gratuitamente no nosso site, no menu Tools and Resources. Com base em dados históricos de velocidade e um backlog de tamanho conhecido, eles executam 500 projetos simulados para determinar a probabilidade de concluir o trabalho em ou antes de um conjunto de datas. Essa é uma explicação simples do que acontece, mas é suficiente para um entendimento básico.

Essa técnica fornece um intervalo com probabilidade, permitindo que se tenha uma conversa muito melhor. Usando essa técnica, vários de nossos clientes descobriram que a técnica de velocidade que estavam usando produzia números com probabilidade menor que 50%. É maravilhoso ver o alívio tomar conta de seus rostos, pois eles percebem que não eram eles que não conseguiam gerenciar bem as equipes, mas suas previsões é que eram insuficientemente formuladas.

InfoQ: Como podemos medir a qualidade usando defeitos escapados?

Norton: Defeitos escapados são aqueles encontrados em produção. Para as equipes que eu treino, não há outros tipos de defeitos, então "escapado" é supérfluo. Mas em algumas empresas, existe esse conceito de defeitos no controle de qualidade e defeitos escapados. Defeitos escapados é tudo o que nos importa aqui.

Medir o número de defeitos escapados introduzidos em uma amostra de iteração ou taxa de transferência pode ser útil, mas pode ser enganoso. Pode-se descobrir que o número de defeitos escapados por iteração está aumentando. É claro que isso não é uma notícia "boa", mas, o quão ruim é a notícia?

Para ajudar a fazer essa determinação, podemos examinar o número de defeitos escapados em relação à taxa de transferência. Isso fornece uma proporção que pode-se usar para ver as tendências. A parte difícil é que você precisa fazer um esforço conjunto para identificar em que iteração ou ciclo de transferência que o defeito foi introduzido. Dependendo da equipe e de como o sistema é usado, isso nem sempre é fácil.

Digamos que você tenha um histórico de velocidade de 8, 9, 12, 14, 19, e 21 e uma contagem de defeitos escapados de 2, 2, 3, 3, 4, e 4, respectivamente. Se os defeitos escapados são uma medida de qualidade, a qualidade está melhorando, degradando, ou se mantendo?

Olhando-se apenas para os defeitos escapados, pode-se concluir que eles estão claramente em ascensão. Daí, pode-se concluir que a qualidade do software lançada a cada ciclo é degradante.

Se, no entanto, considerarmos isso como uma taxa de transferência para defeitos escapados, obteremos 0,25, 0,12, 0,25, 0,21, 0,21 e 0,19. A partir disso, vemos uma tendência geral de queda nos defeitos escapados pela taxa de transferência. Isso significa que, embora haja um aumento na taxa de defeitos, ele está realmente em declínio em relação à taxa de valor.

InfoQ: Como as equipes podem melhorar o uso de métricas?

Norton: Aqui estão algumas coisas que eu acho que as equipes precisam considerar se desejam aproveitar as métricas de uma maneira mais benéfica. Evite definir metas para medições. Concentre-se nas tendências, não nos pontos de dados únicos. Meça vários aspectos do sistema. Use as informações para informar os ajustes no sistema.

Evite definir metas para medições. Quando uma medida se torna um objetivo, não é mais uma boa medida. Esta é uma paráfrase da lei de Goodhart. Métricas são informações sobre como o sistema está operando. Elas são um subproduto do sistema. Se você toma uma medida e a converte em um controle a partir da definição de uma meta, você injeta a medida no sistema - você literalmente altera o sistema. A medida não significa mais o que significava antes, como resultado, a meta que você acredita que acabou de definir não é mais a meta que você pensa que é.

Concentre-se nas tendências, não nos pontos de dados únicos. Preocupe-se menos com o valor de hoje e mais com a tendência. Como é a tendência da métrica? Está na direção que você espera com base em sua estratégia? Se não estiver tendendo conforme o esperado, considere o que pode ser uma causa raiz no sistema e trabalhe para resolvê-lo. Saiba que haverá momentos em que uma estratégia sólida fará com que as métricas se desviem da direção normalmente desejada. Por exemplo, o código tende a ficar mais complexo enquanto você faz a transição de um monólito para microservices. Depois que o código monolítico antigo é removido, a complexidade cai novamente.

Meça vários aspectos do sistema. Existem tensões em todos os sistemas. Se medirmos apenas uma única dimensão, é menos provável que compreendamos a verdadeira saúde do sistema. Por exemplo, se focássemos exclusivamente na taxa de entrega, provavelmente deixaríamos de notar o impacto na qualidade, na adoção de recursos pelo cliente ou na satisfação dos funcionários. Cada uma delas afeta nossa capacidade de sustentar o sistema.

Use as informações para informar os ajustes no sistema. Estamos medindo para informar, não definindo metas para dar direções. Estamos analisando tendências e comparando-as com nossas expectativas com base em nossa estratégia. E analisamos várias dimensões para ajudar a garantir que não otimizamos demais em uma dimensão específica. Quando nossa tendência é reduzida em qualquer uma dessas dimensões, queremos considerar quais ajustes precisamos fazer para aproximar o sistema de um equilíbrio saudável.

Sobre o Entrevistado

Doc Norton, coach ágil e líder de equipes, é um profissional de software que trabalha para tornar o mundo do desenvolvimento de software um lugar melhor. Sua experiência abrange uma ampla gama de tópicos de desenvolvimento. Autor e palestrante internacional, Norton é apaixonado por ajudar outras pessoas a se tornarem melhores desenvolvedores, trabalhar com equipes para melhorar a entrega e criar grandes empresas. Trabalhabdo na OnBelay, Norton tem oportunidades para realizar sua paixão todos os dias.