UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA

Transcrição

1 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA ADERÊNCIA DO SCRUM AO PMBOK Por: Wellington Souza Amaral Orientador Prof. Nelsom Magalhães Rio de Janeiro 2012

2 2 UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA ADERÊNCIA DO SCRUM AO PMBOK Apresentação de monografia à AVM Faculdade Integrada como requisito parcial para obtenção do grau de especialista em Gerencia de projetos. Por: Wellington Souza Amaral.

3 3 AGRADECIMENTOS Ao Tribunal de Justiça do Estado do Rio de Janeiro, por promover a formação e excelência de seus funcionários, a Michele Oliveira, pelo empenho em garantir a realização desse curso, ao Renato Warwar, que me permitiu usar vários conhecimentos sintetizados nesse trabalho nos projetos da DIPOR.

4 4 DEDICATÓRIA A minha esposa Luciana, minha companheira em todos os momentos, a minha filha Júlia, que fez silêncio para eu poder estudar, aos meus pais Elton e Ivete, cujo maior legado foi o estudo e a educação, e aos meus irmãos Adriano e Elizabel, pela paciência e compreensão nos momentos em que estou recluso aos estudos. Eu dedico a vocês os meus melhores dias.

5 5 RESUMO O presente trabalho versa sobre a aderência do Scrum, que é uma metodologia de gerência de projetos cujo uso tem crescido rapidamente em meio a projetos de desenvolvimento de software, ao Guia Project Management Body of Knowledge (PMBOK), que é referência no mundo em gerência de projeto. As duas primeiras partes desse trabalho apresentam de forma sintética os principais elementos e características do PMBOK e do Scrum. Na terceira parte é realizado um aprofundamento dos processos formais e os não formais existentes no Scrum. Onde os processos do Scrum, mesmo os empíricos, são identificados e classificados de acordo com as áreas de conhecimento do PMBOK. A conclusão pontua os aspectos de maior significância desse trabalho, esclarecendo as características mais acentuadas do Scrum, suas vantagens e desvantagens, e suas possibilidades de aplicação em projetos.

6 6 METODOLOGIA A metodologia utilizada na elaboração deste trabalho foi a pesquisa bibliográfica em livros, artigos de revistas e da internet, jornais, guias, as principais fontes de consultas foram o próprio PMBOK 4ª edição 2008 e o livro Scrum e XP direto das Trincheiras, que traz um case real bem completo e complexo da aplicação do Scrum combinado com o extreme Programming para o desenvolvimento de software.

7 7 SUMÁRIO AGRADECIMENTOS... 3 DEDICATÓRIA... 4 RESUMO... 5 METODOLOGIA... 6 INTRODUÇÃO... 9 Capítulo I - PBMOK Capítulo II - SCRUM Capítulo III - ADERÊNCIA CONCLUSÃO CONCLUSÃO Glossário BIBLIOGRAFIA CITADA BIBLIOGRAFIA CONSULTADA WEBGRAFIA... 47

8 8

9 9 INTRODUÇÃO Scrum é um método ágil de gerenciamento de projetos de software, concebido por Jeff Sutherland no início dos anos 90. Nos últimos anos tem sido amplamente utilizado para o gerenciamento de projetos de software. E, devido a seu sucesso nessa área, tem sido adotado em outros ramos da indústria. A capa do caderno Boa Chance do jornal O globo de 15 de fevereiro de 2009 trazia a seguinte manchete "Fim ao Planejamento sem Fim", cujo primeiro parágrafo trazia o seguinte texto: "Um método de trabalho, inicialmente utilizado no desenvolvimento de softwares, está virando febre entre empresas brasileiras. Trata-se do Scrum, conceito que chegou ao Brasil há três anos e agora começa a chamar a atenção, inclusive de áreas além da computação." (MARCH, 2009) (O Globo, 2009, Capa do caderno boa chance)

