UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia da Computação RAFAEL HIDEMASA FURUKAWA

Transcrição

1 UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia da Computação RAFAEL HIDEMASA FURUKAWA ESTUDO DE APLICAÇÃO DE PRÁTICAS DO PMBOK EM PROJETOS DE SOFTWARE BASEADOS EM SCRUM Itatiba 2012

2 UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia da Computação RAFAEL HIDEMASA FURUKAWA ESTUDO DE APLICAÇÃO DE PRÁTICAS DO PMBOK EM PROJETOS DE SOFTWARE BASEADOS EM SCRUM Itatiba 2012 RAFAEL HIDEMASA FURUKAWA

3 ESTUDO DE APLICAÇÃO DE PRÁTICAS DO PMBOK EM PROJETOS DE SOFTWARE BASEADOS EM SCRUM Trabalho aprovado pelo Programa de Graduação em Engenharia de Computação da Universidade São Francisco, como requisito parcial para obtenção do título de Bacharel em Engenharia de Computação Data de Aprovação: 12/12/2012 Banca Examinadora: Professor Esp. Ricardo César Boaretto Prof. (Orientador) Universidade São Francisco Professor Dr. Cláudio Kiyoshi Umezu Prof. (Examinador) Universidade São Francisco Professor Anderson Luis Pancotto Prof (Examinador) Universidade São Francisco

4 Dedicatória A minha família e amigos

5 AGRADECIMENTOS A minha família, por tudo. Aos meus amigos por me apoiarem. Aos colegas de trabalho pela ajuda nesta etapa tão importante. Ao Professor Ricardo, que me orientou e guiou neste trabalho. Aos professores e colegas da universidade, com os quais aprendi muito.

6 RESUMO Um projeto é tipicamente definido como uma iniciativa de um grupo ou empresa, muitas vezes envolvendo pesquisa e desenvolvimento, que é cuidadosamente planejada para alcançar um determinado objetivo dentro de um prazo, com certo custo e qualidade. Projetos de software demandam grande velocidade em seu desenvolvimento, o mercado exige soluções prontamente cada vez mais, novas tecnologias surgem a cada momento e os negócios devem se adaptar a elas. Para alcançar o objetivo do projeto da melhor forma, são utilizadas metodologias e conhecimentos, comprovadamente eficazes para gerenciar esse esforço da empresa, grupo ou entidade. O PMBOK é um conjunto de práticas conceituadas há bastante tempo no mercado, permitindo gerenciar projetos de todo o tipo, incluindo os de software. O Scrum é um framework atual, uma metodologia ágil, criada em tempos modernos focada especificamente em projetos de software. Este trabalho irá apresentar as duas metodologias quando utilizadas em projetos de software, comparar técnicas e métodos que podem ser utilizados em conjunto para se alcançar o melhor resultado. Palavras-chave: PMBOK, SCRUM, Gerencia de Projetos.

7 ABSTRACT A project is typically defined as an initiative of a group or company, often involving research and development, that is carefully planned to achieve a particular goal within a time limit, with certain cost and quality. Software projects require great speed in its development, the market requires solutions readily, new technologies emerge every time and businesses must adapt to them. To achieve the objective of the project in the best way, are used methodologies and knowledge, proven effective in managing the effort of the company, group or entity. The PMBOK is a set of practices conceptualized a long time on the market, allowing management of projects of all kinds, including software. The Scrum is an actual framework, an agile methodology, created in modern times focused specifically on software projects. This work will present the two methods when used in software projects, compare techniques and methods that can be used together to achieve the best result. Key-words: PMBOK, SCRUM, Project Management

8 LISTA DE FIGURAS FIGURA1 Custos típicos e nível de pessoal através do ciclo de vida do projeto 11 FIGURA 2 Impacto de uma variável baseado no tempo do projeto 12 FIGURA 3 Mapeamento de grupo de processos de gerenciamento de projetos e áreas de conhecimento 15 FIGURA 4 Gerenciamento de Integração De Projetos 18 FIGURA 5 Gerenciamento De Escopo De Projetos 20 FIGURA 6 Visão Geral do Gerenciamento de Tempo do Projeto 22 FIGURA 7 Visão Geral do Gerenciamento de Custo do Projeto 24 FIGURA 8 Visão Geral do Gerenciamento de Qualidade do Projeto 25 FIGURA 9 Visão Geral do Gerenciamento de Recursos Humanos do Projeto 27 FIGURA 10 Visão Geral do Gerenciamento de Comunicações do Projeto 29 FIGURA 11 Visão Geral do Gerenciamento de Risco do Projeto 32 FIGURA 12 Visão Geral do Gerenciamento de Aquisições do Projeto 34 FIGURA 13 Exemplo de Release Backlog 41 FIGURA 14 Exemplo de Release Burndown Chart 42 FIGURA 15 Exemplo de Product Backlog 47 FIGURA 16 Exemplo de Sprint Backlog 48 FIGURA 17 Sprint Burndown 49 FIGURA 18 Ciclo Sprint 50 FIGURA 19 Proposta de novos papéis no Scrum 58 FIGURA 20 Proposta de novo fluxo de Scrum 59 -

9 LISTA DE SIGLAS PMBOK Project Management Body of Knowledge

10 SUMÁRIO INTRODUÇÃO Objetivos Metodologia Objetivos O GUIA PMBOK Projeto Gerenciamento de projeto Relações entre Gerenciamento de Projeto, Gerenciamento de Programa e Gerenciamento de Portfólio Gerenciamento de Portfólio Gerenciamento de Programa Projetos e Planejamento Estratégico Função do Gerente de Projeto Ciclo de vida do projeto e organização O Ciclo de Vida do Projeto Visão Geral Características do Ciclo de Vida do Projeto Fases do Projeto Partes interessadas Processos de Gerenciamento de Projeto ÁREAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS Gerenciamento de Integração de Projeto Gerenciamento de Escopo de Projeto Gerenciamento de Tempo de Projeto Gerenciamento de Custo de Projeto Gerenciamento de Qualidade de Projeto... 25

11 5.6 Gerenciamento de Recursos Humanos de Projeto Gerenciamento de Comunicação de Projeto Gerenciamento de Risco de Projeto Gerenciamento de Aquisição de Projeto SCRUM Time Scrum e Papéis Product Owner Equipe de desenvolvimento Scrum Master Eventos Scrum Sprint Planning Poker Reunião Diária Artefatos do Scrum User Stories Definição de Pronto Análise comparativa do PMBOK e Scrum Definição dos requisitos do projeto Responsabilidades no projeto Definição do custo do projeto Definição do tempo do projeto Definição de riscos do projeto Qualidade no projeto Recursos Humanos Comunicações Aquisições Aplicação de práticas do PMBOK em projetos com SCRUM Conclusão REFERÊNCIAS BIBLIOGRÁFICAS... 63

12 1 INTRODUÇÃO Um projeto é tipicamente definido como uma iniciativa de um grupo ou empresa, muitas vezes envolvendo pesquisa e desenvolvimento, que é cuidadosamente planejada para alcançar um determinado objetivo dentro de um prazo, com certo custo e qualidade. O esforço coletivo deve ser organizado para se alcançarem os objetivos determinados da melhor forma, para isso um gerenciamento de projetos é necessário. Esse gerenciamento irá aplicar conhecimentos, habilidades e técnicas na elaboração das atividades para se alcançarem os objetivos. O PMBOK (Project Management Body of Knowledge) é um conjunto de práticas em gerência de projetos publicado pelo Project Management Institute (PMI) a maior associação do gênero no mundo. Essas práticas são compiladas na forma de um guia, o Guia PMBOK. O guia fornece um conjunto de boas práticas para serem utilizadas em gerenciamento de projetos, como são boas práticas isso quer dizer que não devem ser aplicadas em todos os projetos sem considerar se são apropriados para aquele propósito. O Scrum é uma metodologia destinada para gerenciamento de projetos de software principalmente, utilizado em trabalhos complexos aonde não é possível prever todas as ações. As técnicas do PMBOK podem ser benéficas para o Scrum, mas é necessário que se faça uma análise delas para que elas possam agregar melhores resultados.

