Neste blog post, apresentarei 2 valiosas técnicas para que você possa compreender de forma holística o fluxo de desenvolvimento de software de uma equipe.

1. CFD

Segundo Brodzinski, Cumulative Flow Diagram (CDF) é um dos gráficos que oferece rápida visão geral do que está acontecendo num projeto ou produto.

O CFD é um instrumento valioso para rastrear e prever projetos ágeis. Ao usá-lo, você pode verificar rapidamente o status atual: quanto trabalho foi feito, o que está em andamento e quanto tempo será necessário para que determinado escopo seja concluído.

A estrutura do gráfico é muito simples. O eixo horizontal representa um período de tempo (semanas, sprints, etc) e o vertical indica, de forma acumulada, o número de itens no processo (total de tarefas, total de histórias, etc.). Cada área pintada no gráfico está relacionada a uma etapa do fluxo de trabalho (backlog, em progresso, finalizado, etc) e as curvas são basicamente o número de itens acumulados em tais etapas.

Para demonstrar como usamos o CFD na Plataformatec, descreverei o exemplo de um projeto. Nesse caso, tivemos um fluxo de desenvolvimento composto pelas seguintes etapas:

• Backlog: itens que precisavam ser refinados.
• Ready to Dev: itens com critérios de aceite definidos e com uma definição explícita de “feito”.
• Developing: itens em desenvolvimento.
• Testing: itens sendo verificados e validados.
• Accepted: itens lançados em produção.

Neste projeto, utilizamos o CFD para: (1) comunicar o progresso; (2) identificar os gargalos do processo; (3) gerenciar as filas. Escolhemos acompanhar o andamento semanalmente, pois precisávamos informar o status do projeto para o CTO nessa frequência.

Os próximos 3 diagramas representam o projeto no início (primeiras 7 semanas), no meio (11ª semana) e no final (semana 22).

O começo

No início do projeto, a equipe enfrentou uma situação em que a relação entre a chegada e a saída dos itens não era proporcional — o throughput médio da equipe era de 3 itens por semana e o escopo aumentava 7 itens por semana. Este comportamento é ruim, porque significa que o número de itens entregues dificilmente será igual ao número de itens do escopo. Naquele instante, a equipe e a PO discutiram soluções para que a taxa de crescimento do escopo acompanhasse a cadência de entrega.

Outra informação que pode ser extraída do gráfico é que alguns itens foram criados (estágio de Backlog), mas não foram detalhados (Ready to Dev). Neste caso, o time refinou junto da PO um conjunto de itens e os deixou prontos para serem trabalhados.

O meio

Ao analisar o CFD no meio do projeto, é possível observar que as etapas de desenvolvimento (Developing) e testes (Testing) não apresentavam acúmulo entre as etapas (sobrecarga). Comparado com as primeiras 6 semanas (início do projeto), a relação entre itens criados e entregues passou a ser a mesma: 3 itens por semana.

A equipe sabia que o throughput precisava aumentar. Além disso, o projeto ainda apresentava indefinições — 15 itens não estavam preparados para serem desenvolvidos. Um dos causadores de tal situação foi a alta incerteza no design da aplicação.

O fim

Uma coisa interessante que percebemos no final deste projeto foi que o trabalho na etapa de teste fluiu bem. Olhando para o gráfico, é possível reconhecer que as linha azuis (etapa de Teste) desapareciam rapidamente. Isso ocorreu porque a interação dentro do time foi intensa. Na semana 19, a equipe e a PO alinharam que nenhum novo item seria incluído no escopo, porque o prazo de entrega estava chegando.

Outra informação que pode ser observada no gráfico de CFD acima é que a equipe não concluiu todas as histórias previstas no escopo — a etapa “Accepted” não ocupou todo o diagrama. Nesse caso, a equipe de desenvolvimento do nosso cliente assumiu os 5 itens que estavam em progresso (2 em desenvolvimento e 3 em testes).

Vale compartilhar que os itens entregues geraram uma solução de qualidade e alinhada com o que nosso cliente precisava.

Adotamos como boa prática verificar o CFD semanalmente para impulsionar melhorias dos nossos processos. Tal diagrama se mostrou um excelente companheiro para discussões sobre limitação e gerenciamento de WIP.

2. Lead time breakdown

Para aprimorar reuniões de acompanhamento do projeto ou retrospectivas, criamos uma visualização chamada “lead time breakdown“.

Resumidamente, este gráfico permite que o time avalie, compare e analise em detalhes a latência entre o início e o término de cada uma das etapas do processo de desenvolvimento, para cada item de trabalho que passa pelo fluxo (bugs, histórias do usuário, etc).

