BT
x A sua opinião é importante! Por favor preencha a pesquisa do InfoQ sobre os seus hábitos de leitura!

Sinais vitais de um projeto ágil: saúde através de indicadores

Postado por Paulo Rebelo em 17 Dez 2011 |

Da mesma forma que as pessoas precisam constantemente acompanhar e avaliar seu estado de saúde, os sinais vitais de projetos precisam ser monitorados, desde o início. A análise e a monitoração dos principais indicadores da saúde de um projeto ganham interpretações e prioridades diferentes nos projetos ágeis, que focam principalmente em transparência, visibilidade, simplicidade e medidas quantitativas.

Com pessoas, quando algum problema começa a aparecer, o médico diagnostica e receita intervenções em busca da reestabilização do paciente, analisando alguns indicadores importantes como pressão arterial e temperatura.

Medindo a equipe

Nos projetos ditos tradicionais, geridos com práticas do guia PMBoK por exemplo, o foco se concentra primordialmente em quatro indicadores: escopo, prazo, custos e qualidade. Já em projetos que utilizam as práticas e a filosofia Agile, entretanto, a equipe aparece como um indicador de peso e ganha destaque sobre os demais. Isso vem do próprio Manifesto Ágil no que diz respeito a focar mais nos "indivíduos e interações" que em "processos e ferramentas".

A medida do indicador da equipe deve refletir o nível de satisfação dos membros e se cada um está motivado e confiante sobre as entregas do projeto ou se atenderá as expectativas do cliente. Essa medida deve ser coletada com frequência determinada, ser transparente a todos e ser mostrada até mesmo no quadro do time. A partir das notas atribuídas pelo time (de 1 a 5, por exemplo), pode-se elaborar um gráfico e acompanhá-lo a cada iteração.

Sobre esse assunto, vale a pena a leitura de dois excelentes artigos (títulos traduzidos): "A porta da felicidade, outro excelente método de feedback", de Jurgen Appelo e "A métrica da felicidade - a onda do futuro", de Jeff Sutherland.

Escopo, tempo e orçamento

Para os demais indicadores, como escopo, custos, prazos e qualidade, algumas modificações na forma de coleta e avaliação se fazem necessárias, a fim de tornar o processo mais simples e transparente para os projetos ágeis.

Para acompanhamento do escopo, por exemplo, um Scope Burn-Up, que rastreia o escopo e prazo para exibir a data de entrega prevista (ou Diagrama de Fluxo Cumulativo) traz informações valiosas e consolidadas de fácil interpretação. Ele retrata a saúde do projeto de acordo com o ciclo de desenvolvimento ágil, que vai desde a concepção de uma história (estado de preparação) até o momento em que ela é efetivamente implantada em produção (released). Veja o gráfico abaixo, extraído da ferramenta Rally (projeto interno da empresa onde trabalho):

Da análise do Scope Burn-up é possível avaliar, por exemplo, se a taxa de histórias aceitas (Accepted) acompanha o crescimento de histórias completas (Completed), o que pode indicar um risco de possível retrabalho, caso as histórias completas não sejam aceitas com a mesma velocidade com que são concluídas. Outra análise que é possível fazer deste gráfico é o grau de maturidade das histórias no tempo, pode-se ter um sinal de alerta caso existam muitas histórias não definidas aproximando-se da data final do release.

Em se tratando de tempo e duração do projeto, o Release Burndown pode ser empregado, pois apresenta um panorama geral da situação do projeto em relação ao prazo e a tendência, de acordo com os dados reais e previstos.

Munido destas informações é possível antever atrasos nas datas e períodos acordados, trazendo a necessidade de investigação da causa raiz, e eventual negociação e colaboração com o cliente sobre o andamento do projeto.

Já para o acompanhar e tratar os desvios no orçamento do projeto, faz-se uso de um Budget Burn-Down. O gráfico abaixo demonstra o estado do orçamento de um projeto em relação ao escopo entregue. Ele exibe gradativamente o que é consumido do orçamento original dentro de um período estipulado e compara com o que foi planejado.

Mas somente esta análise pode não trazer todo contexto e expectativa de valor das entregas e do avanço do projeto. A sugestão é também acompanhar o valor de negócio do conjunto de histórias entregues e medi-las a cada iteração.

