Pensando em métricas para times ágeis

Juntamente à decisão de usar Scrum para gerenciar projetos de forma ágil, vem, segundo o seus criadores, a obrigação de traçar o gráfico de BurnDown, apenas uma das inúmeras métricas que podem ajudar (ou atrapalhar!) a acompanhar características do projeto e da equipe.

Escolher bem quais métricas usar em cada momento de um projeto é até mais importante do que fazer uma boa escolha de metodologia: é com base nas métricas que evoluimos e aperfeiçoamos nossa forma de trabalhar, escolhendo a inadequada corre-se o risco de parar no processo de melhoria contínua. Métrica específicas podem ajudar em diversas situações distintas, como algumas listadas a seguir.

Problema: nunca sabemos se atrasaremos ou adiantaremos

Em uma ocasião, um time termina tudo o que se comprometeu a fazer antes do tempo planejado, mas, como só descobriu que isso aconteceria próximo a entrega, fica parado até que o cliente (ou P.O.) possa definir um novo item e explicá-lo. Em outra iteração, o mesmo time se compromete com 5 histórias e acaba, no último dia, descobrindo 3 delas não ficarão prontas.

Discussão de métrica:

Embora um gráfico de BurnDown (ou BurnUp) ajude nesses problemas, ele também pode ser o próprio causador desses cenários. Seguindo cegamente o que é dito no Scrum Guide, uma equipe que usa Scrum teria um BurnDown de tarefas de uma Sprint.

Tal gráfico nos indica razoavelmente bem se terminaremos as histórias mais cedo do que o planejado, mas frequentemente dá a falsa impressão de que tudo está correndo bem, mesmo que ainda falte terminar todas as histórias.

Veja o seguinte BurnDown no penúltimo dia de um Sprint:

burndown perigoso

No último dia, sobram três pontos a fazer, um de cada história, e assim três delas ficam pra trás – o cliente não as recebe. Embora seja uma boa métrica para diversos casos, o BurnDown não nos ajudou nesse momento. O que poderia ajudar mais?

Solução: quadro branco

Uma ferramenta que traz de brinde várias métricas bastante úteis e interessantes é o quadro branco – quando, claro, bem utilizado. Vejamos como um quadro bastante simples, que apenas contenha um quadro de acompanhamento, já nos ajudaria no problema acima:

quadro branco do mesmo sprint

Esse quadro também mostra a mesma informação que o burndown nos dá, mas além disso nos aponta algumas outras informações importantes.

A primeira delas é que, apesar de faltar pouco para terminarmos, há três histórias pendentes. Isto é, embora tudo esteja sendo feito, as tarefas em andamento comprometem três das cinco histórias planejadas – é um impacto muito grande na iteração, se não conseguirmos terminá-las.

A segunda, e talvez mais importante, é que a história mais prioritária da iteração não foi terminada, enquanto a última ficou pronta até antes do último dia. Temos um problema de prioridade que passaria em branco se confiássemos apenas no gráfico de BurnDown.

Problema: “isso aí é com tal desenvolvedor”

Outro problema que assombra diversos times de desenvolvimento é código confuso, frequentemente legado, que fica na responsabilidade exclusiva de um programador que já está lá há tempos e conhece melhor aquela bagunça.

E essa situação não está limitada a código legado. Também vemos vários cenários em que uma parte que requer um conhecimento específico de negócio acaba caindo na mão de apenas um ou dois desenvolvedores de um time.

Para reduzir o problema de concentração de conhecimento, uma das técnicas que pode ajudar é o pareamento – isto é, dois desenvolvedores temporariamente trabalhando sobre o mesmo problema em uma mesma máquina, discutindo as possibilidades enquanto constroem a solução.

Mas, mesmo em times que utilizam pareamento como prática comum, tal acúmulo ainda pode acontecer. Se for esse o caso, o conhecimento fica concentrado em duas pessoas, isto é, o truck factor aumenta de um para dois: não é grande vantagem.

Medir a difusão de conhecimento é algo verdadeiramente complexo, mas um dos sinais mais facilmente observáveis é a quantidade de vezes que uma mesma dupla pareou.

Solução: Quadro de pareamento

Para fazer esse acompanhamento, é comum a utilização de um quadro de pareamentos como o seguinte:

quadro de pareamentos

Essa imagem nos indica um ambiente em que o pareamento está concentrado em dois pares de desenvolvedores: um, Luiz e Atoji, e o outro, Caires e Victor. Provavelmente haverá ilhas de conhecimento limitadas a um par de pessoas – apesar de ser uma situação melhor que conhecimento isolado, é possível mudá-la.