13 2 1 OBJETIVOS O objetivo deste trabalho foi estudar, analisar e comparar as técnicas do PMBOK que podem ser empregadas na metodologia SCRUM, alcançando assim os objetivos do projeto com maior qualidade, velocidade ou custos. O Scrum foi estudado em conjunto, para que se possa compreender quais suas características e como as práticas do PMBOK podem auxiliar essa metodologia ágil no desenvolvimento de software. As diferenças principais das técnicas das metodologias serão comparadas e analisadas, vantagens e desvantagens serão apresentadas em cada modelo e analisadas. Esse estudo permitiu que PMBOK e SCRUM sejam aplicados em conjunto, utilizando técnicas que sejam benéficas para a metodologia de ambos.

14 3 2 METODOLOGIA Um estudo foi realizado para conhecer as práticas do PMBOK, com ênfase em práticas que podem ser utilizadas em projetos de software o caso típico em que o SCRUM é utilizado. Com as práticas escolhidas que podem ser utilizadas em SCRUM foi feita uma análise comparativa, qual impacto ela teria no SCRUM, suas vantagens e desvantagens, diferenças. Por fim foi apresentada a combinação do PMBOK e SCRUM, com práticas que fazem sentido para o negócio e agregam valor a ele.

15 4 3 OBJETIVOS Esperou-se mostrar neste trabalho que PMBOK e SCRUM podem ser aplicados juntos, comparando as práticas de ambos e mostrando fraquezas que podem ser sanadas através dessa junção. Alcançando assim projetos que obtenham totalmente seus objetivos. O PMBOK apresenta técnicas que estão sendo aperfeiçoadas há anos, porém sua eficiência em projetos de software é questionável. O Scrum foi desenvolvido para software, mas é jovem ainda e não possui tanta experiência quanto o PMBOK. Combinados pode-se obter uma solução ágil e eficiente, utilizando técnicas de ambos.

16 5 4 O GUIA PMBOK O PMBOK surgiu devido à necessidade de gerenciamento de projetos de forma padronizada, aplicando conhecimento, processos, habilidades, ferramentas e técnicas que impactam no sucesso e qualidade do projeto. O Guia PMBOK possui essa base de conhecimentos para projetos que são ditas como boas práticas, pois seu uso não deve ser aplicado uniformemente em todo o projeto, cabe aos seus responsáveis do projeto, empresa, definir o quê é apropriado para o seu projeto, extrair o melhor para cada caso em particular deste guia, conforme o Guia PMBOK. 4.1 Projeto O Guia PMBOK define um projeto como uma empreitada temporária para criar um produto, serviço ou resultado. O fato de ser temporário indica que possuirá um começo e fim definitivo. Seu fim é alcançado através da obtenção dos resultados esperados ou quando seu objetivo não pode ser alcançado, ou não é necessário mais. Os projetos apesar de serem temporários não são curtos necessariamente, e seu resultado, produto, pode ser algo que irá durar muito tempo. Todo projeto é único, mesmo contendo elementos repetitivos, processos ou eventos similares com outros, algo o tornará único sempre. Um projeto poderá criar: Um produto que poderá ser um componente de outro item, ou um item final. Um serviço. Um resultado, conclusão. 4.2 Gerenciamento de projeto Gerenciamento de projeto é a aplicação do conhecimento, habilidades, ferramentas e

17 6 técnicas para projetar atividades e alcançar os requisitos do projeto. O gerenciamento de projetos é alcançado através da aplicação correta e integração de 42 processos lógicos agrupados em 5 grupos de processos, conforme o Guia PMBOK. Esses grupos são: Iniciar Planejar Executar Monitorar e controlar Encerrar Gerenciar um projeto tipicamente implica: Identificar requisitos Cuidar de várias necessidades, preocupações e expectativas das partes interessadas conforme o projeto é planejado e construído. Balancear as restrições do projeto, algumas delas são: o Escopo o Qualidade o Prazos o Orçamento o Recursos o Risco A relação entre esses fatores é grande, se um fator é alterado pelo menos um dos outros será também. Um orçamento menor pode impactar nos prazos ou qualidade por exemplo. O plano de gerenciamento de projeto é iterativo e passa por mudanças ao longo de se elaboração progressiva, ele evolui e se torna mais detalhado quando mais informação específica torna-se disponível e estimativas ficam mais apuradas, segundo o Guia PMBOK.

18 7 4.3 Relações entre Gerenciamento de Projeto, Gerenciamento de Programa e Gerenciamento de Portfólio Em organizações maduras de gerenciamento de projetos, o Guia PMBOK determina que o gerenciamento de projeto existe em um contexto maior governado pelo gerenciamento de programa e gerenciamento de portfólio. Estratégias organizacionais e prioridades são ligadas e possuem relações entre portfólios e programas, e entre programas e objetos individuais. Planejamento organizacional impacta projetos na parte de priorização de projetos, baseado em risco, financiamento, e plano estratégico da organização. 4.4 Gerenciamento de Portfólio O Guia PMBOK define um portfólio como um conjunto de projetos ou programas e outros trabalhos que são agrupados para facilitar o gerenciamento daquele trabalho e alcançar os objetivos estratégicos do negócio. Os projetos ou programas não precisam ser relacionados diretamente uns com os outros, os projetos relacionados podem ser tratados como um programa enquanto outros são tratados como outros programas. Gerenciamento de Portfólio se refere à centralização do gerenciamento de um ou mais portfólios, incluindo identificação, priorização, autorização, gerenciamento, controle de objetos, programas e outros trabalhos relacionados; para alcançar objetivos específicos estratégicos do negócio. O Gerenciamento de portfólio foca em assegurar que projetos e programas são revisados para priorizar alocação de recursos, e que o gerenciamento do portfólio é consistente e alinhado com as estratégias organizacionais, segundo o Guia PMBOK.

19 8 4.5 Gerenciamento de Programa Um programa é um grupo de projetos relacionados gerenciados de uma forma coordenada para se obter benefícios e controle que não seriam possíveis se fossem gerenciados separadamente. Um projeto pode ser ou não ser parte um programa, mas um programa sempre terá projeto, de acordo com o guia PMBOK. O Gerenciamento de Programas foca nas interdependências e auxilia em determinar a ação correta para gerenciá-los. Essas ações podem ser: Resolver restrições de recursos e/ou conflitos que afetam múltiplos projetos dentro do programa. Alinha decisões estratégias da organização que afetam os objetivos dos projetos e do programa. Resolver a questões e mudar o gerenciamento dentro de uma estrutura de governança compartilhada. 4.6 Projetos e Planejamento Estratégico Projetos são freqüentemente utilizados como meios de se alcançar um plano estratégico de uma organização. Projetos são autorizados como resultado de um ou mais das seguintes considerações estratégicas, definido pelo guia PMBOK. Demanda de mercado. Oportunidade estratégica ou necessidade de negócio. Pedidos de clientes. Avanço tecnológico. Requisitos legais. Organizações gerenciam portfólios baseado em seu plano estratégico, um objetivo do portfólio e maximizar seu valor, através da análise se seus componentes. Ao mesmo tempo projetos fornecem informações para programas e portfólios, através de relatos de status e requisições de mudanças que podem impactar outros projetos, programas ou portfólios. As