Esse tipo de visualização permite analisar o processo com mais detalhes se comparado com a análise do CFD. Geralmente, o lead time breakdown é utilizado para responder questões como:

• O que está acontecendo com os itens que estão em progresso?
• Existe algum tipo de impedimento atrapalhando a fluidez do time?
• O time está lidando com algum gargalo no processo (exemplo: sobrecarga na etapa de testes)?

Criar a visualização é bem simples. No eixo vertical estão os dias de trabalho; no horizontal, os itens de trabalho em progresso ou já entregues pelo time (exemplo: o montante de histórias do usuário monitorados pelo quadro Kanban). Para representar cada uma das etapas do processo, é utilizado o gráfico de barra acumulado.

Vamos ver um exemplo a partir de um projeto real. A equipe tinha o fluxo de trabalho com as seguintes etapas:

Neste fluxo, há etapas com o objetivo de medir gargalos criados pelas etapas de QA (Waiting for QA) ou pelo responsável pelas aprovações das entregas dos itens (Waiting for Review). O gráfico de lead time breakdown do exemplo ficou assim representado:

Podemos identificar que quase todas os itens do exemplo necessitam de mais de 3 dias para serem revisados (comportamento visto pela barra roxa). Em alguns casos, tal tempo de passagem pode ser inaceitável, dado a criticidade da entrega.

Outro ponto interessante é a alta variabilidade no lead time da etapa de codificação (barra azul). Neste caso, o time provavelmente trazia para o fluxo de desenvolvimento itens com pouca padronização.

Durante este projeto, a equipe sofreu pois tinha que compartilhar um especialista de teste (repare na altura das barras exibidas em amarelo no gráfico). À medida que a equipe e os stakeholders acessavam periodicamente o gráfico, o problema ficava evidente para todos e soluções foram discutidas para resolvê-lo. Uma delas foi o Scrum Master exercer o papel de especialista em teste, em alguns períodos do ciclo de vida do projeto.

Como boa prática, em todos os projetos que atuamos, temos utilizado o gráfico de lead time breakdown periodicamente para entender o status atual da equipe. Tal ferramenta tem sido útil para:

• Guiar discussões recorrentes de como remover desperdícios no processo.
• Promover melhorias no processo baseadas em dados.
• Deixar evidente o tempo de espera ao longo do desenvolvimento dos itens de trabalho.
• Analisar mais facilmente as demandas que estão próximas de serem finalizadas.
• Utilizar as informações para apoiar retrospectivas quando a pauta é relacionada ao processo.
• O que o time precisa manter?
• O que o time precisa mudar?

Concluindo

A visualização do fluxo através do CFD ou do lead time breakdown fornece uma visão quantitativa e qualitativa de problemas potenciais no processo de desenvolvimento de software. Encontrar soluções é uma outra história.

Para aprender mais sobre o CFD, recomendo 4 boas referências:

• O excelente artigo, Cumulative Flow Diagram do Pawel Brodzinski.
• O livro do Daniel Vacanti, Actionable Agile Metrics for Predictability.
• The Cumulative Flow Diagram in a nutshell.
• Minha publicação recente e em português, Métricas Ágeis – Obtenha melhores resultados em sua equipe.

E você, como tem utilizado o CFD? Qual a sua opinião sobre a visualização do lead time breakdown? Compartilhe sua opinião nos comentários abaixo!

The post Métricas Ágeis: Cumulative Flow Diagrams e Lead Time Breakdown first appeared on Plataformatec Blog.

Neste post, vou apresentar como usamos os gráficos de Throughput e Burnup na Plataformatec, durante o ciclo de vida de um projeto.

Aprendendo a partir do Throughput

A LeanKit define Throughput como o número médio de unidades processadas por unidade de tempo. No fluxo de desenvolvimento de uma equipe, os exemplos podem ser “cartões por dia”, “cartões por semana” ou “cartões por mês”.

Uma observação importante a respeito o Throughput é que a métrica difere do “Velocity” (quantidade de story points entregue por iteração ou sprint) utilizado no Scrum.

Na Plataformatec, consideramos Throughput como o número de itens (por exemplo, história do usuário) entregues por semana.

Geralmente, analisamos o Throughput para responder questões como:

• Quantos itens de trabalho a equipe entrega por semana?
• O time está criando uma tendência crescente de entrega?
• Algum fator tem bloqueado a capacidade de entrega da equipe?

