Blog

Tendências e novidades sobre tecnologia e negócios

24/03/2020 | 5 min de leitura

Falamos em nosso artigo anterior (para quem não leu segue o link) sobre algumas métricas utilizadas em projetos ágeis. Não é preciso que todas sejam  utilizadas, mas sim que sejam analisadas quanto ao cenário do projeto e necessidades.

métricas

Vejamos outras métricas de agregam grande valor ao projeto, ao time e ao cliente:

4. Velocidade da equipe

Quando trabalhamos com sprints, o nosso maior desejo é entregar o que planejamos. Mas depois de algumas sprints entregues conforme o planejado, começamos a nos perguntar se o que planejamos é realmente a nossa capacidade de entrega.

É muito comum que times ágeis comecem a puxar mais demandas durante as sprints. A medida que o projeto avança, as entregas sofrem alteração de quantidade, devido ao escopo, complexidade, impedimentos e tamanho do time (o que se espera que não mude, mas é mais comum do que imaginamos).

Quando falamos em velocidade, nos referimos a quantidade média de trabalho que uma equipe pode concluir em uma sprint, seja medida em story points ou horas.

Vejamos um exemplo abaixo:

story points

Podemos ver, além do quanto a equipe vem entregando, o quanto do trabalho entregue foi homologado pelo cliente, ou seja, completo.

Após a leitura a cada interação, o time deve refletir sobre os números obtidos. Um bom momento é a reunião de retrospectiva. Vejamos alguns questionamentos que podem agregar com base na leitura deste gráfico:

  • Existe uma pressão inerente ao negócio que estica a equipe além de seus limites?
  • Houve algum desafio imprevisto, que não consideramos durante a estimativa?
  • Estamos sendo otimistas demais ao prever a sprint?
  • Houve algum fator que justifique a baixa ou alta entrega extrema?

A velocidade média será um guia para o time planejar as próximas sprints. Para rodar várias sprints com assertividade recomenda-se descartar a menor e a maior entrega.

5. Gráficos de controle

Os gráficos de controle podem auxiliar de diversas formar, conforme o que queremos monitorar. O mais comum na sua utilização é a identificação de um padrão ao longo do tempo, seja a quantidade, tamanho das entregas ou o monitoramento de bug’s ou incidentes ocorridos após a liberação da versão.

Equipes ágeis com ciclos mais curtos terão um resultado maior ao tempo que equipes com ciclos consistentes terão uma entrega de trabalho previsível.

lead time

Diferente do modelo acima que demonstra um volume ao longo do tempo, podemos também encontrar gráficos de controle para avaliar indicadores que possuem limites, tanto para um valor máximo quanto para mínimo. Veja o exemplo:

gráfico

Tomando como base a imagem acima, podemos demonstrar o % entregue x planejado), com um % médio de assertividade no planejamento, atingindo altos ou baixos valores. Isso significa estar fora do limite superior ou do limite inferior, demonstrando uma anomalia do projeto.

Não é uma caça às bruxas, mas sim identificar a causa dos números relatados e corrigi-los, pois podemos indicar uma falha na execução ou planejamento.

6. Diagrama de fluxo cumulativo

O diagrama de fluxo cumulativo (também conhecido como CFD) é uma das mais avançadas análises para a gestão Lean. Ele fornece uma visualização concisa das três métricas mais importantes para o seu fluxo:

  • Tempo de ciclo
  • Taxa de transferência
  • Trabalho em progresso

É super comum o time não compreender este gráfico, mas não há com o que se preocupar. Vejamos como é simples. Seu objetivo é demonstrar a estabilidade do fluxo ao longo do tempo. Ele fornece dados quantitativos e qualitativos sobre o projeto e pode visualizar quantidade enorme de dados.

A regra básica do CDF é identificar os gargalos do processo para que possamos atacá-los e gerar mais fluidez no processo. Vejamos alguns exemplos:

Exemplo 1

fluxo cumulativo

O gráfico acima demonstra que as faixas estão ocorrendo em paralelo, ou seja, o projeto está saudável. O que o time recebe, ele desenvolve e homologa, sem gargalos.

Exemplo 2

fluxo cumulativo

Neste exemplo estamos vendo uma faixa rapidamente se estreitando, indicando que a transferência do estágio que ela representa é maior do que a taxa de entrada. Este é um sinal de que você possui mais capacidade do que precisa neste estágio e deve realocar esforços para otimizar o fluxo.

Podemos colocar como exemplo que o PO não está incluindo muitas estórias no projeto e que você possui mais desenvolvedores do que precisa para dar vazão.

Exemplo 3

fluxo cumulativo

Aqui já podemos ver o inverso do exemplo 2, onde as faixas estão se alargando no decorrer do tempo. Neste caso nota-se que o time tem recebido demandas e que não consegue dar vazão nas que estão em andamento, criando um gargalo. É um problema comum que geralmente é causado por multitarefa e outras atividades que não geram valor. Neste caso recomenda-se o controle do WIP, assunto que trataremos em outros artigos.

7. Throughput

O  throughput refere-se ao número de unidades que podemos processar em um período tempo, seja por dia, semana ou mês. O uso comum de sua utilização é a análise da vazão de estórias diárias/semanais ou por sprint em um time de desenvolvimento.

Uma observação importante a respeito o throughput é que a métrica difere do velocidade do time (quantidade de story points entregue por interação ou sprint) utilizado no Scrum.

Geralmente, analisamos este indicador para obter algumas respostas aos questionamentos abaixo:

  • 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?

Vejamos um exemplo:

throughout

Podemos observar no gráfico acima que nas primeiras interações não houve entrega. Percebemos também que após certo período o time iniciou uma entrega em ascendência até encontrar uma constante.

Caso o throughput esteja em linha 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 fornece um indicador de quantas ações corretivas podem ser necessárias.

O que costumo dizer aos times é que indicador bom é aquele que aponta nossas falhas. Com ele podemos identificar problemas e corrigi-los a tempo – caso contrário teremos de arcar com as consequências de não termos monitorado o projeto.

Bem pessoal, espero que estas informações possam ajudar em seus projetos. Se você tem alguma dica de temas ágeis que gostaria de aprender mais, deixe seu comentário com sugestões.

Até a próxima.

 

heider


Tecnologia

Deixe o seu comentário

O seu e-mail não será publicado. Os campos marcados com * são obrigatórios.

Blumenau - SC

Rua República Argentina, 2001 Ponta Aguda - CEP 89.050-173

47 3328-9400

São Paulo - SP

Av. Rebouças, 3970, 17º andar Pinheiros - CEP 05.425-070

11 3434-6553