10 10 Em pesquisa da PMSURVEY.ORG em 730 organizações de 18 setores diferentes no Brasil, na Argentina, na França e no Uruguai, quando essas organizações foram perguntadas se usavam algum método ágil para gerenciamento de projetos, 23% das organizações responderam que usam o Scrum como metodologia para gerenciamento de projetos. O gráfico 1 representa a distribuição das respostas a essa pergunta. gráfico 1 - Pesquisa da PMSURVEY.ORG sobre o uso de metodologias ágeis para gerenciamento de projetos. ( Mas a dúvida que surge é se o Scrum é uma metodologia de gerenciamento de projetos completa em si mesmo e se ele é aplicável em qualquer tipo de projeto. Vamos então colocar uma lente de aumento sobre os processos do Scrum e verificar a sua compatibilidade com o conjunto de boas práticas para gerenciamento de projetos que é referência no mundo todo, o Project Management Body of Knowledge, que para muitos é o estado da arte no gerenciamento de projetos.

11 11 Capítulo I - PBMOK O Project Management Body of Knowledge (Corpo de conhecimento de Gerência de Projetos) ou simplesmente PMBOK é mantido pelo PMI (Project Management Institute). O PMI, que foi fundado em 1969, é uma organização sem fins lucrativos que visa normatizar e desenvolver a gerência de projetos em todo mundo. Sua sede está na Pensilvânia-EUA e possui mais de membros distribuídos em 160 países. O PMBOK reúne as práticas bem sucedidas dessas organizações na gerência de projetos. Formando nessa publicação o corpo do conhecimento do gerenciamento de projetos. Um projeto, segundo o PMBOK, é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Essa definição é importante para distanciar o projeto de um trabalho operacional, que produz produtos ou serviços idênticos de forma contínua. Como uma fábrica de vassouras que produz o mesmo tipo de vassoura dia após dia. Ainda segundo o PMBOK, o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. Para que um projeto seja bem-sucedido, a equipe do projeto deve: Selecionar os processos apropriados necessários para cumprir os objetivos do projeto; Usar uma abordagem definida que possa ser adotada para atender aos requisitos; Cumprir os requisitos para atender às necessidades e expectativas das partes interessadas e obter um equilíbrio entre as demandas concorrentes de escopo, tempo, custo, qualidade, recursos e riscos, para gerar o produto, o serviço ou o resultado especificado. (PMBOK, 2008, PAG. 38)

12 12 Em sua 4ª edição de 2008 ele identifica 42 processos distribuídos por cinco grupos de processos do ciclo de vida do projeto. Os cinco grupos de processos são: Processos de iniciação: São processos que são realizados para definir um novo projeto e obter a autorização para o iniciar um projeto. Processos de planejamento: Quase metade dos processos estão nesse grupo. Pois são nesses processos em que o escopo do projeto é identificado e as ações necessárias para alcançar esse escopo são planejadas, levando em consideração de tempo de duração, custo, os risco envolvidos, qualidade esperada, os recursos humanos necessários, aquisições que precisarão ser feitas e a comunicação entre as partes envolvidas no projeto. Também são nesses processos que serão definidas como essas atividades serão monitoradas e controladas. Processos de execução: aquilo que foi planejado será executado nos processos desse grupo. Processos de monitoramento e controle: Nesses processos as ações executadas são revisadas e acompanhadas para que alcancem os seus objetivos conforme o planejamento. Caso algum processo se desvie do planejado, medidas devem ser tomadas para que esse desvio não comprometa os objetivos do projeto. Processos de encerramento: Processos que finalizam formalmente o projeto.

13 13 A figura 1 ilustra como os grupos de processos interagem entre si para formar o ciclo de vida do projeto. figura 1 - Grupo de processo de gerenciamento de projetos. (PBMOK, 2008, PAG.40) Os grupos de processos não são fases. Em muitos momentos os grupos de processo se sobrepõem durante o ciclo de vida do projeto. A figura 2 ilustra os momentos de atividade de cada grupo. figura 2 - Os grupos de processos interagem em uma fase ou em um projeto. (PMBOK, 2008, PAG.41)

14 14 Os mesmos 42 processos são classificado ainda pelo PMBOK em 9 áreas de conhecimento a saber: Gerenciamento do escopo do projeto - processos que levantam o escopo do projeto. Tudo aquilo que o projeto deve realizar tem que estar no escopo. Gerenciamento do Tempo do projeto - processos que trabalham com o tempo necessário para execução do projeto e definem a data de término do projeto. Gerenciamento de Custo do projeto - processos que estimam qual será o custo do projeto. Gerenciamento da Comunicação do projeto - processos que organizam as comunicações entre as partes interessadas no projeto. Gerenciamento de Risco do projeto - identifica os riscos negativos e positivos do projeto planejando uma respostas a eles. Gerenciamento da Qualidade do projeto - planeja, garante e controla a qualidade dos produtos, serviços ou resultados do projetos. Gerenciamento de Recursos Humanos do projeto - inclui os processos que gerenciam a equipe do projeto. Gerenciamento de Aquisição do projeto - inclui os processos que realizam as compras de produtos ou as contratações de serviços necessários para alcançar os objetivos do projeto. Gerenciamento da Integração do projeto inclui os processos que integram todas as áreas de conhecimento.

15 15 Tabela 1 - Mapeamento de grupos de processos de gerenciamento de projetos e áreas de conhecimento Áreas de Conhecimento Iniciação Planejamento Execução Monitorament o e controle Encerramento Integração Escopo Tempo Custos Qualidade Recursos Humanos Comunicação Riscos 1. Desenvolver o termo de abertura do projeto 1. Identificar as partes interessadas 2. Desenvolver o plano de gerenciamento do projeto 1. Coletar os requisitos 2. Definir o escopo 3. Criar a EAP 1. Definir as atividades 2. Sequenciar as atividades 3. Estimar os recursos das atividades 4. Estimar as durações das atividades 5. Desenvolver o cronograma 1. Estimar os custos 2. Determinar o orçamento 1. Planejar a qualidade 1. Desenvolver o plano de recursos humanos 2. Planejar as comunicações 1. Planejar o gerenciamento dos riscos 2. Identificar os riscos 3. Realizar a análise qualitativa dos riscos 4. Realizar a análise quantitativa dos riscos 5. Planejar as respostas aos riscos 3. Orientar e gerenciar a execução do projeto 2. Realizar a garantia de qualidade 2. Mobilizar a equipe do projeto 3. Desenvolver a equipe de projeto 4. Gerenciar a equipe do projeto 3. Distribuir as informações 4. Gerenciar as expectativas das partes interessadas 4. Monitorar e controlar o trabalho do projeto 5. Realizar o controle integrado de mudanças 4. Verificar o escopo 5. Controlar o escopo 6. Controlar o cronograma 3. Controlar os custos 3. Realizar o controle da qualidade 5. Reportar o desempenho 6. Monitorar e controlar os riscos 6. Encerrar o projeto ou fase Aquisição 2. Conduzir 1. Planejar as aquisições as aquisições (PMBOK,2008, PAG.43) 3. Administrar as aquisições 4. Encerrar as aquisições

16 16 Cada processo tem os seguintes elementos: Entradas: são as saídas de outros processos ou demandas externas ao projeto. exemplo: O processo definir o escopo tem como entrada o termo de abertura do projeto, documentação de requisitos e os ativos de processos organizacionais. Saídas: é o produto criado ou transformado na atividade do processo. exemplo: o processo desenvolver cronograma tem como saída o cronograma do projeto. Ferramentas e técnicas: São instrumentos que possibilitam e auxiliam a atividade do processo. exemplo: o processo Identificar os riscos tem como ferramentas e técnicas as revisões de documentação, as técnicas de coleta de informações (brainstorming, técnica delphi, entrevistas, Análise da causa-raiz), opinião especializada entre outras. Os processos de gerenciamento de projetos são aplicados globalmente e nos mais variados setores e indústrias. Boa prática significa que existe um acordo geral de que a aplicação dos processos de gerenciamento de projetos pode aumentar as chances de sucesso em uma ampla série de projetos. (...) Os gerentes de projetos e suas equipes devem abordar com cuidado cada processo e as entradas e saídas que o constituem. Este capítulo deve ser usado como um guia para os processos que devem ser considerados ao gerenciar o projeto. Este esforço é conhecido como adequação. (PMBOK, 2008, PAG. 39)

17 17 A prescrição dos processos do PMBOK não significa que a sua adoção seja mandatória para todo projeto e em todo tipo de organização. De acordo com as necessidades do projeto, das características da organização e das competências da equipe do projeto, os processos do PMBOK devem ter sua aplicação e relevância avaliadas.

18 18 Capítulo II - SCRUM O nome vem de uma jogada no rúgbi. Após uma jogada irregular ou em alguma penalização, os oito avançados das duas equipes fazem uma formação uns contra os outros. A figura 3 ilustra a jogada. figura 3 - foto da jogada de Scrum do rúgbi ( O nome e o trabalho em equipe são as únicas coisas em comum entre o Scrum do gerenciamento de projetos e o Scrum do Rúgbi. Dentro do desenvolvimento de software ele se enquadra na categoria dos processos de desenvolvimento ágil. Os processos ágeis surgiram em contraponto aos métodos tradicionais que são caracterizados por uma pesada documentação, vários processos de definição e levantamento de requisitos antes que as codificações sejam iniciadas. Os processos ágeis ao contrário dos processos tradicionais são caracterizados por adaptabilidade e se concentrar naquilo que traz valor para o cliente.

19 19 O manifesto ágil: "Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda." ( A sabedoria convencional em desenvolvimento de software afirma que os custos de mudanças aumentam de forma não linear conforme o projeto avança. É relativamente fácil assimilar uma mudança quando uma equipe de software está juntando requisitos. Pode-se ter de alterar um detalhamento do uso, ampliar uma lista de funções ou editar uma especificação por escrito. Os custos de tal trabalho são mínimos e o tempo demandado não afetará negativamente o resultado do projeto. Mas se adiantarmos alguns meses, o que aconteceria? a equipe está em meio aos testes de validação (o que ocorre relativamente no final do projeto) e um importante interessado está requisitando uma mudança funcional de vulto. A mudança requer uma alteração no projeto da arquitetura do software, o projeto e desenvolvimento de três novos componentes, modificações em outros cinco componentes, projeto de novos testes, e assim por diante. Os custos crescem rapidamente e não serão triviais o tempo e custos necessário para assegurar que a mudança seja feita sem efeitos colaterais. (PRESSMAN, 2011, PAG.83) É nesse contexto descrito por Pressman que os processos ágeis encontraram terreno fértil para crescerem. A principal características dos processos ágeis é a adaptabilidade, resiliência e robustez que eles têm a

20 20 mudanças. O que nos processos tradicionais poderiam levar atrasos no cronograma, estouros de orçamento e até mesmo ao fracasso do projeto, nos ágeis, as várias mudanças no escopo são acomodadas com razoável facilidade. Os processos ágeis foram criados justamente para terem essa característica de trabalhar em ambientes e escopos instáveis. Entre as principais características do Scrum podemos citar: é um processo ágil para gerenciar e controlar o desenvolvimento de projetos; é um wrapper para outras práticas de engenharia de software; é um processo que controla o caos resultante de necessidades e interesses conflitantes; é uma forma de aumentar a comunicação e maximizar a cooperação; é uma forma de detectar e remover qualquer impedimento que atrapalhe o desenvolvimento de um produto; é escalável desde projetos pequenos até grandes projetos em toda empresa. ( PAG. 8) Os principais elementos do Scrum são: work item - é cada entregável do projeto que é construído durante sua execução; tarefa - são as atividades necessárias para realizar um Work Item; product backlog. é a lista de works itens e o escopo do projeto;

21 21 product owner - é o proprietário do produto, é o cliente e patrocinador do projeto, e é quem deve definir e priorizar o product backlog; team - é a equipe do projeto que tem entre 4 e 9 pessoas. Scrum master - é o líder do projeto, quem gerencia a equipe do projeto e normalmente conduz as reuniões de trabalho; partes interessadas - são as pessoas ou instituições que possuam interesse no projeto; sprint - dentro do ciclo de vida do projeto, são realizados vários sprints que duram de 2 a 6 semanas. Ao final de cada sprint um grupo de work itens do backlog é entregue; sprint backlog. é um subconjunto da lista de work itens do product backlog que será executada no sprint seguinte. Geralmente é composta pelos work itens mais importantes da product backlog e ainda não finalizados; daily Scrum - é uma reunião com equipe do projeto que ocorre durante o sprint, com freqüência diária e dura entre 15 a 30 minutos; reunião de planejamento do sprint (sprint planning meeting) - é uma reunião que ocorre antes de cada sprint para planejar o sprint e definir o sprint backlog; revisão do sprint (sprint review) - é uma reunião de revisão do Sprint. Ocorre ao final do Sprint onde tudo aquilo que foi desenvolvido durante aquele sprint é apresentado para as partes interessadas. retrospectiva do sprint (sprint retrospective) - é uma reunião da equipe do projeto que ocorre após o sprint review. O objetivo é

22 22 encontrar o que deu errado ou certo dentro do sprint e checar o que pode ser corrigido ou melhorado para os próximos sprints. A figura 4 ilustra o ciclo de vida do projeto no Scrum. scrum master reunião diária product owner equipe do projeto. SPRINT 2 a 6 semanas. revisão Prioridade Reunião de planejamento do sprint sprint backlog produtos (entregáveis) product backlog retrospectiva figura 4 - Ciclo de vida do Scrum (autor) Tudo começa com a escolha do time. Ele deve ter entre 4 e 9 pessoas. Esse limite é importante, pois uma equipe maior que isso seria uma fonte de problemas de comunicação. Deve se também escolher o scrum Master e definir quem será o product owner. O scrum master faz parte da equipe do projeto, o product Owner não. Ele é o patrocinador do projeto ou seu representante. É fundamental que as partes interessadas tenham claramente quem são essas pessoas. O product owner deve construir e priorizar o backlog. Essa lista pode sofrer alterações durante o projeto de acordo com o andamento do mesmo. O planejamento de sprint é uma reunião crítica, provavelmente o evento mais importante no Scrum (na minha opinião, claro). Um encontro de planejamento de sprint mal feito pode bagunçar totalmente um sprint.

23 23 O propósito da reunião de planejamento do sprint é dar à equipe informação suficiente para trabalharem em paz por algumas semanas, e para dar ao product owner confiança suficiente para deixá-los fazerem isto. (KNIBERG, 2007, PAG.15) Os Sprints são planejados no sprint planning meeting, cuja meta é definir o objetivo principal do Sprint, definir o sprint backlog, definir quais as tarefas necessárias para cada work item e decidir quanto tempo durará o sprint. A duração do sprint deve ter entre 2 e 6 semanas. A duração deve ser longa o suficiente para que a equipe do projeto possa produzir um entregável que tenha valor para o negócio e o mais curta possível para dar agilidade a organização e não ficar suscetível a problemas na mudanças de escopo do projeto. O sprint backlog será composto pelos work itens com maior prioridade do backlog do projeto, como ilustra a figura 5. A quantidade de work itens que irá compor o sprint backlog vai depender do que será possível concluir dentro de um único sprint com duração já definida. Nessa equação, a duração do sprint se mantém constante e o escopo varia para se adequar ao tempo disponível.

24 24 Product backlog Sprint backlog duração do work item duração do sprint Prioridade figura 5 - product backlog e sprint backlog (autor) Durante o sprint são realizadas reuniões diárias com a equipe do projeto que duram entre 15 e 30 minutos. Normalmente são realizadas no mesmo lugar e no mesmo horário. Cada membro da equipe responde a três perguntas: O que ele fez desde o último daily meeting. Se ele está encontrado problemas para executar a tarefa. O que ele fará até próximo daily meeting. Atualizar o andamento do projeto no quadro de tarefas figura 6 e identificar quais são obstáculos que a equipe está encontrando ao executar as tarefas são os objetivos dessa reunião diária.

25 25 figura 6 - quadro de tarefas do sprint (KNIBERG, 2007, PAG. 49) Ao final de cada sprint é realizada uma reunião de revisão, onde os entregáveis prontos são apresentados para as partes interessadas. O objetivo essencial é validar o que foi realizado no sprint por meio do feedback dos interessados. Essa avaliação pode referendar a qualidade do que se foi construído e alterar os objetivos dos próximos sprints Após a reunião de revisão, é realizada uma reunião de retrospectiva somente com a equipe do projeto e product owner. Segundo KNIBERG (2007, PAG. 69), esse é o segundo evento mais importante no Scrum, o primeiro seria a reunião de planejamento do sprint. Usando brandstorming ou técnica de delphi são identificadas oportunidades de melhoria, como se o projeto pudesse ser realizado novamente. Algumas sugestões são selecionadas e as lições aprendidas podem ser aplicadas nos próximos sprints. Essa ação de inspeção é importante para a melhoria continua do projeto e do próprio scrum que pode ser customizado ciclo após ciclo.

26 26 São realizados tantos sprints quantos necessários para finalizar product backlog.

27 27 Capítulo III - ADERÊNCIA O Scrum, pela sua natureza menos formal, possui pouquíssimos processos formais que congregam muitos sub-processos informais e empíricos. Existem dois tipos de processos: definidos e empíricos. Processos definidos são aqueles que determinam o que deve ser feito, quando e como. Para um mesmo conjunto de variáveis de entrada, deve-se esperar o mesmo resultado sempre. Um exemplo bem conhecido de processo definido é o RUP da IBM (Rational). O RUP é um processo de desenvolvimento de software que define quais as atividades necessárias para que o produto, ou software, seja construído de forma repetitivel. (...) O Scrum, como um bom processo empírico, parte do princípio que nem todas as características do produto são conhecidas na análise e que provavelmente os requisitos mudarão com o passar do tempo. O Scrum prevê somente os seguintes processos: Criação do product backlog. Sprint planning meeting. Executar sprint. Daily Scrum meeting. Revisar sprint Retrospectiva ( Cada processo desse é composto por um ou mais sub-processos informais que, segundo a classificação do PMBOK, podem pertencer a áreas de conhecimento diferentes.

28 Processos Scrum e áreas de conhecimento do PMBOK. A seguir, identificamos e classificamos esses sub-processos de acordo com as áreas de conhecimento do PMBOK Gerenciamento do escopo. No PMBOK os processos para gerenciamento do escopo são: coletar requisitos, definir escopo, criar a estrutura analítica do projeto, verificar o escopo, controlar escopo. No Scrum, podemos identificar os seguintes processos para o gerenciamento do escopo: Definir do product backlog. O product backlog é criado pelo product owner, que identifica as demandas e solicitações de mudança que o projeto deverá atender. O objetivo é reduzir a uma lista as demandas, solicitações, necessidades internas ou externas que a organização tem para o projeto Definir do sprint backlog O sprint backlog será um subgrupo do escopo principal do projeto. Ele será o escopo do sprint seguinte. Ele é composto pelos work itens mais prioritários ainda não concluídos do product backlog. Durante a execução do sprint, o sprint backlog deve ser manter inalterado. Isso evita mudanças constantes no trabalho da equipe e matem um planejamento inalterado enquanto o sprint está rodando. Caso um fator externo e superveniente aconteça e é imprescindível que o sprint backlog tenha que ser alterado, o sprint deve ser cancelado e todo ciclo do sprint deve ser iniciado novamente. O objetivo é separar um subgrupo do product backlog para ser realizado dentro do sprint que deve durar até 6 semanas.

29 Planejar as tarefas dos work itens. O work item é descrito a nível de negócio e para realizá-lo são necessárias a execução de uma ou mais tarefas. A tarefa é aquilo que precisa ser feito para realizar o work item. E identificar todas as tarefas necessárias para a realização de cada work item é fundamental para se estimar corretamente o esforço necessário e quais e quantos work itens poderão ficar prontos dentro de um sprint. O objetivo é identificar as tarefas para realizar um work item Identificar tarefas não planejadas. Durante a execução do sprint, a equipe do projeto pode identificar uma ou mais tarefas que não foram planejadas antes do início do sprint. O objetivo é identificar o mais cedo possível essas tarefas e organizá-las dentro do planejamento do sprint Aumentar escopo do sprint. O Sprint backlog não deve ser alterado durante a execução do sprint. Quando os work itens do sprint backlog acabam antes do prazo determinado para a duração do sprint, acontece a única exceção a essa regra. Work itens do topo do product backlog são incluídos nos Sprint corrente. Esse passo é repetido até que o prazo do sprint termine como fora planejado Gerenciamento de tempo. O PMBOK tem seis processos para gerenciar o tempo: definir atividades, seqüenciar as atividades, estimar recursos das atividades, estimar duração das atividades, desenvolver cronograma e controlar cronograma. No Scrum, podemos identificar os seguintes processos para gerenciamento do tempo:

30 Realizar a estimativa inicial da duração dos work itens. A estimativa inicial é uma análise grosseira e prematura, com base somente na experiência do Scrum master e na comparação com outros work itens análogos. O objetivo dessa estimativa é dar um norte ao product owner no momento em que está priorizando o product backlog. Isso vai ajudá-lo a equilibrar entregas importantes com o tempo estimado para sua conclusão. Mais conhecida como relação custo benefício Definir duração do sprint. Os sprints devem ter duração entre 2 e 6 semanas e durante o projeto a duração dos sprints deve ser mantida. A duração curta e constante dos sprints é um dos pontos chaves do Scrum. Manter a equipe do projeto no mesmo ritmo, manter as entregas constantes, manter o desenvolvimento do projeto iterativo e contínuo, facilitar mudanças grandes de escopo, manter o projeto resiliente a falhas no levantamento de requisitos do produto são algumas das diversas vantagens dessa abordagem. O tempo médio de todos os work itens levantados na estimativa inicial, o tamanho da equipe, a necessidade com o que o cliente precisa das entregas, os fatores ambientais e a cultura organizacional são algumas das variáveis consideradas para se definir a duração do sprint. O sprint ter que se longo o suficiente para que a equipe do projeto possa entregar um número mínimo de work itens e ter uma reserva no caso de algum atraso ou impacto negativo. Mas tem que ser curta o suficiente para que todas as vantagens relacionadas no parágrafo anterior sejam mantidas Estimar duração das tarefas. Na reunião de planejamento de cada sprint a equipe do projeto estima a duração das tarefas dos work itens com maior prioridade.

31 Estimar duração dos work itens. A duração dos work itens consiste na soma das tarefas que o compõem. A cada sprint, a duração dos work itens mais prioritários são estimadas até que a soma desses alcance o prazo de duração do sprint. Essa estimativa substitui a estimativa inicial Atualizar o quadro de tarefas. A parte esquerda do quadro de tarefas é organizada em linhas e colunas, onde as colunas segmentam em que fase está o work item ou tarefa, que geralmente tem as seguintes fases, mas não se limitam a elas, não iniciado, iniciado e pronto e a cada linha tem um work item e suas tarefas. No daily meeting, cada membro da equipe atualiza a tarefa pela qual é responsável passando a sua tarefa para a coluna seguinte quando a fase anterior for superada. Como mostra a figura 8 figura 7 - Quadro de tarefas do sprint (KNIBERG, 2007, capa)

32 Atualizar o burndown. O burndown é um gráfico cujos eixos são a soma das durações de todas as tarefas do sprint VS o prazo de duração do sprint, onde uma linha pontilhada liga os extremos dos dois eixos, formando a linha base. A atualização do burndown consiste em subtrair do total de pontos do sprint os pontos associadas as tarefas que são concluídas e marcar a diferença no gráfico burndown, como ilustra figura Gerenciamento de custo. figura 8 - Gráfico Burndown (KNIBERG, 2007, PAG. 53) O PMBOK tem os processos estimar custo, determinar orçamento e controlar custos para realizar o gerenciamento de custo do projeto. No Scrum, não existe nenhum processo para planejar, gerenciar ou até mesmo controlar custos do projeto Gerenciamento de qualidade O PMBOK tem três processos para gerenciar a qualidade: planejar qualidade, garantir qualidade e controlar qualidade.

33 33 Existem dois processos no Scrum para gerenciamento da qualidade do projeto: Definir como os work itens serão demonstrados. No momento da criação do work item, é definido como o work item será apresentado ao final do sprint. Essa definição, além de orientar como será a demonstração, ajuda a definir adequadamente o próprio work item, pois essa definição obriga o product owner a defini-lo de maneira tangível o suficiente para que seja demonstrado Demonstrar os resultados do sprint. Com a instrução de como cada work item deve ser demonstrado, na reunião de revisão do sprint, o work item é apresentado para os presentes. E uma pesquisa de avaliação dos produtos do sprint deve ser realizada. O objetivo é ter o feedback o mais rápido possível quanto a qualidade do que foi desenvolvido e se ele atende aos objetivos do negócio Gerenciamento de recursos humanos. No PMBOK há quatro processos para gerenciar recursos humanos, desenvolver o plano de recursos humanos, mobilizar a equipe do projeto, desenvolver a equipe do projeto, gerenciar a equipe do projeto No Scrum podemos identificar dois processos para gerenciamento de recursos humanos: Definir equipe do projeto e seus papéis. Nesse processo a equipe do projeto deverá ser definida considerando os recursos disponíveis, o perfil dos membros e as necessidades do projeto. Os papéis de Scrum Master e de product Owner devem ser definidos e devem estar claros para toda a equipe e para toda a organização. É importantíssimo que a equipe, que não inclui o product owner, esteja dedicada exclusivamente

34 34 para o projeto e que o product owner esteja disponível para atender e acompanhar andamento do projeto e seus sprints Gerenciar equipe do projeto Esse processo é comum a qualquer atividade em equipe. O Scrum, como todo processo ágil, tem como características equipes auto-organizadas e o "empowerment" de seus membros. O gerente tem a função de incentivar e buscar essas qualidades para a equipe do projeto. Essa característica é explicitada no dayli meeting, em que no lugar do Scrum Master do projeto distribuir as atividades, cada membro da equipe escolhe a tarefa que vai fazer no dia seguinte. Com isso, a equipe se coloca como responsável na execução das tarefas no lugar de ser responsabilizada. Isso só é possível com equipes motivadas. O papel do Scrum master é de facilitador do trabalho da equipe Gerenciamento de comunicações. O PMBOK define cinco processos para a gerência de comunicações: identificar as partes interessadas, planejar comunicações, distribuir informações, gerenciar expectativas das partes interessadas, relatar performance. No Scrum existem os seguintes processos que podem ser classificados como processos para gerência de comunicação: Comunicar o início do sprint. Nesse processo, deve-se comunicar aos interessados no projeto as informações sobre o sprint e quando ele será iniciado. O objetivo é moldar a expectativa dos interessados sobre os resultados do sprint Comunicar o fim do sprint. Nesse processo, o fim do sprint, os seus resultados são comunicados aos interessados no projeto. O objetivo é dar publicidade sobre o que foi realizado no sprint e como isso é avaliado pela organização.

35 Gerenciamento de riscos. O PMBOK prevê Planejar gerenciamento de riscos, identificar riscos, analisar qualitativamente riscos, analisar quantitativamente riscos, planejar repostas a riscos, monitorar e controlar riscos. Não existe processo formal ou informal no Scrum para gerenciamento dos riscos do projeto. No entanto, o Scrum trata o risco de uma maneira implícita quando reduz o tamanho do sprint para que as mudanças de requisitos ou a falha de no levantamento de requisitos tenham um baixo impacto no projeto. Com isso se mitiga a possibilidade de se gastar muito tempo e dinheiro com um projeto que desenvolva o produto errado Gerenciamento de aquisição O PMBOK prevê quatro processos para aquisições. Planejar aquisições, conduzir aquisições, administrar aquisições e encerrar aquisições. Não existe nada assemelhado no Scrum. O Scrum não tem nenhum processo, ferramenta ou arcabouço para realizar aquisições e contratações Gerenciamento de Integração O gerenciamento de integração, no PBMOK, é um integrador de todos os processos das outras áreas de conhecimento. No SCRUM temos: Reunião de preparação do sprint Nessa reunião, todas as definições quanto ao sprint são fechadas, como duração, escopo, objetivo, equipe, horário das reuniões diárias e outras definições do sprint.

36 Executar sprint. Esse processo é a própria atividade de executar todas as tarefas identificadas durante o planejamento do sprint Avaliar resultados do sprint. Acontece após a apresentação dos resultados do sprint e é feita por todos interessados no projeto. Após a apresentação dos produtos desenvolvidos no sprint, os interessados no projeto avaliam se o que foi entregue é o que se desejava e se os objetivos do sprint foram alcançados. O objetivo principal é verificar se o que foi feito atende as demandas do negócio Realizar análise crítica do sprint. Acontece na reunião de retrospectiva do sprint, onde somente a equipe do projeto avalia os produtos e como o sprint foi feito, fazendo sugestões e críticas. Decisões de melhoria para os próximos sprints podem ser tomadas. Como se a equipe pudesse executar o projeto novamente para registrar as lições aprendidas O objetivo principal é colocar o sprint num ciclo virtuoso de melhoria contínua Agrupando os processos Podemos agrupar esses sub-processos informais pelos processos formais do Scrum da seguinte maneira: Antes do início do projeto. (não é um processo em si. É um momento no ciclo de vida) o Definir equipe do projeto e seus papéis Criação do product backlog. o Definir do product backlog. o Realizar a estimativa inicial da duração dos work itens. Sprint planning meeting. o Definir do sprint backlog

37 37 o Planejar as tarefas dos work itens. o Definir duração do sprint. o Estimar duração das tarefas. o Estimar duração dos work itens. o Definir como os work itens serão demonstrados. Antes do início do sprint. (não é um processo em si. É um momento no ciclo de vida) o Comunicar o início do sprint. Executar sprint. o Gerenciar equipe do projeto o Executar sprint. Daily Scrum meeting. o Identificar tarefas não planejadas. o Aumentar escopo do sprint. o Atualizar quadro de tarefas. o Atualizar o burndown. Revisão. o Comunicar o fim do sprint. o Demonstrar os resultados do sprint. o Avaliar resultados do sprint. Retrospectiva. o Realizar análise crítica do sprint Ciclo de vida. O PMBOK tem uma definição que bem caracteriza os ciclos de planejamento e execução dos sprints no Scrum que é o planejamento em ondas sucessivas. "O planejamento em ondas sucessivas é uma forma de planejamento com elaboração progressiva, onde o trabalho a ser executado num futuro próximo é planejado em detalhes e o trabalho futuro é planejado nos níveis

38 38 mais altos da EAP. Portanto, um trabalho pode existir em vários níveis de detalhamento dependendo de onde está no ciclo de vida do projeto. Por exemplo, durante o planejamento estratégico inicial, quando a informação está menos definida, os pacotes de trabalho podem ser decompostos até o nível dos marcos. Conforme mais é conhecido a respeito dos eventos vindouros num futuro próximo, podem ser decompostos em atividades." (PMBOK, 2008, PAG. 117.) É exatamente isso que ocorre no Scrum, os itens que estão com maior prioridade do product backlog são planejados em detalhes e separados para a execução no próximo Sprint. Isso permite que os itens com maior valor para o cliente possam ser entregues logo no início do projeto e, ainda, que não seja necessário conhecer em detalhes todos os itens do backlog. Os itens que não se tem total conhecimento no início do projeto, estão obscuros ou imprecisos e que carecem de um levantamento mais detalhado podem amadurecer durante a execução do projeto até que seja necessário realizar o levantamento detalhado.

39 39 CONCLUSÃO O Scrum é um arcabouço altamente customizável de gerência de projetos que se caracteriza pela informalidade, muitos processos empíricos, poucos processos formais, equipes pequenas, planejamento em ondas sucessivas, planejamento e execução interativo e contínuo, participação ativa do patrocinador do projeto (product owner), entregas após ciclos curtos, equipes auto-organizadas, foco no negócio e um facilitador que é o líder da equipe (Scrum master). Características que como vimos tem sua origem no desenvolvimento ágil e garantem ao Scrum o gerenciamento de projetos com o mínimo de documentação, formalidade e planejamento possíveis. Mesmo com essas características, ele não se afasta dos princípios do PMBOK. Todos os processos que identificamos no Scrum puderam ser classificados de acordo com áreas de conhecimento do PMBOK. E dependendo dos fatores ambientais da organização e das características do projeto, o Scrum pode atender plenamente a necessidade de gestão do projeto Vantagens e desvantagens Facilidade de operar. Pela sua característica informal e empírica, não é necessário que o gestor do projeto ou que a equipe do projeto tenham conhecimentos aprofundados sobre as suas ferramentas e processos. É uma metodologia robusta a mudanças no escopo do projeto e a requisitos mal levantados. Mantêm um constante diálogo entre as partes interessadas e a equipe do projeto, podendo promover correções cedo no projeto, antes que muito tempo e dinheiro sejam desperdiçados. É veloz em entregar itens que tenham valor para o negócio. Os Sprints são curtos para que essa vantagem possa ser explorada.

40 40 Tem cobertura muito boa nas áreas de conhecimento de escopo, gerenciamento de recursos humanos, o que incentiva equipes autoorganizadas e empowerment de seus membros. Seus controles acontecem de maneira fluida e natural durante a execução do projeto. Nos seus processos não foi possível identificar nenhum controle que possa se tornar excessivo ou com um custo próximo ao custo do objeto controlado. Não é aplicável a projetos grandes ou pelo menos projetos que não possam ser decompostos em entregas de até 6 semanas. Quanto o maior o número da equipe do projeto, maiores são os problemas de comunicação e mecanismos como as reuniões diárias, de revisão e retrospectiva começam a ficar inviáveis com um número grande de pessoas. No Scrum, o trabalho de gerenciar uma equipe cresce exponencialmente a quantidade dos membros dessa equipe. A sua informalidade tem um risco para determinados tipos de organizações. O fato do conhecimento dos produtos criados ficar mais concentrado nas pessoas do que nos processos, em circunstâncias que existe uma alta rotatividade, muito conhecimento pode ser perdido, haja vista o Scrum ter pouquíssimos registros formais de suas atividades. A dedicação exclusiva da equipe. Essa é uma característica que pode ser inviável em determinadas organizações. Já que pode haver projetos que concorrem por um mesmo especialista e a organização pode não dispor de recursos humanos com a qualificação necessária em número adequado. Dedicação do patrocinador do projeto. Uma das causas comuns para o fracasso de projetos é a falta de patrocínio apoiando o projeto. No Scrum essa carência se torna mais acentuada, já que a participação do patrocinador em várias fases do projeto se torna imprescindível.

41 Customização e extensão. De acordo com as necessidades do projeto, os processos e as áreas de conhecimento não cobertas pelo Scrum podem ser objeto de processos de outras metodologias ou frameworks. O gerenciamento de custo, aquisição, risco são áreas de conhecimento sensíveis de projetos que podem ser atendidas por outros processos. O potencial de customização do Scrum permite que ele seja integrado a ativos de processos organizacionais já existentes. Pode-se, ainda, alterar o seu ciclo de vida para contemplar processos prescritos por outras metodologias. Os processos para gerenciamento de custo do PMBOK, podem, por exemplo, ser combinados com o Scrum da seguinte maneira: o planejar custos e elaborar orçamento podem ser alocados entre o início do projeto e o início de cada sprint e controlar custos aconteceria durante a execução do sprint, como ilustra a figura 9. Planejamento de custos. Elaboração do orçamento. SPRINT 2 a 6 semanas. reunião diária Controlar custos. revisão Prioridade Reunião de planejamento do sprint sprint backlog produtos (entregáveis) product backlog retrospectiva figura 9 - Ciclo de vida do Scrum com os processos de custo do PMBOK. (autor)

42 Aplicabilidade As características do Scrum nos permitem limitar seu uso a organizações e projetos que tenham as seguintes características: ambientes caóticos, seja porque não existe planejamento ou não é possível planejar a médio e longo prazo. requisitos dos produtos imprecisos ou escopo do projeto volátil; pessoas motivadas; equipes com capacidade de se auto organizarem; projetos onde as áreas de conhecimento que o Scrum não cubram não sejam relevantes para o projeto ou que já existam processos organizacionais que tratem dessas áreas. disponibilidade do patrocinador do projeto ou do seu representante. projetos cujos produtos possam ser decompostos em entregas que possam ser concluídas em menos de 6 semanas. Isto posto, é fácil entender porque Scrum faz tanto sucesso em projetos de desenvolvimento de software onde estas características são latentes. Mas as possibilidades de uso do Scrum não se limitam aos projetos desse tipo, qualquer projeto que guarde relação com essas características é candidato ao uso do Scrum. Concluímos, portanto, que o Scrum é aderente em parte com o PMBOK. Pois ele não cobre todas as áreas de conhecimento de um projeto. Portanto, sua aplicabilidade deve ser analisada no caso concreto, verificando se as características do projeto, da equipe e da organização são propícias para o uso do Scrum.

43 43 Glossário Burndown É um gráfico de trabalho restante versus tempo. Daily Scrum Reunião diária É uma reunião da equipe do projeto com freqüência diária e dura entre 15 a 30 minutos. Empowerment delegar O empowerment parte da idéia de dar às pessoas o poder, a liberdade e a informação que lhes permitem tomar decisões e participar ativamente da organização. PMBOK Project Management Corpo do conhecimento do gerenciamento do projeto. Body of Knowledge Product Backlog do É uma lista de Works itens que devem ser backlog produto criadas durante o projeto. Product Owner Proprietário do produto É o proprietário do produto é o cliente do projeto e quem deve definir e priorizar as funcionalidades do product backlog. Project Instituição mantenedora do PMBOK. Management Institute (PMI). Scrum Master é o líder do projeto, quem gerencia a equipe do projeto e normalmente conduz as reuniões de trabalho. Sprint no ciclo de vida do projeto, são realizados vários sprints que duram de 2 a 4 semanas. Ao final de cada sprint um grupo de funcionalidades é entregue. Sprint Backlog É um subconjunto da lista de

44 44 funcionalidades do product backlog que será desenvolvida no sprint seguinte. Geralmente é composta pelos work itens mais importantes da product backlog ainda não finalizados. Sprint Reunião de É uma reunião que ocorre no início de cada Planning Meeting Planejamento do Sprint sprint para que entre outras coisas se defina o Sprint backlog daquele sprint. Sprint Retrospective Retrospectiva do Sprint Sprint Review Revisão do É uma reunião de revisão do Sprint. Ocorre sprint ao final do Sprint onde tudo aquilo que foi desenvolvido durante aquele sprint é apresentado para as partes interessadas. Stakeholders Partes interessadas são as pessoas ou instituições que possuam interesse no projeto. Task Tarefa são as atividades necessárias para realizar um Work Item. Team Equipe do é a equipe do projeto que tem entre 4 e 9 projeto pessoas. Works item Entregável cada entregável do projeto que é construído durante sua execução.

45 45 BIBLIOGRAFIA CITADA MARCH, Rodrigo. Fim ao Planejamento sem Fim. Rio de Janeiro: O Globo, 15 de fevereiro, capa do caderno boa chance, 2009 KNIBERG, Henrik. Scrum e XP direto das Trincheiras, C4Media, PMBOK, Um guia do Conhecimento em Gerenciamento de Projetos, 4ª ed., Pensilvânia: Project Management Institute, 2008 PRESSMAN, S. Roger. Engenharia de software, Uma abordagem profissional. 7ª ed., New York: The McGraw-Hill Companies, 2011.

46 46 BIBLIOGRAFIA CONSULTADA BROOKS, Frederick P. Jr. The Mythical man-month. 4ª ed., Boston: ADDISON-WESLEY, CRUZ, Tadeu. Sistemas Métodos & Processos 2ª ed., São Paulo: Atlás S.A, 2005 KNIBERG, Henrik. Scrum e XP direto das Trincheiras, C4Media, PICHLER, Roman. Agile project management with Scrum, Boston: ADDISON-WESLEY, PMBOK, Um guia do Conhecimento em Gerenciamento de Projetos, 4ª ed., Pensilvânia: Project Management Institute, 2008 PRESSMAN, S. Roger. Engenharia de software, Uma abordagem profissional. 7ª ed., New York: The McGraw-Hill Companies, 2011.

47 47 WEBGRAFIA CRUZ, Leandro R.S. Desenvolvimento de Software com Scrum. Acessado em 01 de outubro de 2012 FERREIRA, Décio; COSTA, Felipe, ALONSO, Filipe; ALVES, Pedro; NUNES, Tiago - SCRUM Um Modelo Ágil para Gestão de Projetos de Software. Acesso em 04 de outubro de Manifesto para Desenvolvimento Ágil de Software. Acessado em 04 de outubro de 2012 PMSURVEY. PMSURVEY 2012 edition results. Acessado em 04 de outubro de 2012

48 48 ÍNDICE AGRADECIMENTOS... 3 DEDICATÓRIA... 4 RESUMO... 5 METODOLOGIA... 6 INTRODUÇÃO... 9 Capítulo I - PBMOK Capítulo II - SCRUM Capítulo III - ADERÊNCIA Processos Scrum e áreas de conhecimento do PMBOK Agrupando os processos Ciclo de vida CONCLUSÃO Vantagens e desvantagens Customização e extensão Aplicabilidade Glossário BIBLIOGRAFIA CITADA BIBLIOGRAFIA CONSULTADA WEBGRAFIA... 47