Como o time está atento para a métrica, o problema é rapidamente identificável e solucionável: apenas uma questão de disciplina na troca mais frequente de pares. Aliado a outras técnicas, como code review e apresentações de discussões internas, as ilhas de conhecimentos podem ser minimizadas.

Problema: incêndios constantes e o bombeiro é você

Outra frequente reclamação em times que começam a usar Scrum é que eles conseguiriam terminar os itens com que se comprometeram no planejamento, mas que constantes interrupções os fazem perder tempo apagando incêndios.

Até mais importante do que a própria interrupção é notar que cada uma delas faz o desenvolvedor perder o foco no que estava fazendo e, portanto, tomará mais algum tempo para recuperar a linha de raciocínio e voltar a produzir.

Solução: gráfico de interrupções

Para que tanto a equipe quanto as pessoas que os interrompem notem tal prejuizo, um simples contador de interrupções pode ajudar. A idéia é bastante simples: para cada interrupção durante o Sprint, o contador é incrementado. Então, ao final do Sprint, a contagem vai para um gráfico simples que mede as interrupções através dos Sprints desse projeto.

O tracking das interrupções, quando comparados ao desempenho do time em cada Sprint, pode levantar dados importantes. Contudo, a simples marcação do número tende a fazer as pessoas evitarem interromper o time. Frequentemente, pessoas externas ao time não se dão conta da frequência das interrupções.

O uso do quadro, afinal

Nesse contexto, para um time com todos esses problemas, o quadro acabaria, nesse momento, assim:

quadro completo

E, claro, é preciso manter em mente a razão pela qual cada uma dessas métricas está aí. Se uma delas deixar de fazer sentido, o time deve removê-la; se outro problema recorrente aparecer, o time deve buscar uma boa métrica para deixá-lo visível e, eventualmente, resolvê-lo. O mundo do desenvolvimento não deve se reduzir a expressar qualidade através de métricas pois muitas daquelas que seriam necessárias envolvem o tato humano de como lidar com uma situação, algo que uma função matemática simples ainda não é capaz de mensurar.

Esses foram apenas exemplos do que pode acontecer a um time. Outros casos envolveriam outras métricas. E seu time? Quais métricas trazem ou trouxeram bons resultados para vocês? Quais acabaram atrapalhando e enviesando o desenvolvimento?

