Definição de um Processo Ágil de Gestão de Riscos em

Ambientes de Múltiplos Projetos

Lucio Ribeiro1, Cristine Gusmão1,2
1
Departamento de Sistemas e Computação
Escola Politécnica de Pernambuco (POLI/UPE) – Recife – PE – Brasil
2
Curso de Bacharelado em Sistemas de Informação
Faculdades Integradas Barros Melo – Olinda – PE – Brasil
{lr,cristine}@dsc.upe.br

Abstract. The Risk Management is one of the main interesting topics of Project
Management to researchers, because it involves many challenges and
unpredictable and difficult factors to control. However, due to the number of
unsuccessful projects, Agile Methodologies appear as an approach that can
bring satisfactory results. The success of organizations also depends on good
management and knowledge of several projects that they lead simultaneously.
In this regard, this article proposes a definition of an Agile Risk Management
Process in Multiple Project Environments.

Keywords: Risks, Agile Methodologies, Multiple Project Risk Management

Environment and Agile Management of Environment Risk.

Resumo. A Gerência de Riscos é um dos principais tópicos de interesse de

pesquisadores na área de Gerência de Projetos, pois envolve vários desafios e
inúmeros fatores imprevisíveis e de difícil controle. Devido ao número de
projetos registrados sem sucesso, as Metodologias Ágeis aparecem como uma
abordagem que pode trazer resultados satisfatórios. O sucesso das
organizações também depende de um bom gerenciamento e conhecimento dos
vários projetos que elas conduzem simultaneamente. Com este propósito, este
artigo propõe a definição de um Processo Ágil de Gestão de Riscos em
Ambientes de Múltiplos Projetos.

Palavras-chave: Riscos, Metodologias Ágeis, Gerenciamento de Riscos em

Ambientes de Múltiplos Projetos e Gestão Ágil de Riscos de Ambiente.

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. 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 é
____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 67
inerente nestes ambientes, o Gerenciamento de Riscos vem se tornando cada vez mais
relevante neste contexto [Rocha e Belchior 2004].
Projetos de software oferecem desafios específicos para sua realização e seu
gerenciamento. Pesquisas do Standish Group International mostram que os índices de
projetos encerrados com resultados insatisfatórios (insucesso ou sucesso parcial)
continuam relativamente elevados (71% em 2004) [Standish 2004]. Isto vem motivando
as organizações a adotarem Metodologias Ágeis como uma alternativa de gerenciamento
de projetos complexos. O gerenciamento ágil surgiu a partir das necessidades do
mercado atual exigir resultados imediatos, sob condições de altas incertezas e constantes
mudanças. Ele é caracterizado por iterações curtas e dirigidas a produtos, com decisões
colaborativas, contínua integração das novas funcionalidades e rápida incorporação de
alterações [Ribeiro e Arakaki 2006].
Embora a Gerência de Riscos seja um processo saudável para as organizações,
sua utilização ainda está aquém das expectativas. Se já é difícil gerenciar riscos em um
único projeto de desenvolvimento, imagine o grau de dificuldade associado a um
ambiente de múltiplos projetos. Nestes ambientes as dificuldades residem no tratamento
da estratégia organizacional, prioridades e restrições dos projetos e o compartilhamento
dos recursos da organização. Logo, pode-se concluir que essa gestão necessita de um
grau de compromisso maior entre os gerentes de projetos envolvidos e que seja de fácil
condução, pois serão questionados riscos de ambiente organizacional, que pode ter
influência em mais de um projeto, além da necessidade de um papel “influenciador”,
junto à alta direção da empresa, que busque a mitigação desses riscos.
Dentro deste contexto, este trabalho de pesquisa, propõe a definição de um
processo ágil de gestão de riscos em ambientes de múltiplos projetos. Para isto, nas
próximas seções, é exposta uma visão geral sobre agilidade e algumas metodologias
ágeis (Seção 2), os conceitos e atividades do Gerenciamento de Riscos em Ambientes de
Múltiplos Projetos (Seção 3), apresentação do processo proposto (Seção 4), e algumas
considerações da situação atual da pesquisa (Seção 5).

2 Metodologias Ágeis
No final da década de 90, um grupo de pessoas, com muito conhecimento nos processos
de desenvolvimento de software, se reuniu e trocou idéias sobre um conjunto de valores
e princípios encontrados em suas práticas. Isto resultou na criação da Aliança Ágil e no
estabelecimento do Manifesto Ágil para Desenvolvimento de Software [AgileManifesto
2001]. A partir daí, surgiram várias metodologias que seguem estes valores e princípios.
Algumas abordam a questão da Gerência de Projetos como é o caso do Scrum
[Schwaber 2004] e do APM (Agile Project Management) [Highsmith 2004].