Vamos ver um exemplo prático. Imagine uma situação que você, como Gerente de Desenvolvimento, precisa ajudar o time a explorar o Throughput passado a fim de gerar melhorias futuras.

Primeiramente, podemos observar no gráfico acima que somente em 15% das semanas (4 de 27) a quantidade de itens entregues foi zero (0).

Além disso, é possível extrair mais informações do gráfico de tendência. Caso o Throughput esteja em crescente, a equipe está aumentando o número de itens entregues em uma semana. Se a tendência é de queda, pode colocar em risco o prazo de entrega de um projeto. Um limite inferior pode ser estipulado como forma de fornecer um indicador de quando ações corretivas podem ser necessárias. Nesta equipe, o Throughput aumenta nas primeiras semanas, seguida de uma ligeira queda e, finalmente, estabiliza-se.

Olhando para a distribuição de Throughput da equipe temos uma situação em que a média (linha verde), a moda (linha laranja) e a mediana (linha laranja) possuem quase o mesmo valor (aproximadamente dois). Portanto, é razoável dizer que o time, em geral, entrega dois itens por semana.

Outra forma de validar o argumento sobre a capacidade de entrega da equipe é buscar o percentil 80 (linha cinza). Ele nos diz que apenas em 20% das semanas, a equipe conseguiu entregar mais de três itens por semana.

Uma boa prática que definimos para os projetos na Plataformatec é uma verificação semanal do Throughput, como um processo de compreensão das causas que afetam o ritmo de entrega. Geralmente, o Throughput de uma equipe cai pelos seguintes motivos:

• Requisitos ruins — exemplo, baixa qualidade nos critérios de aceite de histórias de usuário;
• Dívidas técnicas — exemplo, necessidade de refatorações inesperadas;
• Gargalos do processo — exemplos, especialista de testes sobrecarregado, pipeline de implantação falho;
• Backlog com baixo nível de itens prontos para desenvolvimento;
• Mudança de escopo — por exemplo, aumento no escopo de uma história de usuário.

Olhando para o gráfico de Burnup

O gráfico de Burnup é uma ferramenta valiosa para gerenciamento do escopo. Ele apresenta a quantidade de trabalho entregue por uma equipe e, fornece mais informações do que o Burndown, pois combina escopo e total de entrega na mesma visualização.

É comum ver gráficos de Burnup com linha de tendência para estimar o prazo de entrega do escopo que está sendo analisado.

Tenho visto Product Owners e Agile Coaches projetando cenários baseados em três perspectivas:

• Pior caso: projetar a performance futura da equipe com base no menor Throughput histórico.
• Melhor caso: considerar que a equipe atuará no futuro com base no maior Throughput histórico.
• Caso mais provável: considerar que a equipe terá no futuro um comportamento semelhante ao Throughput “médio” (recomendo a leitura do post que escrevi sobre o motivo pelo qual você deve ter cuidado ao usar a média como medida).

Em nosso contexto, o gráfico de Burnup está nos ajudando a responder perguntas como:

• O escopo do projeto está crescendo de forma saudável?
• Quando a equipe terminará o escopo atual do projeto?

O exemplo abaixo aconteceu com um cliente da Plataformatec e as circunstâncias eram as seguintes:

• Duração do projeto: 23 semanas (quase seis meses).
• Expectativa do cliente: ter uma solução para resolver um problema de processo interno (projeto do zero, sem código legado).
• Roadmap do produto: após a sessão inicial de story mapping, a equipe e o cliente reduziram o escopo da entrega.
• Desafio do projeto: assegurar que o software estivesse disponível para uso na data acordada.

Neste projeto, usamos o gráfico de Burnup como ferramenta para comunicar o progresso do projeto. O gráfico foi desenvolvido para exibir:

• O número de itens de trabalho planejado para a entrega (escopo);
• O número de itens entregues;
• Cenários para possíveis datas de entrega do projeto.

Os próximos três gráficos representam o projeto no início (primeiras seis semanas), no meio (doze semanas) e no fim (semana 23).

Analisando o início do projeto, tivemos um cenário de aumento do escopo e algumas entregas.

Em relação ao escopo, o aumento aconteceu devido ao refinamento de um conjunto de histórias de usuário criadas após o story mapping.

Um indicador útil para analisar o crescimento do backlog é calcular a taxa de aumento semanal de novas histórias de usuários (no exemplo, sete histórias de usuário foram criadas por semana no início do projeto). Aqui na Plataformac, usamos esse indicador como ferramenta para manter o aumento do escopo previsível.