20 9 necessidades dos projetos, incluindo as de recurso, são encaminhadas para o nível do portfólio, que por sua vez define a direção do planejamento da organização. 4.7 Função do Gerente de Projeto O gerente de projeto é a pessoa escolhida pela organização para alcançar os objetivos do projeto. O papel do gerente de projeto é diferente de um gerente funcional ou de um gerente de operações. Tipicamente o gerente funcional é focado em prover gerenciamento para uma área administrativa e o de operações é responsável por operações do negócio, conforme o Guia PMBOK. Além dos conhecimentos utilizados em gerenciamento de projetos, é necessário outras características para o gerente de projeto: Conhecimento Se refere sobre o que o gerente de projeto conhece do projeto. Desempenho Se refere ao que o gerente de projeto é capaz de realizar enquanto aplica seu conhecimento de projetos. Pessoal Se refere a como o gerente de projeto se comporta enquanto realiza suas atividades do projeto. Eficiência pessoal se refere a atitudes, personalidade e liderança, sua habilidade de guiar o time de projeto enquanto alcançam os objetivos. 4.8 Ciclo de vida do projeto e organização Projetos e gerenciamento de projetos estão em ambientes maiores que o projeto. Entender esse ambiente maior assegura que o trabalho é realizado de acordo com os objetivos da empresa e é gerenciado de acordo com as metodologias estabelecidas por ela, de acordo com o Guia PMBOK. As seguintes seções serão abordadas: O Ciclo de Vida do Projeto Visão Geral. Projetos VS Trabalho Operacional. Partes interessadas.

21 10 Influências da Organização no Gerenciamento de Projetos. 4.9 O Ciclo de Vida do Projeto Visão Geral O Ciclo de Vida do Projeto é uma coleção geralmente de fases seqüenciais e vezes simultâneas as quais o nome o número são determinados pelo gerenciamento ou natureza do projeto. Um ciclo de vida pode ser documentado, com uma metodologia. Enquanto todo projeto possui começo e fim, as ações específicas que ocorrem durante ele variam grandemente com o projeto. O ciclo de vida fornece a estrutura básica para gerenciar o projeto, não importando o trabalho específico envolvido, definido pelo Guia PMBOK Características do Ciclo de Vida do Projeto O Guia PMBOK menciona que projetos variam em tamanho e complexidade. Não importando o quanto pequenos ou grandes, simples ou complexos, todos os projetos podem ser mapeados de acordo com a seguinte estrutura de ciclo de vida: Iniciar o projeto. Organizar e preparar. Executar o trabalho. Fechamento do projeto. Esse ciclo de vida genérico é utilizado quanto se comunicando com entidades menos familiares com o projeto.

22 11 Fonte: PMBOK Guide (2008, p16) FIGURA 1 Custos típicos e nível de pessoal através do ciclo de vida do projeto. O ciclo de vida genérico possui as seguintes características: Níveis de custo e pessoal são baixos no começo, tem seu pico durante o trabalho e caem rapidamente quando o projeto se aproxima do seu fim. As influências das partes envolvidas, risco e incerteza, são maiores no começo do projeto. Esses fatores diminuem ao longo do projeto. A habilidade em influenciar as características finais do produto do projeto, sem impactar significantemente o custo, são maiores no começo do projeto e diminuem ao longo de sua vida.

23 12 Fonte: PMBOK Guide (2008, p17) FIGURA 2 Impacto de uma variável baseado no tempo do projeto Fases do Projeto Fases do projeto são divisões dentro de um projeto aonde controle extra é necessário para efetivamente gerenciar a realização de uma entrega. A estrutura das fases permite que o projeto seja segmentado em subconjuntos lógicos para facilitar o gerenciamento, planejamento e controle. O número de fases, a necessidade de fases e o grau de controle aplicado dependem do tamanho, complexidade e potencial impacto no projeto. Independente do número de fases, todas possuem as mesmas características, conforme o Guia PMBOK. Quando as fases são seqüenciais, o fechamento de uma fase termina com alguma forma de transferência ou entrega do produto do trabalho produzido conforme a fase. Esse fim de fase é um ponto natural para se reavaliar o esforço empregado e mudar ou terminar o projeto se necessário. Esses pontos são chamados de phase exists, milestones, phase gates, decision gates, stage gates ou kill points. O trabalho tem um foco distinto que difere de outras fases. O produto primário ou objetivo da fase requer um grau extra de controle para ser bem sucedida. A repetição de processos através dos 5 grupos, provê esse controle

24 13 adicional e define os limites da fase. Não existe maneira ideal de se definir uma estrutura para um projeto. Apesar de a indústria optar por algumas estruturas preferidas, baseadas em experiências similares anteriores, sempre haverá variações. Tudo depende do projeto e do estilo do seu time e organização, conforme o Guia PMBOK Partes interessadas As partes interessadas são as pessoas ou organizações que estão envolvidas com o projeto. Elas podem interagir desde detalhes até grandes decisões. O Guia PMBOK define as seguintes partes: Clientes/Usuários: Pessoas ou organizações que utilizarão o produto. Patrocinador: Pessoas ou grupos que financiam o projeto. Participa da definição do escopo do projeto. Gerentes de Portfólio: Gerenciam conjuntos de projetos. Gerentes de Programas: Gerenciam projetos coordenados, auxiliando o Gerente de Projetos. Gerentes de Projetos: Gerenciam um projeto em específico, sendo o responsável em informar as partes interessadas do projeto as informações necessárias. Equipe do Projeto: A equipe é o time envolvido tanto no gerenciamento do projeto quanto em sua execução. Gerentes Funcionais: Gerenciam outras áreas administrativas, mas podem auxiliar com informações o projeto. Gerentes de Operações: Gerenciam áreas que estão diretamente envolvidas com os produtos ou serviços que a empresa vende.

25 Processos de Gerenciamento de Projeto Os processos são técnicas ou ferramentas necessárias para se alcançar um objetivo do projeto. Eles são divididos em cinco grupos: Grupo de processos de iniciação: Processos relacionados com ao início de um projeto ou de uma fase dele, requisitando sua autorização. Grupo de processos de planejamento: Processos relacionados com a definição de escopo, objetivos, seu planejamento. Grupo de processos de execução: Processos relacionados com a execução do projeto, como executar as tarefas necessárias. Grupo de processos de monitoramento e controle: Processos para acompanhar o andamento do projeto, podendo assim identificar intervenções aonde necessário. Grupo de processos de encerramento: Processos relacionados para encerrar um projeto ou fase. Os grupos de processos não são as fases de um projeto, cada fase utiliza de todos os grupos desde sua criação até seu encerramento. A figura a seguir ilustra relação dos grupos de processos com as áreas de conhecimento do PMBOK e seus processos, pode-se notar que a maioria deles está na fase de planejamento.

26 15 Fonte: PMBOK Guide (2008, p43) Figura 3 Mapeamento de grupo de processos de gerenciamento de projetos e áreas de conhecimento.

27 16 5 ÁREAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS As áreas de conhecimento do PMBOK definem processos específicos para diversos casos, definindo entradas, ferramentas, técnicas e saídas que são utilizadas. Todas as informações, detalhadas ao longo deste capitulo tem como referência o Guia PMBOK, elaborado pelo Project Management Institute, 4ª edição de Gerenciamento de Integração de Projeto O Gerenciamento de Integração de Projeto define o que é necessário para identificar, definir, combinar, unificar e coordenar os processos e atividades dos grupos de processos de gerenciamento segundo o Guia PMBOK. Neste capítulo serão apresentados os processos para a integração. Termo de abertura do projeto O termo de abertura é um documento que inicia formalmente o projeto, autorizando e definindo seus requisitos iniciais necessários para as partes interessadas, conforme o Guia PMBOK. Plano de gerenciamento do projeto O plano de gerenciamento do projeto, de acordo com o Guia PMBOK, é o documento que define as ações necessárias para definir, integrar e coordenar todos os planos auxiliares.

