Técnicas, processos e ferramentas utilizadas para um gerenciamento eficiente dos riscos em projetos ágeis com Scrum

1. 1
Gerenciamento de
Riscos em Scrum
http://www.gp4us.com.br contato@gp4us.com.br
http://www.facebook.com/gp4us
http://www.twitter.com/gp4us

2. 2
Amplamente divulgado através do PMBOK, o Gerenciamento de
Riscos propõe a identificação de riscos e planos de ação para mitigá-
los, eliminá-los, ou mesmo transferi-los. Tais riscos podem ser
facilmente categorizados como técnicos, de negócio e ambientais,
entre outros.
Porém, como o Gerenciamento de Riscos pode ser tratado no
Scrum? Realizar um Workshop interno para identificação dos riscos ?
Tratá-los na própria Sprint ? Deixar que a identificação inicial seja
realizada pelo próprio Product Owner ?
Enfim, muitas são as dúvidas referentes a este assunto e é neste
artigo que discutiremos as melhores formas e técnicas para sua
gestão através dos Métodos Ágeis.

3. 3
1. Introdução
O desenvolvimento de software é uma atividade complexa,
envolvendo inúmeros fatores que são imprevisíveis e de difícil controle,
como inovações tecnológicas e mudanças constantes nos requisitos
do cliente. Segundo Rocha e Belchior 2004:
Esta complexidade faz com que grande parte dos projetos de
desenvolvimento de software exceda o prazo e o orçamento
previstos, além de não atender às expectativas do cliente em
termos de funcionalidades e qualidade. Diante deste cenário, um
gerenciamento eficaz tem-se evidenciado como de fundamental
importância para o sucesso desses projetos.
Uma vez que a incerteza é inerente nestes ambientes, o
Gerenciamento de Riscos vem se tornando cada vez mais relevante
neste contexto. O objetivo principal da Gestão de Riscos é controlar
todo e qualquer impedimento que possa surgir durante os vários ciclos
de desenvolvimento, impedindo o progresso do projeto de acordo
com as previsões iniciais. Projetos tradicionais baseiam-se na área de
conhecimento Gestão de Riscos do PMBOK, onde as seguintes etapas
são identificadas:
 Identificação dos Riscos;
 Análise qualitativa dos riscos;
 Análise quantitativa dos riscos;
 Definir as respostas aos riscos;
 Análise e monitoramento dos riscos.
Realizadas no início do planejamento e revisadas durante todo o
processo de desenvolvimento, tais riscos são documentados e
preferencialmente apresentados às Partes Interessadas do projeto,
para que juntos trabalhem não somente na minimização dos mesmos,
mas também na constante identificação de novos riscos.

4. 4
Porém, em Scrum não identificamos nenhum processo formal
para a Gestão de Riscos ou formas como os mesmos pode se
tratados.
2. Visão do Produto
Muito semelhante ao tão conhecido Termo de Abertura
existente em projetos que seguem os Modelos Tradicionais de
Gerenciamento de Projetos, a Visão do Produto é de extrema
importância para todo o Time Scrum, pois é através deste que todos
terão consciência se o projeto está no caminho certo ou se ajuste são
necessários.
Desta forma, logo na fase de criação da Visão do Produto uma
série de questionamentos relacionados aos possíveis riscos do projeto
podem ser realizados tendo como objetivo realizar uma análise inicial
dos possíveis impedimentos a serem enfrentados.

5. 5
3. Mapeamento dos Riscos
Todo o processo de Gerenciamento de Riscos em Scrum de um
modo geral pode ser observado através da imagem abaixo. A
mesma apresenta 3 momentos distintos onde deve ser feita a análise
de identificação e monitoramento dos riscos.
4. Identificação dos Riscos
1º Priorização do Backlog
 Durante o processo de priorização do Backlog do
Produto, o Product Owner pode realizar um primeiro
levantamento dos principais riscos relacionados ao
projeto. Estes riscos serão identificados e armazenados
em uma Lista de Riscos utilizada posteriormente;
2º Reunião de Planejamento
 Durante a reunião de Planejamento da Sprint, o Time de
Desenvolvimento, junto com o Scrum Master e o Product

6. 6
Owner realizam levantamentos de possíveis riscos
relacionados à execução das atividades do projeto por
parte do Time de Desenvolvimento, atualizando a Lista
de Riscos criada inicialmente pelo PO.
3º Reuniões Diárias
 Com o avanço do projeto e das Sprints os riscos
identificados previamente podem, por algum motivo,
serem removidos da Lista de Riscos caso o mesmo não
seja mais considerado como um risco. Da mesma forma,
novos riscos podem ser identificados, sendo necessário
atualizar a Lista de Riscos.
Apesar de presente na imagem acima, alguns cuidados devem
ser observados no momento de criar a Lista de Riscos:
1. Não inclua perguntas;
2. Não inclua itens de ação;
3. Use sentenças completas;
4. Seja o mais específico possível;
5. Formule o risco e a área de impacto;
6. Pense na habilidade de qualificar o evento de risco.
5. Técnicas para Identificação dos Riscos
De acordo com o SBOK (2016), algumas técnicas para a
identificação dos riscos do projeto podem ser utilizadas, dentre elas:
1º revisar as Lições Aprendidas
 Aprender com projetos similares e Sprints anteriores,
