Veja neste artigo porque as métricas são importantes para equipes ágeis de desenvolvimento de software, favorecendo sua melhoria contínua e algumas sugestões de métricas a serem utilizadas.
Duas das premissas das equipes ágeis são Inspeção e Adaptação. Grande parte das cerimônias de equipes ágeis existem para atender essas premissas (retrospectivas, reuniões de melhoria, etc.).
Apesar disso, muitas vezes é difícil medir se e quanto uma equipe está evoluindo, e mesmo saber quando uma medida melhora ou compromete o seu desempenho. Para obter essas informações a maioria das equipes ágeis faz uso de métricas.
Métricas
Uma métrica é um número, que representa determinado aspecto de um software, de um projeto ou de uma equipe.
De acordo com a equipe determinadas métricas podem fazer sentido enquanto outras podem ser irrelevantes. E, para a mesma equipe, uma métrica pode ser relevante em um projeto e irrelevante em outro ou ainda deixar de ser relevante em algum momento.
Algumas características de boas métricas ágeis
- Seguir tendências e não números: Ao medir a velocidade de uma equipe ágil, por exemplo, é mais importante sua tendência de estabilização que seu número absoluto;
- Ser facilmente coletada: Coletar as informações de uma métrica não deve representar um esforço para a equipe, devendo ser, prioritariamente, automatizada;
- Incentivar a comunicação: Uma métrica deve incentivar a comunicação sobre ela entre os membros da equipe, sendo um bom sinal quando as pessoas comentam sobre ela;
- Pertencer a um conjunto pequeno de métricas: É impossível medir tudo, e muita informação pode esconder o que realmente importa. Com um número pequeno de métricas, busca-se medir apenas o que é mais importante;
- Fornecer feedback frequente: As métricas devem ser frequentemente atualizadas e expostas, de forma a acelerar o processo de aprendizado e melhoria.
Alguns exemplos de métricas que podem ser úteis:
Quantidade de interrupções
Desenvolver software exige um grande nível de concentração. Equipes que sofrem muitas interrupções externas perdem a concentração com frequência e isso, normalmente, prejudica a execução de suas tarefas.
Pode ser criado um indicador de interrupções, que explicite para os membros do time e pessoas externas a quantidade de solicitações externas ao projeto que fizeram com que os membros da equipe tiveram de interromper suas atividades.
Esse indicador pode ficar, por exemplo, no quadro de tarefas do time. Dessa forma, o quadro refletirá não só o trabalho executado e restante, como também a quantidade de interrupções. Um eventual atraso da sprint poderá estar explicado, dessa forma, no próprio quadro pela quantidade de interrupções.
Uma vantagem desse indicador é inibir as pessoas de interromperem o trabalho do time, pois dá uma noção clara do quanto essas interrupções são prejudiciais.
Pareamentos
Equipes ágeis gostam de programar em par, e essa prática é encorajada por todas as metodologias ágeis, principalmente por promover a propriedade coletiva do código.
No entanto, para que a propriedade do código seja realmente coletiva o ideal é que os pares revezem constantemente.
Pode ser criada uma tabela que mostre a quantidade de pareamentos realizada entre os membros do time, explicitando os pares menos frequentes (Figura 2).
Figura 1: Tabela de Pareamentos
Valor entregue
Metodologias ágeis são guiadas pela entrega de valor. Parece fazer sentido, portanto, a existência de uma métrica relacionada a quanto valor a equipe está entregando.
Essa quantificação deve ser feita pelo Product Owner, no caso do Scrum.
Uma forma seria quantificar, em cada história de usuário o seu valor para o negócio (em forma de número ou valor financeiro, por exemplo) e, ao final de uma sprint, a equipe somar o valor de todas as histórias prontas, atualizando a sua métrica de valor entregue.
Quantidade de itens não previstos
Itens que devem ser realizados durante uma sprint e que não foram previstos durante a reunião de planejamento impactam diretamente no resultado final da sprint.
Pode ser uma boa ideia medir a quantidade de trabalho não previsto que está sendo identificada no decorrer das sprints e, a partir dessa métrica, buscar identificar o que está faltando na reunião de planejamento da sprint.
O quadro branco
O quadro branco (ou kanban) é o "palco" perfeito para conter as métricas da equipe. Ele fica visível para todos e, por natureza, já contem algumas métricas como o trabalho restante da Sprint (na forma de post-its e do gráfico BurnDown), além da quantidade de trabalho não previsto e outras coisas que a equipe julgar necessário.
Finalidade
Como já foi dito, cada equipe pode sentir necessidade de métricas específicas. No entanto, uma métrica deve nascer de uma necessidade da equipe e não o contrário.
Uma métrica está relacionada a uma fraqueza da equipe e deve ser utilizada, em conjunto com ações de melhoria, para medir o quanto a equipe está melhorando em relação a ela.
Caso a fraqueza deixe de existir, a métrica passa a não fazer mais sentido podendo ser abandonada.
Manter métricas apenas pelas métricas é um desperdício de tempo e esforço.
Quando as métricas são nocivas para a equipe
Métricas podem ser nocivas para a equipe, dependendo do enfoque com que são criadas.
Diz-se que a simples observação de um processo pode alterar o seu resultado.
Caso, por exemplo, seja criada uma métrica de "Quantas histórias cada desenvolvedor finaliza em uma sprint" teremos o cenário onde os desenvolvedores buscarão melhorar seu índice nessa métrica, passando a agirem de forma individualista em detrimento do time, perdendo-se assim o espírito de colaboração.
Da mesma forma, métricas relacionadas à quantidade de pontos realizadas em uma sprint podem levar a equipe a aumentar inconscientemente a quantidade de pontos de cada história, o que resultará em uma "melhora" do índice, sendo que efetivamente a equipe não produzirá mais.
Bom, por hoje é isso. Foram apresentadas algumas sugestões de métricas. Qualquer dúvida, ou sugestões de métricas diferentes, fiquem à vontade para colocar nos comentários. Abraços.