No meio do projeto, houve crescimento contínuo do escopo (seis novas histórias de usuário criadas por semana). Neste momento, tivemos que sentar com o cliente para alinharmos formas de simplificar o escopo, porque, caso o mesmo continuasse a crescer, dificilmente entregaríamos uma versão do software no final do contrato. O gráfico de Burnup foi útil para definir estratégias para melhorar o Throughput com base nos resultados das entregas realizadas.

A técnica de projeção utilizada foi importante para chegar ao final do projeto entregando todas as funcionalidades necessárias para o software.

Na conclusão do projeto, realizamos uma sessão de lições aprendidas e a equipe destacou que o gráfico de Burnup foi útil, pois:

• trouxemos visibilidade ao processo do desenvolvimento garantindo que o cliente estava alinhado com o progresso e o prazo de entrega;
• mostramos visualmente como o aumento do escopo influencia o prazo de entrega, sendo assim, uma boa ferramenta de negociação.

Conclusão

Monitorar o Throughput significa melhorias do processo com base em dados, que expõe o que está sendo feito com transparência à todos envolvidos no projeto.

O gráfico de Burnup é uma ferramenta poderosa de comunicação que pode ser usada para negociar com stakeholders, visto que, revela como mudanças de escopo afetam o prazo de entrega desejado, ao mesmo tempo que informa o progresso real.

Se você busca material avançado em métricas, recomendo o livro Métricas Ágeis – Obtenha melhores resultados em sua equipe. — Tudo bem, é um jabá! Eu sou o autor do livro, mas acredite, minha recomendação é genuína.

The post Métricas Ágeis: Throughput e gráfico de Burnup first appeared on Plataformatec Blog.

Medir é o primeiro passo para controlar e eventualmente promover melhorias. Se você não pode mensurar algo, você não pode entendê-lo. Se você não consegue capturá-lo, você não consegue controlá-lo. Se você não consegue controlá-lo, você não consegui melhorá-lo.

Apenas para deixar claro, meu interesse é melhorar processos e sistemas, portanto defino “controle” como habilidade que uma equipe desenvolve para construir ferramentas que fomentem a auto-gestão, ao invés da cultura de comando e controle.

Desde que comecei a trabalhar com desenvolvimento de software, tenho visto métricas a partir de dois pontos de vista:

1. No lado negro da força, as métricas são aplicadas como ferramentas que enxergam equipes como números e, a única razão para coletá-las visa cobrar respostas e criar conflitos destrutivos. Exemplos de métricas desse tipo são: número de testes unitários escritos, velocidade individual, etc. (dê uma olhada no texto “How To Not Destroy your Agile Team with Metrics”).

2. Do outro lado da força, as métricas promovem ações de melhoria continua e trazem visibilidade para a equipe.

Aqui na Plataformatec, utilizamos as métricas para compreender como podemos fazer o nosso trabalho melhor baseado em dados, como um exercício de evolução.

Este é o primeiro post da série “Métricas Ágeis, em que compartilharei algumas métricas e gráficos que usamos nos projetos dos nossos clientes.

Se você busca material avançado em métricas, escrevi o livro Métricas Ágeis – Obtenha melhores resultados em sua equipe, um guia de aprendizado e boas práticas.

Vamos falar sobre Lead time

Segundo o Wikipedia, “é possível definir lead time como a latência entre o início e a execução de um processo. Por exemplo, o lead time entre o pedido e a entrega de um carro novo de um fabricante pode ser de 2 semanas à 6 meses. No setor de bens industriais, a redução do lead time é uma parte importante da produção enxuta.”

No contexto do desenvolvimento de software, consideramos o lead time como o número de dias entre o início e o fim de uma entrega — por exemplo, história do usuário, bugs, etc. Para medir o lead time deve-se estabelecer os limites de começo e fim.

Para algumas equipes, “feito” pode significar uma história de usuário lançada em produção, para outras pode ser a liberação de uma funcionalidade em ambiente de homologação.

Uso o gráfico de lead time para responder perguntas, como:

• Quanto tempo a equipe precisa para desenvolver um novo item?
• A equipe está conseguindo desenvolver as funcionalidades planejadas dentro do timebox de uma iteração?
• Existe algo afetando a previsibilidade dos itens que são trabalhados pela equipe (por exemplo, tamanho, complexidade, incerteza)? A variabilidade vem aumentando nas últimas semanas?

Bom, agora que definimos as coisas, vamos ver um exemplo prático. Imagine uma situação em que você, como Agile Coach, está aconselhando a equipe C3PO. Que tipo de insight é possível obter do gráfico abaixo?

