Com base no modelo de desenvolvimento de software ágil adotado na coordenação, é proposto o modelo de gestão de riscos adaptado da Extensão de Software do PMI [76]. A Extensão de Software do PMI pretende fazer a ligação entre os processos mais estruturados de gestão de projetos, mencionados no PMBOK e os métodos ágeis de gestão de projetos. Por isso, o modelo ágil sugerido pelo PMI para gestão de riscos mostrou maior integração entre atividades da gestão de riscos dentro das cerimônias do Scrum em relação aos demais modelos investigados no Capítulo 2, item 2.8. A adaptação levou em conta a necessidade de adição explícita das atividades de tratamento e monitoramento dos riscos, assim como a necessidade de descrever as ferramentas e técnicas que poderiam ser utilizadas em cada atividade. Para isso o estudo realizado no Capítulo 2, item 2.7 foi de suma importância para a elaboração deste processo de gestão de riscos ágil. Baseado no processo de desenvolvimento de software do framework Scrum, a gestão de riscos é proposta para ser ágil e integrada às suas atividades e cerimônias.
Figura 5.1: Proposta de processo de gestão de riscos integrada ao Scrum. Fonte: Elaboração Própria.
Conforme Figura 5.1, de posse do backlog do produto, ou seja, da lista de novas fun- cionalidades e manutenções adaptativas ou corretivas do produto, é realizada a Reunião
de Riscos, que inclui a identificação dos riscos inerentes ao desenvolvimento do produto
analisado. Nesta mesma reunião também é realizada a análise e a avaliação que determina quais funcionalidades possuem os riscos mais críticos e altos e, assim, estas são priorizadas no backlog. A definição da estratégia de tratamento dos riscos (aceitar, mitigar, transferir ou evitar) também é realizada nesta reunião.
Durante a reunião de planejamento da (Sprint), o tratamento do risco e suas ações de resposta são definidas e descritas. Neste momento, a equipe do projeto estará reunida e de posse dos requisitos detalhados poderão analisar a avaliação inicial de pri- orização do backlog pelo nível de risco e definir uma ação de resposta para cada risco. Também é possível, neste momento, atribuir a cada risco o ‘dono do risco’.
Quando a iteração se inicia os riscos são monitorados diariamente na reunião diária do Scrum. A identificação de novos riscos também pode ocorrer durante a Sprint, a medida que o entendimento da equipe aumenta e possíveis impedimentos vão aparecendo. Durante a reunião de revisão da iteração, quando a equipe apresenta o incre- mento de software ao cliente, caso sejam solicitadas alterações, novos riscos podem ser identificados, e assim os mesmos deverão compor o backlog que sofrerá repriorização.
Ao final da sprint, durante a reunião de retrospectiva, quando a equipe se reúne para levantamento das lições aprendidas, deverá haver uma análise sobre quais riscos inerentes ao desenvolvimento, poderão ser fechados e quais poderão ser levados para a próxima iteração.
A análise crítica poderá ser realizada tanto no momento da reunião de retrospectiva da Sprint quanto agendada de modo a levantar se as ações de resposta aos riscos estão sendo efetivas, se os riscos estão se manifestando e se o processo de gestão de riscos ainda está adequado ao contexto.
5.6.1 Mapeamento da Gestão de Riscos no framework Scrum
O Quadro 5.1, mostra o mapeamento da gestão de risco no framework Scrum. A identificação dos riscos ocorre durante a maior parte das cerimônias definidas no framework Scrum. Podem ser utilizados os artefatos visão do produto, backlog e roadmap do produto para se identificar os riscos do projeto. Isto poderá ser realizado nas reuniões de planejamento, reuniões diárias e reuniões de revisão, pois a todo momento podem ser encontrados novos riscos na iteração, exceto na cerimônia da retrospectiva da Sprint, pois esta reunião indica o fim da iteração corrente.
As fases de análise e avaliação são comumente realizadas durante a reunião de planeja- mento da sprint, pois o ideal é que seja realizada juntamente com a equipe antes do início
Quadro 5.1: Mapeamento da Gestão de Riscos no Scrum. Fonte: Adaptado de Nyfjord, et al. (2008)[69] Scrum / Gestão de Riscos Identificação de Riscos Análise e Avaliação de Riscos Tratamento e Resposta aos Riscos Monitora- mento Comuni- cação e Consulta Visão x x x Backlog e Roadmap x x x x Planejamento da Sprint x x x x Reunião Diária x x x x x Revisão x x x Retrospectiva x
da iteração, assim como o tratamento e resposta aos riscos que também deverá ocorrer no planejamento da Sprint. Porém eventualmente, algum risco pode ser identificado, ava- liado e tratado durante as reuniões diárias, por ser inerente à sprint corrente e conforme o entendimento dos requisitos for aumentando, novos riscos vão sendo reconhecidos pela equipe.
O monitoramento é frequentemente realizado durante as reuniões diárias, momento este em que todos os membros da equipe estão reunidos, dentre outras coisas, para iden- tificação de possíveis impedimentos na implementação da Sprint corrente, assim os riscos já tratados são diariamente monitorados e novos riscos podem ser revelados.
Na revisão, onde o incremento de software funcional é exibido para cliente ao final da fase de construção, podem surgir novos riscos oriundos de novas solicitações realizadas pelo cliente. Porém, estes riscos deverão ser encaminhados para o backlog juntamente com as novas solicitações para aguardarem nova priorização. O monitoramento também é realizado nesta fase para verificar se algum risco se materializou.
A retrospectiva é realizada após a entrega do incremento do software e tem por objetivo também de fechar riscos e analisar se algum risco desta iteração tem a probabilidade de ocorrer na próxima iteração.
A análise crítica é utilizada para verificar até que ponto as respostas estão reduzindo a probabilidade ou o impacto dos riscos que foram identificados. O feedback da equipe passado na reunião de retrospectiva da Sprint poderá auxiliar o Gestor de Riscos ou o auditor na atividade de análise crítica, que analisará o processo da gestão de riscos, sua estrutura e os próprios riscos. A comunicação e consulta permeia toda a gestão tradicional de riscos e deverá permear todas as cerimônias do framework Scrum para que as partes envolvidas sejam consultadas quanto aos riscos inerentes ao projeto e também possam ser igualmente comunicadas sobre o resultado da gestão de riscos.
Ela ocorre paralelamente as demais atividades, devendo haver uma consulta às partes interessadas no processo para que a gestão de riscos seja efetiva e, de igual maneira estas mesmas partes interessadas necessitam ser comunicadas sobre os riscos. Esta comunica- ção é importante para a tomada de decisões, delegações de riscos, realização das ações mitigadoras pelo dono do risco e no geral, pela ciência de todos os envolvidos no resultado final de sua gestão.