Análise das áreas de processos do PMBOK sob a ótica do gerenciamento ágil

Transcrição

1 Análise das áreas de processos do PMBOK sob a ótica do gerenciamento ágil Tales P. Nogueira 1, Enyo T. Gonçalves 1,2, Mariela I. Cortés 1, Yrleyjânder S. Lopes 1 1 Grupo de Engenharia de Software e Sistemas Inteligentes (GESSI) Universidade Estadual do Ceará (UECE), Fortaleza CE Brasil 2 Universidade Federal do Ceará (UFC), Campus de Quixadá, Quixadá CE Brasil. {tales.paiva, mariela}@larces.uece.br, enyo@ufc.br, yrleyjander@gmail.com Abstract The coexistence of agile and traditional practices is possible in a software project, despite many people assume the opposite. In this paper, the similarities between these two approaches are identified and the moments when they relate along the project s execution flow are appointed. The guide to project management PMBOK and the Scrum framework are used to represent the traditional and agile practices, respectively. Resumo A coexistência de práticas ágeis e tradicionais em um projeto de software é possível, ao contrário do que muitos imaginam. No presente artigo são identificadas as similaridades entre essas duas abordagens, apontando em quais momentos elas se relacionam dentro do fluxo de execução de um projeto. Como representantes de práticas tradicionais e ágeis, são apresentados o guia de gerenciamento de projetos PMBOK e o framework Scrum, respectivamente. 1. Introdução Com o surgimento da Engenharia de Software, as empresas passaram a utilizar ferramentas, técnicas e métodos para melhorar a qualidade dos seus processos como um meio de atingir a melhoria na qualidade de seus produtos. Entre os avanços trazidos pela Engenharia de Software está a formalização da disciplina de gerenciamento de projetos, em contrapartida ao imprevisível desenvolvimento artesanal predominante até então. Uma grande contribuição para a área de gerenciamento de projetos foi a criação do PMBOK (Project Management Body of Knowledge) [7] que resume, na forma de um guia, as melhores práticas segundo os métodos tradicionais de gerenciamento de projetos. O guia PMBOK vem sendo extensamente utilizado na indústria do software. Entretanto, nos últimos anos tem-se observado um forte crescimento na adoção de metodologias ágeis [5] de desenvolvimento, principalmente devido à necessidade de desenvolvimento rápido de aplicações de software. Dentre as metodologias ágeis, se destaca o framework Scrum [9], pois este elenca um consistente conjunto de atividades e artefatos com foco em atividades gerenciais. É importante esclarecer que PMBOK e Scrum não são totalmente equivalentes, mas por outro lado não são incompatíveis. Sendo assim, o objetivo deste trabalho é relacionar algumas boas práticas elencadas no PMBOK com aspectos presentes no

2 framework Scrum, utilizando as áreas de processo do guia do PMI como base para esta análise. Este artigo está estruturado da seguinte forma: na Seção 2, são apresentadas, respectivamente, as principais características do PMBOK, e do framework Scrum. Na Seção 3, é mostrado um mapeamento entre as fases e os artefatos de ambas as abordagens. Na seção 4, são apresentados os trabalhos relacionados. Finalmente, na Seção 5, são apresentadas as conclusões e trabalhos futuros. 2. Referencial Teórico 2.1. PMBOK O PMBOK (Project Management Body of Knowledge) é um guia elaborado pelo PMI (Project Management Institute) que tem como objetivo maior identificar o subconjunto do conjunto de conhecimentos em gerenciamento de projetos, o qual é amplamente reconhecido como boa prática [7]. O guia é dividido em três seções como segue: estrutura do gerenciamento de projetos, norma de gerenciamento de projetos de um projeto e as áreas de conhecimento em gerenciamento de projetos. As nove áreas do conhecimento agrupam e definem detalhadamente os 42 processos de gerenciamento. Os processos são organizados em cinco grupos, de acordo com um determinado objetivo dentro do fluxo de um projeto, a saber: iniciação, planejamento, execução, controle e encerramento. Cada grupo de processos tem um papel destacado em momentos específicos do ciclo de vida de um projeto e podem se sobrepor dentro de cada fase de um projeto, e inclusive dentro das áreas de conhecimento, como mostrado na Figura. Figura. Relação entre os grupos de processos do PMBOK ao longo do tempo [7] 2.2. Scrum Scrum foi desenvolvido por Ken Schwaber e Jeff Sutherland no começo da década de 90. É uma metodologia chamada de método ágil para desenvolvimento de software, e segue o Manifesto Ágil [1]. No entanto, Scrum tem seu foco na atividade de gerência do projeto [16]. Scrum é um framework para desenvolvimento ágil de projetos (não apenas de software), que se encaixa no paradigma iterativo incremental. Por ser um framework, Scrum não dita o que deve ser exatamente realizado a cada passo do projeto, contudo, os problemas inerentes a projetos são mais facilmente identificados e solucionados. Scrum é objetivo, com papéis e responsabilidades bem definidas, de fácil adaptação e curva de aprendizado baixa, mas a sua efetiva utilização requer disciplina,

