Como utilizar indicadores em desenvolvimento ágil de software

Quem nunca ouviu a famosa frase de Deming, “não se gerencia o que não se mede, não se mede o que não se define, não se define o que não se entende, não há sucesso no que não se gerencia”?

Independente se o desenvolvimento é ágil ou não, a necessidade por informações e previsibilidade está presente. Neste cenário, entram os famosos indicadores, os quais deveriam servir para ajudar o time a atingir um objetivo. Mas a realidade nem sempre é essa, alguns inclusive têm o efeito contrário, fazem o time se distanciar ainda mais do objetivo.

E o que o manifesto ágil diz, explicitamente, sobre isso: “Software funcional é a medida primária de progresso”.
Vamos analisar este princípio, o primeiro termo é “software funcional”, ou seja, que funciona, que tem qualidade, isso indica que o desenvolvimento deve ser vertical e não horizontal.

A outra questão é a “medida primária”, isso significa que é a primeira, a mais importante de todas, após ela podem vir outras. Mas não adianta ter dezenas de indicadores, se você não consegue dizer se seu software funciona ou não. Por último, mas não menos importante, é a palavra “progresso”. Seu time pode estar trabalhando 12hs por dia e, ainda assim, não estar progredindo rumo aos objetivos do projeto, por isso, quantidade de horas e progresso não estão relacionados.

Lembrando que movimento não é progresso, por exemplo: realizar diversas atividades para construir a camada de banco de dados de toda a aplicação, é um progresso? É um software funcional?

Muitos times até começam com o indicador de “Software funcionando”, mas o abandona assim que ele indica a realidade do projeto: 0(zero) progresso. Como todo indicador serve para auxiliar no processo de tomada de decisão, tenho que concordar que decidir abandonar o indicador é o mais fácil a fazer.

Você não precisa resolver o problema de apenas livrar-se dele, pelo menos por um tempo, mas lembre-se de Deming “não se gerencia o que não se mede”.

Além da medida primária de progresso, quais outros indicadores utilizar? A resposta é: depende do contexto. Mas gostaria de apresentar pelo menos um indicador que vejo tendo o efeito contrário ao propósito original de ajudar o time a atingir um objetivo, e o qual não recomendo a utilização em um projeto ágil:

• Indicador: Transbordo
• Objetivo: Entregar mais itens por sprint.
• Descrição: É a quantidade de trabalho que não foi realizada dentro da sprint e teve que transbordar para a próxima sprint.
• O que ele indica: Para mim nada, porém alguém pensou que faria com que os desenvolvedores entregassem tudo o que foi planejado na sprint planning.
• Resultado: O time começa a se comprometer com menos trabalho, dadas as incertezas de um projeto de software. O indicador ficou ótimo, porém, o objetivo do mesmo era aumentar a produtividade e não reduzir.

Ao analisar o manifesto ágil e classificar cada um dos valores e princípios, cheguei na conclusão que os objetivos da agilidade são: Ter clientes satisfeitos, produto de qualidade e time engajado. Logo, eu busco criar indicadores que apontem para essa direção e acredito que todos os outros são distrações.

*Por Rodrigo Ramos, Software Delivery Manager na CINQ