3.1. Scrum
O Scrum é uma metodologia cujas práticas são aplicadas em um processo iterativo e
incremental. Assume-se que os projetos no qual o Scrum se insere são complexos e
imprevisíveis, onde não é possível prever tudo que irá acontecer. Por esta razão, ele
oferece um conjunto de práticas que torna tudo isso visível [Schwaber 2004].
A estrutura de processo do Scrum inicia-se com uma visão do produto que será
desenvolvido, contendo as características definidas pelo cliente, premissas e restrições.
____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 68
Em seguida, o Product Backlog é criado contendo a lista de todos os requisitos
conhecidos. O Product Backlog é então priorizado e dividido em releases. Cada release
contém um conjunto de requisitos, denominado Sprint Backlog, que será desenvolvido
em uma iteração, denominada de Sprint [Marçal et al 2007].
Na execução da Sprint, diariamente a equipe faz reuniões de 15 minutos (Daily
Scrum Meeting) para acompanhar o andamento do projeto. Ao final da Sprint, é
realizada o Sprint Review Meeting de modo que o time apresente o resultado alcançado
ao Product Owner (representante do cliente). Este resultado recebe o nome de Increment
of Potentially Shippable Product Functionality. Em seguida, o ScrumMaster conduz o
Sprint Retrospective Meeting com o objetivo de melhorar a equipe, o processo ou o
produto para a próxima Sprint.

3.2. Agile Project Management (APM)

APM é um conjunto de valores, princípios e práticas que auxiliam as equipes de
projetos a entenderem os problemas envolvidos em ambientes instáveis e desafiadores.
Os principais valores do APM endereçam tanto a necessidade de construir produtos de
modo ágil e adaptável como também a necessidade de criar equipes de desenvolvimento
com as mesmas características [Highsmith 2004]. Ele é composto por cinco fases:
Visão, Especulação, Exploração, Adaptação e Encerramento.
A fase de Visão resulta numa visão bem articulada do produto e do negócio que
determinam as entregas, os envolvidos e como eles pretendem trabalhar em conjunto.
Na fase de Especulação os requisitos são definidos, estimativas e estratégias de
mitigação de riscos são elaboradas, e um plano baseado em release, milestones e
iterações é criado, visando sempre entregar algo de valor (features) ao cliente. A fase de
Exploração engloba a entrega das features planejadas, através do gerenciamento das
atividades e do emprego de práticas e estratégias de mitigação de riscos planejadas.
Na fase de Adaptação os resultados são revisados, analisados e ações
adaptativas são incluídas na próxima iteração, se necessário. Observe que as fases
Especulação-Exploração-Adaptação levam ao refinamento do produto através de várias
iterações. Contudo, re-visitar a fase de Visão pode ser necessária quando há novas
informações. E por último, a fase de Encerramento finaliza as atividades do projeto,
registrando as lições aprendidas para que possam ser utilizadas nos próximos projetos.

3. Gerenciamento de Riscos em Ambientes de Múltiplos Projetos