18 Comentários

  1. Danilo Ruziska 26/01/2011 at 14:16 #

    Olá Cecília, ótimo artigo!!Parabéns!!

    Tenho uma dúvida:

    aqui no nosso time, determinamos que todos atacariam a história com a maior prioridade, e só passamos para a próxima história quando a mais prioritária está completa, e assim por diante, de uma maneira vertical.

    Estamos ainda no terceiro sprint, e não sentimos impacto dessa maneira de trabalhar. A longo prazo, isso pode causar algum problema??

  2. Douglas Campos (qmx) 26/01/2011 at 14:19 #

    Excelente post Cecília – Isso me lembrou daqueles quadros em indústrias: Estamos há XX dias sem acidentes – bem que poderíamos tratar as interrupções da mesma forma, não? 🙂

  3. Ceci Fernandes 26/01/2011 at 16:34 #

    @Danilo:
    Acho que não entendi a pergunta… a questão é se atacar sempre a história mais prioritária pode trazer problemas?

    Se sim, eu não vejo muitas possibilidades de problemas aí, a menos que haja membros do time parados em momentos em que não é possível paralelizar tarefas de uma história (ou não há mais tarefas a serem feitas o bastante para todos). Pessoas esperando uma história finalizar para começar outra… aí seria um enorme desperdício.

    Agora, se todos têm trabalho sempre, essa é a forma como nós usualmente trabalhamos também. Queremos sempre ver os cartões no quadro andando da esquerda para a direita e de cima pra baixo.

    @QMX:
    Só se você tiver uma interrupção por dia ou menos! Mas o usual é ter várias interrupções por dia, então teria que reduzir esse quadro a horas, talvez. 🙂

  4. Mauricio Aniche 26/01/2011 at 23:28 #

    Oi Ceci,

    Em uma das equipes que trabalhei (e não éramos tão ágeis quanto gostaria), criamos a mesma métrica: anotar o número de interrupções por dia que cada um sofria. Além disso, deixávamos bem na cara de todos que vinham à nossa mesa; o resultado foi a diminuição imediata das interrupções.

    Portanto, acredito que, além de métricas, trabalhar na visualização das mesmas é bastante importante! 🙂

    Abraços,
    Mauricio

  5. Alexandre Gandra 27/01/2011 at 00:36 #

    Bacana. Gostei da sugestão de quadro.

    Mas não entendi pq o burndown desceu de forma tão suave, já que o segundo sprint não andou evoluiu bem. Aliás, o burndown deveria estar beeem feio, e isto deveria estar claro já na primeira metade do sprint.

    Estou (prá falar a verdade, estava) trabalhando numa apresentação sobre métricas ágeis: http://prezi.com/v3v6-adpjrjk/metricas-cia/ É só un draftzão, heim!

  6. Ceci Fernandes 27/01/2011 at 01:26 #

    @Alexandre:
    Como esse BurnDown recomendado pelo ScrumGuide é feito por tarefas (em vez de historias), ele pode descer suavemente como for… e isso não garante retorno de investimento.

    Isto é, se faltar uma tarefa de cada história, como no exemplo, o BurnDown não alarma a equipe, já que tarefas “o bastante” estão sendo feitas por dia. Ficou mais claro? 🙂

    Dei uma olhada na sua apresentação, também, parece legal. Apenas, discordo de algumas pontuações… acho que não é tão determinístico assim. Mas são boas métricas, as que você recomenda por lá também!

    @Mauricio:
    Certamente, manter em um lugar bem visível é tão importante quanto fazer as métricas. Nesse quadro de interrupções, eu gosto de recomendar aos times que façam os próprios causadores das interrupções marcarem +1 no quadro.

  7. Gustavo 27/01/2011 at 03:31 #

    Olá Cecilia tenho uma experiência a contar considerando o artigo e complementando o que o @mauricioaniche comentou sobre visualização das métricas.
    Visualizei uma cena um dia em que um diretor apenas visualizando o gráfico BurnDown, viu que a equipe estava “adiantada” com a sprint e solicitou a retirada de alguns recursos do time para “apagar incêndios” em outro projeto (visto que os recursos solicitados já havia trabalhado no “outro” projeto), o que causaria um desfalque na equipe na etapa final da sprint.
    Eu acho que as métricas devem se complementar para passar uma informação mais consistente sobre o andamento do projeto, a disseminação do conhecimento e melhorar as estimativas e o gerenciamento de risco.

  8. Luiz Emmerich 27/01/2011 at 10:54 #

    Durante um tempo utilizamos uma métrica “wtf” para medir problemas não planejados (bugs em frameworks, problemas de ambiente, containers que não fazem o que é esperado, código legado confuso…).
    Mas de nossa experiência com Scrum vimos que o mais importante é o que é citado em “E, claro, é preciso manter em mente a razão pela qual cada uma dessas métricas está aí. Se uma delas deixar de fazer sentido, o time deve removê-la; se outro problema recorrente aparecer, o time deve buscar uma boa métrica para deixá-lo visível e, eventualmente, resolvê-lo”.
    Um problema com o board é sua atualização, muitas vezes as pessoas esquecem ou tem problemas em manter todas essas métricas atualizadas, eu sei que parece uma tarefa simples, mas atualizar um número a cada interrupção, a cada pareamento, a cada x… Enfim, o importante é ter sempre reavaliar o que está fazendo sentido para a equipe.

  9. Rodrigo Yoshima 27/01/2011 at 12:53 #

    Olá Cecília, muito bem explicado. Isso tudo que vc colocou está bastante relacionado com a prática de visualizar o processo do Kanban. Tem uns memes bem legais. O que escrevo abaixo não tem muita relação com o que vc postou, mas seria um assunto a discutir.

    Hoje questiono muito se qualquer uma das métricas que usamos são eficientes. Principalmente na comunidade Scrum isso é ainda mais confuso. Pontos servem para que? Acompanhamento ou para reforçar comprometimento de entrega. Tanto um quando para outro os objetivos são questionáveis.

    Pontos muitas vezes são baseados no esforço para uma equipe Scrum atender uma story segundo a sua definição de pronto. No mundo Lean isso seria um simples cycle time de engenharia. Se a sua definição de pronto não contém algo como “Em produção” é difícil fazer uma associação de valor com entrega de pontos. Neste caso, o burndown seria disfuncional.

    O assunto de métricas seria algo para um Noite Ágil. A linha que tenho seguido é achar que estimativa é desperdício. É melhor avaliar esforço ao final do ciclo, e não no seu início. O problema disso é que muitos gestores acham que estimativas servem para medir comprometimento, o que é ruim e gera mais disfunções.

    Abraços e parabéns!

  10. Alexandre Gazola 27/01/2011 at 14:28 #

    Parabéns pelo post!

    O problema de histórias menos prioritárias ficarem prontas antes de histórias mais prioritárias é justamente devido à divisão de trabalho. Teria que haver uma forma de se concentrar o esforço da equipe como um todo no que é mais prioritário, mas normalmente isso não é possível; tem que haver um nível de paralelismo.

    Existe algo que se possa fazer para atacar esse problema da prioridade (além do uso de pair programming) ?

    abraços!

  11. Rodrigo Yoshima 27/01/2011 at 18:13 #

    Alexandre, a única razão plausível para se quebrar uma história em tarefas é para obter paralelismo. Há uma pratica comum que é puxar tarefas na ordem das histórias no quadro. Isso força o swarm da equipe. É comum ter 2 ou 3 pessoas na mesma história mesmo sem pairing.

    Com pairing eu vejo pouco produtivo quebrar historias. Uma equipe mais madura (XP) vai se aproximar do one piece flow…

  12. Ceci Fernandes 27/01/2011 at 22:54 #

    @Gustavo: interessante, a sua história também. Certamente, faltou contexto na decisão do seu diretor. De qualquer forma, é intrinsecamente errado que uma pessoa externa ao time tome esse tipo de decisão passando por cima do time. Foi o caso?
    E, sorry, não posso deixar de dizer… pessoas não são recursos.

    @Luiz: bom ponto! Concordo e acrescento que é melhor não ter métricas do que tê-las desatualizadas. Deixar elas lá e abandonadas só custa mais tempo de pessoas tentando interpretá-las até descobrirem que estão desatualizadas.

    @Yoshima: as métricas são úteis, não importa a metodologia, de fato! 🙂 E são importantes para fins diferentes em casos diferentes, por isso fico com o pé atrás de afirmar que o BurnDown sem deploy não tem valor. Se ela ajuda um time que seja, ela tem valor pra alguém.

    Concordo que isso seria uma excelente discussão para uma próxima noite ágil. Marquemos mais uma!

  13. Ceci Fernandes 27/01/2011 at 23:02 #

    @Alexandre:
    Eu não vejo problema em paralelizar desde que estejam focando no mínimo de histórias possível. Acho bem natural, até.

    Talvez o problema por aí seja a granularidade das tarefas de uma história. Será que não dá pra quebrar uma única história em mais ítens técnicos (aka, tarefas)? Quebrando em mais tarefas paralelizáveis, você conseguiria manter mais pessoas em uma mesma história prioritária.

  14. Alexandre Gazola 28/01/2011 at 11:41 #

    @Yoshima
    Com certeza. O que estou questionando é a (correta) orientação do Scrum de minimizar o paralelismo **entre histórias**.

    @Cecilia
    Acho que é por aí mesmo… ajustar a granularidade para fazer com que uma história tenha tarefas de modo a mais pessoas poderem trabalhar na mesma história, ao invés de irem trabalhando em tarefas de histórias menos prioritárias.

  15. Rodrigo Yoshima 28/01/2011 at 19:40 #

    @Alexandre

    O Scrum roda em ciclos timebox onde seu limite é somente o trabalho selecionado para a Sprint. Há quem diga que isso é um lote muito grande e com isso você pode ter riscos maiores, maior variabilidade do processo e qualidade pior.

    Uma maneira de você fazer isso é usar a prática de Kanban de limitar o trabalho em progresso. Imagine que pela sua política você pode só ter 2 histórias em andamento. Essa transição é o que o Corey Ladas defende com o Scrumban.

  16. Rodrigo Aguas 30/01/2011 at 03:36 #

    Para diminuir o famoso “meio-pronto”, acredito que o burndown deva descer apenas quando as histórias estiverem concluídas, o que não permitiria essa falsa impressão de que está tudo certo. Fora desenvolver as histórias seguindo a ordem de prioridade das mesmas. Essas estratégias se mostraram eficazes no desenvolvimento do ScrumHalf pela equipe que faço parte.

  17. Felipe Zampa 20/11/2011 at 04:17 #

    Sei que o post é antigo mas vi um vídeo (também já antigo) do TED que fala sobre interrupções e é show de bola: http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html?awesm=on.ted.com_97Ow&utm_campaign=jason_fried_why_work_doesn_t_happen_at_work&utm_content=ted.com-talkpage&utm_medium=on.ted.com-twitter&utm_source=direct-on.ted.com
    Valem os 15 minutos!

  18. Ana Perez 07/02/2012 at 16:38 #

    Boa tarde pessoal,

    trabalho numa empresa pequena e que está começando a usar SCRUM. Paralelamente, faço mestrado em engenharia de software e estou na fase de procurar um tema para minha dissertação. Estou bastante propensa a ir pela linha de métodos ágeis e métricas.
    Algué tem alguma sugestão? Algum problema que poderia ser objeto de estudo nessa linha?

    Muito opbrigada,
    Abraços

Deixe uma resposta