Gerenciamento de Riscos em Scrum

Gerenciamento de Riscos em Scrum
Gerenciamento de Riscos em Scrum
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 transferilos.
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 post que discutiremos as melhores formas e
técnicas para sua gestão através dos Métodos Ágeis.
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.
Porém, em
Scrum não identificamos nenhum processo formal para a
Gestão de Riscos ou formas como os mesmos pode se
tratados.
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.
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.
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
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:
Não inclua perguntas;
Não inclua itens de ação;
Use sentenças completas;
Seja o mais específico possível;
Formule o risco e a área de impacto;
Pense na habilidade de qualificar o evento de risco.
Técnicas para Identificação dos Riscos
Se acordo com o SBOK (2016), algumas técnicas para a
identificação dos riscos do projeto podem ser
utilizadas, dentre elas:
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.
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.
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úblic.
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.
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.
Visualização Riscos
Quadro de 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.
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
Mitigar
Aceitar
Tentativa de eliminar a causa do risco, inviabilizando sua ocorrência
Minimização de suas consequências, diminuindo da probabilidade de
ocorrência
Simples ação de aceitar o risco, sem plano de execução caso o mesmo
ocorra
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
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.
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.
Product Owner não sabe exercer sua função;
Alocação do Time não está otimizada para o Sucesso;
Estimativas do Projeto NÃO foram providas pelo time do
Projeto;
Relase Planning Inexistente;
Testers incluídos só no final do projeto;
O Gerenciamento como Impedimento;
Scrum Master preocupado apenas com Status Report para o
chefe e não para o time;
Código de Má Qualidade começam a Imergir;
Equipe Desorganizada;
Falta de Visibilidade do Progresso e dos Impedimentos;
Falta de Priorização Adequada do Product Backlog.
E o que mais ?
Não deixe de assistir o excelente webinar realizado por
Vitor Massari falando sobre Scrum no Gerenciamento de
Crise.
https://youtu.be/yAOCRYxd9DQ
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;