O termo risco, em geral, aparece com o significado de perigo ou oportunidade. A
necessidade de gerenciar riscos é expressa no princípio de Gilb: “If you don’t actively
attack the risks, they will actively attack you” [Gilb 1988], ou seja, para ter sucesso em
um projeto é preciso aprender a identificar, analisar e controlar os riscos de forma que
eles não surpreendam os envolvidos no projeto.
A Gerência de Riscos de Projetos (GRP) foi formalmente apresentada à
comunidade de Engenharia de Software através da proposta do modelo Espiral de Barry
Boehm (1991). Seguindo-se a este evento muitas abordagens e modelos foram
apresentados, destacando-se o programa do SEI (Software Engineering Institute)
[Higuera e Haimes 1996] e, atualmente, os mais conhecidos são o modelo CMMI
(Capability Maturity Model Integration) [SEI 2007] e o Guia PMBOK (Project
____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 69
Management Book of Knowledge) [PMI 2004]. Mas, em geral, há um consenso das
atividades que compõem a GRP. São elas: Identificação de Riscos, Análise de Riscos,
Planejamento de Riscos, Monitoramento, Controle e Comunicação [Gusmão e Moura
2004].
A Gerência de Ambientes de Múltiplos Projetos se preocupa com a distribuição
e controle do esforço e dos recursos para os projetos uma vez que estes tenham sido
selecionados para o ambiente. Neste contexto, as organizações negligenciam os riscos
que podem surgir do relacionamento entre os projetos. Com o intuito de abordar esta
questão surgiu o Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos
Projetos - mPRIME Process (Project RIsk ManagEment Process) [Gusmão 2007], que
tem como objetivos: (i) viabilizar a identificação, avaliação e controle dos riscos em
ambientes de múltiplos projetos; (ii) viabilizar o conhecimento dos riscos e
oportunidades existentes no ambiente de múltiplos projetos; (iii) definir uma estrutura
para as informações sobre os riscos do ambiente; (iv) gerar para a gerência de múltiplos
projetos e equipe, indicadores de avaliação favorecendo a tomada de decisão.
O mPRIME Process é um processo contínuo composto por 5 grandes fases:
• Concepção – define o que é e qual o escopo da Gerência de Riscos no ambiente
organizacional de execução de múltiplos projetos.
• Elaboração – elabora o plano de gerenciamento, com as informações relativas
aos projetos e riscos identificados para o ambiente.
• Execução – contempla atividades de implementação e execução do plano de
Gerência de Riscos definido para o ambiente de múltiplos projetos.
• Controle – agrupa atividades de controle do ambiente e dos projetos, como
forma de garantia da execução eficaz do planejamento da gestão dos riscos do
ambiente.
• Avaliação – agrupa atividades de avaliação do processo de Gerência de Riscos e
do planejamento da Gerência de Riscos quando do encerramento de um projeto
no ambiente.
Cada uma destas fases é composta por um conjunto de atividades que estão
divididas em dois grupos:
• Atividades de Ambiente – relacionadas às variáveis do ambiente
organizacional.
• Atividades de Projeto – relacionadas às atividades individuais de cada projeto
do ambiente, que geram informações para o gerenciamento dos riscos do
ambiente.
Uma grande limitação deste processo é a agilidade para a implementação do
mesmo. Empresas pequenas não poderiam utilizá-lo por completo. Por este motivo, o
trabalho apresentado propõe uma adaptação deste processo de forma ágil. A GRP
analisa os resultados, ambientes e participantes do projeto sob um ponto de vista crítico
de modo a encontrar pontos fracos para tratamento. A importância de executar este
processo de modo ágil é alterar a forma de gerir de projetos para uma gestão voltada

____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 70
para a resolução imediata de empecilhos que possam estar afetando os objetivos do
projeto no momento, impedindo que se chegue ao produto final.

4. Processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos

Um processo de negócio compreende o conjunto de um ou mais procedimentos ou
atividades relacionadas, as quais, coletivamente, realizam um objetivo de negócio no
contexto de uma estrutura organizacional [WfMC 1999]. Portanto, é através da
execução dos processos de negócio que as organizações realizam seus propósitos [Thom
2007]. Processos de software são casos específicos de processos da organização. A
GRP compõe este conjunto de processos. O objetivo de uma gestão ágil é trazer para o
ambiente de trabalho a percepção de que o processo deve ser centrado em pessoas e
comunicação, com respostas rápidas a eventos que ocorrem durante o projeto.
Com base nesses conceitos, este trabalho propõe a definição de um processo ágil
para o tratamento de riscos (impedimentos) em ambientes de múltiplos projetos,
denominado GARA – Gestão Ágil de Riscos de Ambiente. Este processo não tem como
objetivo gerar todos os produtos de trabalho proposto pelo mPRIME Process. Ele é uma
adaptação que segue os valores descritos no Manifesto Ágil, com a ressalva de que o seu
foco não é entregar software, mas gerenciar e solucionar impedimentos, visando atingir
o sucesso do projeto.
O processo GARA tem seu ciclo de vida baseado no APM (vide Figura 1). A
definição das atividades que compõe cada fase deste processo foi baseada no mPRIME
Process, e a execução de cada uma delas segue os valores descritos no Manifesto Ágil,
além de se basear em práticas encontradas nas abordagens APM e Scrum.

Figura 1. Ciclo de Vida do Processo GARA.

