UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO … · indústria. A capa do caderno Boa Chance do...
48
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
Transcript of UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO … · indústria. A capa do caderno Boa Chance do...
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
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
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
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
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
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
SUMÁRIO
AGRADECIMENTOS ......................................................................................... 3
DEDICATÓRIA................................................................................................... 4
RESUMO ........................................................................................................... 5
METODOLOGIA ................................................................................................ 6
INTRODUÇÃO ................................................................................................... 9
Capítulo I - PBMOK .......................................................................................... 11
Capítulo II - SCRUM ........................................................................................ 18
Capítulo III - ADERÊNCIA ................................................................................ 27
CONCLUSÃO .................................................................................................. 39
CONCLUSÃO .................................................................................................. 39
Glossário .......................................................................................................... 43
BIBLIOGRAFIA CITADA .................................................................................. 45
BIBLIOGRAFIA CONSULTADA ....................................................................... 46
WEBGRAFIA ................................................................................................... 47
8
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
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. (http://201.49.223.58:8080/PBEnquete3/public/login.xhtml)
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
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 240.000 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
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
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
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
Tabela 1 - Mapeamento de grupos de processos de gerenciamento
de projetos e áreas de conhecimento
Áreas de Conhecimento
Iniciação Planejamento Execução Monitoramento e controle
Encerramento
Integração
1. Desenvolver o termo de abertura do projeto
2. Desenvolver o plano de gerenciamento do projeto
3. Orientar e gerenciar a execução do projeto
4. Monitorar e controlar o trabalho do projeto 5. Realizar o controle integrado de mudanças
6. Encerrar o projeto ou fase
Escopo 1. Coletar os requisitos 2. Definir o escopo 3. Criar a EAP
4. Verificar o escopo 5. Controlar o escopo
Tempo
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
6. Controlar o cronograma
Custos 1. Estimar os custos 2. Determinar o orçamento
3. Controlar os custos
Qualidade 1. Planejar a qualidade
2. Realizar a garantia de qualidade
3. Realizar o controle da qualidade
Recursos Humanos
1. Desenvolver o plano de recursos humanos
2. Mobilizar a equipe do projeto 3. Desenvolver a equipe de projeto 4. Gerenciar a equipe do projeto
Comunicação
1. Identificar as partes interessadas
2. Planejar as comunicações
3. Distribuir as informações 4. Gerenciar as expectativas das partes interessadas
5. Reportar o desempenho
Riscos
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
6. Monitorar e controlar os riscos
Aquisição
1. Planejar as aquisições 2. Conduzir as aquisições
3. Administrar as aquisições
4. Encerrar as aquisições
(PMBOK,2008, PAG.43)
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
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
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 (http://www.mrfu.mn/c/rugby-laws)
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
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."
(http://www.agilemanifesto.org/iso/ptbr/)
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
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.
(http://www.igorfernandes.com.br/ined/ES/Cap15%20-%20SCRUM.doc, 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
• 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
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.
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.
equipe do projeto.
Reunião de planejamento do sprint
Prio
ridad
e
product owner
sprint backlog
product backlog
scrum master
SPRINT 2 a 6 semanas.
reunião diária
produtos (entregáveis)
revisão
retrospectiva
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
(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.
duração do work item
Prio
ridad
e
duração do sprint
Product backlog Sprint backlog
figura 5 - product backlog e sprint backlog
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
São realizados tantos sprints quantos necessários para finalizar
product backlog.
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.
(http://www.Scrum-master.com)
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
3.1. 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.
3.1.1. 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:
3.1.1.1.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.
3.1.1.2.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
3.1.1.3.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.
3.1.1.4.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.
3.1.1.5.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.
3.1.2. 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
3.1.2.1.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.
3.1.2.2.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.
3.1.2.3.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
3.1.2.4.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.
3.1.2.5.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
3.1.2.6.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 8.
figura 8 - Gráfico Burndown (KNIBERG, 2007, PAG. 53)
3.1.3. Gerenciamento de custo.
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.
3.1.4. Gerenciamento de qualidade
O PMBOK tem três processos para gerenciar a qualidade: planejar
qualidade, garantir qualidade e controlar qualidade.
33
Existem dois processos no Scrum para gerenciamento da qualidade do
projeto:
3.1.4.1.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.
3.1.4.2.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.
3.1.5. 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:
3.1.5.1.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
para o projeto e que o product owner esteja disponível para atender e
acompanhar andamento do projeto e seus sprints.
3.1.5.2.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
3.1.6. 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:
3.1.6.1.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.
3.1.6.2.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
3.1.7. 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.
3.1.8. 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.
3.1.9. 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:
3.1.9.1.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
3.1.9.2.Executar sprint.
Esse processo é a própria atividade de executar todas as tarefas
identificadas durante o planejamento do sprint.
3.1.9.3.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.
3.1.9.4.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.
3.2. 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
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.
3.3. 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
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
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.
4.1. 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
Tem cobertura muito boa nas áreas de conhecimento de escopo,
gerenciamento de recursos humanos, o que incentiva equipes auto-
organizadas 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
4.2. 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.
figura 9 - Ciclo de vida do Scrum com os processos de custo do PMBOK. (autor)
Prio
ridad
e
retrospectiva
revisão
produtos (entregáveis)
reunião diária
SPRINT 2 a 6 semanas.
sprint backlog
Reunião de planejamento do sprint
product backlog
ü Planejamento de custos. ü Elaboração do orçamento.
ü Controlar custos.
42
4.3. 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
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
Body of
Knowledge
Corpo do conhecimento do gerenciamento
do projeto.
Product
backlog
Backlog do
produto
É uma lista de Works itens que devem ser
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
Management
Institute (PMI).
Instituição mantenedora do PMBOK.
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
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
Planning
Meeting
Reunião de
Planejamento
do Sprint
É uma reunião que ocorre no início de cada
sprint para que entre outras coisas se defina
o Sprint backlog daquele sprint.
Sprint
Retrospective
Retrospectiva
do Sprint
Sprint Review Revisão do
sprint
É 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.
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
projeto
é a equipe do projeto que tem entre 4 e 9
pessoas.
Works item Entregável cada entregável do projeto que é construído
durante sua execução.
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, 2007.
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
BIBLIOGRAFIA CONSULTADA
BROOKS, Frederick P. Jr. The Mythical man-month. 4ª ed., Boston:
ADDISON-WESLEY, 1995.
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, 2007.
PICHLER, Roman. Agile project management with Scrum, Boston:
ADDISON-WESLEY, 2010.
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
WEBGRAFIA
CRUZ, Leandro R.S. Desenvolvimento de Software com Scrum.
http://www.igorfernandes.com.br/ined/ES/Cap15%20-%20SCRUM.doc
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. http://paginas.fe.up.pt/~aaguiar/es/artigos%20finais/es_final_19.pdf.
Acesso em 04 de outubro de 2012.
Manifesto para Desenvolvimento Ágil de Software.
http://www.agilemanifesto.org/iso/ptbr. Acessado em 04 de outubro de 2012
PMSURVEY. PMSURVEY 2012 edition results.
http://201.49.223.58:8080/PBEnquete3/public/login.xhtml. Acessado em 04 de
outubro de 2012
48
ÍNDICE AGRADECIMENTOS ......................................................................................... 3
DEDICATÓRIA................................................................................................... 4
RESUMO ........................................................................................................... 5
METODOLOGIA ................................................................................................ 6
INTRODUÇÃO ................................................................................................... 9
Capítulo I - PBMOK .......................................................................................... 11
Capítulo II - SCRUM ........................................................................................ 18
Capítulo III - ADERÊNCIA ................................................................................ 27
3.1. Processos Scrum e áreas de conhecimento do PMBOK. ................... 28
3.2. Agrupando os processos .................................................................... 36
3.3. Ciclo de vida. ...................................................................................... 37
CONCLUSÃO .................................................................................................. 39
4.1. Vantagens e desvantagens ................................................................ 39
4.2. Customização e extensão. .................................................................. 41
4.3. Aplicabilidade ...................................................................................... 42
Glossário .......................................................................................................... 43
BIBLIOGRAFIA CITADA .................................................................................. 45
BIBLIOGRAFIA CONSULTADA ....................................................................... 46
WEBGRAFIA ................................................................................................... 47