explorando as incertezas que afetaram esses projetos e
Sprints pode ser uma maneira útil para identificação de
riscos.

7. 7
2º Checklists de Riscos
 Estes podem incluir os pontos-chave a serem
considerados ao identificar os riscos comuns encontrados
em projetos Scrum, ou até mesmo as categorias de riscos
que devem ser abordados pelo time.
3º Listas de Risco Prompt
 São utilizadas para estimular pensamentos sobre a fonte
de origem dos riscos. Tais listas de vários tipos de
indústrias e de projetos estão disponíveis ao público.
4º Brainstorming
 São sessões onde os Stakeholders e os membros do Time
Central do Scrum, abertamente compartilham ideias,
através de debates e sessões de compartilhamento de
conhecimento, que normalmente são conduzidos por
um facilitador.
5º EAR – Estrutura Analítica de Risco
 Esta é uma das principais ferramentas utilizadas na
identificação de riscos. Através dela os riscos são
agrupados de acordo com suas categorias ou
semelhanças. Por exemplo: riscos técnicos, financeiros,
segurança, etc.
6. Visualização Riscos
Seguindo um dos pilares do Scrum que diz respeito à
Transparência e baseando-se em um dos artefatos utilizados,
podemos também manter os riscos visíveis a todas as Partes
Interessadas é através do quadro de tarefas da Sprint.

8. 8
Opcionalmente o Time pode manter um único quadro com os
riscos já identificados, categorizando-os em três partes: mitigar,
aceitar e evitar de acordo com a imagem apresentada abaixo:
Evitar
Tentativa de eliminar a causa do risco,
inviabilizando sua ocorrência
Mitigar
Minimização de suas consequências,
diminuindo da probabilidade de ocorrência
Aceitar
Simples ação de aceitar o risco, sem plano
de execução caso o mesmo ocorra

9. 9
7. Gráfico de Risco Burndown
As informações coletadas durante a avaliação de risco podem ser
usadas para criar um Gráfico de Risco Burndown. Isto descreve a
gravidade de risco do projeto cumulativo ao longo do tempo.
Segundo o SBOK (2016):
As probabilidades dos diversos riscos são posicionados em cima uns
dos outros para mostrar risco cumulativo sobre o eixo-y. A
identificação e avaliação inicial de riscos sobre o projeto, e a
criação do Gráfico de Risco Burndown são feitas inicialmente.
Em seguida, em intervalos de tempo pré-determinados, novos riscos
podem ser identificados e avaliados, os riscos restantes devem ser
reavaliados e atualizados de acordo com o gráfico.
Um momento oportuno para fazer isso é durante a Reunião de
Planejamento do Sprint. O rastreamento riscos desta forma, permite
que o time possa reconhecer as tendências da exposição ao risco e
tomar medidas adequadas, caso necessário

10. 10
8. Riscos em Portfólios e Programas
Enquanto alguns riscos estão especificamente relacionados com
projetos individuais, outros podem ter origem em programas ou
portfólios e geralmente serem gerenciados nos mesmos. No
entanto, os riscos relacionados a um portfólio ou programa também
impactarão os projetos que fazem parte do respectivo portfólio ou
programa.
Durante a avaliação de riscos em portfólios e programas, se for
determinado que um risco poderá afetar um projeto individual,
informações relevantes ao risco deverão ser comunicadas ao Dono
do Produto e ao Time Scrum.
Quando os riscos em Portfólio são identificados, o Dono do
Produto do Portfólio deverá capturar e avaliar a, proximidade,
probabilidade e o impacto de cada risco identificado, a fim de
priorizá-los e de determinar a resposta apropriada para o portfólio.
O Dono do Produto do Portfólio também precisará comunicar os
riscos aos Stakeholders relevantes, aos times do programa e aos times
do projeto. Em alguns casos, o time do portfólio pode ter que assumir
a responsabilidade de riscos específicos.
A figura abaixo apresenta como os riscos podem ser gerados
dentro do fluxo Scrum para Portfólios e Programas.

11. 11

12. 12
9. Sinais de Riscos em Projetos Scrum
É possível ainda, a identificação antecipada de sinais de riscos
que podem levar ao fracasso projetos Scrum. Abaixo identificamos
cada um deles. Mais detalhes podem ser encontrados no site
Mindmaster.
1. Product Owner não sabe exercer sua função;
2. Alocação do Time não está otimizada para o Sucesso;
3. Estimativas do Projeto NÃO foram providas pelo time do
Projeto;
4. Relase Planning Inexistente;
5. Testers incluídos só no final do projeto;
6. O Gerenciamento como Impedimento;
7. Scrum Master preocupado apenas com Status Report
para o chefe e não para o time;
8. Código de Má Qualidade começam a imergir;
9. Equipe Desorganizada;
10. Falta de Visibilidade do Progresso e dos Impedimentos;
11. Falta de Priorização Adequada do Product Backlog.
10. E o que mais ?
Não deixe de assistir o excelente webinar realizado por Vitor Massari
falando sobre Scrum no Gerenciamento de Crise.
Fonte: https://youtu.be/yAOCRYxd9DQ

13. 13
11. Referências Bibliográficas
 Mindmaster - 12 Sinais de Riscos em Projetos Scrum;
 ScrumHALF - Gerência de Riscos em Scrum;
 ScrumStudy: SBOK - Um Guia Para o Conhecimento em Scrum - 2016;