28 17 Orientar e gerenciar a execução do projeto O processo de como realizar as ações em si, definidas no plano de gerenciamento do projeto, para atingir os objetivos do trabalho segundo o Guia PMBOK. Monitorar e controlar o trabalho do projeto PMBOK. O processo de acompanhar, revisar e regular o progresso do projeto, conforme o Guia Realizar o controle integrado de mudanças O processo de revisão de todas as solicitações, aprovações e gerenciamento de mudanças de acordo com o guia PMBOK. Obtendo assim um histórico de todas as mudanças ocorridas. Encerrar o projeto ou fase O processo de finalização das atividades da fase ou projeto, encerrando assim formalmente esta etapa segundo o Guia PMBOK.

29 18 Fonte: PMBOK Guide (2008, p73) FIGURA 4 Gerenciamento de Integração de Projetos 5.2 Gerenciamento de Escopo de Projeto O gerenciamento de escopo do projeto, conforme o Guia PMBOK, determina todos os processos necessários para se realizar o trabalho com sucesso, sem tarefas desnecessárias graças a uma boa definição de requisitos. Coleta de requisitos

30 19 Segundo o Guia PMBOK, é coleta e definição de requisitos para que as partes interessadas alcancem o objetivo do projeto. Definição de escopo PMBOK. Definição de descrições detalhadas do projeto e do produto, de acordo com o Guia Criação da EAP Criação da Estrutura Analítica do Projeto, aonde as tarefas são divididas em blocos menores para melhor gerenciamento, conforme o Guia PMBOK. Verificar o escopo PMBOK. Formalização da aceitação das entregas terminadas no projeto, segundo o Guia Controlar o escopo Monitorar e controlar o escopo do projeto e do produto, gerenciando todas as mudanças como mencionado no guia PMBOK.

31 20 Fonte: PMBOK (2008, p104) FIGURA 5 Gerenciamento De Escopo de Projetos 5.3 Gerenciamento de Tempo de Projeto Essa área de conhecimento, conforme o Guia PMBOK, define os processos necessários para assegurar o término do projeto no prazo esperado.

32 21 Definir as atividades O Guia PMBOK define esse processo como a identificação das atividades específicas a serem realizadas para produzir as entregas do projeto. Sequenciar as atividades O processo de identificação e documentação dos relacionamentos entre as atividades, conforme o Guia PMBOK. Estimar os recursos da atividade O processo de estimativa de recursos necessários ao projeto, como materiais, equipamentos, pessoas, de acordo com o Guia PMBOK. Estimar as durações das atividades O guia PMBOK define esse processo como a estimativa de tempo necessário para terminar as atividades com os recursos estimados. Desenvolver o cronograma O processo de análise das seqüências das atividades, o tempo e recursos necessários em cada uma delas, são utilizados para a criação do cronograma do projeto conforme o Guia

33 22 PMBOK. Controlar o cronograma O cronograma deve ser acompanhado para que o bom andamento do projeto seja garantido, seguindo o mencionado no Guia PMBOK.

34 23 Fonte: PMBOK Guide (2008, p131) FIGURA 6 Visão Geral do Gerenciamento de Tempo do Projeto 5.4 Gerenciamento de Custo de Projeto O Guia PMBOK descreve o processo de gerenciamento de custo do projeto como as

35 24 estimativas, orçamentos e controle dos custos do projeto, de modo que se possa garantir que ele seja concluído dentro do orçamento aprovado. Os processos para se alcançar isso são: Estimar os custos Consiste na estimativa dos custos do projeto, permitindo assim sua conclusão conforme o Guia PMBOK. Determinar o orçamento O Guia PMBOK define esse processo como a agregação dos custos estimados de atividades ou pacotes de atividades para estabelecer uma linha de base dos custos. Controlar os custos O processo de monitoramento do progresso do projeto para assim acompanhar o orçamento e gerenciar as mudanças realizadas, conforme o Guia PMBOK.

36 25 Fonte: PMBOK Guide (2008, p167) FIGURA 7 Visão Geral do Gerenciamento de Custo do Projeto 5.5 Gerenciamento de Qualidade de Projeto O processo de gerenciamento de qualidade do projeto inclui os processos e as atividades necessárias para assegurar a qualidade do produto, políticas, objetivos, metas para que se atendam as necessidades definidas. É dividida em três processos: Planejar a qualidade O processo define os critérios para a qualidade do produto, conforme o Guia PMBOK. São identificados requisitos, padrões e métricas necessárias.

37 26 Realizar a garantia da qualidade O processo de auditar se os requisitos planejados estão sendo cumpridos, segundo o Guia PMBOK. Realizar o controle da qualidade O processo de monitorar e registrar os resultados das atividades de qualidade, avaliando seu desempenho e podendo assim aplicar melhorias, de acordo com o Guia PMBOK. Fonte: PMBOK Guide (2008, p191) FIGURA 8 Visão Geral do Gerenciamento de Qualidade do Projeto

38 Gerenciamento de Recursos Humanos de Projeto Esta área de conhecimento inclui os processos que organizam e gerenciam a equipe do projeto, garantindo assim o envolvimento de todos os membros com o projeto, de acordo com o guia PMBOK. Desenvolver o plano de recursos humanos Identificar e documentar funções, responsabilidade e criar um plano para gerenciar, conforme o Guia PMBOK. Mobilizar a equipe do projeto Obter a equipe e a tornar disponível para o projeto, de acordo com o Guia PMBOK. Desenvolver a equipe do projeto Melhorar as competências, como a equipe interage e seu ambiente, são os pontos desse processo como o Guia PMBOK menciona. Gerenciar a equipe do projeto Acompanhar o desempenho da equipe, resolver problemas, gerenciar pessoas, como

39 28 visto no Guia PMBOK. Fonte: PMBOK Guide (2008, p217) FIGURA 9 Visão Geral do Gerenciamento de Recursos Humanos do Projeto 5.7 Gerenciamento de Comunicação de Projeto Os processos desta área de conhecimento garantem a boa comunicação, garantindo que

40 29 as informações sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de maneira apropriada, como visto no Guia PMBOK. Essa área possui cinco processos: Identificar as partes interessadas Identificar as pessoas ou organizações que podem ser afetadas pelo projeto e documentar as informações relevantes, conforme o Guia PMBOK. Planejar as comunicações Determinar as necessidades do projeto de informação e definição da abordagem de comunicação, como mencionado no Guia PMBOK. Distribuir as informações Distribuir as informações às partes interessadas, de acordo com o planejamento, conforme o Guia PMBOK. Gerenciar as expectativas das partes interessadas Comunicar e interagir com as partes interessadas, atender as necessidades de forma apropriada, segundo o Guia PMBOK.

41 30 Reportar o desempenho Coletar e distribuir as informações referentes ao desempenho e seu progresso, conforme o Guia PMBOK. Fonte: PMBOK Guide (2008, p244) FIGURA 10 Visão Geral do Gerenciamento de Comunicações do Projeto

42 Gerenciamento de Risco de Projeto Os processos de gerenciamento de risco do projeto, conforme o Guia PMBOK, são aqueles que identificam, analisam e monitoram os riscos do projeto. Os 6 processos dessa área de conhecimento tem como objetivo aumentar os eventos positivos e reduzir a chance de eventos negativos ocorrerem. Planejar o gerenciamento dos riscos Como conduzir as atividades de risco no projeto, conforme o Guia PMBOK. Identificar os riscos Determinar os riscos e documentá-los, como visto no Guia PMBOK Realizar a análise qualitativa dos riscos Esse processo visa priorizar os riscos que podem ocorrer mais e ter maior impacto, de acordo com o guia PMBOK. Realizar a análise quantitativa dos riscos PMBOK. Esse processo analisa numericamente os efeitos dos riscos observados, segundo o Guia

