A Lambda3 há anos costuma ajudar empresas a ir mais longe com a agilidade. Já ajudamos empresas de todos os tamanhos a usar agilidade, realizando consultorias de todos os tipos (Scrum, XP, FDD, engenharia, etc). Mas é nos clientes grandes que costuma aparecer uma questão delicada no mundo ágil: como gerenciar os riscos. A resposta padrão do agilista iniciante é dizer: “não precisa, o meu framework ágil predileto já tem isso embutido!” Ledo engano.

É fato que os frameworks ágeis trazem muito da gestão de risco dentro de cada processo, de cada atividade. As próprias ideias do feedback constante, e da iteração, permitem que erros aconteçam e sejam resolvidos em pouco tempo. Isso dá a impressão de que qualquer risco é mitigável, porque se acontecer saberemos em pouco tempo e teremos tempo para lidar com ele. Só que não é sempre assim.

Projetos curtos, menos críticos, certamente não precisam de uma preocupação maior com o risco. De fato, a gestão de riscos intrínsica dos frameworks ágeis resolve o problema. É nos projetos mais complexos e críticos que um cuidado maior com os riscos vale o esforço extra.

(Observação: Agilistas, mantenham a calma nos próximos parágrafos, estou indo a um lugar, no final há uma conclusão)

Antes de entrarmos a fundo no modelo que estamos acostumados a propor, é uma boa ideia termos uma forma de calcular o tamanho ou importância de um risco. Há várias maneiras de fazer isso, vou propor uma bem simples: o risco é um fator da sua probabilidade de acontecer, e do seu impacto. Assim, um risco com ínfimas chances de acontecer, ainda que tenha um alto impacto, poderia ter um produto final pequeno. Por exemplo, alguém do time, composto por pessoas com menos de 30 anos e saudáveis, morrer de infarte:

0.01% (probabilidade) x 9 (impacto): 0.009 (resultado)

Já o risco de esquecermos de cobrir uma funcionalidade importante com um teste é algo que pode acontecer frequentemente, digamos, uma em cada dez funcionalidades, e pode impactar fortemente o resultado, já que estaremos sem testes de regressão em algo crítico, que pode vir a quebrar depois:

10% (probabilidade) x 6 (impacto): 0.6 (resultado)

Com isso, é possível elencar os riscos por importância, e então decidir estratégias diversas sobre os riscos em cada faixa, como por exemplo, mitigar (riscos muito importantes, por exemplo, acima de 0.5), observar (riscos médios, entre 0.1 e 0.5), ou ignorar (menos de 0.1).

Os números propostos são aleatórios. Cada projeto vai ter o seu. A escala de impacto poderá ser influenciada por impacto financeiro, no prazo, ou no produto final, ou ainda em itens menos palpáveis, como imagem da empresa.

Toda essa teoria de riscos é bem antiga, e costuma ser defendida principalmente pelos praticantes da gestão tradicional de projetos. O PMBoK tem um capítulo bem interessante sobre o assunto. PMPs e gerentes tradicionais estão bem acostumados a lidar com o assunto. Só que em geral, a gestão tradicional de riscos em projetos de TI se limita a uma planilha de Excel que as pessoas são obrigadas a preencher e sequer observam ao longo do projeto. E os riscos que de fato ameaçam o projeto geralmente não são observados de fato, geralmente por problemas políticos, incapacidade ou incompetência, ou todos esses. Problemas políticos predominam, já que algumas empresas  e alguns gerentes sequer querem ouvir que seus projetos estão sob risco.

Vamos sair desse lugar comum. Com a agilidade aprendemos a realizar a gestão lean, enxuta. As planilhas que não servem pra nada podem ficar com o modelo tradicional. Assim, que riscos nos interessam?

Um modelo que temos praticado é separar os riscos entre recuperáveis e irrecuperáveis. Os riscos recuperáveis deixamos para a gestão intrínsica de riscos dos frameworks ágeis. Qualquer desvio será rapidamente observado e corrigido. Assim, a opção destes riscos é clara: ignorar. O problema está nos riscos irrecuperáveis.