O processo inicia-se com a fase de VISÃO, uma reunião rápida do Risk Team
Master e os Project Leader’s (representantes de projetos). Aqui será apresentado o
processo a todos os participantes e definidas as políticas e fronteiras de atuação desta
gerência. Como resultados, são definidos os tipos de impedimentos que estarão sob a
responsabilidade do Risk Team Master (chamados de Impedimentos de Ambiente) e
quais estarão sobre a gerência de cada projeto. Também é definida a periodicidade de
reuniões para as fases de ESPECULAÇÃO e ADAPTAÇÃO.
Na fase de ESPECULAÇÃO, os projetos são apresentados a todos os
participantes, são coletados os impedimentos identificados por cada Project Leader e é
realizada a identificação dos impedimentos de ambiente, podendo nesta mesma reunião
fazer-se análise e planejamento desses impedimentos. Recomenda-se que análise e o
____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 71
planejamento sejam baseados na experiência do time. Ao final, é gerada uma Matriz de
Impedimentos, consolidando todo o resultado desta fase. Essas atividades foram
baseadas no uso da prática de Reuniões Diárias, encontradas no Scrum e APM, para
acompanhar os impedimentos que já foram resolvidos, os que ainda faltam resolver e as
dificuldades existentes para se tentar resolvê-los. Porém, como estas atividades
envolvem o encontro de vários Project Leader’s, aconselha-se que se façam, no
mínimo, reuniões semanais.
A fase de EXPLORAÇÃO contém as atividades para solucionar os
impedimentos identificados. O Risk Team Master tem a obrigação de buscar soluções
para os impedimentos de ambiente, enquanto que os Project Leader’s devem resolver os
impedimentos que estão sob sua responsabilidade.
Na fase de ADAPTAÇÃO, o time se reúne para discutir sobre o processo,
analisando os pontos positivos e negativos, e que melhorias poderiam ser implantadas.
O time estabelece o que mudar e todos concordam em seguir. Após este acordo, a
mudança é institucionalizada para o próximo ciclo de atividades. Esta fase não
necessariamente precisa ser realizada ao final de cada ciclo, pode-se definir um período
maior para sua execução. Esta fase baseou-se na prática de Restrospective Meeting
presente no Scrum.
As atividades de cada fase do processo foram modeladas utilizando-se a notação
BPMN (Business Process Management Notation), vide Figura 2, que tem como
objetivo provê uma notação de fácil entendimento por todos os usuários de negócio,
desde os analistas de negócio que criam os “drafts” iniciais dos processos, até os
técnicos responsáveis por implementar a tecnologia que executará os processos, além
das pessoas que gerenciam e monitoram estes processos [OMG 2008].

Figura 2. Ilustração do Fluxo de Atividades da Fase de Especulação da GARA.

Para cada atividade também foram descritos os seus objetivos, responsável,

participantes, critérios de entrada e saída, produtos de entrada e saída, passos e técnicas
para referência. Não é objetivo deste artigo detalhar todas essas informações.
No processo GARA foram definidos dois papéis:
• Project Leader – responsável pela coordenação do projeto envolvido no
processo, principalmente, no que diz respeito à gestão de riscos. Geralmente esse
papel é desempenhado pelo Gerente de Projeto. Em um metodologia ágil como o
Scrum, este papel é do ScrumMaster.
____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 72
 • Risk Team Master – responsável por garantir que o processo e suas atividades
estejam sendo executadas pelos envolvidos. Semelhante ao ScrumMaster, ele
também tem a obrigação de solucionar os impedimentos de ambiente que forem
identificados.

5. Situação Atual e Considerações Finais

Através deste trabalho, constatou-se que existem poucos trabalhos relacionados à
aplicação da GRP em Metodologias Ágeis. Isso mostra que muita investigação ainda é
necessária. Um exemplo de estudo de caso que pode ser citado é o apresentado por
Preston Smith [Smith 2005]. Ele apresenta o uso de práticas ágeis no Gerenciamento de
Riscos em um projeto de uma unidade da Siemens, baseada no Scrum. Ele afirma que as
práticas de Gerenciamento Ágil de Riscos devem endereçar dois desafios: (i) primeiro,
eles devem integrar, com sucesso, as atividades de Gerenciamento de Riscos dentro das
atividades de planejamento da iteração; (ii) segundo, eles devem adaptar as práticas de
Gerenciamento Ágil de Risco para que toda equipe possa executá-las rapidamente. Essa
adaptação é importante para que se possam explorar as forças da abordagem ágil.
Gerenciar riscos é uma atividade primordial para qualquer organização, seja para
qual for o projeto. O sucesso dos projetos está diretamente associado à GRP, pois toda e
qualquer atividade poderá apresentar riscos. Como citado neste trabalho, ainda existem
muitos projetos que não atingem seus objetivos, de acordo com o Standish Group. Uma
das justificativas é que existem muitas organizações que não aplicam a Gerência de
Riscos ou a aplicam de forma insatisfatória.
Este trabalho avaliou o mPRIME Process e algumas Metodologias Ágeis para
gestão de projetos com o objetivo de definir um processo ágil para a GRP. Algumas
atividades ainda estão em andamento para melhorar o processo e avaliar sua
aplicabilidade em diversos ambientes:
• Aplicação do processo em um projeto piloto acadêmico – onde serão avaliadas as
atividades propostas e a sua aceitação por parte do time envolvido;
• Pesquisa com profissionais das áreas de Metodologias Ágeis para identificar
como os mesmos tratam a GRP em seus ambientes, avaliando os requisitos ora
propostos no GARA.
Como resultado parcial da aplicação do GARA, destaca-se a sua efetividade no
acompanhamento dos objetivos do projeto já que os principais impedimentos
identificados estão relacionados à entrega do produto final. Como limitação, destaca-se
a necessidade de aplicá-lo em um ambiente organizacional.
Como trabalhos futuros, pretendem-se:
• Realizar um estudo de caso em um ambiente organizacional;
• Utilizar ferramentas BPMS (Business Process Management Systems) para
simulação de processos.

6. Referências
AgileManifesto (2001) “Manifesto for Agile Software Development”,
http://agilemanifesto.org/. Última visita: Abril 2008.
____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 73
Gilb, T. (1988) “Principles of Software Engineering Management”, Wokingham,
England, Addison Wesley.
Gusmão, C. M. G. (2007) “Um Modelo de Processo de Gestão de Riscos para
Ambientes de Múltiplos Projetos de Desenvolvimento de Software”, Tese de
Doutorado, Universidade Federal de Pernambuco, Recife, Brasil.
Gusmão, C. M. G. e Moura, H. P. (2004) “Gerência de Riscos em Processos de
Qualidade de Software: uma Análise Comparativa”, In: SBQS 2004 – III Simpósio
Brasileiro de Qualidade de Software.
Highsmith, J. (2004) “Agile Project Management: Creating Innovative Products”,
Addison Wesley.
Higuera, R. P. e Haimes, Y. Y. (1996) “Software Risk Management”, Technical Report,
Software Engineering Institute, Carnegie Mellon University, USA.
Marçal, A. S. C., Freitas, B. C. C., Soares, F. S. F., Maciel, T. M. M. e Belchior, A. D.
(2007) “Entendendo o SCRUM segundo as Áreas de Processo de Gerenciamento de
Projetos do CMMI”, In: CLEI Eletronic Journal.
Object Management Group (2008) “Business Process Management Notation”, V1.1,
OMG Available Specification, http://www.omg.org/spec/BPMN/1.1/PDF.
PMI – Project Management Institute (2004) “A Guide to the Project Management Body
of Knowledge”, ANSI/PMI 99-01-2004, Four Campus Boulevard, Newton Square,
USA.
Ribeiro, A. L. D. e Arakaki, R. (2006) “Gerenciamento de Projetos Tradicional x
Gerenciamento de Projetos Ágil: Uma Análise Comparativa”, In: 3rd CONTECSI –
International Conference on Information Systems and Technology Management, São
Paulo, Brasil.
Rocha, P. C. e Belchior, A. D. (2004) “Mapeamento do Gerenciamento de Riscos no
PMBOK, CMMI-SW e RUP”, In: VI Simpósio Internacional de Melhoria de
Processos de Software – SIMPROS, São Paulo, Brasil.
Schwaber, K. (2004) “Agile Project Management with Scrum”, Microsoft Press.
SEI - Software Engineering Institute (2007) “CMMI - Capability Maturity Model
Integration”, version 1.2, Pittsburgh, PA, Carnegie Mellon University, USA.
Smith, P. G. e Pichler R. (2005) “Agile Risks, Agile Rewards”,
http://www.ddj.com/architect/184415308, Última visita: Abril 2008.
The Standish Group (2004) “Chaos Report”, http://www.standishgroup.com. Última
visita: Maio 2008.
Thom, L. H., Chiao, C. e Iochpe, C. (2007) “Padrões de Workflow para Reuso em
Modelagem de Processos de Negócio”, In: Conferência Latino Americana em
Linguagens de Padrões para Programação, Porto de Galinhas, Brasil.
WfMC – Workflow Management Coalition (1999) “Terminology & Glossary”,
http://www.wfmc.org. Última visita: Setembro 2008.

____________________________________________________________________________________
Hífen, Uruguaiana, v. 32 - nº 62 - II Semestre - Ano 2008 - ISSN 1983-6511 74