43 32 Planejar as respostas aos riscos O processo de desenvolvimento de opções e ações para aumentar os efeitos positivos e reduzir os negativos, mencionado no Guia PMBOK. Monitorar e controlar os riscos PMBOK. Acompanhar e monitorar os riscos identificados e os possíveis, conforme o Guia

44 33 Fonte: PMBOK Guide (2008, p274) FIGURA 11 Visão Geral do Gerenciamento de Risco do Projeto

45 Gerenciamento de Aquisição de Projeto O Guia PMBOK define esses processos como os necessários para aquisições de produtos, serviços ou resultados externos à equipe do projeto. Gerenciar contratos e as mudanças envolvidas nesses processos. Planejar as aquisições Documentar as aquisições do projeto, especificando fornecedores possíveis e a abordagem da aquisição, segundo o Guia PMBOK. Realizar as aquisições o Seleção de fornecedor e validação de contrato, conforme o Guia PMBOK. Administrar as aquisições o Gerenciar a aquisição, monitorando desempenho e ajustando ou mudando o que for necessário para o bom andamento desse processo, como visto no Guia PMBOK. Encerrar as aquisições Finalizar todas as aquisições do projeto, segundo o Guia PMBOK.

46 35 Fonte: PMBOK Guide (2008, p314) FIGURA 12 Visão Geral do Gerenciamento de Aquisições do Projeto

47 36 6 SCRUM O Scrum é definido como um framework para desenvolver e manter produtos complexos, desenvolvido por Ken Schwaber e Jeff Sutherland, utilizado para gerenciar esses produtos complexos desde 1990, de acordo com o Guia Scrum. O Scrum é utilizado principalmente no desenvolvimento de softwares, mas a sua concepção é para resolver problemas complexos e adaptativos, porém de forma produtiva, como definido no Guia Scrum. Schwaber cita que o Scrum não irá criar resultados idênticos aos esperados, mas sim resultados com o maior valor possível. Fundamentado no empirismo, o Scrum se apóia em três princípios conforme o Guia Scrum: Transparência Aspectos significativos do processo devem ser claros para todos, para isso o entendimento de todos desses aspectos deve ser assegurado que é o mesmo. Inspeção Os artefatos devem ser inspecionados regularmente, para evitar variações de seu objetivo. Este trabalho é importante porém não deve comprometer as outras tarefas. Adaptação Os aspectos devem ser ajustados se estão fora do caminho para se alcançar os resultados esperados. Essas mudanças devem ocorrer sempre o mais breve possível. O framework do Scrum é simples se comparado ao PMBOK, porém sua aplicação não é. Figueiredo menciona que o Scrum precisa estar no lugar certo na hora certa, ser promovido no ambiente em que for utilizado, e ser bem planejado para poder ser aplicado. Este capítulo abordará o funcionamento e aplicação dessa estrutura de processos ágil, que está se tornando bastante popular. 6.1 Time Scrum e Papéis O Guia Scrum define que os times devem ser auto-gerenciáveis e multifuncionais. Os

48 37 times auto-organizáveis são capazes de determinar a melhor forma de realizar seu trabalho, e multifuncionais por possuírem todas as competências necessárias para realizar o seu trabalho. O foco do time Scrum é entregar produtos de forma iterativa e incremental, de forma que uma versão funcional dele esteja sempre disponível, segundo o Guia Scrum. Os papéis no time são Product Owner, Scrum Master e a equipe de desenvolvimento. Suas responsabilidade serão detalhadas nos sub capítulos a seguir Product Owner O Product Owner, que significa o dono produto, é o responsável por maximizar o valor do trabalho do produto e do rendimento da equipe de desenvolvimento, conforme o Guia Scrum. Responsável também pelo Product Backlog, que inclui de acordo com o Guia Scrum: Expressar claramente os itens do Backlog do Produto; Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões; Garantir o valor do trabalho realizado pelo Time de Desenvolvimento; Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; Garantir que a Equipe de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário. O Product Owner é uma pessoa, representando a uma organização, cliente, a parte interessada pelo produto. Seu envolvimento no projeto é de forma bastante ativa, explicado no Guia Scrum.

49 Equipe de desenvolvimento A equipe de desenvolvimento tem como objetivo entregar produtos ao final de cada ciclo, Sprint. Esses produtos sempre incrementam o produto final permitindo assim o Product Owner ter uma versão funcional dele para acompanhar o progresso, como definido no Guia Scrum. A equipe tem as seguintes características: Elas são auto-organizadas. Ninguém, nem mesmo o Scrum Master, diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis; Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto. O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra. Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; Equipes de Desenvolvimento não contém sub-equipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios. O Guia Scrum determina que as equipes devem ter um tamanho apropriado para realizar seu trabalho com sinergia, não devem ser muito pequenas nem muito grandes. A sugestão é para equipes com mais de três integrantes e até nove, sem contar o Product Owner e Scrum Master Scrum Master O papel do Scrum master, segundo o Guia Scrum, é de assegurar o entendimento e

50 39 funcionamento do Scrum em si, tanto para os membros dentro do time quanto para os de fora, que possuem interações com o projeto. O Scrum Master desempenha as seguintes funções O Scrum Master trabalhando para o Product Owner O Scrum Master serve o Product Owner de várias maneiras, incluindo: Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto; Claramente comunicar a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento; Ensinar a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa; Compreender a longo-prazo o planejamento do Produto no ambiente empírico; Compreender e praticar a agilidade; Facilitar os eventos Scrum conforme exigidos ou necessários O Scrum Master trabalhando para a Equipe de Desenvolvimento O Scrum Master serve a Equipe de Desenvolvimento de várias maneiras, incluindo: Treinar a Equipe de Desenvolvimento em auto-gerenciamento e interdisciplinaridade; Ensinar e liderar a Equipe de Desenvolvimento na criação de produtos de alto valor; Remover impedimentos para o progresso da Equipe de Desenvolvimento; Facilitar os eventos Scrum conforme exigidos ou necessários; e, Treinar a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

51 O Scrum Master trabalhando para a Organização O Scrum Master serve a organização de várias maneiras, incluindo: Liderando e treinando a organização na adoção do Scrum; Planejando implementações Scrum dentro da organização; Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico; Causando mudanças que aumentam a produtividade do Time Scrum; Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações. Todas as responsabilidades do Scrum Master são para garantir que o Scrum esteja realmente sendo compreendido e executado, sempre maximizando o valor do trabalho. 6.2 Eventos Scrum Os eventos no Scrum são utilizados para definir o ciclo do projeto, esses eventos são do tipo time-boxed com uma duração máxima sempre, para garantir que uma quantia de tempo adequada seja utilizada e minimiza perdas no planejamento (Schwaber e Sutherland, 2011). Os eventos são oportunidades para se aplicar as teorias do empirismo, eles podem ser inspecionados e adaptados a cada iteração, com transparência. Este capítulo abordará esses eventos e seu funcionamento.

