Definio de um Processo gil de Gesto de Riscos em Ambientes de Mltiplos Projetos

Lucio Ribeiro1, Cristine Gusmo1,2 Departamento de Sistemas e Computao Escola Politcnica de Pernambuco (POLI/UPE) Recife PE Brasil Curso de Bacharelado em Sistemas de Informao Faculdades Integradas Barros Melo Olinda PE Brasil
{lr,cristine}@dsc.upe.br
2 1

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 Gerncia de Riscos um dos principais tpicos de interesse de pesquisadores na rea de Gerncia de Projetos, pois envolve vrios desafios e inmeros fatores imprevisveis e de difcil controle. Devido ao nmero de projetos registrados sem sucesso, as Metodologias geis aparecem como uma abordagem que pode trazer resultados satisfatrios. O sucesso das organizaes tambm depende de um bom gerenciamento e conhecimento dos vrios projetos que elas conduzem simultaneamente. Com este propsito, este artigo prope a definio de um Processo gil de Gesto de Riscos em Ambientes de Mltiplos Projetos. Palavras-chave: Riscos, Metodologias geis, Gerenciamento de Riscos em Ambientes de Mltiplos Projetos e Gesto gil de Riscos de Ambiente.

1. Introduo
O desenvolvimento de software uma atividade complexa, envolvendo inmeros fatores que so imprevisveis e de difcil controle, como inovaes tecnolgicas e mudanas constantes nos requisitos do cliente. Esta complexidade faz com que grande parte dos projetos de desenvolvimento de software exceda o prazo e o oramento previstos, alm de no atender s expectativas do cliente em termos de funcionalidades e qualidade. Diante deste cenrio, um gerenciamento eficaz tem-se evidenciado como de fundamental importncia para o sucesso desses projetos. Uma vez que a incerteza
____________________________________________________________________________________ Hfen, 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 especficos para sua realizao e seu gerenciamento. Pesquisas do Standish Group International mostram que os ndices de projetos encerrados com resultados insatisfatrios (insucesso ou sucesso parcial) continuam relativamente elevados (71% em 2004) [Standish 2004]. Isto vem motivando as organizaes 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 condies de altas incertezas e constantes mudanas. Ele caracterizado por iteraes curtas e dirigidas a produtos, com decises colaborativas, contnua integrao das novas funcionalidades e rpida incorporao de alteraes [Ribeiro e Arakaki 2006]. Embora a Gerncia de Riscos seja um processo saudvel para as organizaes, sua utilizao ainda est aqum das expectativas. Se j difcil gerenciar riscos em um nico projeto de desenvolvimento, imagine o grau de dificuldade associado a um ambiente de mltiplos projetos. Nestes ambientes as dificuldades residem no tratamento da estratgia organizacional, prioridades e restries dos projetos e o compartilhamento dos recursos da organizao. Logo, pode-se concluir que essa gesto necessita de um grau de compromisso maior entre os gerentes de projetos envolvidos e que seja de fcil conduo, pois sero questionados riscos de ambiente organizacional, que pode ter influncia em mais de um projeto, alm da necessidade de um papel influenciador, junto alta direo da empresa, que busque a mitigao desses riscos. Dentro deste contexto, este trabalho de pesquisa, prope a definio de um processo gil de gesto de riscos em ambientes de mltiplos projetos. Para isto, nas prximas sees, exposta uma viso geral sobre agilidade e algumas metodologias geis (Seo 2), os conceitos e atividades do Gerenciamento de Riscos em Ambientes de Mltiplos Projetos (Seo 3), apresentao do processo proposto (Seo 4), e algumas consideraes da situao atual da pesquisa (Seo 5).

2 Metodologias geis
No final da dcada de 90, um grupo de pessoas, com muito conhecimento nos processos de desenvolvimento de software, se reuniu e trocou idias sobre um conjunto de valores e princpios encontrados em suas prticas. Isto resultou na criao da Aliana gil e no estabelecimento do Manifesto gil para Desenvolvimento de Software [AgileManifesto 2001]. A partir da, surgiram vrias metodologias que seguem estes valores e princpios. Algumas abordam a questo da Gerncia 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 prticas so aplicadas em um processo iterativo e incremental. Assume-se que os projetos no qual o Scrum se insere so complexos e imprevisveis, onde no possvel prever tudo que ir acontecer. Por esta razo, ele oferece um conjunto de prticas que torna tudo isso visvel [Schwaber 2004]. A estrutura de processo do Scrum inicia-se com uma viso do produto que ser desenvolvido, contendo as caractersticas definidas pelo cliente, premissas e restries.

