Primeiramente, um dos principais benefícios do gerenciamento de riscos se torna desnecessário quando um projeto usa a abordagem ágil. As iterações curtas, o foco em software funcionando, a ênfase em testes automáticos e a entrega frequente ao cliente ajudam o time a enfrentar o maior risco que a maioria dos projetos enfrenta: o de não conseguir entregar o produto. Portanto, o que acontece em muitos projetos ágeis é o gerenciamento implícito de riscos. Para eles, o custo do gerenciamento explícito de riscos se sobrepõe aos benefícios.

Mas, apesar de serem muitos os projetos que podem (e devem) tratar os riscos de tal maneira, outros se beneficiam de gerenciá-los explicitamente. Para isso, John Brothers introduziu uma técnica em 2004 chamada de Risk Burndown Chart, ilustrado na figura abaixo:

Figura: Risk Burndown Chart. A linha vermelha é o parâmetro base da redução do risco ao longo das iterações, enquanto que a azul é a atualização da situação real.

Basicamente, o gráfico mostra a exposição do projeto ao risco ao longo das iterações. A Exposição ao Risco é calculada considerando o tamanho do impacto (em dias) do risco e a sua probabilidade de acontecer. Como exemplo, um risco do atraso do projeto em 15 dias, com 20% de chance de ocorrer, dá uma exposição ao risco de 5 pontos.

Olhando para o gráfico acima, vemos que o risco não tem diminuído a uma taxa apropriada (nem perto disso). Quando isso ocorre, o time pode requisitar dedicar algum tempo no próximo Sprint para trabalhar diretamente com mitigação de riscos.

Como podemos ver então, é possível sim levar a sério o gerenciamento de riscos em projetos ágeis a ponto de explicitá-lo. Se for necessário, o Risk Burndown Chart é uma útil ferramenta.

Por fim, é bom não confundir  “não levar o gerenciamento explícito a sério” com “não levar o risco a sério”. Vimos neste texto que o risco sempre é tratado em projetos ágeis, seja explicita ou implicitamente.

Este artigo foi adaptado do post original no blog do Mike Cohn, que pode ser encontrado clicando aqui.

O processo é simples: o candidato se submete treinamento de 16 horas e, no final, o CST (Certified Scrum Trainer) julga se ele está apto ou não a receber a certificação. Parece fácil, mas não é bem assim. A turma era pequena (oito pessoas), e durante dois dias os candidatos não permaneceram um segundo sequer parados, seja participando de dinâmicas, fazendo exercícios que colocam o cérebro para funcionar ou ainda sendo questionados pelo instrutor sobre como aplicariam em suas realidades particulares o conhecimento passado naquele minuto.

Já trabalho efetivamente há dois anos com Scrum, e achava que sabia exatamente qual era papel do PO, ele era o cliente presente, que avaliava continuamente o trabalho do time e priorizava as demandas. Depois do curso, vi que era muito mais do que isso: ele é o cliente que participa de forma totalmente engajada no projeto, e é quem tem o pescoço mais comprometido de todos. Isso mesmo, mais do que o Scrum Master e o time de desenvolvimento. Por isso, ele influencia massivamente (mesmo que indiretamente e utilizando-se de técnicas e artifícios) o processo de desenvolvimento.

Se o Scrum Master é responsável pelo sucesso do Scrum no processo, o Product Owner é quem deve garantir o sucesso do projeto. Ele é cliente, patrocinador e maior conhecedor do escopo do produto. É ele o responsável pelo ROI (Return On Investment – Retordo do Investimento), e mais ninguém.

No treinamento, o participante aprende como determinar o tamanho de Releases e Sprints, estimar a Velocity do time, facilitar o trabalho deste último de várias formas, atuar para influenciar positivamente a produtividade sem sobrecarregar o time e, o mais importante: calcular o ROI e priorizar requisitos de acordo com ele, de forma que se possa entregar o máximo de valor de negócio no tempo mais curto possível no projeto. Algo como 80% do valor de negócio total em 20% do tempo, em uma situação ideal. Outro momento importante, é lógico, são as situações práticas, onde, por exemplo, o instrutor faz propositalmente os candidatos errarem e se sentirem perdidos e em seguida mostra como agir rapidamente para adaptar o projeto às mudanças que o mercado, o negócio em si e os stakeholders em geral fazem ser necessárias para continuar entregando business value.

O treinamento também me abriu outra nova visão: o quanto precisamos de capacitação, não só nas empresas que desenvolvem e fornecem software, mas também naquelas que adquirem. Um bom Product Owner, segundo o Michel, aumenta o ROI do projeto em até dez vezes. Isso significa que o cliente deve se capacitar, para extrair até a última gota de retorno sobre seu investimento ao fazer um contrato de desenvolvimento de software com seu fornecedor, o que é extremamente importante em no mercado competitivo em que vivemos.

Voltei de Recife como CSPO, mas mais importante, com outra cabeça, com novos objetivos, com a proposta (para mim mesmo) de disseminar esses conhecimentos por aqui, começando no trabalho. No futuro, quem sabe, em outros lugares. Confesso que, devido ao valor relativamente alto, fiz o investimento com um certo medo de ter feito um mau negócio. Passado o treinamento, estou totalmente satisfeito, e recomendo-o firmemente, principalmente àqueles que gostaram ou se identificaram com o post anterior deste blog.