Ao traçar a linha do percentil 75 (linha verde), notamos que 75% dos itens que passaram pelo processo da equipe levaram 20 dias ou menos para serem concluídos.

Outra linha que podemos desenhar é a do percentil 95. Com base nela, é possível assumir que um novo item tem 95% de chance de ser completado em 37 dias ou menos.

Então, o que deduzimos disso tudo?

Se alguém pedir ao time para estimar o tempo necessário para desenvolver um novo item, um palpite pode ser um número dentro do intervalo de 20 à 37 dias. Uma vez que temos alta amplitude, as estimativas não serão muito confiáveis.

Indo um pouco além nas investigações, é possível identificar que após a primeira release, algo aconteceu, afinal, o lead time aumentou. Provavelmente, nas releases posteriores, a equipe lidou com itens mais complexos ou incertos.

Outro ponto interessante para se analisar no gráfico são os casos extremos (lead times que estão nos extremos superior e inferior). Na maioria das vezes, esses valores atípicos são causados ​​por circunstâncias que estão além do controle da equipe, porém, é um ótimo material para retrospectivas como insumo de aprendizado.

Para concluir, gostaria de compartilhar cinco dicas sobre como otimizar o lead time:

1. Eduque a pessoa que estiver vestindo o chapéu de Product Owner para que ela consiga conceber itens que gerem valor com soluções simples (foco: diminuir o lead time).
2. Desenvolva ferramentas para que a equipe diminua a complexidade e remova incertezas técnicas ou de negócio (falo mais sobre isso no post Requisitos em equipes ágeis: Falando sobre complexidade e incerteza).
3. Analise a distribuição de lead time com freqüência. No início, a variabilidade alta será normal, mas, depois de algum tempo, é importante buscar um padrão para que seja possível ter um processo de desenvolvimento previsível.
4. Comunique qualquer variação no lead time para os stakeholders e implemente ações para controlar o crescimento do lead time.
5. Use os casos extremos como uma oportunidade para aprender e melhorar o processo.

E você? Que tipo de pergunta você está respondendo com base no lead time? Compartilhe conosco seus aprendizados nos comentários abaixo!

The post Métricas Ágeis: o que Lead Time fala sobre seu projeto first appeared on Plataformatec Blog.

Ao longo dos mais de 8 anos de vida da nossa empresa, nosso time já compartilhou muito conhecimento:

• mais de 250 blog posts
• dezenas de palestras
• 4 livros (2 no Brasil, 2 nos EUA)

Este post é para falar do mais novo livro que um membro do nosso time está lançando: Métricas Ágeis, do Raphael Albino.

www.casadocodigo.com.br/products/livro-metricas-ageis

Mas antes de falar do livro em si, vamos entender um pouco dos panos de fundo por trás do livro.

Primeiro, um pouco de contexto

Na Plataformatec, nós gostamos de uma frase de efeito que os US Marine Corps utilizam:

“Improvise, Adapt and Overcome”

Especialmente das últimas duas palavras: se adaptar e superar. Por que digo isso? Pois acreditamos que o processo de melhoria contínua em um projeto segue esse mantra. Nós não temos a ingenuidade de que, para melhorar um processo, basta apenas implementar uma caixa preta de metodologias. Nós respondemos a quase todas as perguntas com “depende”. Depende do seu contexto, ambiente, pessoas, economia, estratégia. Tudo, em termos de gerenciamento de projetos de software, depende.

E é aí que muitas empresas se perdem. Decidem implementar Scrum, Kanban, XP ou outra metodologia e acreditam que todos os seus problemas estarão solucionados… não é bem assim. Você precisa analisar como está seu processo para que consiga entender quais práticas, ou conjunto de práticas, seu time está preparado para aderir e, a partir de então, fazer pequenos ajustes rumo a um processo melhor (a famosa melhoria contínua). Com isso em mente, nós aderimos a uma filosofia parecida com a descrita acima:

“Analise, se adapte e supere”

E como fazemos isso? Bom, uma das maneiras é através de métricas de processo. Nós coletamos uma série de métricas de processo assim que entramos em um cliente. Não chegamos mudando as coisas, chegamos analisando. Assim que temos as métricas em mãos, as lemos, analisamos e mudamos os pontos necessários para melhorar o processo pouco a pouco de maneira sustentável. E essa é a palavra chave de uma melhoria de processo. Ela precissa ser sustentável, ou seja, não pode incomodar demais a entropia do time, senão tudo se perde.

Por que um livro de métricas ágeis?

