Métricas em Desenvolvimento Ágil

Saudações!
Estive atrás de informações sobre métricas aliadas ao desenvolvimento Ágil, já que é necessário mensurar o desempenho e validar o estado atual de um projeto.
A pesquisa foi muito melhor do que eu imaginava. Além de regras e fórmulas, encontrei um material bastante pertinente a respeito, inclusive uma edição inteira do Agil Journal falando sobre o tema
Farei uma pequena contextualização antes de continuar:

Deviado ao custo elevado em se manter um departamento de TI (profissionais caros e equipamentos mais caros), são necessários métodos de mensurar o desempenho e garantir que o dinheiro investido não está indo para o ralo. Infelizmente à medida que nos aprofundamos no assunto, seguindo modelos tradicionais de desenvolvimento e desempenho, verificamos que falta clareza na utilização de ferramentas de mensuração, e que estamos a todo momento medindo aquilo que não é importante, deixando de lado o que realmente justifica a utilização da TI: a agregação de valor ao negócio. Ao invés disso, o foco das medidas está em atributos de software e quantidade de dinheiro dispendido. Entre essas medidas podemos citar: pontos de função criados, horas trabalhadas, número de linhas de código por desenvolvedor ou ainda orçamento gasto. Aliado à falta de estrutura para receber tais dados esse relatórios fazem que os itens tenham seu valor superestimado, criando uma visão míope do projeto.

Medidas como linhas de código por desenvolvedor ou horas trabalhadas sempre levam a problemas muito maiores para o projeto. Um programador, quando cobrado em linhas de código, evitará qualquer tipo de reutilização ou refactoring que aumente a qualidade do código para que possa parecer produtivo. Ou ainda ele poderá degradar-se completamente ao trabalhar a mais do que o necessário, criando dificuldades de relacionamento e de participação no projeto (lembrem da prática: Semana de 40 horas). Perceba a complexidade que é criar e fomentar tais medidas.

Tradicionalmente atribuimos uma medida de produtividade aos indivíduos do projeto. É pior ainda! Uma equipe deve possuir uma identidade única, que é projetada ao mundo externo como reflexo de seu comprometimento com o projeto, e não como uma série de indivíduos que trabalham por si em detrimento do grupo. Pois é isso que acontece ao medir produtividade individual das pessoas da equipe. Uma equipe deve competir para ser a melhor dentro de toda a organização. Não acredito que gerentes queiram uma equipe que disputa para ver quem é o melhor dentro dela mesma.
Mike Griffths apresenta sua visão sobre isso de forma bastante interessante em seu artigo. Baseado no Efeito Hawthorne, que demonstrou a mudança de produtividade de trabalhadores através do simples fato deles terem conhecimento da medição de produtividade, Mike apresenta a idéia de que uma medição efetiva não deve em nenhum momento atrapalhar a qualidade do projeto (medir linhas de código não é o caso), e deve estar direcionado a elementos chave para o desenvolvimento. Ele cita também um modelo de seleção de métricas definido por Donald Reinertsen:

Primeiro, deve ser simples, métricas ideais são geradas automaticamente no sentido de que não é necessário esforço extra para serem produzidas. Segundo, elas deve ser relevantes. Isto é, o controle deve ser feito pelas mesmas pessoas que estão sendo medidas. Psicólogos já descobriram que quando as pessoas acreditam que podem controlar alguma coisa, elas estarão mais motivadas para controlá-la. Mensurar uma equipe por algo que ela não tem controle apenas causará estresse, insatisfação e alienação. Terceiro, deve ser focado em indicadores de condução. Meça olhando para o futuro, e utilizando tais dados para relatar o passado. É mais fácil medir o tamando de uma fila de testes do que é medir o tempo de processamento dos testes individuais pelo fato de que o tamanho da fila é um indicador de condução para futuros atrasos no processamento do teste.

Modelos ágeis em sua concepção já promovem um jogo completo de métricas que podem ser coletadas de forma trasparente. Testes unitários, análise da qualidade de código e outras medidas técnicas podem ser automatizadas no processo de Integração Contínua. A unidade comum de trabalho - o história - é o fundamento para medidas de gerenciamento de projetos e qualidade de alinhamento de negócio. É importante lembrar que todo o ferramental existe para dar suporte a isso, e que se deve encarar este modelo de métricas com uma visão global.

Ross Pettit, em seu artigo, propõe a seguinte categorização:

• Excelência em desenvolvimento: Consolidando objetivos para medição de código. Não deve ser analizado em separado, pois causará distorções graves.


• Qualidade: medidas de defeitos que possam escapar ao desenvolvimento bem como o alinhamento entre desenvolvimento e especificações funcionais.


• Sensibilidade ao negócio: para os modelos ágeis, requisitos são assumidos como user stories, tornando-se a real expressão do valor de negócio. Podem ser medidas como o grau de valor objetivado e o grau entregue.

Exemplos reais de métricas e relatórios

CFD - Cumulative Flow Diagrams
Bastante Interessante! Ele seria o complementar ao BurnDown Chart do Scrum, trazendo a relação de requisitos completos, requisitos restantes e requisitos em desenvolvimento.

No exemplo acima, o progresso é indicado pela completude da faixa verde no decorrer do projeto. Importante notar a mudança de proporção relacionada à faixa superior, indicando aumento de user stories no decorrer do projeto. Esta mudança pode indicar um problema relacionado à comunicação entre produto e desenvolvedores.

Parking-Lot Chart
Ouvi falar a primeira vez desse gráfico com Mike Cohn no livro Agile Estimating and Planning, e achei extremamente interessante! A ideia é utilizar agrupadores para reunir requisitos com o mesmo domínio e montar um grafico contendo Dominio, Numero de historias em cada dominio, numero de pontos de historia e a completude. A coisa fica mais ou menos assim:


Retirado do site Feature Driver Development
Pode-se ter uma visão bastante real do estado atual do projeto.

Ambiente Informativo
Apresentado na xpRio, na discussão a respeito de um Ambiente Informativo, Alisson Vale mostrou um modelo muito claro para trabalhar com a equipe:

Acredito que a imagem seja suficientemente auto explicativa.

RTF: Running, Tested Features
Representa a quantidade de requistos estão passando em todos os testes de aceitação. É facilmente gerado utilizando ferramentas automatizadas de teste e Teste de aceitação. Idealmente deve parecer com a imagem abaixo:

Também conhecido como Burn-Up chart. Qualquer anomalia no comportamente desta imagem deve ser encarada como um problema, já que, teoricamente, os requisitos implementados devem passar em todos os testes sempre.
Uma ótima referência para este tipo de teste pode ser encontrado aqui.


Outras medidas

Satisfação do Cliente: Determinada nos encontros entre de definição das iterações, podendo ser feita com um questionário simples de satisfação e representada através de imagens/cores. Medida interessante de ser trabalhada, pois deixa a equipe com o real estado de aceitação que o cliente se encontra.

Code coverage (quantidade de código coberto por testes)

Builds feitos com sucesso (por sprint, por semana, por dia)

Builds não realizados (por sprint, por semana, por dia)




É isso senhores... espero que tenha sido proveitoso.