52 Sprint O Guia Scrum define a Sprint como o evento mais importante do Scrum, um evento com tempo curto, até um mês geralmente, no qual uma versão funcional do produto é entregue. A conclusão de uma Sprint é seguida imediatamente por outra sempre. As Sprints são compostas de uma reunião de planejamento, reuniões diárias, trabalho de desenvolvimento, revisão da Sprint e a retrospectiva da Sprint (Idem, p. X), conforme o Guia Scrum. A Sprint pode ser considerada como um mini projeto dentro do projeto, com o objetivo de entregar um produto ao final dela. É determinado que durante uma Sprint: Não são feitas mudanças que podem afetar o objetivo da Sprint; A composição da Equipe de Desenvolvimento permanece constante; As metas de qualidade não diminuem; O escopo pode ser clarificado e renegociado entre o Product Owner e a Equipe de Desenvolvimento quanto mais for aprendido. As Sprints como são eventos com tempo determinado, permitem que a inspeção e adaptação ocorram quando necessário, limitando o risco dentro do período de tempo determinado Reunião de Planejamento da Sprint e Release Backlog O Guia Scrum determina que o Time Scrum deve elaborar durante a reunião de planejamento da Sprint todo o trabalho que deverá ser realizado durante a mesma. A reunião deve ser um evento com tempo proporcional a Sprint, sendo que a recomendação é de que se a Sprint for de um mês, a reunião deverá ter até oito horas. A reunião deve ser dividida em duas partes iguais, com o intuito de responder as seguintes questões:

53 42 O que será entregue como resultado do incremento da próxima Sprint? Nesta etapa a equipe trabalha para determinar quais funcionalidades estão disponíveis ao final da Sprint. O Product Owner apresenta os itens do Backlog do Produto e a equipe avalia o que pode ser completado durante essa Sprint, os itens que serão desenvolvidos do Backlog são formam o Release Backlog. FIGURA 13 - Exemplo de Release Backlog Fonte: Agile Tools O acompanhamento das atividades e seu tempo despendido são feitos através do Burndown Chart, o exemplo abaixo exibe a quantia de User Stories que restam a cada ciclo iterativo.

54 43 Fonte: Eclipse Process Framework FIGURA 14 - Exemplo de Release Burndown Chart Como o trabalho necessário para entregar o incremento será realizado? A segunda etapa contempla como irá realizar a entrega do incremento até o final da Sprint, o planejamento, ordem, dos itens do Release Backlog a serem desenvolvidos formam a Sprint Backlog Planning Poker As estimativas do Release Backlog podem ser realizadas através de uma técnica chamada Planning Poker, criada por James Grenning. O intuito do Planning Poker é aperfeiçoar o tempo ganho durante a estimativa do tempo do Release Backlog. Grenning (2002) explica que as estimativas de tempo das User Stories devem ser feitas por todo time, ao invés dos membros mais importantes como é realizada geralmente. Para evitar que os membros do time induzam suas estimativas de tempo nos outros, cada

55 44 participante deve escolher o tempo que estima em uma carta e não revelá-la prontamente. As cartas possuem número que seguem a escala de Fibonacci, incluindo o zero. Tipicamente a seqüência é 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. O motivo de se usar a escala de Fibonacci é para representar a incerteza na estimativa de tempo de grandes tarefas. Assim que todo os membros escolherem sua carta devem revelar ao mesmo tempo, com sua estimativa de tempo. Os participantes que tiverem as estimativas mais opostas, maior e menor, deverão discutir para explicar o porquê de sua escolha. Dessa forma as experiências são compartilhadas e chegarão a um consenso, sucessivamente até todos chegarem a mesma estimativa. O benefício do Planning Poker é interagir toda a equipe na estimativa do tempo do Release Backlog, compartilhar experiências é mais rápido e produtivo do que discutir um prazo apenas Reunião Diária A reunião diária é um evento rápido, de até quinze minutos, que ocorre diariamente para determinar as ações do dia da equipe, conforme o Guia Scrum. Durante essa reunião os seguintes pontos devem ser respondidos: O que foi completado desde a última reunião? O que será feito até a próxima reunião? Quais os obstáculos que estão no caminho? O intuito dessa reunião é melhorar a comunicação do time e assegurar que o trabalho está sendo realizado na forma e prazo esperados. Apenas a equipe participa da reunião diária, o Scrum Master deve assegurar apenas que a reunião ocorra sempre, como citado no Guia Scrum.

56 Revisão da Sprint O Guia Scrum determina que a Revisão da Sprint é uma reunião com período de até quatro horas para uma Sprint de um mês, sempre ajustando proporcionalmente com a Sprint. O objetivo dela é apresentar ao término dela o trabalho realizado neste ciclo, respondendo os seguintes pontos: O Product Owner identifica o que foi Pronto e o que não foi Pronto ; A Equipe de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como estes problemas foram resolvidos; A Equipe de Desenvolvimento demonstra o trabalho que está Pronto e responde as questões sobre o incremento; O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta as prováveis datas de conclusão baseado no progresso até a data; O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de Revisão da Sprint fornece valiosas entradas para a Reunião de Planejamento da próxima Sprint. Após a reunião o Product Backlog pode ser atualizado, permitindo assim a escolha para a próxima Sprint Retrospectiva da Sprint A Retrospectiva da Sprint, segundo o Guia Scrum, é utilizada para o time Scrum poder avaliar seu desempenho e aplicar melhorias. A sugestão é de uma reunião de até três horas, mantendo sempre a proporcionalidade com a Sprint. O propósito é: Inspecionar como a última Sprint foi em relação as pessoas, relações, processos e

57 46 ferramentas; Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e, Criar um plano para aplicar melhorias no modo que o Time Scrum faz seu trabalho; O Scrum Master deve encorajar a equipe a melhorar sempre, essas melhorias propostas durante a retrospectiva serão aplicadas na próxima Sprint e avaliadas Artefatos do Scrum O Guia Scrum define os Artefatos do Scrum como meios de se representar o trabalho ou valor, de maneiras úteis e aplicando os conceitos de transparência, inspeção e adaptação. Esses artefatos são o Backlog do Produto e o Backlog da Sprint User Stories User Stories são requisitos do cliente resumidos a poucas palavras, focando nas necessidades apenas e não em sua aplicação. O Product Owner define as User Stories com seus clientes em alto nível, sendo que elas podem ser quebradas em diversas outras User Stories, conforme Steffan Surdek. As User Stories são partes do Product Backlog, elas guiam otrabalho do time Backlog do Produto O Backlog do produto é definido pelo Guia Scrum, 2011, como:

58 47 O Backlog do Produto é uma lista ordenada de tudo que deve ser necessário no produto, e é uma origem única dos requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, disponibilidade e ordenação. O Backlog do produto é criado para ser flexível, ele se adapta constantemente com o projeto, sempre pensando nas necessidades do mesmo. O Backlog do Produto deve listar as User Stories, que são as características, funções, requisitos, melhorias e correções que devem ser feitas nos produtos para as próximas versões. Ele deve ser ordenado com os itens com maior prioridade no topo, essa prioridade é avaliada de acordo com o valor, risco, prioridade e necessidade conforme o Guia Scrum. O Product Backlog é um artefato vivo, que muda constantemente para refletir todas as mudanças e necessidades que surgem. A tarefa de mantê-lo sempre ativo é de vital importância para o sucesso do projeto. O Product Owner e a equipe têm a responsabilidade de gerenciá-lo, sendo que a equipe realiza todas as estimativas.

59 48 Figura 15 - Exemplo de Product Backlog Fonte: Agile Tools Backlog da Sprint O Backlog da Sprint é definido pelo Guia Scrum, 2011, como: O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano de entrega do incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e do

60 49 trabalho necessário para entregar a funcionalidade. O Backlog da Sprint, segundo o Guia Scrum, é o planejamento do trabalho que será realizado na Sprint, assim como o Backlog do Produto ele é um artefato vivo, que sofre mudanças ao longo do ciclo. As reuniões diárias podem acrescentar ou alterar informações dele conforme a necessidade. A Equipe de Desenvolvimento deve controlar esse artefato e ele deve ser muito visível para todos. Figura 16 - Exemplo de Sprint Backlog Fonte: Eclipse Process Framework O trabalho estimado restante na Sprint é calculado diariamente e esses dados são organizados em gráfico para fácil visualização. Esse gráfico é chamado Sprint Burndown. O exemplo abaixo exibe quantas horas de trabalho restam ao longo que os dias passam.