3 organização e planejamento. Por outro lado, não é um processo previsível, pois as práticas propostas são adaptadas à realidade da empresa. Figura. Fluxo geral do Scrum Como mostra a Figura, inicialmente, o projeto passa por uma fase de preparação (financiamento, acordo contratual, visão, backlog inicial do produto, plano de release inicial, envolvimento dos stakeholders, montagem do time). Inicialmente, o projeto é dividido em releases que são divididas em sprints, as quais geram um produto incremental a cada iteração. Em cada instância, são elaboradas diversas estimativas que contribuem para o detalhamento do planejamento do projeto. 3. Mapeamento Nas subseções seguintes é apresentada cada uma das áreas de conhecimento do PMBOK e seus respectivos processos sob a ótica do framework Scrum, identificando quando e como se aplicam Gerenciamento de Integração O termo de abertura do projeto, o primeiro artefato sugerido pelo PMBOK, mesmo não sendo citado pelo Scrum, faz-se necessário como uma das formas de formalizar a existência do projeto. O desenvolvimento da declaração do escopo preliminar do projeto ocorre no Scrum no momento de iniciação durante o alinhamento da visão do Product Owner com o time. Neste momento, os primeiros itens do backlog são elencados. O backlog do produto é o artefato inicial do processo onde são documentados e priorizados os requisitos do produto. Esse artefato é subdividido de forma a gerar os backlogs das sprints, que são os itens que serão desenvolvidos a cada iteração. O desenvolvimento do plano de gerenciamento do projeto é implicitamente definido a partir da escolha do Scrum como a metodologia a ser utilizada no projeto, pois uma das responsabilidades do ScrumMaster é treinar a equipe e o Product Owner no processo. Também é definido o plano de releases e possivelmente uma estimativa, sem compromisso, do backlog. A orientação e gerenciamento da execução do projeto, assim como a monitoração e o controle do trabalho do projeto são processos inerentes do Scrum através dos ciclos de planejamento, execução, revisão e retrospectiva da sprint. O time, no Scrum, tem mais independência do que em metodologias tradicionais no sentido de poder escolher, em alguns casos, quais atividades serão realizadas, desde que haja um comprometimento por parte dos integrantes. Já o monitoramento do trabalho é feito pelo ScrumMaster com o auxílio dos gráficos de burndown das sprints que fornecem uma representação da produtividade do time ao longo das sprints e ao longo do projeto. Podem ser considerados também outros artefatos para

4 acompanhamento, por exemplo: a lista de impedimentos criada pelo time a cada reunião diária, o quadro de tarefas com os itens do backlog e a medida de desempenho velocity (o tempo médio gasto para implementar os itens do backlog a cada sprint). As mudanças fazem parte natural do projeto, então o controle integrado de mudanças é realizado na constante atualização do backlog, de acordo com os pedidos de alterações e priorizações do Product Owner. O encerramento do projeto no Scrum ocorre no final da última sprint, quando o produto final é entregue. Aqui, assim como no termo de abertura do projeto, os procedimentos de encerramento administrativo e de contratos estão fora do escopo das propostas das metodologias ágeis; logo, os procedimentos tradicionais da empresa relativos a essas atividades são realizadas Gerenciamento do Escopo O plano de gerenciamento do escopo não é necessário no Scrum, visto que o simples comprometimento dos envolvidos em seguir o framework é suficiente para que fiquem definidas atividades de gerenciamento do escopo e de todo o projeto, como, por exemplo, a periodicidade das reuniões que são diárias e ao final das sprints e a atualização do quadro de tarefas pelo time. Desde a fase de iniciação, quando é realizado o alinhamento da visão do Product Owner com o time, o escopo começa a ser definido com a elicitação dos itens do backlog do produto, assim como as premissas do projeto. A aceitação de eventuais mudanças no escopo durante o projeto é uma premissa básica do Scrum. Aliando a isso o fato de que a definição das atividades específicas são responsabilidade do time. Resulta inviável a criação da EAP (Estrutura Analítica do Projeto) tradicional no contexto de um projeto ágil. A verificação do escopo ocorre na reunião de revisão da sprint com o Product Owner. Nesse momento os interessados aceitam ou não os resultados apresentados. Diariamente, através do quadro de tarefas, o escopo também é verificado e controlado. Como o escopo no Scrum se resume ao backlog do produto, o controle do escopo é realizado através da manutenção do backlog para que esteja sempre de acordo com as necessidades do cliente. Outra atividade importante para controlar o escopo é garantir que o backlog da sprint não seja alterado uma vez que a mesma seja iniciada Gerenciamento de Tempo De acordo com o PMBOK, em alguns projetos, o seqüenciamento de atividades, a estimativa de recursos da atividade, a estimativa de duração da atividade e o desenvolvimento do cronograma estão tão estreitamente ligados que podem ser considerados um processo único, podendo ser desempenhado pelo gerente do projeto. No Scrum os processos vinculados ao gerenciamento do tempo acontecem de forma independente e são necessariamente atribuídos a diferentes profissionais. O seqüenciamento das atividades é um acordo entre todos os envolvidos, e a duração das sprints é fixa. A estimativa dos recursos é realizada pelo ScrumMaster ao se formar a equipe do projeto, e o desenvolvimento do cronograma é feito pelo ScrumMaster e Product Owner.

5 A definição das atividades é realizada iterativamente a cada release e a cada sprint, através do planejamento da release e do planejamento da sprint. Nessa definição, pode ser utilizada a técnica de story points, onde, para cada item do backlog, são atribuídos pontos que definem a priorização e complexidade do requisito. Dentre as ferramentas sugeridas pelo PMBOK para a definição das atividades, está o planejamento em ondas sucessivas, que consiste em planejar em detalhes as atividades a serem realizadas em curto prazo, o que é perfeitamente condizente com a proposta do Scrum. O seqüenciamento das atividades (identificação das dependências entre elas) é realizado informalmente, sem nenhuma documentação específica prevista além do quadro de tarefas atualizado pelo time. Também é iterativamente realizado nos planejamentos das releases, sprints e nas reuniões diárias. As estimativas de recursos devem ser feitas no início do projeto buscando formar um time com habilidades variadas, e.g. testadores, analistas, desenvolvedores, designers, etc. Caso uma tarefa exija uma habilidade que nenhum integrante do time possua, é possível acrescentar um novo integrante, mesmo que seja apenas durante uma sprint ou release. A duração das atividades do projeto são organizadas em releases, compostas por uma ou mais sprints, que podem durar de uma a quatro semanas. Dentro das sprints, os membros do time definem a duração de cada atividade (é sugerido que dure entre 4 e 16 horas [3]). Cronogramas podem ser desenvolvidos para determinar as releases como marcos e documentar a duração das sprints, mas a documentação de detalhes sobre dependências e seqüenciamento, como gráficos de Gantt, são menos prováveis no Scrum. O controle do cronograma é realizado através da garantia da obediência às datas de início e fim das sprints, que são reforçadas no planejamento das sprints e reuniões de revisão de cada sprint, nas reuniões diárias e no quadro de atividades, além de monitorado com os gráficos de burndown. Mudanças no cronograma, adição ou remoção de sprints, podem ocorrer caso mudanças drásticas afetem o projeto Gerenciamento de Custos Durante a fase de Pregame [9], onde ocorre a definição da nova release, o custo da mesma é estimado incluindo custos de desenvolvimento, material de consumo, marketing, treinamento e implantação. Scrum não especifica o orçamento para projeto completo, embora isso possa ser estimado com base nas primeiras releases. A definição dos custos em projetos ágeis é crucial para a definição das funcionalidades entregues, ao contrário de metodologias tradicionais que tentam primeiro fixar o escopo e depois ajustar os custos. Mesmo com a expectativa de que não haja variações do custo ao logo do projeto, um gerenciamento mínimo do mesmo se faz necessário, independente da metodologia utilizada.

6 3.5. Gerenciamento da Qualidade No Scrum, cabe aos integrantes do framework definir o que será medido e quais testes serão realizados. A garantia e o controle da qualidade são realizados constantemente nas reuniões diárias e reuniões de revisão, onde os impedimentos encontrados para a realização das tarefas são apresentados. Adicionalmente, as funcionalidades resultantes das sprints são apresentadas para avaliação em um ambiente mais próximo possível do ambiente de produção [11] Gerenciamento de Recursos Humanos O planejamento dos recursos humanos do projeto em Scrum tem papéis e funções bem definidos: Product Owner, ScrumMaster e membro do time. No entanto, detalhes de gerenciamento de pessoal, como recrutamento e seleção, tabela de horários, não são atendidos pelo Scrum, assim como os processos de contratar e mobilizar a equipe do projeto. O desenvolvimento da equipe pode ser planejado como uma sprint no planejamento das releases e sprints. As melhorias na interação da equipe é um processo contínuo no Scrum. Para equipes que estejam começando a implementar o Scrum, esse processo pode demorar um pouco, mas traz benefícios comprovados de produtividade. A gerência da equipe é realizada através das reuniões, acompanhamento do quadro de atividades e gráficos de desempenho, e.g. gráfico de burndown. A resolução de problemas consiste na retirada dos impedimentos levantados pela equipe nas reuniões diárias. As mudanças partem sempre do Product Owner e são gerenciadas juntamente com a equipe Gerenciamento das Comunicações As práticas sugeridas de valorização de pessoas e interações e de colaboração do cliente presentes no Manifesto Ágil são os fundamentos das atividades de comunicação no Scrum. Os problemas entre as partes interessadas devem ser resolvidos o mais rapidamente possível, de preferência em contato pessoal. No entanto, nenhuma documentação formal é requerida. A distribuição das informações pode ser considerada mais intensa do que o normal, considerando a quantidade de reuniões e a existência do quadro de atividades com os itens do backlog atualizados. Os gráficos de burndown das releases e sprints podem ser divulgados como relatórios de desempenho Gerenciamento de Riscos O planejamento do gerenciamento de riscos não é formalizado no Scrum. A análise quantitativa normalmente não é realizada em metodologias ágeis, e sim apenas a qualitativa [11]. A identificação de riscos depende da comunicação dos impedimentos pela equipe e da atitude pró-ativa do ScrumMaster, antecipando e eliminando os impedimentos. Esta atividade pode ser considerada como monitoramento e controle dos riscos.

7 3.9. Gerenciamento de Aquisições Nenhum dos processos de gerenciamento de aquisições é contemplado pelo Scrum. 4. Trabalhos Relacionados Diversos trabalhos na literatura descrevem análises comparativas entre diferentes abordagens de desenvolvimento. Em [2], [6], [11], [12], [13], [14] e [16] são realizadas análises comparativas com práticas ágeis, mas não se aprofundam nos conceitos do framework Scrum. Outras pesquisas [3] e [4] tratam da compatibilidade com o CMMI (Capability Maturity Model Integration), colocando como foco o Scrum. Um estudo de caso é apresentado em [15], mas não é apresentada uma análise comparativa mais detalhada. Em [15] fala do uso de um novo modelo na equipe que pode trazer um pouco de resistência por parte da mesma. Vimos que nos dois métodos deve-se ter um líder, o gerente de projetos, este deve exercer a motivação para incorporar a nova idéia. Um dos fatores desta resistência é que a metodologia ágil, que é mais nova, aparenta ser indisciplinado, ao mesmo tempo que a junção da tradicional facilita e põe mais disciplina ao ágil, o que dá uma maior aceitação por parte das empresas conservadoras. 5. Conclusão e Trabalhos Futuros Vimos que muitas das práticas propostas pelo PMBOK são implícitas no próprio framework Scrum, mas sem as formalidades de geração de documentos. Neste sentido, o Guia do PMI sugere vários tipos de planos, tais como plano de gerenciamento de riscos, de recursos humanos, etc. No entanto, a adequação e o grau de rigor de cada processo são variáveis que podem ser ajustadas de acordo às necessidades, segundo orientação do guia PMBOK. Este processo de adequação é uma responsabilidade compartilhada por todos os membros da equipe. Como trabalhos futuros, sugere-se um aprofundamento maior em cada área de processos do PMBOK, determinando semelhanças ou diferenças quando comparado com o Scrum, assim como a observação dos relacionamentos dessas práticas em projetos reais. Em contrapartida, um estudo sobre quais práticas ágeis do Scrum podem ser absorvidas pelo PMBOK [10] também é uma possível continuidade da presente pesquisa. Referências [1] BECK, K; et al. Manifesto for Agile Software Development Disponível em < Acesso em 22 de março de [2] MAGALHÃES, A.; ROUILLER, C.; DE VASCONCELOS, A. Gerenciamento de Projetos de Software Desenvolvidos à Luz das Metodologias Ágeis: Uma Visão Comparativa. Revista ProQuality, Lavras, v. 1, n. 1, p 29-46, maio, [3] MARÇAL, A.; et al. Mapping CMMI Project Management Process Areas to SCRUM Practices. C.E.S.A.R., Recife. Software Engineering Workshop, [4] MARÇAL, A.; et al. Blending Scrum practices and CMMI project management process areas. Journal of Innovations in Systems and Software Engineering. Springer. London, 2008.

8 [5] MARTINIG & ASSOCIATES. Software Development Poll: Programming, Testing, Open Source, UML, Agile, Tools, Web. Disponível em < Acesso em 20 de março de [6] OCHNER, J. Gerência de Projetos: Uma Comparação entre o PMBOK e XPM. Monografia f. Monografia (Bacharelado em Ciência da Computação). Universidade Federal de Lavras, Lavras. [7] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBOK). 4ª ed. Project Management Institute, [8] SCHWABER, K. Agile Project Management with Scrum. Microsoft Press. Redmond, Washington [9] SCHWABER, K. SCRUM Development Process. Proceedings of the 10th Annual ACM Conference on Object-Oriented Programming Systems, Languages, and Applications; Business Object Design and Implementation Workshop [10] SCRUM ALLIANCE. Agile Alliance: Bridging the PMI / Agile gap. Disponível em < Acesso em 20 de março de [11] SLIGER, M. Relating PMBOK Practices to Agile Practices. Disponível em < Acesso em 21 de março de [12] SLIGER, M.; BRODERICK, S. The Software Project Manager's Bridge to Agility. Addison-Wesley Professional [13] SNAVELY, K.; BROOME, T. PMI and Agile Oil and Water or Can they Co- Exist? Agile Conference Toronto, Canadá, [14] SOUZA NETO, O. Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis f.. Monografia (Bacharelado em Ciência da Computação). Universidade da Amazônia, Belém. [15] TAVARES, A. Gerência de Projeto com PMBOK e SCRUM Um Estudo de Caso f. Monografia. Faculdade Cenecista Nossa Senhora Dos Anjos, Gravataí. [16] UDO, N.; KOPPENSTEINER, S. Will Agile Development Change The Way We Manage Software Projects? Agile From a PMBOK Guide Perspective. Projectway, 2003.