O Pessoal do Kudoos entrevistou a mim, Manoel Pimentel e Rodrigo Yoshima para saber como nós encaramos os seguintes temas: “Gestão de riscos no Agile” e o movimento do “No Estimate”, em suma Riscos e Estimativas. Leia o post completo do site do Kudoos para ver todas as respostas.

Agradeço imensamente ao Kudoos que tem prestado um grande serviço à toda a comunidade brasileira de gestão e agilidade, e de forma especial agradeço ao meu grande amigo Leonardo Campos.

Minhas Respostas

A gestão tradicional de projetos (PMBOK) traz a gestão de riscos como uma área de conhecimento que permeia praticamente todas as fases do projeto. Você adota alguma(s) prática(s) específica(s) para gerir os riscos em suas implementações?

Acredito que a melhor forma de lidar com riscos é não apenas reconhecer que eles existem, mas também reconhecer que nem sempre podemos nos prevenir de todos eles. Em software há muita incerteza. Incerteza de custo, de prazo, de escopo de funcionalidade e incertezas de tecnologia, só para citar algumas. Nesse sentido concordo com o PMBOK, os riscos são transversais.

O desenvolvimento ágil de software trabalha ciclos curtos de feedback e, isso, ao meu ver, é uma das melhores ferramentas para se lidar com riscos e diminuir o impacto de todas essas incertezas que temos.

Uma prática bem simples e eficiente apresentada no Agile Brazil 2013 por Paulo Carolli e Tainã Caetano, é criar uma matriz de riscos técnicos e funcionais nas reuniões de planejamento. Basicamente, o time posiciona cada uma das histórias planejadas em um nível de incerteza técnica e funcional. Se o nível de incerteza for alto, podemos tomar alguma atitude para reduzir o risco, como entrevistar especialistas de negócio ou fazer code spikes para conhecer melhor a tecnologia a ser aplicada.

Um movimento que vem ganhando força é o do “no estimate”, que alega ser um desperdício estimar o esforço do trabalho. Qual seu pensamento a respeito?

Eu penso que é preciso estimar se houver valor em se ter previsibilidade ou se trouxer algum outro benefício, seja para o time de desenvolvimento, seja para outros interessados (marketing, executivos, etc.). Fora isso é desperdício.

Na Bluesoft, por exemplo, há alguns anos estimávamos utilizando story points nos planejamentos quase que semanalmente, isso demandava algum tempo, mas nos trazia alguma previsibilidade, e isso nos era útil para planejarmos releases futuras.

Atualmente conseguimos uma previsibilidade aceitável (para nós), basicamente acompanhando a vazão (throughput) semanal de cada equipe, e procurando manter as histórias sempre pequenas para reduzir um pouco a variabilidade. Ou seja, apesar de não estimarmos, conseguimos ter a previsibilidade que precisamos, de forma que agora estimar, para nós, seria desperdício.

Acredito que estimativas, quando tratadas como estimativas e não como compromissos, ou seja, quando é reconhecido o alto grau de incerteza que, geralmente existe, podem ser úteis em alguns contextos sim, mas é importante tornar explícito qual é o valor que se está buscando com essas estimativas, e considerar se não há outras formas mais eficientes de se alcançar esse mesmo valor.