Por exemplo, após a entrega da funcionalidade, que permite ao usuário votar e comentar em um estabelecimento, qual será o índice de crescimento de audiência previsto naquele site? Quanto isso vale para o cliente e o quanto está aderente aos objetivos principais do projeto? Outro exemplo: após a unificação do envio de SMS para todas as operadoras, qual será a redução do tempo no uso da ferramenta? Qual o valor percebido desta funcionalidade em comparação com as demais?

A ideia consiste em classificar cada história por critérios estabelecidos e selecionados pelo Product Owner (exemplo de um critério: agilidade na publicação de um conteúdo em um sistema CMS), pontuando-os por meio de notas (exemplo: 0 a 5), sendo que cada critério tem um peso balanceado e comparado entre os demais. O resultado é a somatória dos produtos das notas de cada critério pelos pesos atribuídos a eles. Portanto, em uma iteração, tem-se esse resultado em pontos de valor de negócio, possibilitando assim o acompanhamento do valor entregue ao cliente a cada iteração.

Qualidade e dívida técnica

Para monitorar a qualidade do produto, por fim, é importante manter sempre visível para o time a quantidade de bugs abertos e traçar metas para a redução destes bugs. Uma meta que algumas empresas adotam é finalizar o sprint sem bugs ou a política de "bugs zero", em que uma história só é considerada finalizada se não possuir bugs associados.

Em alguns cenários estas metas podem ser especialmente difíceis de serem alcançadas. É possível nestes casos trabalhar com a severidade dos bugs e tratar os de menor severidade em outro momento (fora do sprint atual). Existem situações em que alguns bugs são até aceitos pelo cliente, pois não comprometem totalmente a utilização do produto final por parte dos usuários e para os quais o custo-benefício de sua correção não valeria a pena.

Da mesma forma que os bugs, as dívidas técnicas também podem assombrar um projeto e precisam de monitoração constante. Um gráfico visível do número de dívidas técnicas por sprint pode dar uma boa visão sobre tendências e gerar ações pontuais de refatoração quando essas dívidas não estiverem diminuindo naturalmente.

O tratamento da qualidade é bastante discutido e vale analisar os principais fatores de qualidade que sua empresa e clientes adotam a fim de determinar os melhores indicadores.

Conclusões

Neste breve artigo, vimos alguns exemplos de indicadores dos sinais vitais e sua forma de consolidação em projetos ágeis. Os indicadores geralmente são mais efetivos, se mostrados em gráficos claros, disponibillizados para toda a equipe, preferencialmente no quadro onde são realizadas as reuniões diárias. Ajudam a criar um ambiente mais transparente, com metas claras e uma noção global do progresso da equipe.

E você? Quais indicadores utiliza para acompanhar a saúde dos seus projetos?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Indicadores, métricas e alertas by Thiago Diogo

Olá Paulo, primeiramente parabéns pelo artigo pois é muito difícil ver esse nível de maturidade em discussões ágeis, geralmente o foco é perdido.

Onde trabalho estamos implantando agora a gestão por indicadores. Usamos Scrum em cada projeto em execução e também na gestão desses projetos, através de um Escritório de Projetos. Esse Escritório faz medições a cada Sprint (métricas) e com isso temos indicadores para tomarmos decisão e detectarmos problemas antes que eles aconteçam ou aumentem.

Trabalhamos com 4 indicadores: qualidade (qtd de testes unitários e de aceitação, cobertura,etc), aderência ao processo(reuniões diárias realizadas, review e retrospectiva realizadas, etc), desempenho (qtd de pontos entregues, qtd de tarefas fechadas, etc) e valor agregado (visitas ao sistema web, etc) - quase todos coletados diretamente no Redmine da empresa e alimentam um dashboard de acompanhamento.

Na minha opinião o indicador mais importante num projeto é o valor entregue no fim do Sprint. A minha dúvida é como medir a satisfação do usuário depois que aquela funcionalidade vai para o ar? Pensamos em número de visitas (google analytics) que aquelas páginas obtiveram em produção, número de diferentes visitantes no site, tempo de permanência na página, etc... Mas buscamos algo mais "real". Estamos pensando em desenvolver algo como um link em todas as páginas dizendo "Avalie o sistema" para coletar essa percepção do usuário em tempo real.

Outra dificuldade é saber como avaliar os dados coletados. Ou seja, definir os alertas que queremos, por exemplo, se chegarmos no meio de um Sprint e 50% das atividades ainda não foram alcançadas, acender um sinal amarelo e se chegarmos a 80% do tempo do Sprint e nem 80% das tarefas/storias ainda não foram fechadas, então um sinal vermelho se acende...

Mais uma vez parabéns pelo artigo!

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT