Rafa Nascimento

Como medir a produtividade de times ágeis

Posted in métricas by Rafa Nascimento on 22/10/2012

Um dos mantras mais repetidos em uma cultura ágil é “melhoria contínua”. Porém, pouco se faz de fato para facilitar o surgimento de um verdadeiro fluxo de melhoria contínua em um time ágil. Na maioria das vezes, apenas retrospectivas lúdicas com dinâmicas que visam diminuir o tormento de mais uma reunião e que, com o passar do tempo, por conta de resultados superficiais, perdem o efeito “suavizante” que deveriam ter para que a reunião gere um bom plano de ação. Então, como podemos tornar nossas retrospectivas mais produtivas e factuais? Como podemos ajudar nossos times na árdua tarefa de aferir a sua própria performance? Eis a maneira que encontrei de endereçar estes problemas.

Segundo Patrick Lencioni, em seu livro The 5 Dysfunctions of a Team, um time não pode ser considerado um time de verdade se o mesmo não é capaz de aferir os seus próprios resultados e reagir conforme a informação conhecida. Isso porque não é possível melhorar o seu processo se não há um histórico no qual se basear. A melhoria contínua, enfim, só se torna realidade quando é possível concluir que aspectos do processo são passíveis de melhoria, através de métricas.

Em muitas empresas, métricas são vistas como vilãs pelos times de desenvolvimento de software. Isso porque, durante muito tempo, as métricas foram utilizadas, em grande parte, para promover verdadeiras “caças às bruxas” em times que não vinham colhendo bons resultados. Ou seja, as métricas eram utilizadas, tardiamente, para buscar culpados por falhas e insucessos em projetos. Algumas vezes, métricas eram utilizadas sem um propósito claro, e sim pelo simples fato de que elas deveriam existir, perdendo-se excelentes oportunidades de descobrir problemas antes que eles acontecessem.

Para facilitar o processo de melhoria contínua no meu time, me fiz a seguinte pergunta: o que é interessante como métrica para o meu time, e ao mesmo tempo enxuto? Que métricas deveriam estar presentes em seu dashboard? E para responder a estas perguntas, recorri ao livro Agile Project Management, de Jim Highsmith, e ao triângulo da agilidade proposto por ele.

Segundo Highsmith, projetos ágeis devem buscar o equilíbrio entre valor agregado ao negócio, qualidade técnica e as restrições tradicionais de um projeto (tempo, custo e escopo). Tendo em vista estes prismas, criei um dashboard que oferece métricas para aferir os dados de cada um deles. O dashboard, então, fica dividido em 3 partes: o quão efetivo o time está sendo em trazer valor para a empresa que comprou o projeto, o quão efetivo o time está sendo em desenvolver um produto de alta qualidade e o quão efetivo o time está sendo em entregar valor e qualidade dentro das restrições de tempo, escopo e custo do projeto.

Para o prisma de valor agregado, por exemplo, utilizo-me de métricas como velocidade (quantidade de story points que um time á capaz de entregar por iteração), lead time (tempo decorrido entre o pedido de uma feature e a disponibilização da mesma em produção) categorizado por story points, tail (tempo decorrido entre a conclusão de uma feature e a utilização da mesma pelo usuário final) e cumulative flow (representando o tempo que cada passo do processo consome durante o desenvolvimento das features).

Para o prisma de qualidade interna, realizo, por exemplo, medições como a quantidade de pares distintos que estão sendo formados por iteração, a quantidade de releases com features e com bug fixes e a quantidade de quebras do CI por iteração.


Por fim, utilizo, por exemplo, um burndown por story points do trimestre e um gráfico de alocação de horas do time categorizado por tipo de atividade para o prisma das restrições de projeto (um empréstimo da galera da Globo.com!).

Desta forma, deixo visível para o meu time a performance de cada iteração e podemos discutir de uma forma mais factual as possíveis melhorias no nosso processo. Retrospectivas lúdicas são úteis em determinadas ocasiões e momentos do time, mas há momentos em que a melhor opção é vasculhar os dados históricos para encontrarmos possíveis pontos de melhoria que talvez não seriam vistos a “olho nu”.

Anúncios

7 Respostas

Subscribe to comments with RSS.

  1. Rafael Miranda said, on 22/10/2012 at 17:56

    Muito interessante. Parabéns pelo post. Estou numa fase justamente em que sentimos necessidade de ter mais apoio de métricas para guiarmos nossas retrospectivas e seu post caiu como uma luva! 🙂

    No livro recente do Jeff e Ken (http://www.amazon.com/Software-30-Days-Customers-Competitors/dp/1118206665), eles fazem sugestões de algumas métricas para acompanhamento de times ágeis usando Scrum. Basicamente: Produtividade (funcionalidades/valor inve$tido); Qualidade (defeitos por funcionalidade usada a 3 meses pelo usuário final); Valor (quão efetivo é o $ investido). Fica aí o complemento.

    Abraços!

    • Rafa Nascimento said, on 30/10/2012 at 9:31

      Obrigado Rafael! 🙂

  2. Ester Lima de Campos said, on 23/10/2012 at 9:59

    Rafael!

    Muito bacana seu post!!! Realmente “A melhoria contínua só se torna realidade quando é possível concluir que aspectos do processo são passíveis de melhoria, através do uso de métricas”.

    Das métricas apresentadas algumas eu me utilizo delas e outras não. No entanto, a de alocação de horas me chamou a atenção pelo seguinte:

    – como você fez na prática para medir esse tempo? Deixou a cargo da equipe, de alguma ferramenta que automatizasse essa medição e ao final da sprint informasse esses tempos categorizados ou você quem foi medindo em função da presença diária junto a equipe e acompanhamento da mesma?

    Abraços,

    Ester Lima de Campos

    • Rafa Nascimento said, on 30/10/2012 at 9:30

      Oi Ester!

      A medição aconteceu como um misto do que você disse. Diariamente eu anotava as horas alocadas em cada tarefa, que a equipe apontava. Estas horas eram anotadas em uma ferramenta que me oferecia as categorias e, por fim, gerava o gráfico!

      Abs!

  3. Rodrigo Pires said, on 15/11/2012 at 10:20

    Rafael, show de bola o artigo.

    Aliás, assisti também uma palestra sua no AgileBR em SP e gostei bastante.

    Sobre esse artigo, por acaso vc teria como disponibilizar (ou indicar) planilhas ou templates para inputar os dados e gerar esses gráficos?

    Obrigado!

    • Rafa Nascimento said, on 15/11/2012 at 16:08

      Oi Rodrigo!

      Obrigado!

      Vou compartilhar a planilha com vc, mas ainda há muito o que automatizar e completar nela, ok?

      Abs!

      • Rodrigo Pires said, on 16/11/2012 at 11:23

        Opa blz!!

        Vc vai passar o link aqui? Se quiser manda no meu email por favor: rodrigopires[at]gmail.com

        Valeu!


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: