ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS. contato@alinebrake.com.br. fs_moreira@yahoo.com.br. contato@marcelobrake.com.

Transcrição

1 ESTUDO DE CASO: SCRUM E PMBOK UNIDOS NO GERENCIAMENTO DE PROJETOS (CASE STUDY: SCRUM AND PMBOK - STATES IN PROJECT MANAGEMENT) Aline Maria Sabião Brake 1, Fabrício Moreira 2, Marcelo Divaldo Brake 3, João Paulo Leonardo de Oliveira 4 (O) 1 Centro Universitário UNIFAFIBE Bebedouro SP contato@alinebrake.com.br 2 Centro Universitário UNIFAFIBE Bebedouro SP fs_moreira@yahoo.com.br 3 Centro Universitário UNIFAFIBE Bebedouro SP contato@marcelobrake.com.br 4 Centro Universitário UNIFAFIBE Bebedouro SP joaoleo@unifafibe.br RESUMO O presente artigo discorre sobre o estudo de caso referente a união do framework ágil Scrum com processos do Guia PMBOK em um projeto de desenvolvimento de software Web, e identificar se com esta união é possível aprimorar a gestão sem perder os benefícios que o Scrum oferece. Palavras-chave: Scrum; PMBOK ; gestão de projetos. ABSTRACT This article discusses the case study concerning the union of the Scrum agile framework with the PMBOK Guide processes in a project to develop Web software, and identify with this union is possible to improve the management without losing the benefits that Scrum offers. Keywords: Scrum; PMBOK ; project management.

2 1 INTRODUÇÃO Muitos defendem que o uso do framework ágil Scrum é a melhor solução para desenvolvimento de projetos na área de tecnologia, outros apoiam o uso do modelo tradicional (Guia PMBOK), afirmando ser muito mais seguro. No entanto, há um terceiro grupo que acredita que um ambiente de projeto é muito mais complexo do que um modelo padrão, ou um conjunto de boas práticas, e propõe que a equipe identifique o que é melhor em cada momento da sua gestão, fazendo a união dos dois mundos para trazer mais força às equipes de desenvolvimento. (CRUZ, 2013) Assim, a partir da teoria de que a junção da abordagem ágil com a abordagem tradicional é uma estratégia que pode oferecer melhores resultados do que o uso isolado de apenas uma, este artigo tem o propósito de demonstrar o estudo de caso aplicado em uma empresa de desenvolvimento de software que utiliza o Scrum para gerenciar seus projetos de desenvolvimento de software. O objetivo deste trabalho foi aplicar a união do framework Scrum com alguns processos do Guia PMBOK em um dos projetos desenvolvidos pelo departamento de Desenvolvimento Web, e identificar se com esta união é possível aprimorar a gestão no desenvolvimento de projetos de software sem perder os benefícios que o Scrum oferece. A motivação para este estudo é a de maximizar o controle de qualidade, custos, aquisições e riscos do projeto envolvido. 2 REFERÊNCIAL TEÓRICO 2.1 Scrum O Scrum foi desenvolvido por Jeff Sutherland e Ken Schwaber no início da década de 1990 com o propósito de guiar o desenvolvimento de produtos complexos. Tem sido amplamente utilizado na criação ágil de software, porém, seus princípios e práticas podem ser aplicados em qualquer contexto onde um grupo de pessoas necessitam trabalhar em conjunto buscando um objetivo em comum. Segundo (SCHNEIDER, 2008), esta prática está sendo utilizada em projetos do Google, Yahoo, Globo.com, e o seu nome foi inspirado no esporte Rugby (PRESSMAN, 2006). Seu método de trabalho é iterativo e incremental. Iterativo por ser divido em fases ou

3 Sprints e cada Sprint é responsável pela entrega das funcionalidades do produto, estas funcionalidades são pré-determinadas pela equipe durante a reunião de planejamento da Sprint. Incremental pois ao término de cada Sprint, uma versão melhorada do produto ser entregue. A figura 1 ilustra uma iteração e um incremento do produto. Figura1: Sprint Scum Fonte: Por ser um framework ágil para o desenvolvimento de produtos, possui um conjunto reduzido de regras que estão divididas em papéis, artefatos e atividades. Papel é uma atribuição a um membro da equipe, artefatos são os documentos relacionados ao produto que se deseja construir, e atividades ou reuniões são os encontros da equipe para alinhamento e feedback sobre o produto. Os papéis do Scrum têm a seguinte denominação: Product Owner (PO), Development Team Member e ScrumMaster (SM). Product Owner (PO) é o dono do produto, ele é responsável pelo produto a ser desenvolvido. É ele quem define o escopo do produto desejado e garante que o resultado final tenha o mais alto valor possível. O PO pode receber ajuda da equipe de desenvolvimento afim de refinar os requisitos do projeto, denominado de Product Backlog, porém ainda é o PO quem direciona a equipe para o resultado final. Development Team Member é o membro da equipe de desenvolvimento, um profissional altamente qualificado capaz de se auto-gerenciar nas tarefas de desenvolvimento,

4 seguindo o Product Backlog e as metas da Sprint. Não existe hierarquia dentro da equipe e esta liberdade permite que as pessoas interajam de uma forma mais colaborativa, contribuindo para aumentar a performance do time. Scrum Master (SM) é o elo entre o PO e o Development Team. Ele tem o conhecimento sobre o framework Scrum e garante que todos os membros do time de desenvolvimento estejam alinhados com o Product Backlog. Ele também ajuda o PO a refinar o Product Backlog e garante que o resultado seja atingido no final de cada ciclo. Os artefatos podem ser entendidos como a documentação do produto em si e estão dividos em: Product Backlog e Sprint Backlog. Product Backlog é a essência do projeto, é um documento que contém todos os itens que precisam ser desenvolvidas para finalizar o projeto, ou seja o produto final. Como normalmente ele parte da área de negócios, é possível que o escopo não esteja totalmente definido antes do inicio das implementações, porém o framework permite que o Product Backlog seja amadurecido e consequentemente detalhado ao longo das fases de implementação. O PO é o responsável pelo Product Backlog, mas a equipe poderá ajuda-lo a refinar. Sprint Backlog é um subitem do Product Backlog, nele a equipe relaciona as atividades que serão executadas e as funcionalidades que serão implementadas durante a Sprint. A parte final do Scrum são as atividades: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective. O Sprint Planning é o planejamento da Sprint, ou seja, o que será executado durante a Sprint, é uma reunião de toda a equipe para definir o que será implementado e como será implementado. O resultado da reunião são as metas que deverão ser atingidas ao final da Sprint. Daily Scrum são reuniões rápidas da equipe de desenvolvimento afim de alinhar o trabalho em execução com o Sprint Planning. Como a equipe é auto-gerenciável, ela é capaz de verificar se as metas estão sendo cumpridas ou se são necessários ajustes na rotina de trabalho para que o planejamento da Sprint não seja comprometido. Sprint Review é uma reunião com tempo determinado, realizada uma vez por semana dentro da Sprint para revisar todo o trabalho executado e validar com o PO, dando uma visão geral de tudo que foi implementado durante a semana. Quando a Sprint chega ao final, é então realizada uma reunião denominada Sprint Retrospective, nela são revistos todos os itens do Sprint Planning, o que foi bem executado

5 bem como os itens que precisam de revisão e ajustes. Pela busca da agilidade e entrega de valor ao cliente no menor tempo possível, o Scrum não aborda várias das áreas que precedem, sucedem ou atravessam o desenvolvimento de um produto, focando quase exclusivamente em processos da etapa de execução. Desta forma, não abrange áreas fundamentais, que de acordo com a complexidade do projeto, se tornam tão importantes quanto a entrega do produto final, tais como custos, riscos, qualidade e aquisições. (CRUZ, 2013) 2.3 PMBOK Segundo o PMBOK (2013, p. 417), "projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado único" e o de Projetos é "a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos". O Guia sugere que o gerenciamento de projetos através da aplicação e integração apropriadas dos seus quarenta e sete processos, logicamente agrupados em cinco grupos de processos e dez áreas de conhecimento, de acordo com o mapeamento a seguir: QUADRO 1 Mapeamento de grupos de processos de gerenciamento de projetos e áreas de conhecimento Grupos de Processos do de Projetos Áreas de Conhecimento Monitoramento e Iniciação Planejamento Execução Encerramento Controle Encerrar o Projeto ou Fase da Integração 5. do Escopo 4.1 Desenvolver o Termo de Abertura do Projeto 4.2 Desenvolver o Plano de do Projeto 5.1 Planejar o do Escopo 5.2 Coletar os Requisitos 5.3 Definir o Escopo 5.4 Criar a EAP 4.3 Orientar e Gerenciar o Trabalho do Projeto 4.4 Monitorar e Controlar o Trabalho do Projeto 4.5 Realizar o Controle Integrado de Mudanças 5.5 Validar o Escopo 5.6 Controlar o Escopo

6 6. do Tempo 7. dos Custos 8. da Qualidade 9. dos Recursos Humanos 10. das Comunicações 6.1 Planejar o do Cronograma 6.2 Definir as Atividades 6.3 Sequenciar as Atividades 6.4 Estimar os Recursos das Atividades 6.5 Estimar as Durações das Atividades 6.6 Desenvolver o Cronograma 7.1 Planejar o dos Custos 7.2 Estimar os Custos 7.3 Determinar o Orçamento 8.1 Planejar o da qualidade 9.1 Planejar o dos Recursos Humanos 10.1 Planejar o das Comunicações 8.2 Realizar a Garantia da Qualidade 9.2 Mobilizar a Equipe do Projeto 9.3 Desenvolver a Equipe do Projeto 9.4 Gerenciar a Equipe do Projeto 10.2 Gerenciar as Comunicações 6.7 Controlar o Cronograma 7.4 Controlar os Custos 8.3 Controlar a Qualidade 10.3 Controlar as Comunicações 11. dos Riscos 12. das Aquisições 11.1 Planejar o dos riscos 11.2 Identificar os Riscos 11.3 Realizar a Análise Qualitativa dos Riscos 11.4 Realizar a análise Quantitativa dos Riscos 11.5 Planejar as Respostas aos Riscos 12.1 Planejar as Aquisições 12.2 Conduzir as aquisições 11.6 Monitorar e Controlar os Riscos 12.3 Administrar as Aquisições 12.4 Encerrar as Aquisições

7 13. das Partes Interessadas 13.1 Identificar as Partes Interessadas 13.2 Planejar o das Partes Interessadas 13.3 Gerenciar o Engajamento das Partes Interessadas 13.4 Controlar o Engajamento das Partes Interessadas Fonte: PMBOK (2013) Segundo CRUZ (2013), é um excelente guia, mas vários profissionais e iniciantes na área o interpretam de forma equivocada, entendendo que ele é engessado, burocrático e inapropriado para projetos que precisam ser mais ágeis e dinâmicos. No entanto, o PMBOK se propõe a ser um conjunto de boas práticas que deve ser executado sobre uma metodologia - e esta sim tem o poder de torna-lo engessado ou flexível, ágil ou pesado. A maior fraqueza do guia PMBOK é que ele sugere o que deve ser feito, mas não descreve como, portanto, é alvo principal do Scrum. Já os maiores pontos fortes do guia PMBOK são o detalhamento do que deve ser feito, e o fato de abranger todas as áreas de gerenciamento como custos, aquisições, qualidade e riscos, que não são cobertos pelo Scrum. (CRUZ, 2013) 3 METODOLOGIA O presente artigo ter por base o estudo de caso realizado em uma fábrica de software de Bebedouro, estado de São Paulo, onde foi possível aplicar a teoria proposta. O método utilizado avalia os acontecimentos ao longo de um período sem intervir no fatos ocorridos. Dentre as questões que determinam a escolha de uma pesquisa, verificou-se que o "como" e "por que" são as questões ligadas ao estudo de caso e também podem ser utilizadas em outras formas de estudo como: experimentos ou pesquisas históricas (YIN, 2001). Para a elaboração deste trabalho também foi utilizada a pesquisa bibliográfica, realizada através de informações encontradas em livros, reportagens e artigos. Este tipo de pesquisa é classificado como qualitativa documental, ou seja, embasada em estudo de livros, fundamentando ideias de autores. 4 DESENVOLVIMENTO 4.1 Iniciação do projeto - Antes da União Como a empresa já trabalha com o Scrum, foi estudado como encaixar os processos

8 PMBOK neste cenário. Para o estudo de caso foi escolhido um projeto do departamento de Desenvolvimento Web em fase de desenvolvimento, pois não havia previsão de início de um novo projeto. A equipe deste projeto é composto pela gerente do departamento de Desenvolvimento Web, que atua nos papéis de PO e SM, e pelo Development Team, que é multifuncional e multidisciplinar, capaz de construir o produto do projeto e realizar as entregas. O Development Team conta com três analistas de sistemas, quatro programadores, uma auxiliar de programação e um design gráfico. O projeto escolhido deu-se início após uma reunião, sendo que não foi criado um termo de abertura nem nenhum plano de gerenciamento formal. 4.2 Como foi efetuada a união O projeto escolhido possui sete módulos de tamanho médio, e cada analista de sistemas conhece bem a arquitetura e funcionamento de pelo menos um módulo, então aproveitou-se este conhecimento e cada analista assumiu o papel de GP de pelo menos um módulo, sendo que estes GP's foram chamados de líderes de módulo. Os primeiros trabalhos com os GP's e a PO/SM foram com o objetivo de identificar quais áreas de conhecimento e processos do PMBOK poderiam se encaixados no dia-a-dia da Development Team, de forma a aumentar o gerenciamento de áreas que causavam problemas. Foram escolhidas quatro áreas (7, 8, 11 e 12) e dezesseis processos (7.1, 7.2, 7.3, 7.4, 8.1, 8.2, 8.3, 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 12.1, 12.2 e 12.3). Após foram criadas as primeiras versões dos planos de gerenciamento. Neste momento foram utilizados os processos 7.1, 8.1, 11.1 e 12.1 do PMBOK. Nos próximos tópicos serão demonstrados como a união foi realizada durante as atividades do Scrum: Planejando o Backlog Em adição aos processos já realizados pelo Scrum (coletar os requisitos e definir o escopo), a PO/SM e os GP's começaram a prever qual era a capacidade aproximada do Development Team para trabalhar e completar o trabalho do Product Backlog, e, com a estimativa dos recursos, eles tiveram informações suficientes para estimar os custos e determinar o orçamento do projeto para a próxima Sprint. Neste momento foram utilizados os

9 processos 7.2 e 7.3 do PMBOK Sprint Planning A reunião de planejamento da Sprint (Sprint Planning) continuou a ser executada normalmente, onde o time selecionava os itens que formariam o Sprint Backlog, fazia a decomposição dos itens em tarefas menores, estimava a duração das tarefas, que por fim eram adicionadas no software Team Foundation System, da Microsoft, que funciona como um quadro de tarefas. No planejamento da Sprint e nas reuniões diárias (Daily Scrum), o time de desenvolvimento (Development Team) levantava várias questões, e algumas delas geraram riscos que precisavam ser gerenciados. Nestes momentos os GP's utilizavam os processos 11.2, 11.3, 11.4, 11.5 e 11.6 do PMBOK Sprint e Daily Scrum Durante a execução da Sprint continuaram a ocorrer as reuniões diárias (Daily Scrum), onde a PO/SM orientava e conduzia os trabalhos do time de desenvolvimento (Development Team), que transformava o Sprint Backlog em produto. Na reunião diária, os GP's participavam (até por terem também suas próprias tarefas de desenvolvimento), e tinham a oportunidade de identificar riscos ou questões que poderiam afetar as outras áreas do projeto, como aquisições e qualidade. Cada GP assumiu três responsabilidades perante os programadores com tarefas nos módulos atribuídos a ele: - Orientar: Logo após a definição da Sprint, dar orientações sobre a arquitetura já existente e dicas de como iniciar o desenvolvimento das tarefas; - Auxiliar: No decorrer da Sprint, auxiliar o programador em caso de falta de conhecimento técnico para cumprir determinada tarefa; - Validar: Após a conclusão de uma tarefa, validar se a funcionalidade está correta e a estrutura criada está dentro dos padrões do módulo, caso não, orientar e auxiliar o programador nas correções. As duas primeiras responsabilidades, os analistas de sistemas antes de serem GP's já faziam naturalmente, embora informalmente, por terem um conhecimento maior sobre o módulo, mas com a responsabilidade assumida empenharam-se mais em compartilhar o

10 conhecimento, e os programadores sentiram-se mais seguros em desenvolver as suas tarefas, tirar dúvidas e solicitar ajuda aos mais experientes. Aliadas com a responsabilidade de validação, notou-se um aumento no conhecimento técnico dos analistas e programadores, e uma redução drástica na ocorrência de bug's, aumentando a qualidade do projeto. No decorrer da Sprint, os GP's utilizavam os processos 7.4, 8.2, 8.3, 11.2, 11.3, 11.4, 11.5, 11.6, 12.2 e 12.3 do PMBOK Sprint Review e Sprint Retrospective Como a duração da Sprint é de uma semana, as atividades de reunião de revisão (Sprint Review) e retrospectiva (Sprint Retrospective) de cada Sprint são realizadas juntas, momentos antes da reunião de planejamento da nova Sprint (Sprint Planning), com a realização das seguintes tarefas: - Aceitação da PO/SM referente aos itens de Backlog completados e apresentados; - Solicitações de mudança para os itens reprovados, o que podia também gerar atualizações nos planejamentos do projeto; - Os itens aceitos eram liberados para a entrega aos clientes (lançamento da versão). Nestas reuniões todo o time Scrum participava, buscando uma melhoria contínua da equipe e do projeto, e registrando as lições aprendidas. Após a troca da Sprint, a PO/SM também participava de uma reunião com os diretores da empresa, com o objetivo central de passar uma situação resumida do projeto, focando em avanços, riscos ou impedimentos identificados. No final da Sprint continuou a ser gerado o incremento do produto (nova versão do sistema), que é colocada em um ambiente para validação pelos clientes, e após uma semana é colocada em produção Encerramento do projeto Até o final do estudo de caso o projeto não havia sido encerrado. 5 RESULTADOS Mesmo o projeto não tendo sido encerrado durante o estudo de caso, foi possível observar vários ganhos obtidos, dentre eles:

11 - Excelentes resultados de qualidade: percebeu-se uma redução drástica na ocorrência de bug's; - Controle de custos: conseguiu-se estimar os custos previstos para as Sprint's; - Controle de aquisições: houve maior preocupação com as aquisições para o projeto. Vale salientar que os GP's com a PO/SM notaram a necessidade de aquisição de um novo membro para o Development Team, um analista de testes, também no intuito de aumentar a qualidade do projeto pela execução de testes automatizados, de desempenho, de carga, de segurança, entre outros. Foi escolhida uma funcionária de outro departamento da empresa que já havia demonstrado interesse nesta área, sendo que a liberação da transferência de departamento só ocorreu no início do mês de novembro e até o final do estudo de caso estava criando casos de teste e testes parcialmente automatizados; - Controle de riscos: houve minimização da ocorrência de riscos; - Desenvolvimento do Time Scrum: a equipe vivenciou a experiência de aplicar as melhores técnicas ágeis proporcionadas pelo Scrum em conjunto com as mais fortes práticas do PMBOK, entregando um ganho enorme de conhecimento, aprendizado e experiência a todos os envolvidos. No início do estudo de caso notou-se uma redução na quantidade de itens entregues por Sprint, pois o time passou por uma fase de adaptação e os GP's que eram analistas de sistemas Development Team Member, assumiam menos itens para poder orientar, auxiliar e validar os itens criados pelos demais Development Team Members. No entanto, com o passar do tempo, notou-se o aumento do conhecimento dos demais Development Team Members, que passaram a necessitar menos de auxílio e os itens precisavam de menos correções após a validação, onde a produtividade de todos aumentou. 6 CONSIDERAÇÕES FINAIS Este estudo de caso mostra o sucesso na aplicação da união do framework ágil Scrum com alguns processos do Guia PMBOK, aprimorando a gestão do projeto escolhido, sem perder os benefícios que o Scrum oferece. Este aprimoramento pode proporcionar a fidelização de clientes atuais e a conquista de novos clientes.

12 REFERÊNCIAS ALLIANCE, Scrum. Core Scrum. Disponível em: < Acessado em: 1 de Agosto de CRUZ, Fábio. Scrum e PMBOK unidos no gerenciamento de projetos. 1. ed. Rio de Janeiro: Brasport, PRESSMAN, ROGER S. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, PMBOK, Guia. Um guia do conhecimento em gerenciamento de projetos. 5. ed. Pensilvânia: Project Managment Institute, Inc, SCHWABER K. ;SUTHERLAND J. Guia do Scrum: Um guia definitivo para o Scrum. Disponível em: < BR.pdf>. Acessado em: 1 de Agosto de YIN, R.K. Estudo de caso: planejamento e métodos. 2. ed. Porto Alegre: Bookman, 2001.