____________________________________________________________________________________ Hfen, 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 ento priorizado e dividido em releases. Cada release contm um conjunto de requisitos, denominado Sprint Backlog, que ser desenvolvido em uma iterao, denominada de Sprint [Maral et al 2007]. Na execuo da Sprint, diariamente a equipe faz reunies 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 alcanado 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 prxima Sprint. 3.2. Agile Project Management (APM) APM um conjunto de valores, princpios e prticas que auxiliam as equipes de projetos a entenderem os problemas envolvidos em ambientes instveis e desafiadores. Os principais valores do APM endeream tanto a necessidade de construir produtos de modo gil e adaptvel como tambm a necessidade de criar equipes de desenvolvimento com as mesmas caractersticas [Highsmith 2004]. Ele composto por cinco fases: Viso, Especulao, Explorao, Adaptao e Encerramento. A fase de Viso resulta numa viso bem articulada do produto e do negcio que determinam as entregas, os envolvidos e como eles pretendem trabalhar em conjunto. Na fase de Especulao os requisitos so definidos, estimativas e estratgias de mitigao de riscos so elaboradas, e um plano baseado em release, milestones e iteraes criado, visando sempre entregar algo de valor (features) ao cliente. A fase de Explorao engloba a entrega das features planejadas, atravs do gerenciamento das atividades e do emprego de prticas e estratgias de mitigao de riscos planejadas. Na fase de Adaptao os resultados so revisados, analisados e aes adaptativas so includas na prxima iterao, se necessrio. Observe que as fases Especulao-Explorao-Adaptao levam ao refinamento do produto atravs de vrias iteraes. Contudo, re-visitar a fase de Viso pode ser necessria quando h novas informaes. E por ltimo, a fase de Encerramento finaliza as atividades do projeto, registrando as lies aprendidas para que possam ser utilizadas nos prximos projetos.

3. Gerenciamento de Riscos em Ambientes de Mltiplos Projetos

O termo risco, em geral, aparece com o significado de perigo ou oportunidade. A necessidade de gerenciar riscos expressa no princpio de Gilb: If you dont 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 no surpreendam os envolvidos no projeto. A Gerncia de Riscos de Projetos (GRP) foi formalmente apresentada comunidade de Engenharia de Software atravs 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 so o modelo CMMI (Capability Maturity Model Integration) [SEI 2007] e o Guia PMBOK (Project

____________________________________________________________________________________ Hfen, 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 compem a GRP. So elas: Identificao de Riscos, Anlise de Riscos, Planejamento de Riscos, Monitoramento, Controle e Comunicao [Gusmo e Moura 2004]. A Gerncia de Ambientes de Mltiplos Projetos se preocupa com a distribuio e controle do esforo e dos recursos para os projetos uma vez que estes tenham sido selecionados para o ambiente. Neste contexto, as organizaes negligenciam os riscos que podem surgir do relacionamento entre os projetos. Com o intuito de abordar esta questo surgiu o Modelo de Processo de Gesto de Riscos para Ambientes de Mltiplos Projetos - mPRIME Process (Project RIsk ManagEment Process) [Gusmo 2007], que tem como objetivos: (i) viabilizar a identificao, avaliao e controle dos riscos em ambientes de mltiplos projetos; (ii) viabilizar o conhecimento dos riscos e oportunidades existentes no ambiente de mltiplos projetos; (iii) definir uma estrutura para as informaes sobre os riscos do ambiente; (iv) gerar para a gerncia de mltiplos projetos e equipe, indicadores de avaliao favorecendo a tomada de deciso. O mPRIME Process um processo contnuo composto por 5 grandes fases: Concepo define o que e qual o escopo da Gerncia de Riscos no ambiente organizacional de execuo de mltiplos projetos. Elaborao elabora o plano de gerenciamento, com as informaes relativas aos projetos e riscos identificados para o ambiente. Execuo contempla atividades de implementao e execuo do plano de Gerncia de Riscos definido para o ambiente de mltiplos projetos. Controle agrupa atividades de controle do ambiente e dos projetos, como forma de garantia da execuo eficaz do planejamento da gesto dos riscos do ambiente. Avaliao agrupa atividades de avaliao do processo de Gerncia de Riscos e do planejamento da Gerncia de Riscos quando do encerramento de um projeto no ambiente. Cada uma destas fases composta por um conjunto de atividades que esto divididas em dois grupos: Atividades de organizacional. Ambiente relacionadas s variveis do ambiente

Atividades de Projeto relacionadas s atividades individuais de cada projeto do ambiente, que geram informaes para o gerenciamento dos riscos do ambiente. Uma grande limitao deste processo a agilidade para a implementao do mesmo. Empresas pequenas no poderiam utiliz-lo por completo. Por este motivo, o trabalho apresentado prope uma adaptao deste processo de forma gil. A GRP analisa os resultados, ambientes e participantes do projeto sob um ponto de vista crtico de modo a encontrar pontos fracos para tratamento. A importncia de executar este processo de modo gil alterar a forma de gerir de projetos para uma gesto voltada
____________________________________________________________________________________ Hfen, Uruguaiana, v. 32 - n 62 - II Semestre - Ano 2008 - ISSN 1983-6511 70

para a resoluo imediata de empecilhos que possam estar afetando os objetivos do projeto no momento, impedindo que se chegue ao produto final.

4. Processo gil de Gesto de Riscos em Ambientes de Mltiplos Projetos

Um processo de negcio compreende o conjunto de um ou mais procedimentos ou atividades relacionadas, as quais, coletivamente, realizam um objetivo de negcio no contexto de uma estrutura organizacional [WfMC 1999]. Portanto, atravs da execuo dos processos de negcio que as organizaes realizam seus propsitos [Thom 2007]. Processos de software so casos especficos de processos da organizao. A GRP compe este conjunto de processos. O objetivo de uma gesto gil trazer para o ambiente de trabalho a percepo de que o processo deve ser centrado em pessoas e comunicao, com respostas rpidas a eventos que ocorrem durante o projeto. Com base nesses conceitos, este trabalho prope a definio de um processo gil para o tratamento de riscos (impedimentos) em ambientes de mltiplos projetos, denominado GARA Gesto gil de Riscos de Ambiente. Este processo no tem como objetivo gerar todos os produtos de trabalho proposto pelo mPRIME Process. Ele uma adaptao que segue os valores descritos no Manifesto gil, com a ressalva de que o seu foco no 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 definio das atividades que compe cada fase deste processo foi baseada no mPRIME Process, e a execuo de cada uma delas segue os valores descritos no Manifesto gil, alm de se basear em prticas encontradas nas abordagens APM e Scrum.

Figura 1. Ciclo de Vida do Processo GARA.

O processo inicia-se com a fase de VISO, uma reunio rpida do Risk Team Master e os Project Leaders (representantes de projetos). Aqui ser apresentado o processo a todos os participantes e definidas as polticas e fronteiras de atuao desta gerncia. Como resultados, so definidos os tipos de impedimentos que estaro sob a responsabilidade do Risk Team Master (chamados de Impedimentos de Ambiente) e quais estaro sobre a gerncia de cada projeto. Tambm definida a periodicidade de reunies para as fases de ESPECULAO e ADAPTAO. Na fase de ESPECULAO, os projetos so apresentados a todos os participantes, so coletados os impedimentos identificados por cada Project Leader e realizada a identificao dos impedimentos de ambiente, podendo nesta mesma reunio fazer-se anlise e planejamento desses impedimentos. Recomenda-se que anlise e o
____________________________________________________________________________________ Hfen, Uruguaiana, v. 32 - n 62 - II Semestre - Ano 2008 - ISSN 1983-6511 71

planejamento sejam baseados na experincia do time. Ao final, gerada uma Matriz de Impedimentos, consolidando todo o resultado desta fase. Essas atividades foram baseadas no uso da prtica de Reunies Dirias, 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. Porm, como estas atividades envolvem o encontro de vrios Project Leaders, aconselha-se que se faam, no mnimo, reunies semanais. A fase de EXPLORAO contm as atividades para solucionar os impedimentos identificados. O Risk Team Master tem a obrigao de buscar solues para os impedimentos de ambiente, enquanto que os Project Leaders devem resolver os impedimentos que esto sob sua responsabilidade. Na fase de ADAPTAO, o time se rene 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. Aps este acordo, a mudana institucionalizada para o prximo ciclo de atividades. Esta fase no necessariamente precisa ser realizada ao final de cada ciclo, pode-se definir um perodo maior para sua execuo. Esta fase baseou-se na prtica de Restrospective Meeting presente no Scrum. As atividades de cada fase do processo foram modeladas utilizando-se a notao BPMN (Business Process Management Notation), vide Figura 2, que tem como objetivo prov uma notao de fcil entendimento por todos os usurios de negcio, desde os analistas de negcio que criam os drafts iniciais dos processos, at os tcnicos responsveis por implementar a tecnologia que executar os processos, alm das pessoas que gerenciam e monitoram estes processos [OMG 2008].

Figura 2. Ilustrao do Fluxo de Atividades da Fase de Especulao da GARA.

Para cada atividade tambm foram descritos os seus objetivos, responsvel, participantes, critrios de entrada e sada, produtos de entrada e sada, passos e tcnicas para referncia. No objetivo deste artigo detalhar todas essas informaes. No processo GARA foram definidos dois papis: Project Leader responsvel pela coordenao do projeto envolvido no processo, principalmente, no que diz respeito gesto de riscos. Geralmente esse papel desempenhado pelo Gerente de Projeto. Em um metodologia gil como o Scrum, este papel do ScrumMaster.
____________________________________________________________________________________ Hfen, Uruguaiana, v. 32 - n 62 - II Semestre - Ano 2008 - ISSN 1983-6511 72

 Risk Team Master responsvel por garantir que o processo e suas atividades estejam sendo executadas pelos envolvidos. Semelhante ao ScrumMaster, ele tambm tem a obrigao de solucionar os impedimentos de ambiente que forem identificados.

5. Situao Atual e Consideraes Finais

Atravs deste trabalho, constatou-se que existem poucos trabalhos relacionados aplicao da GRP em Metodologias geis. Isso mostra que muita investigao ainda necessria. Um exemplo de estudo de caso que pode ser citado o apresentado por Preston Smith [Smith 2005]. Ele apresenta o uso de prticas geis no Gerenciamento de Riscos em um projeto de uma unidade da Siemens, baseada no Scrum. Ele afirma que as prticas de Gerenciamento gil de Riscos devem enderear dois desafios: (i) primeiro, eles devem integrar, com sucesso, as atividades de Gerenciamento de Riscos dentro das atividades de planejamento da iterao; (ii) segundo, eles devem adaptar as prticas de Gerenciamento gil de Risco para que toda equipe possa execut-las rapidamente. Essa adaptao importante para que se possam explorar as foras da abordagem gil. Gerenciar riscos uma atividade primordial para qualquer organizao, 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 no atingem seus objetivos, de acordo com o Standish Group. Uma das justificativas que existem muitas organizaes que no aplicam a Gerncia de Riscos ou a aplicam de forma insatisfatria. Este trabalho avaliou o mPRIME Process e algumas Metodologias geis para gesto de projetos com o objetivo de definir um processo gil para a GRP. Algumas atividades ainda esto em andamento para melhorar o processo e avaliar sua aplicabilidade em diversos ambientes: Aplicao do processo em um projeto piloto acadmico onde sero avaliadas as atividades propostas e a sua aceitao 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 aplicao do GARA, destaca-se a sua efetividade no acompanhamento dos objetivos do projeto j que os principais impedimentos identificados esto relacionados entrega do produto final. Como limitao, 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 simulao de processos.

6. Referncias
____________________________________________________________________________________ Hfen, Uruguaiana, v. 32 - n 62 - II Semestre - Ano 2008 - ISSN 1983-6511 73

AgileManifesto (2001) Manifesto for Agile http://agilemanifesto.org/. ltima visita: Abril 2008.

Software

Development,

Gilb, T. (1988) Principles of Software Engineering Management, Wokingham, England, Addison Wesley. Gusmo, C. M. G. (2007) Um Modelo de Processo de Gesto de Riscos para Ambientes de Mltiplos Projetos de Desenvolvimento de Software, Tese de Doutorado, Universidade Federal de Pernambuco, Recife, Brasil. Gusmo, C. M. G. e Moura, H. P. (2004) Gerncia de Riscos em Processos de Qualidade de Software: uma Anlise Comparativa, In: SBQS 2004 III Simpsio 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. Maral, 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 Anlise Comparativa, In: 3rd CONTECSI International Conference on Information Systems and Technology Management, So Paulo, Brasil. Rocha, P. C. e Belchior, A. D. (2004) Mapeamento do Gerenciamento de Riscos no PMBOK, CMMI-SW e RUP, In: VI Simpsio Internacional de Melhoria de Processos de Software SIMPROS, So 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 http://www.ddj.com/architect/184415308, ltima visita: Abril 2008. Rewards,

The Standish Group (2004) Chaos Report, http://www.standishgroup.com. ltima visita: Maio 2008. Thom, L. H., Chiao, C. e Iochpe, C. (2007) Padres de Workflow para Reuso em Modelagem de Processos de Negcio, In: Conferncia Latino Americana em Linguagens de Padres para Programao, Porto de Galinhas, Brasil. WfMC Workflow Management Coalition (1999) Terminology & Glossary, http://www.wfmc.org. ltima visita: Setembro 2008.
____________________________________________________________________________________ Hfen, Uruguaiana, v. 32 - n 62 - II Semestre - Ano 2008 - ISSN 1983-6511 74