Definição de um Processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos

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 organizacional.

Ambiente

–

relacionadas

às

variáveis

do

ambiente

• 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 http://agilemanifesto.org/. Última visita: Abril 2008.

Software

Development”,

____________________________________________________________________________________ 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 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) “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