61 50 Fonte: Eclipse Process Framework FIGURA 17 - Sprint Burndown Definição de Pronto A Sprint tem como objetivo ao término dela entregar um item do Backlog do Produto pronto, conforme o Guia Scrum. Essa definição de pronto pode ter várias interpretações de acordo com cada membro da equipe, por isso é necessário que essa definição seja de forma transparente definida e aceita por todos, a figura 18 mostra as etapas para a entrega de um incremento de produto. A definição é importante para que cada item entregue esteja pronto para todos, ajudando assim no planejamento a equipe a seleciona os itens a serem trabalhados na Sprint de forma coerente com os recursos disponíveis. A maturidade do time ajuda a melhorar os critérios de pronto, melhorando assim a qualidade do produto, como visto no Guia Scrum.

62 51 FIGURA 18 - Ciclo Sprint Fonte: Mountain Goat Software

63 52 7 ANÁLISE COMPARATIVA DO PMBOK E SCRUM Este capítulo abordou as diferenças encontradas entre as duas metodologias de gerenciamento de projetos. O Guia PMBOK é uma metodologia extensa, que cobre diversos tópicos com suas áreas de conhecimento, prevendo diversas situações. O Scrum é uma metodologia com foco em realizar o trabalho em si, com foco na execução das atividades. A análise identificou as diferenças e comparou as técnicas que são melhores para projetos de software. 7.1 Definição dos requisitos do projeto Tanto o Guia PMBOK como o Guia do Scrum determinam uma figura que define os requisitos do projeto, qual o objetivo que ele deseja alcançar. No PMBOK essa definição é feita pelo financiador do projeto, o Patrocinador; no Scrum o Product Owner realiza esse papel. O Guia PMBOK define os requisitos e escopo do projeto em sua fase inicial, através do termo de abertura. O termo ocorre a cada fase do projeto, no qual o patrocinador deve defender os benefícios que esse projeto trará e cabe ao gerente de projeto compreender todas essas necessidades. O Guia Scrum define possui uma comunicação melhor com o Product Owner do que o PMBOK com o patrocinador. O Product Owner deve participar ativamente durante o projeto, durante o planejamento da Sprint e em sua revisão. No PMBOK o patrocinador participa durante a abertura de uma fase apenas, fases essas que podem levar longos períodos de tempo. Essa forte interação com a parte interessada que define os requisitos, permite ao Scrum ser capaz de se adaptar rapidamente, assegurando que o produto final está se tornando o que o Product Owner espera.

64 Responsabilidades no projeto As duas metodologias comparadas possuem papéis e responsabilidades para o projeto. Essas definições têm o intuito de definir quais tarefas cada um deve desempenhar para alcançarem o sucesso do projeto sempre. O Guia PMBOK define a figura do Gerente de Projetos, que tem a responsabilidade de alcançar o objetivo do projeto. Essa pessoa deve possuir amplos conhecimentos, tanto do produto que está sendo concebido como de o projeto como um todo, sendo a ponte de comunicação com todas as partes interessadas. O progresso e acompanhamento do trabalho são feito pelo Gerente d Projetos, que deve exigir os resultados. O Guia Scrum não possui um papel com as mesmas responsabilidades que um Gerente de Projeto no PMBOK, o que mais se aproximaria dele seria o Scrum Master conforme menciona o Guia Scrum. O Scrum Master não possui toda a responsabilidade do projeto sobre si, mas sim a responsabilidade de o Scrum ser compreendido e utilizado no projeto. O Scrum divide a responsabilidade de gerenciar o projeto com todos, dividindo tarefas e conscientizando as responsabilidades. A equipe de desenvolvimento no Scrum deve ser autogerenciável e multifuncional para alcançar esse propósito. Um time auto-gerenciável exige pessoas experientes, capazes de assumir responsabilidades e se gerenciarem, dessa o andamento do trabalho é exigido pela equipe. Se o time não possuir essa maturidade, o Scrum não possui uma figura para guiá-los. 7.3 Ciclos no projeto O Guia PMBOK define que o projeto possui fases, nos quais o tempo delas deve ser planejado de acordo com as necessidades do projeto. As fases podem ser seqüenciais, sobrepostas ou iterativas. O Guia Scrum determina que o uso das Sprints, que são semelhantes as fases mas ocorrem em curtos períodos de tempo, no máximo de um mês e de forma iterativa. A Sprint tem como objetivo entregar rapidamente uma parte funcional do produto, permitindo assim que alterações sejam feitas mais rapidamente e que o Product Owner possa acompanhar o

65 54 progresso de forma mais interativa que no PMBOK. 7.4 Definição do custo do projeto O Guia PMBOK possui uma área de conhecimento específica para gerenciar os custos do projeto. Os processos dessa área detalham as informações em três processos, estimativa, determinação e controle dos custos. São apresentadas técnicas e ferramentas para controlar e monitorar as entradas e saídas do projeto de forma detalhada. O Guia Scrum não define de forma específica como a gerência dos custos deve ocorrer. A Sprint pode conter essas informações, mas o controle pela própria equipe das entradas e saídas é feita de forma informal e pouco planejada se comparada ao PMBOK. 7.5 Definição do tempo do projeto O Guia PMBOK determina o gerenciamento de tempo com uma área de conhecimento específica, com processos que definem as atividades e criam um cronograma para ser seguido e controlado. O Guia Scrum determina o tempo das atividades na Sprint, a equipe seleciona os itens no Product Backlog que podem ser realizados durante o tempo dela, isso exige experiência dos membros, pois eles que determinam como irão desenvolver o trabalho e quanto tempo necessitarão. A equipe consegue determina o tempo das atividades através de suas experiências e base de conhecimento, que evolui com o decorrer do projeto. A entrega do produto ao final de cada ciclo da Sprint de forma funcional promove bastante a velocidade do projeto e seu controle é feito através da Sprint Backlog e das atualizações do Product Backlog. 7.6 Definição de riscos do projeto

66 55 O Guia PMBOK define em uma área de conhecimentos específica o gerenciamento dos riscos no projeto. Os riscos são mapeados através da identificação deles, seus impactos no projeto são avaliados para determinar a prioridade de cada um, as respostas para cada risco são determinadas e os riscos são monitorados. Novos riscos que forem identificados ao longo do projeto são tratados da mesma forma. O Guia Scrum determina que os riscos devem ser avaliados na Sprint, o curto ciclo da Sprint limita o risco ao tempo dela apenas, as reuniões diárias da equipe podem se adaptar para tratar os riscos que surgem. O Product Backlog pode conter também o risco, para que sua prioridade seja maior que outros itens. A identificação dos riscos, acompanhamento e respostas dependem da experiência da equipe. 7.7 Qualidade no projeto O Guia PMBOK define os processos de qualidade do projeto através de uma área de conhecimento específica novamente. Esses processos planejam os requisitos de qualidade, os realizam e monitoram o desempenho das ações. O Guia Scrum determina que cada Sprint procurar melhoria sempre, a Sprint Review que acontece ao término de cada Sprint serve para analisar o que pode ser melhorado para a próxima Sprint, permitindo assim aplicar requisitos de qualidade, porém esses requisitos não são definidos formalmente cabe a equipe aplicar a sua experiência. 7.8 Recursos Humanos O Guia PMBOK determina processos de Recursos Humanos dentro de uma área de conhecimento específica, com o objetivo de formar uma equipe para a realização do projeto. Os processos determinam as funções, responsabilidades, habilidades e as relações hierárquicas dessa equipe. Com isso a equipe é alocada e seu desempenho acompanhado.