Imagine que estamos na metade do projeto, e o time não escreveu testes automatizados. Nem de unidade, nem integrados, nem funcionais, nada. Nem antes com TDD ou BDD, nem depois. Chegamos a 6 meses de projeto entregando iterativamente, batendo metas e o release burndown aponta que entregaremos as metas de negócio nos prazos estimados. E, de repente, a velocidade do time começa a cair. E cai rápido. Em 3 sprints os times estão quase à metade da velocidade. Conclui-se que o código está muito acoplado, difícil de ser mantido, e o time está com medo de evoluí-lo. Todo mundo sabe que esses são sintomas da falta de testes e de testes feitos antes do código. Só que agora já gastamos metade do orçamento do projeto, ainda não batemos todas as metas, e o código está impossível de manter. Ou jogamos o código for  e refazemos tudo certo desta vez, ou passamos vários meses cobrindo nosso recém feito legado com testes e refatorando. Nos dois casos, o projeto está a caminho do fracasso. Provavelmente, irrecuperável.

Um time maduro jamais se colocaria nesta posição. Por isso, gosto também de classificar os riscos conforme seus responsáveis. Há riscos onde o time é responsável, como os riscos que vem de não fazer testes. E há riscos onde a empresa, externa ao time, é responsável. Uma contratação, por exemplo, prevista para a metade do projeto, que o RH não entregou, é um risco externo ao time, e que pode impactar gravemente a entrega. E é possível que o atraso causado por essa contratação que não aconteceu, seja também irrecuperável. Até podemos dizer que isso é um impedimento, que o ScrumMaster teria que resolver. Mas isso não muda o fato de que é um risco externo ao time. Outro exemplo seria o financiamento do projeto ser encerrado antes da entrega dos valor de negócio por motivo de alguma crise. Risco irrecuperável que enterraria o projeto.

Além disso, uma contratação vai, em geral, levar diversas semanas para se concretizar. Provavelmente vai levar mais do que uma iteração. Nesse caso, o impacto não será sabido rapidamente, e o acompanhamento do risco vai também levar várias sprints. Quem faz este acompanhamento? O time? O ScrumMaster? O PO?

Assim, temos um gráfico que ajuda a visualizar:

Os frameworks ágeis vão agir perfeitamente bem para resolver os riscos que se apresentam nos quadrantes 3 e 4. No quadrante 1, os frameworks ágeis que tocam na engenharia, como o XP, também vão atuar diretamente. Para este quadrante, dependendo do time, valerá a pena mitigar ou observar.  E pra que todos, 1, 3 e 4 funcionem, precisamos de um time com ao menos alguns profissionais competentes e sêniors. Na maioria dos projetos não precisará que sejam todos do time. Os melhores instrumentos para a avaliação de risco destes tipos são os burndowns, que vão mostrar rapidamente qualquer desvio.

O problema está no quadrante 2. O projeto está sujeito a riscos que estão além do time, e que podem condená-lo ao fracasso. Estes riscos precisam ser acompanhados e monitorados por alguém. Estes riscos não podem ser ignorados. Em que papel estará essa pessoa, se será do time direto do projeto ou se será externa, qual sua função no projeto, etc, na minha experiência, muda de empresa para empresa, de projeto para projeto. Mas um fato permanece: ela não comanda ou controla o time. Ela tem os contatos para acompanhar o risco e mitigá-lo se for possível.

Não vou entrar nos específicos de como resolver cada caso, cada tipo de risco, já que isso seria impossível e eu me estenderia ainda mais. Só quero deixar aqui a mensagem de que gestão de riscos é algo maior que os frameworks ágeis, e que pode, e deve, ser feita em um projeto ágil que tenha tamanho ou criticidade para não suportar o impacto de um risco irrecuperável. Além disso, gestão de riscos de um projeto ágil deve ser também feita de forma ágil, respeitando os princípios do manifesto ágil: foco nas pessoas, comunicação, feedback, colaboração com o cliente. E nada de ficar com medo dos riscos, que devem ser encarados de frente, tanto pelo cliente do projeto, quando pelo time, PO e ScrumMaster.