Pode parecer difícil e complicado esse processo de coleta de métricas, análise, adaptação e superação. Nós tratamos desse assunto no nosso blog, mas, se quiser realmente “beber da fonte” de tudo isso – saber de onde as métricas vieram, como coletar, ler e, principalmente, como melhorá-las – eu indico o novo livro do Albino.

Não é jabá. É fato. Na minha opinião, é o livro que melhor explica as métricas de processo, todos os tipos de leitura de gráficos e a melhor maneira de utilizar esses dados. Aliás, este é o maior valor do livro. É muito fácil você começar a coletar métricas… Mas isso não traz resultados se você não souber utilizar os dados que você coletou!

Albino aborda no livro toda a parte processual, matemática e heurística que os métodos trazem, sem nunca deixar de lado o valor de negócio atrelado. Resumindo, o livro não trata de “métricas por métricas”… trata de métricas para obter os melhores resultados possíveis no seu negócio. Entre os assuntos abordados estão o Throughput, Lead Time, Simulação de Monte Carlo, Eficiência de Fluxo e muito mais.

Então, se quiser entender melhor como nós fazemos para ter sucesso com nossos clientes e a metodologia por trás das nossas ações, não esqueçam de comprar o livro do Albino, acompanhar os novos blog posts e se cadastrar na nossa newsletter de ágil.

The post Estamos lançando mais um livro: Métricas Ágeis, do nosso consultor Raphael Albino first appeared on Plataformatec Blog.

Sim, imprevisibilidade é inerente ao desenvolvimento de software. Seria impossível prever todas as features de um sistema no começo de um projeto, por exemplo.

Mas e se nós pudéssemos prever como as próximas semanas se comportariam?

Isso é o que tentamos alcançar ao compilar métricas e rodar simulações de Monte Carlo.

Para entender mais sobre as métricas que utilizamos, veja:

• Why we love metrics? Learning with lead time
• Why we love metrics? Throughput and burnup charts
• Why we love metrics? Cumulative flow diagrams

A maioria das pessoas não usa métrica alguma para gerenciar projetos. Então, imagine quantas usam modelos estatísticos complexos para prever o fim de um projeto. No entanto, aplicar esse conhecimento em seu projeto ajudará entregar mais rápido e melhor.

Neste post, você verá como evoluímos de uma abordagem ingênua de predição para uma mais precisa e robusta utilizando a simulação de Monte Carlo. Mais ainda, explicarei de uma maneira fácil como esta simulação funciona, fazendo analogia entre um jogo de dados e projeto de desenvolvimento de software. Saber quando o projeto, provavelmente, vai acabar pode ajudar você a gerenciar as despesas da empresa, melhorar feedbacks a stakeholders e passar mais confiança de que você está no controle do projeto.

Por que não outros métodos?

Nós passamos por diferentes métodos de predição desde o início da empresa, e todos eles tinham algum ponto fraco. Aqui, listei alguns deles e o porque optamos por abandoná-los.

Throughput médio

Alguns podem pensar em um método simples, no qual usaria o throughput médio para prever o final de um projeto. No entanto, como você pode ver neste post Power of the metrics: Don’t use average to forecast deadlines, isso seria um método ingênuo e não funcionaria.

Regressão Linear

Este foi nosso primeiro método. Regressão linear baseada no throughput acumulado para prever quando um projeto seria finalizado:

No entanto, identificamos dois pontos diferentes que não estávamos considerando quando fazíamos esse tipo de análise:

• Nós mantínhamos o número de itens no backlog constante para que a predição funcionasse, o que causa muito viés.
• Nós descobrimos, depois de algumas análises, que tanto o nosso throughput quanto lead times não seguem distribuição normal, portanto não faz sentido calcular regressão linear (veja em Looking at Lead Time in a different way e Assumptions of Linear Regression)

Configuração Manual

Primeiramente, focamos em evitar erros estatísticos, como o caso da regressão linear. Começamos a utilizar um modelo mais compreensível, que usa métodos que sabemos que estão enviesados, mas que podemos controlar de acordo com o contexto do projeto.

Adicionamos manualmente diferentes retas de predições de throughput baseados em percentis do histórico do projeto.

Nós tivemos melhores resultados com isso, já que podíamos mudar a previsão manualmente e, portanto, ajustá-la de acordo com o contexto específico do projeto. Porém, o fato de desconsiderarmos mudanças no backlog, nos motivou a dar um passo a mais e testar Simulações de Monte Carlo.

Planilha Simulação de Monte Carlo
BAIXAR PLANILHA GRÁTIS

Simulação de Monte Carlo

Wikipedia define Monte Carlo como:

Qualquer método de uma classe de métodos estatísticos que se baseiam em amostragens aleatórias massivas para obter resultados numéricos, isto é, repetindo sucessivas simulações um elevado número de vezes, para calcular probabilidades heuristicamente.

Pode parecer complexo ou difícil inicialmente, mas é muito mais simples do que parece. Você pode considerar que é o método de força bruta das previsões. Vou apresentar um simples exemplo, e então, mostrar como nós aplicamos na vida real. Existe uma simulação feita por Larry Maccherone, que pode facilitar o entendimento ainda mais.

Jogo de dados

Imagine que você está jogando um jogo de dados, no qual o objetivo é alcançar a soma de 12 pontos com o menor número de jogadas. A melhor jogada, no caso, seria jogar 2 dados consecutivos nos quais você tiraria o número 6 em ambos. A pior seria jogar o dado 12 vezes e caísse no 1 todas as vezes. O que queremos calcular com Monte Carlo é a probabilidade de finalizar o jogo depois de N rodadas.

Considerando que temos 6 possíveis resultados para cada jogada de dado (6 faces) qual é a probabilidade de terminar o jogo na primeira rodada?

Zero. Já que é impossível tirar 12 pontos se o dado vai até 6.

E na segunda rodada?

É a probabilidade de conseguir dois 6 consecutivos, e que, em estatística básica, é:

E na terceira rodada?

Você pode alcançar 12 pontos de diferentes maneiras: (3,3,6), (3,4,5), (3,5,4), (3,4,6), (5,5,2), (4,4,4), etc. Agora, o cálculo estatístico não são tão fáceis, certo? É aí que entra a simulação de Monte Carlo.

O que Monte Carlo faz é simular milhares de rodadas de dados, para então, analisar o resultado. Por exemplo, para saber a probabilidade de terminar o jogo na terceira rodada, a simulação rodaria o dado três vezes, somaria os pontos, e guardaria o resultado. Depois disso, iria repetir esses passos 5000 vezes e resumir quantas rodadas cada soma de pontos obteve:

Agora, o algoritmo soma todas as ocorrências que geraram soma maior do que 12 e divide o resultado pelo número total de ocorrências (5000). Neste caso:

O mesmo que fizemos para o terceiro round, faríamos para o quarto, quinto, etc.

Mundo Real

A solução do mundo real é muito similar ao exemplo dos dados. A única diferença é que o objetivo varia também (os 12 pontos no cenário do jogo), para considerar mudanças no backlog.

Então, o possível resultado de cada rodada (os lados do dado) são o histórico de throughput. E, do mesmo jeito que nós “rodamos dados” para o throughput , nós precisamos rodar os dados para o backlog, para dar chances do mesmo crescer também. Nesse caso, os possíveis resultados são chamados de Backlog Growth Rates (BGR).

Comecemos devagar. Digamos que nosso histórico do projeto é o seguinte:

Então, as possíveis jogadas para cada rodada de throughput seria o conjunto {2,3,0,2,5,0,1,3,3} e para backlog seria {0,2,1,1,2,1,0,2,0}. Não excluímos números repetidos, pois com eles mantemos a maior probabilidade de sair esses números, ao invés de outros.

Podemos aplicar o mesmo racional que esta por trás do jogo dos dados. Qual a probabilidade do throughput acumulado alcançar a mesma quantidade que o backlog, ou mais, na primeira semana? Alguns dos possíveis resultados são os seguintes:

Então, rodaríamos muitos como esses e veríamos quantos deles tem soma de throughput maior do que a soma do backlog, e dividiríamos o resultado pelo número de simulações. Fazendo isso, teríamos a probabilidade do projeto ser finalizado na primeira semana. Para a próxima semana, nós faríamos a mesma coisa, mas rodando dois dados em cada simulação (dois para BGR e dois para throughput) somando-os.

Um problema que esse método tem é que o backlog, no começo do projeto, se comporta diferente do que no meio ou final do mesmo. No começo, o backlog cresce muito mais rápido pois estamos tendo melhor conhecimento dos problemas e nuances do projeto. Já no final, o crescimento é de basicamente por causa de refinamento de histórias.

Para resolver este problema, ao invés de considerar todo o histórico de backlog para os cálculos, nós consideramos apenas os últimos 10 pontos, o que nos dá melhor perspectiva de como o backlog está se comportando ultimamente.

O resultado para as próximas 10 semanas, utilizando a abordagem acima, é representada no gráfico:

Como podem ver, realcei três áreas do gráfico para ilustrar o que poderia ser o entendimento do mesmo:

• A primeira área, a vermelha, são as semanas nas quais temos 50% ou menos probabilidade de terminar o projeto. O que significa que seria arriscado demais dizer aos stakeholders que seu projeto seria finalizado nessas 4 semanas.
• A próxima área, laranja, ilustra as semanas que têm probabilidade entre 50% e 75% de terminar o projeto. Eu diria que, se os stakeholders estão te pressionando para entregar rápido, seria possível terminar nessas semanas, mas alguns ajustes de processos seriam necessários.
• A área verde é a mais livre de riscos, onde a probabilidade de terminar o projeto é maior do que 75%. Eu sugiro que você sempre dê preferência para estimar o fim do seu projeto baseado nesta área. No entanto, sabemos que nem sempre podemos ser tão flexíveis assim.

Nós testamos Monte Carlo em projetos passados, e parece funcionar muito bem, no entanto, como em todo método estatístico, ele se torna melhor depois de algumas semanas que o projeto já começou, por ter mais dados para trabalhar.

Conclusão

Prever quando um projeto irá acabar parece muito mágico, mas este método é extremamente simples de ser implementado; aumenta nosso entendimento e predição em relação ao projeto. É importante deixar claro que este método é estatístico e heurístico, portanto, não é a prova de falha. O objetivo principal é adicionar mais um elemento ao seu conjunto de ferramentas e deixar o gerenciamento de projetos um pouco mais fácil.

Para executar simulações sem muito trabalho, disponibilizamos uma versão simples da nossa planilha para você baixar.

Se quiser aprender mais sobre simulações de Monte Carlo, recomendo essas referências:

• Troy Magennis – Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-carlo Simulation
• Daniel Vacanti e seus website, livro e blog: Actionable Agile
• Joel Spolsky’s blog post on Evidence Based Scheduling

Como você faz sua projeção de fim de projeto? Qual sua opinião sobre nossa abordagem? Compartilhe seus pensamentos conosco nos comentários abaixo!

The post Por que usamos Simulações de Monte Carlo para gerenciar projetos first appeared on Plataformatec Blog.

• Forecasting software project’s completion date through Monte Carlo Simulation
• Lead Time Experiment: Calculating Lead Time of the whole process
• Case Study of a WIP Limit Implementation: Why, When and How to use WIP Limits

Another experiment that we did was to analyze the metrics that we generally use, however, instead of tracking them on a weekly basis, doing it daily. The project was supposed to be very short and weekly metrics would have shown us the problems when it was already too late to act. The intention here was to see if with a shorter feedback cycle, the metrics would make us notice problems faster: like bottlenecks, queues etc.

If you are not aware of the metrics we use, here are some blog posts about them:

• Why we love metrics? Cumulative flow diagrams
• Why we love metrics? Throughput and Burnup charts
• Why we love metrics? Learning with Lead time

We will present next our opinion on the effectiveness of using each one of those metrics on a daily basis.

Cumulative Flow Diagram (CFD)

The daily CFD was the most used daily metric for us. In the first weeks, it was too difficult to find bottlenecks only by seeing the weekly metrics. But as you can see on our daily CFD chart, we spotted some queue growth throughout our project and could act on them on a daily basis to avoid losses.

Burnup chart

We didn’t use much the daily burnup chart, but we believe that it can be very helpful in case your client and/or product owner want faster feedbacks on how the project health is.

It is possible to see that the backlog changed on a daily basis in the beginning of the project, that information could help the stakeholders take faster actions to mitigate possible delays.

Throughput and Predictions

Our Monte Carlo simulation didn’t work well with “daily throughputs”, that are actually the number of deployed stories per day. That happened because, if you remember how we use Monte Carlo from our blog post Forecasting software project’s completion date through Monte Carlo Simulation, we base our simulation on our throughput history. Moreover, if you see our throughput histogram, you’ll be able to notice that on most of the days there weren’t deploys, which means that the simulation would be extremely pessimistic and skewed to zero.

Conclusion

At the beginning of projects, we usually feel we don’t have enough data to make decisions, but if you start gathering data on a daily basis you might have enough information to perform fast changes on your process and guarantee an even better cadence to your deliveries.

At the end of the project, after we already had enough weekly input, we abandoned the idea of a daily metric. We did that because with the progress of the project, the daily data became more noisy than helpful, and the weekly data was already reliable enough. Therefore, this approach seems to work best at the beginning of a project.

What do you think of daily metrics? Would you use them? Leave your comments below!

The post The pros and cons of using daily metrics first appeared on Plataformatec Blog.