67 56 O time no Scrum deve ser auto gerenciável, capaz de controlar seu próprio trabalho e com habilidades necessárias para realizar suas atividades. Todos os integrantes da equipe possuem o mesmo título, desenvolvedor, independente de qual atividade está realizado no projeto. As atividades podem ser flexíveis se necessário. 7.9 Comunicações Os processos de comunicação do PMBOK, contemplados em uma área de conhecimento, definem todas as partes interessadas que devem ser informadas das informações relevantes do projeto. O gerente de projetos é o responsável por essa comunicação, ele é o ponto de foco de todas as partes interessadas, a maior parte de seu tempo é dedicada a comunicações, conforme o Guia PMBOK. A comunicação no Scrum é realizada ativamente através do compartilhamento de conhecimento, reuniões diárias, maior envolvimento do Product Owner, envolvimento de toda a equipe, geram comunicação efetiva de acordo com o Guia Scrum Aquisições O Guia PMBOK possui processos claros para aquisições que ocorram durante o projeto, contidos dentro de uma área de conhecimento. As aquisições podem ser referentes a produtos, serviços ou resultados externos a equipe do projeto. Os processos desse grupo planejam, realizam e administram as aquisições envolvidas. O Guia Scrum não determina processos específicos para aquisições durante o projeto, cabe a equipe utilizar a experiência e se adaptar.

68 57 8 Aplicação de práticas do PMBOK em projetos com SCRUM A análise comparativa do PMBOK e SCRUM pôde constatar que existem pontos positivos e negativos nos dois métodos para gerenciar projetos. As práticas do PMBOK podem ser aplicadas em projetos de diferentes escopos. As áreas de conhecimento possuem processos relacionados com desde o início do projeto até seu término. As práticas devem ser compreendidas e aplicadas aonde necessário, nem todas cabem a todos os tipos de projeto. A grande estruturação de processos no PMBOK é sua vantagem e desvantagem, essa definição de muitos processos agrega bastante controle e registro dos seus processos, define parâmetros e metas de forma consistente. Porém a realização do trabalho tende a ser mais vagarosa e pouco flexível. A hierarquia dentro do PMBOK determina que o gerente de projetos seja a figura principal no projeto, cabe a esse profissional garantir resultados, comunicação efetiva e comprometimento dos membros, grandes responsabilidades para uma única pessoa. O Scrum aplica técnicas com foco em realizar o trabalho em si de forma eficiente e produtiva, as técnicas foram criadas para o desenvolvimento de software, mas podem ser aplicadas em outras áreas se adaptadas. O ciclo iterativo que ocorre através de Sprints promove velocidade, compartilhamento de conhecimento e responsabilidades com todos da equipe e flexibilidade para adaptações. A equipe é responsável por seu trabalho como um todo, para isso ocorrer é necessário maturidade profissional dos integrantes. O Scrum Master assegura que o Scrum aconteça, mas não interfere nas atividades desempenhadas do time diretamente. O Scrum não é detalhado o suficiente em alguns processos e não menciona algumas situações possíveis de ocorrer durante um projeto. É possível com isso afirmar que o PMBOK pode trazer práticas benéficas para o Scrum em projetos de software, sem comprometer sua natureza ágil, como veremos a seguir. A definição dos requisitos do projeto, qual o seu objetivo, é realizada pelo Scrum através de participação ativa do Product Owner. Essa técnica é positiva, pois o Product Owner assim pode entender melhor o que acontece durante o projeto e tem maior flexibilidade para alterações, e a equipe isso assegura que os requisitos do cliente estão sendo atendidos. As responsabilidades no projeto diferem quando se compara o Gerente de Projetos com o Scrum Master. O Gerente de Projetos trabalha de forma hierárquica, exerce comando

69 58 sobre a equipe do projeto. O Scrum Master é responsável pelo Scrum, mas não tem comando sobre a equipe, pois ela é auto gerenciável. O conceito de times auto gerenciáveis exige uma equipe experiente, algo que não é possível de ocorrer sempre. Propõe-se neste caso que o Product Owner da equipe possua o comando que um Gerente de Projetos teria, esse papel é necessário para orientar melhor a equipe em suas atividades e exercer também atividades como controles de custos, riscos e tempo de forma mais ativa. Os custos do projeto podem ser gerenciados através das técnicas do PMBOK, que são detalhadas e controlam todos os custos envolvidos, algo que o Scrum não contempla em suas práticas. Desta forma os custos são planejados, determinados e controlados no projeto. O uso de tempo no projeto quando gerenciado através das técnicas do PMBOK tende a ser menos flexível, as atividades e seus tempos são determinados no cronograma inicial para então ser seguido e adaptado conforme mudanças. A solução do Scrum de definição de tempo ao início da Sprint, na escolhe dos itens do Product Backlog a ser trabalhado, é mais dinâmica e flexível, característica importante para projetos de software. Técnicas auxiliares como o Planning Poker ajudam a estimar de forma mais rápida o tempo das atividades para assim direcionar o foco na realização do trabalho em si. O controle dos riscos no projeto através das técnicas do PMBOK é mais efetivo, o Scrum não determina de forma efetiva um controle de riscos, os riscos podem ser avaliados ao começo de cada Sprint e em sua retrospectiva, mas uma tratativa específica não é determinada. O PMBOK define processos para determinar como será gerenciado o controle de riscos, como os riscos serão identificados, qual a prioridade de cada um, seu impacto em números relevantes ao negócio, quais respostas para cada caso e seu monitoramento e controle. A qualidade no projeto gerenciado pelo PMBOK tem os requisitos do cliente planejados e controlados através de processos estruturados para isso. Isso permite melhor definição dos requisitos, identificação de melhorias e prevenção. O Scrum define o controle de qualidade antes da Sprint, e durante o fechamento da Sprint, na retrospectiva, o time pode planejar métodos para melhorar a qualidade para a próxima Sprint. A técnica do PMBOK define melhor os requisitos de qualidade a serem criados, utilizado em conjunto com a retrospectiva da Sprint, os requisitos podem ser acompanhados facilmente. Os recursos humanos são gerenciados de acordo com o Guia PMBOK através de seu planejamento, mobilização da equipe, desenvolvimento da equipe e acompanhamento dela. Os membros da equipe têm cargos e funções definidas, de acordo com suas técnicas necessárias ao desenvolvimento do projeto. O Scrum não possui cargos, por acreditar que isso

70 59 pode limitar o trabalho dos membros. Todos possuem habilidades necessárias como um time para realizar o trabalho. As equipes Scrum são times pequenos, uma estruturação complexa como a do PMBOK não é necessária e poderia até diminuir a flexibilidade, mas técnicas como avaliação de desempenho do PMBOK podem ser integradas de forma eficaz. Para o Scrum um bom parâmetro de desempenho é o quanto o membro colabora com a equipe, característica chave para o Scrum funcionar. As comunicações no Scrum são feitas de forma bastante efetiva, reuniões diárias com a equipe, grande envolvimento do cliente ou Product Owner, fazem com que o conhecimento seja compartilhado melhor que com as técnicas do PMBOK, pois toda a comunicação é centralizada no gerente de projetos. O Scrum não possui processos para gerenciar as aquisições no projeto, sejam elas produtos ou serviços necessários para o mesmo. Toda a área de conhecimento do PMBOK sobre aquisições pode ser empregada para lidar com as aquisições. Com a análise das práticas do PMBOK que podem ser utilizadas junto do Scrum, pode se propor um novo fluxo de processo para o Scrum.

71 FIGURA 19 Proposta de novos papéis no Scrum 60

72 FIGURA 20 Proposta de novo fluxo de Scrum 61