Do you really ROAM?

Hello, leitores!
Sim, o título deste artigo é em inglês mesmo! O motivo é que o acrônimo ROAM pode ser usado como verbo no contexto de classificação e gestão de riscos durante uma Sprint ou um incremento de programa (Program Increment). Acompanhe o artigo para conhecer cada letra do acrônimo dessa ótima ferramenta do SAFe!

Introdução

Riscos acontecem em qualquer projeto e a qualquer momento. No desenvolvimento de software, os riscos podem ser encontrados em dependências entre módulos (ou equipes), restrições da tecnologia utilizada, integração entre diferentes sistemas ou até mesmo relacionados a recursos humanos, como as férias de um desenvolvedor. Porém, riscos não devem ser apenas identificados. Devem, também, ser controlados. Quando digo isso, não estou me referindo à severidade do risco, mas de como, quem e quando ele será gerido.

O framework SAFe (Scaled Agile Framework) fornece uma ferramenta produtiva para essa administração de riscos, conhecida como ROAM. Por meio dessa ferramenta, os riscos são classificados em quatro áreas:

• Resolved (Resolvido): O risco foi eliminado, ou seja, não prejudicará o projeto;
• Owned (Responsabilizado): Alguém ficará responsável por resolvê-lo;
• Accepted (Aceito): O risco foi reconhecido e todos estão cientes da possibilidade de sua ocorrência;
• Mitigated (Mitigado): Foram tomadas providências para reduzir o impacto do risco.

A explicação acima já o suficiente para compreender a lógica do ROAM. Durante o evento de planejamento (ou Release Planning no SAFe), os riscos são levantados pelas equipes e categorizados em cada campo. Dessa forma, haverá um consenso mútuo de todos os contratempos que podem surgir durante o ciclo de desenvolvimento. Interessante, não é?

Para realçar a utilidade do ROAM, fiz questão de elaborar 4 cenários para exemplificar cada letra do acrônimo. Confira:

R = Resolved

Dois analistas de testes foram contratados para a equipe X, mas, por serem novos, ainda não compreendem a regra de negócio do cliente. Por conta disso, as atividades de testes podem sofrer um atraso, já que será necessário estudar as regras antes de testá-las. Este risco pode ser resolvido ao fazer um repasse (workshop) de 2 ou 3 dias sobre as regras de negócio para estes colaboradores (claro, desde que o tempo deste repasse seja considerado na estimativa).

O = Owned

Uma das funcionalidades do Backlog exige que o módulo A seja integrado com o módulo B, porém, a classe de integração vem apresentando alguns problemas de incompatibilidade e pode dificultar a codificação. Como solução, a correção dessa classe será designada para um desenvolvedor ou uma equipe específica, portanto, o risco será responsabilizado por alguém.

A = Accepted

Um dos desenvolvedores do time tem uma cirurgia marcada no meio da Sprint. Como é algo que envolve saúde, resta a equipe aceitar o risco de atrasar algumas entregas, ou reduzir o escopo, em função da ausência deste desenvolvedor. Pensei nesse exemplo porque foi exatamente o que aconteceu comigo, haha.

M = Mitigated

O sistema de controle de versão da empresa será atualizado nas próximas semanas. Se houver algum problema com a atualização, as equipes ficarão impossibilitadas de enviar alterações. Para mitigar este risco, será criado um backup do controle de versão antes da atualização, como forma de contingência. No caso de qualquer inconsistência, ao invés de as equipes ficarem bloqueadas por várias horas, basta restaurar o backup. Observe que o risco poderá ocorrer, mas o impacto será menor.

Conclusão

Mas ainda há um detalhe. Notou que o título faz uma pergunta? “Do you really ROAM?”

Existe uma diferença entre usar uma ferramenta e saber como usá-la. Como analogia, do que adianta criar uma planilha de gastos se, no final do mês, ninguém irá consultá-la para calcular o quanto gastou?

Com o ROAM acontece o mesmo. Não basta apenas criar o board da classificação de riscos. É preciso acompanhá-lo em um intervalo regular, como a cada semana. Caso contrário, alguns riscos que foram responsabilizados ou mitigados, por exemplo, podem ser “esquecidos” ou não cumpridos. Ou então, no terceiro exemplo acima, a cirurgia poderá ser remarcada para outra data, alterando a capacidade da Sprint.

Na minha opinião, o ROAM não é apenas um board de distribuição de riscos. Quando utilizado adequadamente, é também uma ferramenta de monitoramento, já que proporciona ações de contingência.

Pois bem, pensando assim, como você responderia a pergunta do título?

• Sure! We are really ROAM’ing!
• No, we don’t really ROAM, but we will!

Qualquer uma das respostas é válida! 🙂

Boa sorte, leitores!
Um grande abraço!