Pmi Scrum

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA
LEONARDO BRUNO PEREIRA DE ARAUJO
ESTUDO COMPARATIVO DA COMPATIBILIDADE
ENTRE AS MELHORES PRÁTICAS DO PMI® E
SCRUM
São Paulo
2009
SCRUM
Trabalho de Conclusão de Curso apresentado

à Faculdade de Informática e Administração
Paulista, como um dos requisitos para
conclusão do Curso de Pós-Graduação em
®
Gestão de Projetos – PMI .
Orientador: Prof. Ms. Antonio Augusto

Barbosa Camargos
São Paulo
2009
SCRUM
Trabalho de Conclusão de Curso apresentado

à Faculdade de Informática e Administração
Paulista, como um dos requisitos para
conclusão do Curso de Pós-Graduação em
®
Gestão de Projetos - PMI .
Aprovada em ____________ de 200_
BANCA EXAMINADORA
Prof. Ms. Antonio Augusto Barbosa Camargos.

Orientador
Prof.(ª) Ms. ou Dr.

Componente da Banca
Prof.(ª) Ms. ou Dr.

Componente da Banca
ii
Dedico
À minha família, pelo carinho, apoio,

compreensão e pela participação no
processo do curso.
iii
AGRADECIMENTOS
Deus, pelo sentido da vida, saúde e proteção.
Ao professor Augusto Camargos pela dedicação e disponibilidade nos

momentos de orientação e esclarecimentos de dúvidas.
À minha família, pelo apoio e carinho para a conclusão desse curso.

iv
RESUMO
A história registra grandes feitos da humanidade, desde o início das civilizações, que
podem ser classificados como projetos. Contudo, muitos desses projetos foram
realizados de forma empírica, sem os conhecimentos e as habilidades necessárias
de gerenciamento de projetos, ou melhor, sem a aplicação organizada, racionalizada
e coordenada de esforços e recursos. Gerenciar projetos com excelência é um
desafio, fator essencial para sobrevivência das organizações. Isso necessita ser feito
de forma excepcional, conduzido por profissionais qualificados e, observando as
novas exigências da globalização – quer para atender organizações privadas,
governamentais ou ONGs.
Palavras-chave: PMI® . Metodologia Ágil. SCRUM. Gerenciamento de projetos.

ABSTRACT
The great achievements recorded history of mankind since the beginning of

civilizations, which can be classified as projects. However, many of these projects
were made on an empirical, without the knowledge and skills necessary for project
management, or better, without the application organized, streamlined and
coordinated the efforts and resources. Manage projects with excellence is a
challenge, an essential factor for survival of organizations. This needs to be done in
exceptional circumstances, conducted by qualified professionals, and observing the
new demands of globalization - or to take private organizations, governmental or
ONGs.
Keywords: PMI® . Agile Methodology. SCRUM. Project Management.

LISTA DE FIGURAS
Figura 1 - Extreme Programming ........................................................................... 25
Figura 2 - Feature Driven Development ................................................................. 32
Figura 3 - MSF ...................................................................................................... 35
Figura 4 - MSF ...................................................................................................... 38
Figura 5 - SCRUM ................................................................................................. 40
Figura 6 - Quadro de tarefas.................................................................................. 51
Figura 7 - Formato de Processo ............................................................................ 58
Figura 8 - Grupos de Processos ............................................................................ 58
Figura 9 - WBS ..................................................................................................... 67
Figura 10 - Desenvolvimento Iterativo – Grupos de processos do PMBOK® ........ 69

8
LISTA DE GRÁFICOS
Gráfico 1 – Sprint Burndown ..................................................................................... 48

9
LISTA DE TABELAS
Tabela 1 - Áreas fundamentais segundo o MSF ...................................................... 38
Tabela 2 - Áreas do conhecimento........................................................................... 59
Tabela 3 - Mapeamento dos processos nos grupos de processos e áreas de
conhecimento. ........................................................................................................... 60
Tabela 4 – Principais diferenças e similaridades entre as metodologias ágeis e
PMBOK® . .................................................................................................................. 64

10
LISTA DE SIGLAS
ALGOL Algorithmic Language
ANS Padrão Nacional Americano
ANSI Instituto de Padrões Nacional Americano
AT&T American Telephone and Telegraph
COBOL Common Business Oriented Language
EUA Estados Unidos da América
EVM Earned Value Management
FBS Feature Breakdown Structure
FDD Feature Driven Development
HP Hewlett-Packard
IBM International Business Machines
Lean Lean Thinking
LHS Limite de Horas da Sprint
MSF Microsoft Solutions Framework
NASA National Aeronautics and Space Administration
OPM3® Organizational Project Management Maturity Model
PMBOK® Project Management Body of Knowledge
PMI® Project Management Institute
PMJ Project Management Journal
PMP Profissionais de Gerenciamento de Projeto
PMP®) Project Management Professional
PMQ Project Management Quarterly
ROI Retorno Financeiro

11
SDLC Software Development Life Cycle
TAs Task Authorizations
TBS-EMF Treasury Board of Canada Secretariat - Enhanced Management
Framework
TI Tecnologia da Informação
WBS Work Breakdown Structures
WCMS Sistema de Gerenciamento de Conteúdo de Web
XP Extreme Programming
12
SUMÁRIO
INTRODUÇÃO ...................................................................................................... 14
1 METODOLOGIAS ÁGEIS .............................................................................. 20
1.1 Extreme Programming .................................................................................. 23
1.1.1 Estórias .................................................................................................... 25
1.1.2 Planejamento ........................................................................................... 26
1.1.3 Desenvolvimento iterativo ...................................................................... 26
1.1.4 Iterações de uma semana ....................................................................... 27
1.1.5 Teste antecipado ..................................................................................... 28
1.1.6 Refactoring .............................................................................................. 29
1.1.7 Programação em par............................................................................... 29
1.1.8 Envolvimento dos clientes ..................................................................... 30
1.2 Feature Driven Development ........................................................................ 30
1.2.1 Desenvolver um modelo geral ............................................................... 32
1.2.2 Construir uma lista de funcionalidades ................................................ 33
1.2.3 Planejar por funcionalidade ................................................................... 33
1.2.4 Projetar por funcionalidade .................................................................... 33
1.2.5 Construir por funcionalidade ................................................................. 34
1.3 Microsoft Solutions Framework ................................................................... 39
1.3.1 Release Manager ..................................................................................... 37
1.4 SCRUM............................................................................................................ 39
1.4.1 Como funciona? ...................................................................................... 40
1.4.2 Papéis e responsabilidades ................................................................... 41
1.4.3 Artefatos, conceitos e fases ................................................................... 42
1.4.3.1 Product Backlog ............................................................................... 42
1.4.3.2 Planejamento da Sprint .................................................................... 42
1.4.3.3 Execução e controle da Sprint......................................................... 42
1.4.3.4 Final da Sprint .................................................................................. 51
2. PMI® e PMBOK® ............................................................................................. 52
2.1 O gerenciamento de projeto ......................................................................... 52
2.2 História ........................................................................................................... 53
13
2.3 Hoje ................................................................................................................. 54

2.4 PMBOK® ......................................................................................................... 55
2.5 Projeto ............................................................................................................ 56
2.6 Gerenciamento de projeto ............................................................................ 56
2.7 Grupos de Processos .................................................................................... 57
2.8 Áreas de conhecimento ................................................................................ 59
2.9 Processos nos grupos e nas áreas de conhecimento ............................... 60
3. DIFERENÇAS, SIMILARIDADES E PROPOSTAS DE
COMPATIBILIZAÇÃO ........................................................................................ 62
3.1 Diferenças e similaridades............................................................................ 62
3.2 Propostas de compatibilização .................................................................... 66
4. ESTUDO DE CASO ........................................................................................ 70
4.1 Metodologias ágeis e o guia PMBOK® . Técnicas de gerenciamento de
projeto: mais perto do que você imagina .......................................................... 70
4.1.1 Introdução ................................................................................................ 70
4.1.2 Áreas de conhecimento do guia PMBOK® e a abordagem SCRUM ... 70
4.1.3 Gerenciamento de integração do projeto ............................................. 70
4.1.4 Gerenciamento de escopo do projeto ................................................... 74
4.1.5 Gerenciamento do tempo do projeto..................................................... 76
4.1.6 Gerenciamento de custos do projeto .................................................... 78
4.1.7 Gerenciamento de qualidade do projeto ............................................... 79
4.1.8 Gerenciamento de comunicação do projeto ......................................... 80
4.1.9 Conclusões .............................................................................................. 81
CONCLUSÃO ....................................................................................................... 83
REFERÊNCIAS .................................................................................................... 84
14
INTRODUÇÃO
A segunda metade do século XX foi marcada por grandes descobertas científicas e

em entra elas, o surgimento dos computadores, que teve inicialmente o seu
desenvolvimento fortemente patrocinado pela indústria bélica, projetados
basicamente para cálculos de trajetórias balísticas, esses computadores eram
mantidos em segredo pelo o governo americano até o final da segunda guerra
mundial, quando foram anunciados ao mundo.
Nos anos 60, houve a difusão dos chamados mainframes, estas máquinas
marcaram início da substituição do relês e válvulas pelo o uso de circuitos
integrados, uma melhora surpreendente no desempenho do hardware, profundas
modificações na arquitetura, aumento significativo na memória, capacidade de
armazenamento e uma variedade incomum de dispositivos de entrada e saída.
Empresas como a International Business Machines (IBM), Hewlett-Packard (HP) e a

Unisys lançaram seus modelos, no fim dos anos 70, e ao mesmo tempo, que
cresciam os sistemas destinados a grandes corporações, começaram a reduzir o
tamanho de seus mainframes, e foi da Unisys as primeiras máquinas micro-
programáveis, o que lhe conferia maior flexibilidade.
Para acompanhar a evolução dos computadores, linguagens de programação

surgiram desde os anos 50, a primeira linguagem de programação de alto nível foi
Fortran, criada em 1954, em 1957 foi criada B-0, que daria origem a Flow-Matic em
1958, antecessor imediato do Common Business Oriented Language (COBOL), de
1959, Lisp e Algorithmic Language (ALGOL) criadas em 1958.
A criação do COBOL foi notadamente um feito, embora tenha sido proposto

originalmente como solução para resolver problemas de programação do governo e
das forças armadas americanas, programas COBOL continuam em uso na maioria
das empresas comerciais em todo o mundo e em grandes instituições financeiras, e
continua ainda em uso depois de mais de 40 anos.
15
Segundo Pressman (2002) atualmente os softwares e os computadores assumem

um duplo papel, ele é o produto e, ao mesmo tempo, o meio para entregar o
produto, como produto oferece o potencial de computação presente no computador
ou, mais amplamente, numa rede de computadores acessível pelo o computador
local. Quer resida em telefone celular, quer opere em um mainframe, o software é
um transformador da informação. Como veículo usado para entrega do produto, o
software age como uma base para controle do computador (sistemas operacionais),
para a comunicação da informação (redes) e para a criação e o controle de outros
programas (ferramentas e ambientes de software), ele entrega o mais valioso
produto da nossa era – a informação.
Ao longo do tempo, sistemas baseados em computador se tornaram mais

sofisticados e complexos. Sofisticação e complexidade produzem magníficos
resultados quando um sistema é bem-sucedido, mas também podem causar
enormes problemas para quem precisa construir sistemas complexos.
Para citar alguns bugs famosos:
1. Derrubada do Airbus 320, 1988.
O navio da marinha americana USS Vicennes derrubou um Airbus 320, o qual foi
confundido por um F-14. 290 pessoas morreram. O software do radar não
diferenciou um avião de passageiros de um caça inimigo de ataque.
2. Divisão de números com ponto flutuante no microprocessador Pentium, 1993.
Um problema com os microprocessadores provocou uma falha na divisão de

números com ponto flutuante. Por exemplo, ao dividir 4195835,0 por 3145727,0
o resultado apresentado pelo microprocessador era 1,33374 ao invés de
1,33382, um erro de 0.006%. Ainda que a falha afetasse poucos usuários,
resultou num problema para a Intel, que se viu obrigada a trocar entre três e
cinco milhões de chips, numa operação que lhe custou mais de meio bilhão de
dólares.
3. Foguete Ariane, 1996.

16
Em junho de 1996, foi realizado o primeiro vôo do novo foguete da Agência

Espacial Européia – o foguete Ariane 5. Reutilizaram parte do código de seu
predecessor, o Ariane 4, mas os motores do novo foguete incorporavam
também, sem que ninguém desse conta, um bug numa rotina aritmética no
computador de vôo que falhou segundos após a decolagem do foguete; em
decorrência, meio segundo depois o computador principal da missão também
apresentou problemas. O Ariane 5 desintegrou-se 40 segundos após o
lançamento. O foguete e o satélite, que ele carregava, valiam US$ 500 milhões.
4. Mars Climate Orbiter, 1999.
Em outubro de 1999, a National Aeronautics and Space Administration (NASA)

lançou ao espaço a nave espacial exploratória Mars Climate Orbiter, a qual
custou US$ 125 milhões. A espaçonave perdeu-se no espaço durante o seu vôo
para Marte. Acredita-se que isto ocorreu devido a um erro de conversão de
dados no software da espaçonave. Foi descoberto que uma parte do software
utilizava sistema métrica americano e a outra, a internacional.
Dentre as várias tarefas que deveria executar, a espaçonave deveria prover

suporte de comunicação para a missão exploratória da espaçonave Mars Polar
Lander, a qual falhou por razões desconhecidas em dezembro 1999.
5. Blackout no Noroeste dos EUA, 2003.
A pior falha no sistema elétrico dos Estados Unidos da America (EUA) em toda
sua história, o blackout deixou mais de 50 milhões de clientes sem energia
elétrica, mais de 100 centrais geradoras foram desligadas, as perdas
econômicas foram estimadas em US$ 6.0 bilhões, um bug de software foi
identificado como o grande fator determinante para a causa do blackout.
Vemos então um cenário onde é mais comum o fracasso de um projeto de

software do que seu sucesso. Perguntas feitas a 40, 20, 10 anos atrás estão
sendo feitas atualmente quando sistemas complexos são construídos:
• Por que leva tanto tempo para concluir o software?

• Por que os custos de desenvolvimento são tão altos?
17
• Por que não podemos achar todos os erros antes de entregar o software aos
clientes?
• Por que continuamos a ter dificuldade em avaliar o progresso enquanto o
software é desenvolvido?
• Por que os cronogramas e custos são imprecisos?
• Por que não existem dados históricos sobre o processo de desenvolvimento?
• Por que a comunicação é deficiente?
• Por que os usuários ficam insatisfeitos?
• Por que há carência de conceitos quantitativos sobre confiabilidade, qualidade
e reusabilidade?
Para tentar responder essas, e muitas outras perguntas e tentar racionalizar os

processos de desenvolvimento de sistemas e minimizar impactos negativos em
projetos o Project Management Institute (PMI® ), fundado em 1969 nos EUA e
atualmente difundido em mais de 120 países é o maior difusor do gerenciamento de
projetos, e publica um Guia do Conjunto de Conhecimentos em Gerenciamento de
Projetos (Guia PMBOK® - Project Management Body of Knowledge).
Editado na forma de livro, o Guia PMBOK® está atualmente na quarta edição de

2008 e traduzido oficialmente para diversos idiomas, inclusive o português do Brasil.
As edições anteriores foram publicadas nos anos de 1996, 2000 e 2004. O PMBOK®
formaliza diversos conceitos em gerenciamento de projetos, como a própria
definição de projeto e do seu ciclo de vida, reconhece cinco grupos de processos de
gerenciamento de projetos e nove áreas de conhecimento.
Conceitos amplamente utilizados em projetos de desenvolvimento de software. O

Gerenciamento de projetos segundo as melhores práticas do PMI® ajuda as
organizações a atenderem as necessidades de seus clientes padronizando tarefas
rotineiras e reduzindo o número daquelas que poderiam ser esquecidas, assegura
que os recursos disponíveis são alocados da maneira mais eficiente e eficaz,
permitindo aos executivos seniores a perceber "o que está acontecendo" e "para
onde as coisas estão indo" dentro das organizações.
Muitas organizações ao redor do mundo, como NASA, IBM, American Telephone

and Telegraph (AT&T), Siemens, Chiyoda Corporation, Sociedade Computacional de
18
Singapura e o Governo Estadual de Oregon (EUA), lançam mão do Gerenciamento

de Projetos para desenvolver processos inovadores, planejar, organizar e controlar
iniciativas estratégicas, monitorar desempenho, analisar divergências significantes e
prever seus impactos nos projetos e na organização.
O Gerenciamento de Projetos ganhou popularidade durante as últimas décadas em

função de uma série de mudanças significativas no local de trabalho. Algumas
destas mudanças incluem:
• Processos de Downsizing (menos pessoas para fazer mais tarefas);

• Projetos e serviços maiores e mais complexos;
• Competição global e feroz;
• Acesso à informação mais fácil através de amplas redes de comunicação;
• Clientes mais sofisticados que exigem produtos e serviços de maior qualidade;
• Crescimento tecnológico exponencial;
• Organizações multinacionais que buscam estabelecer práticas uniformes para
gerenciar projetos.
Por outro lado, uma nova abordagem para desenvolvimento de software tem
despertado grande interesse entre as organizações de todo o mundo. Vivemos uma
tendência para o desenvolvimento acelerado de aplicações devido ao ritmo das
mudanças na tecnologia da informação, pressões por constantes inovações,
concorrência acirrada e grande dinamismo no ambiente de negócios (BOEHM,
2006).
Apesar de existir a um bom tempo, apenas recentemente a expressão “Métodos

Ágeis” vem ganhando popularidade no Brasil por usar abordagem simplificada no
desenvolvimento de sistemas de informação, no entanto, “ser simples” geralmente é
confundido com falta de controle e rigidez, na verdade, ser simples, ter agilidade, é
fazer a diferença e, ao contrário do que parece, exige muito disciplina e organização.
Criada por Jeff Sutherland, Ken Schwaber e John Scumniotales na década de 1990,
a SCRUM é uma metodologia ágil para gerenciamento de projetos, geralmente de
software, mas pode ser utilizada para outros tipos, como desenvolvimento de
produtos físicos, ou projetos diversos. Baseada no Pensamento Lean (Lean
19
Thinking), desenvolvimento iterativo e incremental, e novas estratégias de criação de

produtos. Sua aplicação não está limitada a projetos de software.
O objeto dessa pesquisa é uma análise comparativa de ambos os modelos

buscando responder dúvidas como: É possível usar modelo Project Management
Body of Knowledge (PMBOK® ) com SCRUM em um mesmo projeto? Ou é preciso
optar por uma abordagem ou outra? Se for possível, como adaptar o processo para
o uso em conjunto? Como trabalhar as áreas e processos do PMBOK® com uma
abordagem Ágil? Como gerenciar o escopo? E o tempo? Áreas que parecem
conflitantes entre PMBOK® e SCRUM. Alguns mais radicais defendem a adoção
puramente de PMBOK® e outros, por sua vez a adoção exclusiva de Metodologias
Ágeis.
No que se refere a projetos de software, o uso das duas abordagens é perfeitamente

possível e positiva. A motivação da pesquisa vem da visibilidade crescente que as
Metodologias Ágeis de desenvolvimento de software têm recebido em todo o mundo,
e também aqui no Brasil.
20
1 METODOLOGIAS ÁGEIS
As recentes definições sobre metodologias ou métodos ágeis evoluíram a partir da

metade de 1990 como parte de uma reação contra métodos considerados
"pesados", caracterizados por uma pesada regulamentação, regimentação e micro
gerenciamento usado no modelo em cascata que é composto basicamente por
atividades seqüenciais de levantamento de requisitos, análise, projeto,
implementação, teste, implantação e manutenção. Este modelo é derivado de outras
engenharias tradicionais (Civil, Elétrica, Naval) e foi o primeiro a ser usado pela
Engenharia de Software, na década de 70 (COCKBURN; HIGHSMITH, 2001).
Mesmo com a evolução dos computadores, das técnicas e ferramentas nos últimos
anos, a produção de software confiável, correto e entregue dentro dos prazos e
custos estipulados ainda é muito difícil. Dados de 1995 segundo a Standish Group -
Chaos Report, usando como exemplos 8380 projetos, mostram que apenas 16,2%
dos projetos foram entregues respeitando os prazos e os custos e com todas as
funcionalidades especificadas. Aproximadamente 31% dos projetos foram
cancelados antes de estarem completos e 52,7% foram entregues, porém com
prazos maiores, custos maiores ou com menos funcionalidades do que especificado
no início do projeto (SOARES, 2009).
Dentre os projetos que não foram finalizados de acordo com os prazos e custos
especificados, a média de atrasos foi de 222%, e a média de custo foi de 189% a
mais do que o previsto. Considerando todos os projetos que foram entregues além
do prazo e com custo maior, na média, apenas 61% das funcionalidades originais
foram incluídas. Mesmo os projetos cuja entrega é feita respeitando os limites de
prazo e custos possuem qualidade suspeita, uma vez que provavelmente foram
feitos com muita pressão sobre os desenvolvedores, o que pode quadruplicar o
número de erros de software, segundo a mesma pesquisa. As principais razões
destas falhas estavam relacionadas com o processo em cascata (COCKBURN;
HIGHSMITH, 2001).
21
A recomendação final foi que o desenvolvimento de software deveria ser baseado

em modelos incrementais, o que poderia evitar muitas das falhas reportadas.
Processos orientados a documentação para o desenvolvimento de software, como o
modelo em cascata, são de certa forma fatores limitadores aos desenvolvedores.
Além disso, muitas organizações não possuem recursos ou inclinação para
processos pesados de produção de software. Por esta razão, muitas organizações,
particularmente as pequenas, acabam por não usar nenhum processo, o que pode
levar a efeitos desastrosos em termos de qualidade de software. Torna-se
necessário, então, utilizar metodologias ágeis, que não são orientadas à
documentação nem tampouco se preocupam apenas com a codificação. A maioria
das metodologias ágeis nada possui de novo. O que as diferencia das metodologias
tradicionais são o enfoque e os valores. A idéia das metodologias ágeis é o enfoque
nas pessoas e não em processos ou algoritmos (ISOTTON NETO, 2008).
Além disso, existe a preocupação de gastar menos tempo com documentação e

mais com a implementação. Uma característica das metodologias ágeis é que elas
são adaptativas ao invés de serem preditivas. Com isso, elas se adaptam a novos
fatores decorrentes do desenvolvimento do projeto, ao invés de procurar analisar
previamente tudo o que pode acontecer no decorrer do desenvolvimento. Apesar do
uso crescente das metodologias ágeis, ainda falta uma base maior de projetos para
verificar suas vantagens. Mesmo assim, os resultados iniciais em termos de
qualidade, confiança, entregas e custos são promissores (ISOTTON NETO, 2008).
Para ser realmente considerada ágil a metodologia deve aceitar a mudança ao invés
de tentar prever o futuro. O problema não é a mudança em si, mesmo porque ela
ocorrerá de qualquer forma. O problema é como receber, avaliar e responder às
mudanças. Enquanto as metodologias ágeis variam em termos de práticas e
ênfases, elas compartilham algumas características, como desenvolvimento iterativo
e incremental, comunicação e redução de produtos intermediários, como
documentação extensiva. Desta forma existem maiores possibilidades de atender
aos requisitos do cliente, que muitas vezes são mutáveis (SOARES, 2009).
Em 2001, membros proeminentes na área de software se reuniram em Utah nos

EUA e embora cada membro tivesse suas próprias práticas e teorias sobre como
fazer um projeto de software ter sucesso, cada qual com as suas particularidades,
22
todos concordavam que, em suas experiências prévias, um pequeno conjunto de

princípios sempre parecia ter sido respeitado quando os projetos foram considerados
de sucesso e então publicaram o Manifesto ágil, documento que reúne os princípios
e práticas desta metodologia de desenvolvimento. Mais tarde, algumas pessoas
formaram a Agile Alliance, uma organização não lucrativa que promove o
desenvolvimento ágil (AGILE, 2009).
Segundo Fowler (2005) os conceitos chave do Manifesto Ágil são:
• “Indivíduos e interações ao invés de processos e ferramentas.”

• “Software executável ao invés de documentação.”
• “Colaboração do cliente ao invés de negociação de contratos.”
• “Respostas rápidas a mudanças ao invés de seguir planos.”
O Manifesto Ágil não rejeita os processos e ferramentas, a documentação, a

negociação de contratos ou o planejamento, mas simplesmente mostra que eles têm
importância secundária quando comparado com os indivíduos e interações, com a
colaboração do cliente e as respostas rápidas a mudanças e alterações. Esses
conceitos aproximam-se melhor com a forma que pequenas companhias de
Tecnologia da Informação trabalham e respondem a mudanças (SOARES, 2009).
Atualmente, existem algumas metodologias ágeis, cada uma exposta pela The Agile
Alliance. Nesse estudo, apresentarei quatro propostas ágeis, são elas: Extreme
Programming (XP), Feature Driven Development (FDD), SCRUM e Microsoft
Solutions Framework (MSF). Darei ênfase na metodologia ágil SCRUM, que será
objeto de análise desse trabalho de conclusão de curso.
23
1.1 Extreme Programming
Um dos principais fundadores da Extreme Programming chama-se Kent Beck. O

método da XP para gerenciar projetos de desenvolvimento de software começou a
ser concebido em meados da década de 1980, quando Kent Beck e Ward
Cunninghan trabalharam juntos num grupo de pesquisa na Tektronix. Segundo Kent
Beck a XP é uma metodologia que endereça as limitações do processo de
desenvolvimento de software. Ela não aborda o processo de gerenciamento do
projeto, análise financeira, marketing ou vendas. A XP afeta todas as áreas, mas não
as aborda diretamente, é um estilo de desenvolvimento de software cujo foco está
na excelência da aplicação das técnicas de programação, comunicação clara e
trabalho em equipe (TELES, 2004).
De acordo com Beck (1999) a XP é uma forma de promover a excelência no

desenvolvimento de software, e distingue-se de outras técnicas pelas seguintes
características:
• Trabalha com iterações de duração bastante curta, resultando em respostas

rápidas, concretas e contínuas;
• Usa uma abordagem incremental de planejamento, que resulta em planos
abrangentes que podem evoluir durante o ciclo de vida do projeto;
• Tem a possibilidade de planejar melhor a implementação das funcionalidades do
software, permitindo responder mais rápido às necessidades de mudanças dos
negócios;
• Usa mecanismos automatizados para realizar testes, que podem ser
desenvolvidos pelos programadores, clientes ou pessoal de qualidade para
monitorar o progresso do desenvolvimento, permitindo que o sistema evolua e
que os defeitos sejam identificados o mais cedo possível;
• Confia na comunicação oral, nos testes e nos programas fontes para comunicar a
estrutura do sistema;
• Trabalha com um processo evolutivo de design que persiste durante a vida do
projeto;
24
• Confia na colaboração entre indivíduos ativamente engajados e com talentos

específicos;
• Usa práticas que atendem às necessidades imediatas dos membros da equipe e
de longo prazo do projeto.
A XP enfatiza um conjunto de princípios, esses princípios são: Comunicação,

Simplicidade, Feedback, Coragem, Respeito, Ser mais humano, Benefício Mútuo,
Reutilização, Melhoria Contínua, Diversidade, Qualidade, Desenvolvimento em
pequenos passos, Responsabilização. Na XP os papéis são divididos por: testador,
designer de interação, arquiteto, gerente de projeto, gerente de produto, executivo,
documentador técnico, usuário e programador. Embora exista uma definição para
cada papel, uma pessoa pode assumir mais de um papel. A metodologia prevê três
fases principais, são elas: a exploração, o compromisso e o direcionamento. Embora
cada fase seja descrita de forma seqüencial, o projeto não segue uma seqüência,
indo de uma fase para outra. Todo o processo é cíclico, indo de uma fase para outra
na medida do necessário.
Na fase de exploração o objetivo da equipe é identificar o que o sistema precisa

fazer. Nesta fase a equipe executa três atividades básicas: escrever uma estória,
estimá-la e decompô-la. Na fase de compromisso a equipe de negócio determina o
escopo de cada release do sistema e as datas das entregas. Este trabalho leva em
conta as informações fornecidas pela a equipe de desenvolvimento e as
necessidades de negócio. Finalmente, na fase de direcionamento o plano é
atualizado à medida que as mudanças ocorrem durante a execução. As duas fases
anteriores acontecem quase que simultaneamente, enquanto que esta ocorre mais
tarde, durante a iteração ou entre as iterações. Veja a Figura 1.
25
Figura 1 - Extreme Programming (Adaptado). Fonte: http://www.extremeprogramming.org, 2009.
Na condução de um projeto a XP propõe a aplicação de um conjunto de práticas,

que podem ser divididas em duas categorias: as básicas e as complementares. As
básicas deveriam implementadas em qualquer projeto XP e as demais poderiam ser
consideradas como opcionais. A XP trabalha com várias práticas, contudo nem
todas precisam ser seguidas, e a importância relativa entre elas depende do
ambiente de cada projeto e das oportunidades de melhorias que existem. As
práticas mais expressivas da XP são descritas a seguir:
1.1.1 Estórias
As estórias representam unidades de funcionalidade da forma como são percebidas

pelos usuários, por exemplo, “Como caixa da loja eu vou identificar os produtos que
o cliente escolheu e o sistema vai informar o preço”. São textos simples e objetivos
para orientar o desenvolvedor sobre o que deve ser programado (JEFFRIES et al.,
2001).
26
1.1.2 Planejamento
Na XP é construído um plano geral do projeto que determina, de forma abrangente,

quando cada release vai ser concluído e o que vai compor cada um deles
(MARTINS, 2009).
No inicio de cada iteração, o conteúdo da iteração ou release é detalhado e um

plano de implementação é criado. Como cada iteração é relativamente curta, o
planejamento é feito logo antes do trabalho ser executado. Desta forma a chance de
haver desvios entre o que foi planejado e o que foi executado é menor e, caso
ocorra algum desvio, as suas razões podem ser verificadas rapidamente e corrigidas
logo no início da próxima iteração (MARTINS, 2009).
Normalmente a data de conclusão do projeto é previamente definida, desta forma é

possível definir quanto esforço pode ser dedicado para cada estória. As estórias que
provêem maior valor para os negócios devem ser trabalhadas prioritariamente
(BECK; FOWLER, 2001).
Como é difícil avaliar o custo e o valor de cada estória, fica difícil fazer o
planejamento do projeto. As informações utilizadas para fazer este tipo de avaliação
mudam no tempo. O planejamento não é uma previsão do futuro. No melhor caso,
ele expressa tudo que se conhece hoje sobre o que pode acontecer amanhã. O
plano representa um ponto de partida (MARTINS, 2009).
1.1.3 Desenvolvimento iterativo
Na XP o software é desenvolvido iterativamente em pequenos releases que

adicionam features ao sistema e permitem um retorno rápido do usuário. Os
27
releases devem ser do menor tamanho possível e que ainda possam produzir algum
valor para o negócio (POPPENDIECK; POPPENDIECK, 2003).
Numa implementação do tipo big-bang1, a equipe pode gastar meses sem adicionar
nenhuma nova funcionalidade ao sistema, mas preparando-se para o dia D, fazendo
horas extras e trabalhando em finais de semana. Mesmo que o projeto tenha
sucesso, após a implantação a equipe fica exausta e pode precisar de várias
semanas para se recuperar. Se o projeto não tiver sucesso os custos são ainda
maiores. Implantações do tipo big-bang têm altos riscos e grandes custos humanos
e econômicos.
1.1.4 Iterações de uma semana
O trabalho deve ser planejado uma semana de cada vez, que é o horizonte da
iteração. Deve haver uma reunião no começo de cada semana para fazer o
planejamento, nesta reunião serão abordados os seguintes assuntos (TELES, 2004):
• Rever o progresso até o momento, incluindo o progresso da última semana

comparado ao esperado;
• O cliente deve apontar as estórias de maior valor, que serão trabalhadas nesta
semana;
• Decompor as estórias em tarefas, e permitir que os membros da equipe se
voluntariem a pegar cada uma delas e façam suas estimativas.
A semana deve começar com os desenvolvedores escrevendo testes automatizados

que serão executados quando as estórias estiverem concluídas. Se a equipe chegar
à quarta-feira e ficar evidente que os testes não vai executar, que as estórias não
serão concluídas e prontas para serem entregues, ainda haverá tempo para
escolher as mais importantes e priorizá-las (JEFFRIES et al., 2001).
1
O método do big bang é o mais usado por empresas de software comercial. A idéia é manter o
máximo de segredo possível, e só liberar o software para aquisição quando cada pequena parte dele
estiver funcionando bem.
28
Podem ser criadas estórias menores, o que elimina a necessidade de decompô-las

em tarefas menores. Isto vai gerar mais trabalho para os usuários, que escrevem as
estórias. Uma alternativa é trabalhar com uma pilha única de tarefas; assim que um
desenvolvedor concluir uma tarefa ele pega a próxima tarefa da pilha. Esta
abordagem elimina um problema bastante comum: os desenvolvedores correm para
pegar as tarefas “melhores” e sobram as “piores”, que ninguém quer fazer (BECK;
FOWLER, 2001).
1.1.5 Teste antecipado
As rotinas de teste são construídas antes que qualquer código seja escrito. Os
critérios para os testes de aceitação são gerados e escritos pela área de negócios
assim que os requisitos, na forma de estórias, são documentados, os testes de
unidade são criados pelos os desenvolvedores logo antes da programação, e todo
programa gerado precisa passar por todos estes testes (JEFFRIES et al., 2001).
Esta abordagem vai permitir resolver vários problemas de uma só vez:
• Mudança de escopo – é fácil divagar e programar algo apenas porque pode vir a
ser necessário no futuro. Ao definir claramente o que o sistema precisa fazer, o
programador terá um foco maior ao fazer a programação;
• Acoplamento e coesão – se for muito difícil desenvolver uma rotina de teste, isto
pode ser um sinal de que há algum problema quanto à forma como o sistema foi
projetado, e não um problema com a rotina de teste propriamente dita. Programas
com baixo acoplamento e alta coesão são fáceis de testar;
• Confiança – é difícil confiar num desenvolvedor que escreve um programa que
não funciona. Ao escrever um código que funciona e que pode ser demonstrado
através de uma rotina automatizada de teste, o desenvolvedor consegue
conquistar a confiança do seu grupo com muito mais facilidade;
• Ritmo – é fácil o programador perder-se por horas quando está programando. Ao
desenvolver antes a rotina de teste, fica mais claro o que deve ser feito na
29
seqüência: desenvolver outra rotina de teste ou corrigir o problema encontrado.

Logo este se transforma numa rotina de trabalho: teste, programação, refactoring.
1.1.6 Refactoring
O refactoring implica na melhoria continua do código-fonte, sem alterar seu

comportamento. Com a refatoração, você descobre que o ponto de equilíbrio do
trabalho muda. Descobre que o projeto, em vez de acontecer todo no início, ocorre
continuamente durante o desenvolvimento. Aprende, com a construção do sistema,
a como melhorar o projeto. A interação resultante leva a um programa que
permanece bom à medida que o desenvolvimento continua. A experiência mostra
que o programa fonte requer mais refactoring à medida que o projeto evolui. Isto não
é surpresa, já que a qualidade do código, as funcionalidades e o escopo mudam ao
longo do tempo, por conta disso, à medida que novas funcionalidades vão sendo
construídas, o sistema precisa vez mais refactoring (FOWLER, 2005).
1.1.7 Programação em par
A programação em par é a prática mais popular da XP, quase todas as

implementações de XP começam com esta prática. Na programação em par o
código-fonte é escrito por duas pessoas trabalhando em conjunto num único
computador. Esta prática tem vantagens, principalmente nas situações em que a
programação apresenta uma complexidade maior (WILLIAMS; KESSLER, 2003):
• Um programador ajuda o outro a manter o foco na tarefa;

• Fazer brainstorm para criar melhores abordagens;
• Ajuda a clarear as idéias;
30
• Quando um dos programadores fica imobilizado por falta de alternativas o outro

pode ajudar assumindo o controle;
• Um ajuda o outro a não perder de vista os valores e as práticas da equipe;
• É uma forma de disseminar o conhecimento e transferir experiência;
• Permite que todo o código produzido seja dinamicamente revisado por pelo
menos outra pessoa, que também entende o contexto no qual o código foi
desenvolvimento.
1.1.8 Envolvimento dos clientes
Ao colocar as pessoas com as necessidades de negócio em contato direto com os

desenvolvedores facilita a compreensão dos requisitos, além de acelerar o feedback.
O usuário que participa da equipe pode dar um feedback rápido e ajudar a definir
prioridades (MANHÃES TELES, 2005).
1.2 Feature Driven Development
Criado no final da década 90 em Cingapura por um time liderado por Jeff De Luca é
uma simples compilação de práticas estabelecidas nos últimos 30 anos. Um de seus
maiores desenvolvedores, Peter Coad, definiu a idéia de Feature Definition e
Feature List. Renomados autores participaram da concepção das idéias do FDD,
entre eles: Tom De Marco, Tim Lister, Jerry Weinberg e Frederic Brooks. Em sua
essência o FDD é um processo ágil e adaptativo com as seguintes características
(ABRAHAMSSOM, 2002):
• Iterativo;
• Enfatiza a qualidade;
• Entrega resultados tangíveis e freqüentes;
31
• Provê relatórios de progresso precisos e significativos, requerendo pouca

sobrecarga de trabalho por parte dos programadores;
• É apreciado pelos clientes, gerentes e desenvolvedores;
O FDD destaca os seguintes valores: comunicação, redução da complexidade e a

qualidade. O FDD conta com a experiência e capacidade das pessoas para o
sucesso do projeto. A produtividade pessoal é muito importante, se a equipe for
composta por pessoas altamente capacitadas, o processo e a tecnologia serão
utilizados com sucesso. O FDD define seis papéis principais para o projeto mais
alguns adicionais de suporte. Os papéis definidos no FDD representam grupos de
responsabilidades que um profissional pode assumir no projeto. Dependendo da
complexidade do projeto e da capacitação do profissional, ele pode assumir
simultaneamente mais de um papel (PALMER; FELSING, 2002).
O FDD começa depois que a equipe já tem informações e conhecimentos suficientes

quanto ao negócio ou domínio do problema e quanto aos processos que precisam
ser automatizados. No FDD a primeira etapa é a criação de um modelo de classes e
objetos de negócio, desenvolvido em conjunto com pessoas especializadas no
domínio do problema. O próximo passo é desenvolver a lista de funcionalidades ou
features que o novo sistema deverá apresentar; este trabalho é elaborado com base
no conhecimento adquirido durante a modelagem e captura de requisitos funcionais
(PALMER; FELSING, 2002).
Na seqüência é esboçado um plano global do projeto e as responsabilidades são

divididas entre os membros da equipe. O projeto vai ser conduzido em iterações,
que podem ser executadas em paralelo ou em série. Cada grupo de
desenvolvedores trabalha numa iteração e aborda um pequeno conjunto de
funcionalidades, trabalhando no seu projeto técnico e na sua construção. Cada uma
deverá ser construída em no máximo duas semanas; se a estimativa for superior a
esta, ela deve ser decomposta em funcionalidades menores. O projeto é conduzido
dessa forma até que todas as funcionalidades sejam desenvolvidas (MARTINS,
2009). Veja a Figura 2.
32
Figura 2 - Feature Driven Development (Adaptado). Fonte: http://www.nebulon.com/, 2009.
O FDD consiste em cinco processos. O projeto começa com a modelagem das

classes do domínio do problema, depois segue com a tabulação das funcionalidades
que o sistema deverá disponibilizar e a seguir com o planejamento de como estas
funcionalidades serão implementadas. Os próximos dois processos são onde a
programação realmente acontece. O líder técnico seleciona um pequeno conjunto de
funcionalidades para desenvolver nos próximos dias, não mais que duas semanas,
identifica os donos das classes envolvidas e os convoca para compor a equipe para
a iteração. A equipe trabalha na modelagem dinâmica das funcionalidades e
escrevem as estruturas das classes, compostas pelas definições dos métodos e dos
atributos. Depois a equipe faz uma inspeção do projeto técnico, e os programadores
adicionam código fonte nas classes, fazem testes de unidade, integração e inspeção
de código. Quando os lideres técnicos estiverem satisfeitos com o trabalho
desenvolvido os programas gerados são liberados para compor a versão candidata
para o ambiente de produção. Os processos do FDD são descritos a seguir
(MARTINS, 2009):
1.2.1 Desenvolver um modelo geral
Neste processo o especialista no domínio do problema e a equipe de

desenvolvimento trabalham em conjunto e fazem uma análise inicial de alto nível
33
quanto ao escopo do sistema e o seu contexto. A equipe divide o domínio do

problema em áreas e faz vários walkthroughs em cada uma delas, cada vez
aumentando mais o nível de detalhe. À medida que o trabalho se desenvolve a
equipe vai construindo o modelo de classes e objetos de negócio. Depois todos os
modelos são combinados para formar o modelo final (LAURINDO, 2007).
1.2.2 Construir uma lista de funcionalidades
Com base no conhecimento adquirido na primeira etapa, o líder técnico decompõe

as funcionalidades do domínio e constrói uma lista de funcionalidades. Orientado
pelo especialista no negócio, ele as divide por área de negócio, cada área é
decomposta em atividades, que dão origem a grupos de funcionalidades. Cada
funcionalidade é definida como uma funcionalidade pequena e de valor para o
cliente e é expressa na forma <ação> <resultado> <objeto>. Um exemplo de
funcionalidade é "calcular o total de vendas". Documentos existentes de requisitos
são utilizados como referência para este trabalho, como Casos de Uso,
especificação funcional, dentre outros. Cada funcionalidade deverá pertencer a
somente um conjunto (atividade) e a somente uma área de negócio. As
funcionalidades são organizadas numa Feature Breakdown Structure (FBS) onde
são agrupadas em conjunto e divididas por área de negócio. Normalmente cada uma
corresponde a uma atividade particular de negócio (MARTINS, 2009).
1.2.3 Planejar por funcionalidade
No terceiro processo do FDD o gerente de projeto, o gerente de desenvolvimento e o

líder técnico, trabalhando em conjunto, planejam a seqüência de desenvolvimento
dos grupos de funcionalidades (atividade de negócio) e dos conjuntos de
funcionalidades (área de negócio) (FDD, 2009).
34
1.2.4 Projetar por funcionalidade
As funcionalidades são atribuídas aos lideres técnicos que são responsáveis pelo
seu desenvolvimento. O líder técnico seleciona as próximas funcionalidades para
desenvolvimento a partir da sua lista de prioridades, e compõe seus pacotes de
trabalho. Algumas delas podem ser desenvolvidas simultaneamente quando elas
estão baseadas no mesmo conjunto de classes (LAURINDO, 2007).
1.2.5 Construir por funcionalidade
Usando a especificação feita no projeto técnico, os donos das classes fazem a

programação. Depois o programa fonte passa pelo teste de unidade e inspeção de
código, mas nem todo código precisa necessariamente passar pela inspeção. Há
situações em que cenários simples se repetem em várias partes do programa,
nestes casos a inspeção de apenas uma amostragem pode ser suficiente para
localizar a maioria dos problemas. Finalmente as funcionalidades desenvolvidas são
integradas à versão final (MARTINS, 2009).
O FDD é definido ao redor de um conjunto central de práticas que embora não sejam
inovadoras, são utilizadas de forma inovadora: elas reforçam e complementam umas
as outras. A equipe pode implementar somente algumas das práticas, mas se não
considerar todas elas não obterá todos os benefícios previstos pelo FDD. As práticas
propostas são: Modelagem de Objetos do Domínio, Desenvolvimento por
funcionalidade, o código fonte de cada classe pertence a um programador, Equipes
por funcionalidades, inspeções, builds constantes, gerenciamento de configuração e
controle do progresso (LAURINDO, 2007).
Uma característica marcante do FDD é que este é um processo definido para fazer
repetidamente entregas constantes, tangíveis e funcionais. O FDD é um método
35
simples, objetivo e fácil de seguir, possui técnicas objetivas para lidar com os
problemas de desenvolvimento de software, técnicas claras para informar o
progresso e permitir que as decisões possam ser tomadas em tempo oportuno
(LAURINDO, 2007).
1.3 Microsoft Solutions Framework
O MSF 4.2 possui duas novas instâncias: MSF for Agile Software Development e
MSF for CMMI Process Improvement. Podemos afirmar que o MSF Agile é a soma
de posições equilibradas, pois defende um Software Development Life Cycle (SDLC)
mais curto com iterações de no máximo quatro semanas, contudo preserva a
importância dos papéis definidos previamente e abomina a linha "todo mundo pode
fazer tudo no projeto". Outro quesito de destaque nesta fusão são os testes unitários
e a preocupação com a cobertura de 100% do código fonte (MICROSOFT, 2009).
Veja a Figura 3.
Figura 3 – MSF – Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009.
36
Um tema muito forte dentro do MSF Agile é integração. Metodologias ágeis

necessitam que os "stakeholders" estejam presentes o tempo todo durante o projeto.
Para isso são constituídos cenários de tarefas de trabalho que englobam atividades
planejadas para um desenvolvedor. Estes cenários fazem parte de uma determinada
iteração do plano de iterações. Esta iteração agrupa os cenários de
desenvolvedores e os cenários de testes, que são efetuados em seguida ao
desenvolvimento. Desta forma controla-se a integração de um time com papéis
diversos dentro do projeto, usuário, desenvolvedor e analista de testes (CAMARA,
2007).
MSF Agile é um processo iterativo e incremental. Um processo iterativo é

geralmente definido como a técnica de desenvolvimento de software que a definição
dos requerimentos, o planejamento, a implementação e os testes ocorrem de forma
cíclica ao invés de seqüencial, resultando em produtos incrementais do conjunto do
software. Iterativo é o mesmo que repetível. Incremental é porque se repete sempre
aumentando seu resultado, ou seja, incrementando (RODRIGUES et al, 2009).
Quando você pensa iterativo e incremental, você organiza a "cultura" do seu projeto
de forma econômica, com foco absoluto no produto e com elementos de motivação.
Esta abordagem de trabalho também propicia o gerenciamento de risco, pois a
informação para a tomada de decisão acontece em períodos curtos (RODRIGUES et
al, 2009).
Podemos destacar três itens essenciais em um processo iterativo e incremental

(CAMARA, 2007):
• Teoria do controle: Pequenas iterações permitem você calibrar com mais

agilidade suas estimativas e reduzir a margem de erro. O retorno rápido das
informações de como está seu projeto incrementa a visibilidade e a
previsibilidade;
• Envolvimento do cliente / usuário: Os interessados no resultado do projeto podem
ter contato com as telas e funcionalidades rapidamente e continuamente. Desvios
são tratados com antecedência, pois você terá informações reais para a tomada
de decisão. Desta forma permite você utilizar a máxima: "o menor prejuízo é
sempre o primeiro";
37
• Aprendizado contínuo: O próprio projeto é uma rica lição a cada iteração. Você
percebe a evolução da curva de produtividade e acompanha a autonomia técnica
crescente dos colaboradores a cada dia dentro do projeto. Para o MSF, um
projeto precisa dos seguintes papéis, entendem-se papéis como
responsabilidades que devem ser assumidas por algum membro da equipe:
o Program Manager
o Product Manager
o User Experience
o Tester
o Developer
o Architect
1.3.1 Release Manager
O Modelo de Equipe da MSF tem como princípio fundamental a idéia de "Equipe de

Iguais" – Team of Peers, significando com isto que não há nenhuma hierarquia entre
os membros da equipe. Por exemplo, neste modelo, um gerente de projeto dá
suporte à equipe, a qual atua em consenso do que necessita ser feito para continuar
o projeto (CAMARA, 2007).
Cada membro da equipe é bem autônomo, e espera-se que saibam o que fazer e
planejam como vão fazer a entrega de sua parte do trabalho. Esta valorização do
poder de cada membro da equipe é um dos conceitos que a maioria dos gerentes
tradicionais de projeto precisa aprender ao aplicar o MSF (GARCIA, 1999). Veja a
Figura 4.
38
Figura 4 – MSF – Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009
A equipe é estruturada basicamente em sete áreas fundamentais para o sucesso do

projeto perante o cliente. Cada papel é auto-explanatório. O principal é entender que
cada papel advoga para um constituinte, isto é, as necessidades do cliente de uma
maneira ou de outra (GARCIA, 1999). Veja a Tabela 1.
Tabela 1 - Áreas fundamentais segundo o MSF

Objetivo para o sucesso perante o Sintoma típico quanto o Papel responsável
cliente objetivo não é atingido pela obtenção do
objetivo
Entrega dentro dos limites do projeto “O projeto atrasou e ficou acima Gerência de
do orçamento” Programa
Construir o que foi pedido “O que foi construído na verdade Desenvolvimento
não era o que queríamos”
Lançar a versão somente depois que “Esta coisa é imprevisível – Teste
problemas são identificados e continuamos descobrindo novos
corrigidos problemas”
Lançamento sem imprevistos e “Não conseguimos fazer com que Lançamento e
preparação para a transição para funcione em produção” Operações
operação em produção
Ampliar a eficiência e eficácia do “É simplesmente muito difícil de Experiência do
usuário final usar” Usuário
Satisfazer os clientes “Não atende nossas expectativas. Gerência de Produto
Não estamos contentes com o
resultado”
Arquitetar a solução para fácil “Tivemos que pagar muito para Arquitetura
manutenção e outras características adicionar funcionalidade mais
39
de alto nível tarde”

Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009.
É árduo afirmar quem foi o fundamentador do MSF, porém o grande patrocinador

sempre foi a própria Microsoft. Para não ficar em branco com nomes, Michael
Cusamano, Steve McConnell e Clementino Mendonça destacam-se entre muitos
outros como personagens da história do MSF (GARCIA, 1999).
1.4 SCRUM
As raízes do SCRUM estão num artigo que sumarizam as 10 melhores práticas em

empresas japonesas, escrito por Takeuchi e Nonuka, cujo título é "O jogo do
desenvolvimento de novos produtos" que foi publicado na Harvard Business Review
em janeiro de 1986. Este artigo introduziu o termo SCRUM, que se refere ao jogo de
Rugby, quando os jogadores se organizam em círculo para planejar a próxima
jogada. É uma forma de mostrar que o projeto deve ser conduzido em pequenos
ciclos, mas com uma visão de longo prazo, que é ganhar o jogo. Jeff Sutherland é
um dos criadores do SCRUM e era vice-presidente da Easel Corporation em 1994,
quando introduziu algumas das práticas do SCRUM, com base neste artigo. Ele
também foi influenciado por um relatório de projeto com produtividade acima da
média, na Borland Corporation, que dentre outras coisas introduziu a reunião diária
(MARTINS, 2009).
Segundo Schwaber (2004), SCRUM não é um processo previsível, ele não define o
que fazer em toda circunstância. Ele é usado em trabalhos complexos nos quais não
é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de
práticas que torna tudo visível. Isso permite aos praticantes do SCRUM saber
exatamente o que acontece ao longo do projeto e fazer os devidos ajustes para
manter o projeto se movendo ao longo do tempo, visando alcançar os seus objetivos
40
Logo, o SCRUM não vai dizer exatamente o que fazer, não irá resolver todos os
seus problemas, mas com certeza os problemas serão mais facilmente identificados.
Por ser um framework, irá servir como um guia de boas práticas para atingir o
sucesso. Entretanto, as decisões de quando e como usá-Io, quais táticas e
estratégias seguir para obter produtividade e realizar as entregas ficam por conta de
quem aplicar. O conhecimento das suas práticas permite a aplicação das mesmas
de forma variada e este é um dos aspectos positivos do SCRUM, a adaptabilidade
(SCHWABER, 2004).
Vale ressaltar que as práticas do SCRUM podem ser aplicadas em qualquer

contexto onde pessoas precisem trabalhar juntas para atingir um objetivo comum.
SCRUM é recomendado para projetos de outras áreas além de software
principalmente para projetos de pesquisa e inovação (CHAPIEWSKI, 2009).
1.4.1 Como funciona?
A Figura 5 ilustra o ciclo de desenvolvimento do SCRUM de forma simplificada.
Figura 5 – SCRUM, Fonte: http://www.sof4thouse.se/Uploades/Scrum_eng_webb.pdf, 2009.

41
O ciclo do SCRUM tem o seu progresso baseado em uma série de iterações bem
definidas, chamada Sprints, cada uma com duração de duas a quatro semanas,
chamada de Time-box. Antes de cada Sprint, realiza-se uma Reunião de
Planejamento - Sprint Planning Meeting em que o time de desenvolvedores tem
contato com o cliente - Product Owner para priorizar o trabalho que precisa ser feito,
selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. A próxima
fase é a Execução da Sprint (MOUNTAIN, 2009).
Durante a execução da Sprint, o time controla o andamento do desenvolvimento

realizando Reuniões Diárias Rápidas - Daily Meeting, não mais que 15 minutos de
duração, e observando o seu progresso usando um gráfico chamado Sprint
Burndown. Ao final de cada Sprint, é feita uma revisão no produto entregue para
verificar se tudo realmente foi implementado (PEREIRA et al, 2009).
Ao final da Sprint, deve-se realizar uma Reunião de Revisão - Sprint Review, em que
o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo
em seguida, realiza-se a Reunião de Retrospectiva - Sprint Retrospective, uma
reunião de lições aprendidas, com o objetivo de melhorar o processo/time e/ou
produto para a próxima Sprint (FIGUEIREDO, 2009).
SCRUM torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de

requisitos, sejam eles novos ou apenas requisitos modificados. No entanto para
aplicá-Io, é preciso entender antes os seus papéis, responsabilidades, conceitos e
artefatos das fases de seu ciclo (FIGUEIREDO, 2009).
1.4.2 Papéis e responsabilidades
Ele implementa uma estrutura iterativa e incremental através de três papéis

principais: o Product Owner, o SCRUM Team e o SCRUM Master como descrito
abaixo (ISOTTON NETO, 2008):
42
• Product Owner
o Define os requisitos do produto, decide a data de release e o que deve conter

nela;
o É responsável pelo Retorno Financeiro (ROI) do produto;
o Prioriza os requisitos de acordo com o seu valor de mercado;
o Pode mudar os requisitos e prioridades a cada Sprint;
o Aceita ou rejeita o resultado de cada Sprint.
• SCRUM Master
o Garante que o time esteja totalmente funcional e produtivo;

o Facilita a colaboração entre as funções e áreas e elimina os impedimentos do
time;
o Protege o time de interferências externas;
o Garante que o processo está sendo seguindo;
o Participando das reuniões diárias, revisão da Sprint e planejamento.
• SCRUM Team
o Multifuncional, entre 5-9 membros;

o Seleciona, entre os itens priorizados, os que irão ser executados durante a
Sprint;
o Tem todo o direito de realizar o que quiser dentro da Sprint para cumprir o
objetivo da iteração;
o Auto-organizado: organiza o time e o trabalho entre os membros de forma
participativa;
o Ao final da Sprint, realiza o demo do produto finalizado.
1.4.3 Artefatos, conceitos e fases
1.4.3.1 Product Backlog

43
Um dos conceitos mais importantes são o Backlog do produto (ou Product Backlog)
e o Backlog de Impedimentos - lmpediment Backlog, ambos considerados o coração
do SCRUM. O Product Backlog contém uma lista de itens priorizados que incluem
tudo o que precisa ser realizado, que possa ser associado com valor de negócio e
para a finalização do projeto, sejam requisitos funcionais ou não. É importante
ressaltar que cada item no Backlog do produto deve ter um valor de negócio
associado - Business Value, no qual podemos medir o retorno do projeto e priorizar
a realização dos itens. O Impediment Backlog contém todos os itens que impedem o
progresso do projeto e geralmente estão associados a riscos. Estes itens não
possuem uma priorização, mas estão geralmente associados a algum item de
Backlog do produto ou ás tarefas do item, exemplos: "instalar ambiente para os
desenvolvedores", "Instalação de banco de dados do projeto" e etc. O controle
desses itens é muito importante e o SCRUM Master é o grande responsável pela
liberação desses impedimentos, abrindo caminho para o time de desenvolvimento
executar a realização dos itens do Backlog do produto (SCHWABER, 2004).
Existem muitas formas para gerenciar o Product Backlog e o Impediment Backlog,

todas elas precisam que cada item seja identificado e estimado, em tempo ou
tamanho, e que a sua ordem de importância seja estabelecida pelo cliente. Com
esses atributos, é possível ter os itens em uma ordem de priorização (SCHWABER,
2004).
1.4.3.2 Planejamento da Sprint
A atividade que precede o início da Sprint chama-se Sprint Planning Meetinq -

reunião de planejamento da Sprint. Essa atividade é muita importante e precisa de
alguma preparação. Deve-se ter cuidado para que essa reunião não extrapole a
duração planejada e seu objetivo (PEREIRA et al, 2009).
É lógico que a equipe precisa de tempo para poder estimar com segurança, mas ela
deve ser sempre guiada pelo SCRUM Master para que seja produtiva e não disperse
e perca o foco (PEREIRA et al, 2009).
44
No planejamento da Sprint o Product Backlog deve estar pronto antes de cada

reunião. Mas o que significa isso? Que todos os requisitos têm que estar
perfeitamente definidos e que as estimativas iniciais devem estar corretas? Que
todas as prioridades estão finalizadas? (KNIBERG, 2006)
Não, precisamos apenas garantir:
• Que o Product Backlog exista e cada item esteja estimado;

• Deve existir apenas um Product Backlog e um Product Owner;
• Todos os itens devem ter uma nota em função de sua importância;
• Essa nota serve apenas para organizar os itens por importância;
• O Product Owner deve entender todos os itens do Product Backlog, normalmente
ele é o autor do mesmo, mas em alguns casos outras pessoas podem ter
colocado itens no Backlog;
• Ele não precisa saber como cada item deverá ser feito, mas precisa saber o
motivo do item estar lá;
• Apenas o Product Owner tem o poder de associar a nota de importância de cada
item do Product Backlog.
Estando preparados os itens acima, pode-se iniciar a reunião de planejamento. O

objetivo da reunião é priorizar os itens que serão executados na Sprint, além de dar
ao time informação suficiente para que o mesmo possa validar e estimar o esforço
em horas para cada item. Vale lembrar que esta reunião é muito crítica para o
sucesso do projeto e que uma reunião mal planejada pode afetar em muito o
andamento da Sprint e causar danos grandes ao prazo do projeto (SCHWABER,
2004).
Com o Product Backlog priorizado, o time seleciona os itens que acha possível de
executar durante a Sprint. As dúvidas do time são esclarecidas e ao final temos
então o Sprint Backlog, que são os itens do Backlog priorizados para a Sprint. Para
cada item, o time inicia o detalhamento de suas atividades, estimando em horas, a
duração de cada uma delas. Não é mandatário, mas é sugerido que cada tarefa não
ultrapasse a duração de 16h. Se for necessário, deve-se quebrar a tarefa até que
individualmente todas as tarefas estejam dentro do limite de 16h. Uma vez que todas
as tarefas foram estimadas, o time questiona se realmente consegue assumir o
45
compromisso de realizar tarefas dentro da Sprint e finalizar o item selecionado

(SCHWABER, 2004).
Uma vez decidido o item, o time passa para o próximo e esse processo continua até
que todos os itens do Sprint Backlog sejam validados. Nesse momento, não são
alocados os recursos para as tarefas; apenas se estabelece as estimativas em horas
para cada uma. Após a estimativa refinada, pode-se calcular o total de horas
necessário para realizar todas as tarefas. É importante deixar sempre uma folga, já
que mesmo detalhando a estimativa sempre podem aparecer surpresas (PEREIRA
et al, 2009).
Uma vez ajustados os valores e com o time se comprometendo com a execução das
tarefas, existe um ambiente completo para a produção do resultado final da Sprint. O
próximo passo é iniciar a execução da Sprint. É importante lembrar que a Sprint
possui um limite de horas disponível. Este limite é conhecido por LHS (Limite de
Horas da Sprint) que pode ser medido utilizando uma fórmula simples (PEREIRA et
al, 2009):
LHS= (R x H) x D
Onde:
R = Total de recursos do time
H = Total de horas disponíveis para cada recurso
D = Total de dias úteis da Sprint
Note que se você tiver o H variando para alguns recursos, é importante considerar
isso na fórmula. A relação de 1 homem/dia efetivo = 6 homens/hora efetiva é mais
real dependendo do tipo do projeto. Isso significa que se devem considerar apenas
seis horas efetivas de cada recurso das oito normalmente trabalhadas, apenas 75%
do tempo real do recurso é considerado produtivo para a Sprint. Esta sobra é
importante, pois fornece uma idéia mais realista da produtividade de cada recurso e
também garante uma margem de segurança para eventuais imprevistos. Com a
simulação a seguir, pode se entender melhor como calcular o LHS (KNIBERG,
2006).
46
Para uma Sprint com time-box padronizado em 5 dias e um time possui 5 recursos
em que 3 são de 8h, um de 6h e outro de 8h, mas apenas alocado por 50% de seu
tempo, temos o LHS diário considerando a relação acima sugerida de (MOUNTAIN,
2009):
8hx75% = 6h (3)
6hx75% = 4,5h (1)
8hx50% = 4h x 75% =3h (1)
Dias úteis da Sprint = 5
logo,
((3x6) + (4,5) + (3)) = 31,50 (dia)
LHS= 5 x 31,50 = 157,50 h
Esses são cálculos bem simples e você vai precisar usá-los apenas antes de cada
planejamento da Sprint, pois o LHS é que vai indicar se você está alocando as horas
corretas para a equipe (SCHWABER, 2004).
É importante salientar que uma vez estabelecido a duração da Sprint não deve
alterar sua data final, pois todo o projeto é guiado por essa duração. Logo, adiantar
ou atrasar não é interessante para ninguém. Outro motivo importante para se manter
o padrão de duração da Sprint é a relação de produtividade do time dentro da Sprint.
A métrica de esforço (velocity) para o grupo de itens que foram priorizados na Sprint
é que vai dizer se conseguimos medir para um mesmo time-box o total de itens que
foram finalizados por Sprint, e isso comparado a um histórico. Esta métrica é muito
importante, e apenas será real se as Sprints forem de tamanhos iguais
(SCHWABER, 2004)
47
1.4.3.3 Execução e controle da Sprint
Durante a Sprint, o time, de forma organizada, controla como as tarefas devem ser
executadas. Durante a Sprint não deve existir interferência externa, esse é um dos
principais papéis do SCRUM Master, blindar o time de qualquer desvio do objetivo
traçado. O acompanhamento do progresso é feito realizando reuniões diárias,
chamada de daily meeting. Essas reuniões devem ser rápidas, não mais que 15
minutos, e objetivas. Todos participam, o SCRUM Master e o time. Visitantes são
bem-vindos, mas devem ser apenas ouvintes, pois o daily meeting resume-se ao
time. No daily meeting, a equipe trabalha apenas três perguntas, que são
respondidas por cada membro (PEREIRA et al, 2007):
• O que foi feito desde ontem?

• O que você planeja fazer para amanhã?
• Você tem algum impedimento?
Todo e qualquer problema encontrado durante o daily meeting deve ser tratado em
uma outra reunião, apenas com os envolvidos. Durante a execução da Sprint, a
alocação de recursos para cada tarefa é dirigida pelo próprio time, cada membro da
equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e
dependência entre elas. Um fator importante de sucesso para o time com o uso do
SCRUM é o controle da disciplina. O time é considerado auto-gerenciável e deve
responder como tal. Para isso, todos os membros do time devem reportar as horas
utilizadas em tarefas para que o valor de horas restantes seja calculado
corretamente e o time possa verificar o seu progresso. Para esse acompanhamento,
o time usa um gráfico chamado de Sprint Burndown, ele exibe o progresso diário do
time em função do total de horas estabelecido pela soma de horas das tarefas dos
itens do Product Backlog selecionados. (PEREIRA et al, 2007), O Gráfico 1 ilustra
um exemplo:
48
Gráfico 1 – Sprint Burndown (adaptado), Kniberg, 2006, p.51
O Sprint Burndown é um gráfico muito simples que indica o consumo de horas

diárias. O eixo X indica a escala de horas totalizando o valor de horas estimado para
a Sprint, e o eixo Y os dias que representam o tamanho da Sprint de acordo com seu
time-box. Mesmo se existir um comportamento linear para os dias, a soma de horas
pode oscilar para cima. Este comportamento indica que algumas estimativas foram
erradas ou novas tarefas foram adicionadas, de uma forma ou de outra o total de
horas naquele momento aumentou. Estas oscilações podem ser perigosas e
precisam ser acompanhadas diariamente. Os Gráficos 2 e 3 ilustram algumas
dessas oscilações (ANDERSON, 2003).
49
O Gráfico 2 indica que a Sprint irá acabar depois da data final. Logo, é preciso rever
as estimativas, pois muitos imprevistos não apareceram durante a preparação da
Sprint, e a indicação é que não será possível terminar o que foi previsto. Talvez seja
necessário rever os itens do Product Backlog remanescentes e eliminar aqueles com
grau de importância menor (ANDERSON, 2003).
50
O Gráfico 3 ilustra uma situação inversa. Nesse caso, é preciso adicionar novos
itens do Product Backlog, pois o gráfico indica que a Sprint será concluída antes do
esperado.
Em ambos os casos, as decisões sempre devem ser tomadas junto com o Product
Owner, nunca apenas pelo time. O time também possui um "quadro de trabalho" no
qual organiza as atividades, dos itens de Backlog da Sprint, separando-as em
basicamente quatro estados: Para fazer, Em andamento (inclui o nome do
responsável por executar a tarefa), Para Verificar e Concluído. Esse "quadro" é
muito produtivo, pois basta olhar para ele para realizar a leitura do progresso da
Sprint, inclusive nele pode-se indicar se existe algum impedimento para que as
atividades sejam executadas conforme planejado (ANDERSON, 2003). Veja
sugestão na Figura 6:
51
Figura 6 – Quadro de tarefas (adaptado), Kniberg, 2006, p.49
1.4.3.4Final da Sprint
Ao final de cada Sprint, acontece a reunião de revisão. Nela, o time entrega o

produto testado e revisado realizando uma demonstração prática. Este é o momento
do Product Owner inspecionar o produto final e verificar se o mesmo está como foi
pensando. Após esta reunião, a reunião de retrospectiva é realizada, podendo ser
chamada também de "lições aprendidas". Nesta, o time levanta tudo de bom e ruim
que ocorreu e procura estabelecer pontos de melhoria. Estas ações são levadas
para a próxima Sprint melhorando o processo e/ou produto. O ciclo do SCRUM é
repetido até que todos os itens do Product Backlog tenham sido finalizados,
atendidos e/ou o produto final tenha sido aceito pelo cliente (PEREIRA et al, 2007).
52
2. PMI® e PMBOK®
2.1 O gerenciamento de projeto
As pessoas têm planejado e gerenciado projetos desde o início dos tempos. Toda
vez que uma civilização criou suas raízes houve projetos a serem gerenciados:
prédios a construir, estradas a pavimentar e leis a serem escritas. Mesmo sem as
ferramentas, técnicas e metodologias avançadas de que dispomos hoje, as pessoas
criaram linhas de tempo, alocaram materiais e recursos e avaliaram os riscos
envolvidos em seus projetos. Com o passar do tempo, as pessoas perceberam que
as técnicas para controle de custo, desenvolvimento da programação, procura e
compra de recurso e gerenciamento de riscos poderia ser aplicado a uma variedade
de projetos, seja erguendo pontes, realizando colheitas sazonais ou decidindo como
se governar. Estas idéias foram precursoras do estabelecimento de técnicas de
gerenciamento que hoje conhecemos como "Gerenciamento de Projetos Moderno”.
(PMI® -SP, 2009).
As organizações modernas estão descobrindo que a utilização do gerenciamento de

projetos traz muitas vantagens. Clientes esclarecidos exigem cada vez mais
produtos melhores e serviços mais rápidos. As pressões para acompanhar a
velocidade do mercado demandam maior eficiência. Gerenciar projetos de forma
profissional encontrou seu lugar na arena empresarial competitiva e global de hoje.
(PMI® -SP, 2009).
53
2.2 História
O Project Management Institute (PMI® ) foi fundado em 1969 por cinco voluntários. A
Comunidade da Pensilvânia emitiu as Cláusulas de Incorporação do PMI® ,
oficializando sua fundação. Durante aquele mesmo ano, o primeiro PMI® Seminars &
Symposium aconteceu em Atlanta, Geórgia EUA, com a participação de 83 pessoas.
Nos anos setenta, a primeira edição do Project Management Quarterly (PMQ) foi
publicada, e posteriormente renomeada para Project Management Journal (PMJ). O
primeiro Capítulo do PMI® foi oficializado e o primeiro Programa de Prêmios
Profissionais estabelecido. Ao final da década, o PMI® somava mais de 2.000
associados no mundo (PMI® -SP 2009).
Durante os anos oitenta, o número de associados do PMI® continuou crescendo,

bem como os programas e serviços oferecidos pela associação. Um Código de Ética
foi adotado para a profissão e o primeiro Project Management Professional (PMP®)
foi credenciado. O primeiro modelo padrão de Gerenciamento de Projetos foi
publicado: o Special Report on Ethics Standards and Accreditation (PMQ). As
publicações do PMI® sobre produtos e serviços cresceram rapidamente durante esta
década. O primeiro livro do PMI® foi co-publicado e nasceu a PMNetwork®, revista
mensal do PMI® . Em função deste crescimento foi estabelecida a Divisão de
Publicações do PMI® na Carolina do Norte, EUA (PMI® -SP 2009).
Em 1990, o PMI® somava mais de 8.500 associados e em 1993 este número crescia
cerca de 20% ao ano. Durante os anos noventa foram formados os Grupos de
Interesses Específicos, os Colleges e o Seminars USA, uma série de programas
educacionais em Gerenciamento de Projeto. O PMI® também marcou presença na
rede mundial da Internet e publicou o "A Guide to the Project Management Body of
Knowledge (PMBOK® Guide)", um guia englobando todas as áreas do
conhecimento que regem as regras do gerenciamento de projetos. O PMI Today® ,
boletim informativo mensal do PMI® , foi impresso pela primeira vez e o Programa de
54
Desenvolvimento Profissional foi estabelecido para que os profissionais

credenciados como PMP mantenham sua certificação.
No inicio do século 21, o PMI® tinha mais de 50.000 associados, mais de 10.000
Profissionais de Gerenciamento de Projeto (PMP) credenciados e mais de 270.000
cópias do guia PMBOK® estavam em circulação (PMI® -SP 2009).
2.3 Hoje
Atualmente o PMI® conta com mais de 250.000 associados em 170 países. Os

associados do PMI® são indivíduos praticando e estudando o Gerenciamento de
Projeto nas mais diversas áreas, como aeroespacial, automobilística, administração,
construção, engenharia, serviços financeiros, tecnologia da informação, farmacêutica
e telecomunicações (PMI® -SP, 2009).
Com o passar do tempo, o PMI® se tornou, e continua sendo, a principal associação

profissional em Gerenciamento de Projetos. Os associados e interessados em
Gerenciamento de Projetos têm à sua disposição uma extensa relação de produtos e
serviços oferecidos pelo PMI® (PMI® -SP, 2009).
O PMI® ocupa uma posição de liderança global no desenvolvimento de padrões

para a prática da profissão de Gerenciamento de Projetos em todo o mundo. O
principal documento padrão do PMI® , "A Guide to the Project Management Body of
Knowledge", é um padrão globalmente reconhecido para o Gerenciamento de
Projetos nos mercados de hoje. O PMBOK® Guide é aprovado como um Padrão
Nacional Americano (ANS) pelo Instituto de Padrões Nacional Americano (ANSI). O
PMI® está compromissado com a expansão e melhoria contínua do guia PMBOK® ,
assim como com o desenvolvimento de padrões adicionais (NETO; BOCOLI, 2003).
Além do guia PMBOK® , outros padrões foram desenvolvidos, estando

disponibilizados aos associados (PMI® -SP, 2009):
55
• Project Manager Competency Development Framework - Second Edition

(PMCDF)
• Organizational Project Management Maturity Model (OPM3®)
• Practice Standard for Earned Value Management (EVM)
• Practice Standard for Work Breakdown Structures - Second Edition (WBS)
• Practice Standard for Scheduling
• Practice Standard for Project Configuration Management
• The Standard for Program Management
• The Standard for Portfolio Management
Também foram desenvolvidas extensões para áreas específicas do guia PMBOK® ,

tais como:
• Governo
• Construção
E vários outros padrões estão sendo construídos para possibilitar o aumento do

conhecimento em gerenciamento de projetos.
2.4 PMBOK®
O Project Management Body Of Knowledge ou simplesmente guia PMBOK® é o

principal documento de referência do PMI® , embora não seja o único. Como o
próprio nome em português diz, ele é “Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos”. Está atualmente na quarta edição, lançada em 2008
(CAMPOMORI; TEIXEIRA, 2009).
Como ele mesmo descreve o seu objetivo é:
®
“O principal objetivo do Guia PMBOK é identificar o subconjunto do
Conjunto de conhecimentos em gerenciamento de projetos que é
amplamente reconhecido como boa prática. “Identificar” significa fornecer
uma visão geral, e não uma descrição completa. “Amplamente reconhecido”
significa que o conhecimento e as práticas descritas são aplicáveis à
56
maioria dos projetos na maior parte do tempo, e que existe um consenso

geral em relação ao seu valor e sua utilidade. “Boa prática” significa que
existe acordo geral de que a aplicação correta dessas habilidades,
ferramentas e técnicas podem aumentar as chances de sucesso em uma
ampla série de projetos diferentes. Uma boa prática não significa que o
conhecimento descrito deverá ser sempre aplicado uniformemente em todos
os projetos; a equipe de gerenciamento de projetos é responsável por
®
determinar o que é adequado para um projeto específico (PMBOK , 2008,
p. 9).
No guia PMBOK® encontram-se muitas definições e práticas que guiam a gerência

de projetos em geral. Algumas destas definições são descritas abaixo.
2.5 Projeto
Projeto é descrito pelo guia PMBOK® (PMBOK® , 2008) como “um esforço
temporário empreendido para criar um produto, serviço ou resultado exclusivo”.
Quando diz temporário, significa que o projeto deve ter um inicio e fim definidos.
Basicamente quando os objetivos do mesmo são alcançados chegasse ao fim, logo
para isso é importante ter bem claro quais os objetivos do projeto. Quando se fala
em temporário pensa-se instintivamente em um curto espaço de tempo, porém
projetos podem levar dias, meses ou até anos, no entanto precisa ter uma data de
fim já que um projeto não é eterno. O produto gerado pelo projeto até pode ter vida
“eterna” e/ou indeterminada, mas não o projeto.
Quando diz produto, serviço ou resultado exclusivo significa que as entregas são
únicas, pois há elementos que os tornam únicos, sejam a data, as pessoas que
estão envolvidas, os recursos. O guia exemplifica através do exemplo da construção
de prédios. Cada prédio é diferente um do outro, pois possuem diferentes
proprietários, locais diferentes, construtoras diferentes. Embora haja elementos que
se repetem, ainda assim cada prédio possui sua singularidade.
2.6 Gerenciamento de projeto

57
O guia define a atividade de gerenciamento de projeto como: “a aplicação de

conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de
atender aos seus requisitos” (PMBOK® , 2008, p. 11).
O papel do Gerente de Projetos é responsável pelo andamento do projeto e por

gerenciar as atividades necessárias para o atendimento dos objetivos do mesmo.
Para isso ele precisa planejar, controlar e executar as atividades do mesmo. O termo
Stakeholders descreve todas as partes envolvidas ou interessadas no projeto,
inclusive o próprio Gerente de Projeto. Dentre os interessados, um dos mais
importantes é o Sponsor, ou patrocinador do projeto. É a pessoa que financia e/ou
defende o projeto dentro da organização. Outros exemplos de partes envolvidas:
fornecedores, sociedade, a equipe do projeto, cliente, usuários finais, dentre outros,
conforme o projeto (TAVARES, 2008).
2.7 Grupos de processos
O guia PMBOK® (2008) possui 42 processos onde cada um recebe Entradas que
são utilizadas por Ferramentas e/ou Técnicas que geram Saídas, conforme ilustrado
na Figura 7.
Segundo o PMBOK® processo é: “um conjunto de ações e atividades inter-

relacionadas realizadas para obter um conjunto pré-especificado de produtos,
resultados ou serviços” (PMBOK® , 2008, p. 38).
58
®
Figura 7 - Formato de Processo. Fonte: PMBOK , 2008, p. 19.
Os processos segundo o guia ainda são distribuídos em cinco grupos que se

integram entre si, conforme Figura 8.
®
Figura 8 - Grupos de Processos. Fonte: PMBOK , 2008, p. 19.
“Estes grupos de processos não representam necessariamente uma fase do projeto,

sendo que dependendo do tipo de projeto e sua organização os processos de um
grupo de processo podem ser repetidos por fases do projeto” (PMBOK® , 2008, p.
41).
59
2.8 Áreas de conhecimento
O guia também organiza os 42 processos em nove áreas de conhecimento,

conforme listagem abaixo e Tabela 2:
• Gerenciamento de Integração do Projeto;

• Gerenciamento do Escopo do Projeto;
• Gerenciamento de Tempo do Projeto;
• Gerenciamento de Custos do Projeto;
• Gerenciamento da Qualidade do Projeto;
• Gerenciamento de Recursos Humanos do Projeto;
• Gerenciamento das Comunicações do Projeto;
• Gerenciamento de Riscos do Projeto;
• Gerenciamento de Aquisições do Projeto.
Tabela 2 - Áreas do conhecimento

Área do conhecimento Objetivo
Integração Assegurar que todos os elementos do projeto sejam

adequadamente coordenados
Escopo Assegurar que todo o trabalho requerido – e somente

aquele requerido – esteja incluído no projeto, para
concluí-lo de maneira bem sucedida
Tempo Assegurar a conclusão do projeto no prazo previsto
Custos Assegurar que o projeto seja concluído dentro do

orçamento previsto
Qualidade Assegurar que os produtos ou serviços do projeto estejam

em conformidade com o solicitado pelo cliente, ou
contratante
Recursos Humanos Fazer uso mais efetivo do pessoal envolvido com o projeto
Comunicações Assegurar que as informações do projeto sejam

adequadamente obtidas e transmitidas
Riscos Assegurar um tratamento seguro ao risco do projeto,

cuidando de sua identificação, análise e resposta
60
Aquisições Adquirir bens e serviços de fora da organização promotora

®
Fonte: PMBOK , 2008, p. 20.
2.9 Processos nos grupos e nas áreas de conhecimento
A Tabela 3 exibe o mapeamento dos 42 processos de gerenciamento de projetos

nos cinco grupos de processos e nas nove áreas de conhecimento em
gerenciamento de projetos.
Tabela 3 - Mapeamento dos processos nos grupos de processos e áreas de

conhecimento.
Grupos de Processos
Áreas de
conhecimento Iniciação Planejamento Execução Controle Encerramento
Integração Desenvolver Desenvolver o plano de Dirigir e Monitorar e controlar Encerrar projeto ou

Termo de gerenciamento Gerenciar a trabalhos do projeto fase
Abertura Execução do
Projeto Desenvolver controle de
mudanças integrado
Escopo Obter requisitos Controlar escopo

Definir escopo
Criar WBS
Tempo Definir atividades Controlar cronograma

Sequenciar atividades
Estimar recursos por
atividades
Estimar duração de
atividades
Desenvolver cronograma
Custos Estimar custos Controlar custos

Determinar orçamento
Qualidade Planejar qualidade Desenvolver Executar controle de

garantia da qualidade
Qualidade
Recursos Desenvolver plano de Contratar time

Humanos recursos humanos do projeto
Desenvolver
time do projeto
Gerenciar time
do projeto
61
Comunicação Identificar partes Planejar comunicações Distribuir Reportar performance

interessadas informações
Gerenciar
expectativas de
partes
interessadas
Riscos Planejar gerenciamento Monitorar e controlar riscos

de riscos
Identificar riscos
Preparar analise
qualitativa de riscos
Preparar analise
quantitativa de riscos
Planejar respostas para
riscos
Aquisições Planejar aquisições Conduzir Administrar aquisições Encerrar contrato

aquisições
®
Fonte: PMBOK , 2008, p. 21-22
Ao olhar para esta tabela, é perceptível o forte foco do guia em planejamento, já que
boa parte, 20 dos processos estão concentrados no grupo de planejamento.
62
3. DIFERENÇAS, SIMILARIDADES E PROPOSTAS DE

COMPATIBILIZAÇÃO
3.1 Diferenças e similaridades
O PMBOK® tem foco no planejamento e muita disciplina no processo, partindo do

princípio de que a aplicação de controle possibilita alcançar o objetivo planejado
dentro de limites preestabelecidos de tempo, custo e escopo. Muito deste formalismo
provém de necessidades inerentes a grandes projetos ou a restrições severas de
confiabilidade, como ocorre em sistemas relacionados a atividades que apresentam
risco de vida. Para projetos desta natureza, o formalismo da abordagem tradicional
demonstra-se ainda adequado. Para a maioria dos projetos, porém, o gerenciamento
tradicional acaba acrescentando somente custo e complexidade, enquanto fornece
um falso senso de segurança, uma vez que o gerente está sempre ocupado –
exaustivamente planejando, medindo e controlando. Muitas companhias
desperdiçaram cifras enormes com planejamento prematuro, sem desenvolver de
forma rápida e iterativa e sem envolver o cliente, fatores que são hoje considerados
fundamentais para o sucesso de um projeto de software.
Como ele foi concebido para ser um guia genérico, ele desconsidera as
peculiaridades da execução de produtos e serviços de software. Sua implantação
prática na área de software exige um investimento importante na concepção de um
processo adequado, que venha realmente alavancar o negócio e facilitar a vida dos
envolvidos, sem requerer trabalho adicional somente para atender aos seus
requisitos.
63
Em contrapartida, as metodologias ágeis vêm-se consolidando e atraindo novos

adeptos. Elas se apresentam como uma coleção de boas práticas, especialmente
adequadas para projetos de natureza exploratória desenvolvidos por equipes
pequenas. Na sua essência, o ciclo de vida ágil é semelhante a qualquer outra
abordagem de desenvolvimento: descobrir o que o cliente quer, certificar-se
exatamente sobre o que ele quer, calcular o esforço, construir a solução e entregá-la
ao cliente. O que muda na abordagem ágil, porém, é que o ciclo fica reduzido em
algumas semanas para cada componente funcional desenvolvido, tornando-se muito
mais rápido e sendo executado diversas vezes.
No gerenciamento tradicional de projetos, que parte do princípio de que o

planejamento direciona os resultados e que entregar o planejado é sinônimo de
sucesso em um projeto, a abordagem ágil considera que os resultados devem
direcionar o planejamento e o sucesso advém de entregar o resultado desejado, não
necessariamente o resultado planejado. A grande diferença entre estas duas
abordagens está na atitude em relação às mudanças no planejamento: a abordagem
ágil considera necessário incentivar a mudança, e não desencorajá-la por meio da
aplicação de procedimentos que restringem e diminuem a criatividade. A abordagem
ágil esforça-se para reduzir o custo de mudança ao longo do processo de
desenvolvimento de software (NESMA, 2005).
Cautelas importantes ao uso da abordagem ágil: a falta de documentação e a forma

superficial com a qual questões gerenciais e organizacionais são tratadas – duas
questões alarmantes do ponto de vista de um gerente de projetos. Como a
abordagem ágil transmite muita confiança na comunicação oral, a documentação
muitas vezes é relegada a segundo plano em prol do conhecimento implícito, tácito.
É necessário buscar um ponto de equilíbrio, de forma a não gerar documentação

além do necessário. Como a abordagem ágil não impõe uma estrutura de gerência
no estilo “comando-e-controle”, ela não enfatiza o papel do gerente, mas destaca a
necessidade de líderes para resolver os problemas e necessidades de clientes. Para
a equipe, é preferível seguir um líder a ser limitada por um gerente. A abordagem
ágil introduz o papel de um orientador, que facilita a comunicação e direciona a
equipe. Ao conduzir o projeto, ele verifica se os valores e práticas estão sendo
adotados, se não existe conflito técnico ou pessoal na equipe, se há escassez ou
64
excesso de recursos. Além de identificar as expectativas e requisitos do cliente,

avaliar custos, benefícios e riscos necessários para atender aos requisitos, o
planejamento deve também enfocar e entender o contexto organizacional no qual o
projeto está sendo desenvolvido, incluindo cultura, política e diretrizes financeiras.
As atividades fundamentais de planejamento são necessárias, porém um plano de

projeto muito detalhado é, geralmente, inadequado. Boehm explica que tanto a
abordagem ágil quanto a dirigida por planejamento possuem aspectos positivos e
negativos e também compara as duas em relação a uma série de fatores e discute
formas de aproximá-las – usando o planejamento para aperfeiçoar métodos ágeis e
a agilidade para dar maior eficiência aos métodos dirigidos pelo planejamento – e
propõe métodos híbridos, que podem considerar os riscos do projeto como fator de
ajuste na busca do ponto de equilíbrio entre elas (COCOMOII, 2009).
O essencial para contornar as diferenças está em considerar, na escolha da

abordagem, as características do projeto a ser desenvolvido, buscando aplicar a
ferramenta correta para o trabalho a ser realizado. A dinâmica requerida em projetos
de natureza exploratória, e que primam pela inovação, inviabiliza o uso da
abordagem tradicional, pois o risco de alterar um produto depois da conclusão de
uma fase de seu ciclo de vida é bastante alto. Por outro lado, a aplicação da
abordagem ágil para planejamento estratégico ou priorização de projetos não será
eficiente, uma vez que uma das premissas principais da abordagem ágil é entregar
incrementos de funcionalidade específicos em curto espaço de tempo. A abordagem
ágil é mais adequada para projetos definidos em alto nível, com objetivos claros e
foco forte nos valores empresariais – principalmente custos e prazos, necessitando
de grande participação do cliente durante todo o processo. Também é adequada
para o detalhamento do trabalho tático necessário para completar um projeto, bem
como para mudanças mínimas requeridas na manutenção de sistemas
É importante destacar que a abordagem ágil não é estritamente uma metodologia,

mas uma visão e um conjunto de atitudes, valores e princípios. Há processo, mas
não no senso rigoroso de um processo baseado em papel ou uma metodologia
centrada em controle. A comparação entre as duas parece ser um pouco vaga
devido à abordagem ágil enfatizar menos os processos e mais os seus valores e
práticas. Ela está sendo refinada e amadurecida a partir de observações sobre o uso
65
de práticas ágeis no planejamento e acompanhamento de projetos de software. O

objetivo principal da abordagem ágil é simplificar o processo de desenvolvimento,
minimizando e dinamizando tarefas e artefatos que são importantes no processo,
além do software funcionando. Na realidade, independentemente das metodologias
ágeis, outras tendências em gerenciamento de projetos já indicavam certa
convergência entre a comunidade de gerência e a comunidade técnica em relação à
agilidade. A seguir diferenças marcantes em relação às práticas do PMBOK® ,
destacadas na Tabela 4.
Tabela 4 - Principais diferenças e similaridades entre as metodologias ágeis e

PMBOK®
PMBOK Metodologias Ágeis
São adaptativas: O desenvolvimento também São adaptativas: Partem do princípio de que o
ocorre de forma iterativa e evolutiva, com ondas conhecimento sobre o problema aumenta à
sucessivas. A principal diferença é que cada medida que o sistema vai sendo desenvolvido,
iteração corresponde usualmente a uma fase do levando a uma busca constante por melhores
projeto, o que normalmente não é de curta soluções. O desenvolvimento ocorre de forma
duração. Pode levar mais do que 4 semanas. iterativa e evolutiva, com iterações tão curtas
quanto possíveis (de 2 a 4 semanas). Ao final de
cada iteração, obtém-se uma versão com a
implementação de um novo subconjunto de
funcionalidades, pronta para ser colocada em
produção.
São orientadas a processos e pessoas: Partem São orientadas a pessoas: Para melhor
do princípio de que processos bem definidos gerenciar projetos de software, pessoas devem
devem ser impostos e executados, para garantir ser tratadas como indivíduos e não como
a qualidade do produto resultante. O talento das recursos, pois cada pessoa apresenta um ritmo
pessoas é refletido nas estimativas, é valorizado de trabalho único e completamente diferente,
ainda na opinião dos especialistas e é que é fruto da sua vivência pessoal. Os
considerado quando se pondera o cronograma membros da equipe escolhem as tarefas que
com nivelamento de recursos. Ainda o talento do irão desenvolver durante a iteração seguinte,
gerente do projeto é estimulado nos dois além de estimarem o tempo a ser gasto com
aspectos: gerente/chefe e líder, motivador, elas, o que aumenta a motivação, o
coach. comprometimento e a produtividade da equipe.
São rígidas: pressupõem que é possível São flexíveis e iterativas: adaptam-se
especificar de antemão todos os requisitos do constantemente ao conjunto de requisitos mais
software a ser desenvolvido, dificultando – e atual: a cada iteração, usuários, clientes e
muitas vezes impedindo – realizar alterações e desenvolvedores decidem sobre quais
comprometendo a evolução natural da solução. características devem ser adicionadas,
Estão mais voltadas para a obtenção do software modificadas e até retiradas do sistema. Além de
previamente especificado do que para o sucesso ser desenvolvido da forma mais iterativa
do projeto ou negócio para o qual o software foi possível, é possível escolher os pontos mais
apontado como solução. Enfatiza de fato o críticos ou que mais agregam valor ao sistema
planejamento prévio da solução global. Porém para serem desenvolvidos em primeiro lugar.
uma alternativa, caso não se tenha condições de Estão mais voltadas para o bem do negócio: seu
especificar o todo é trabalhar por ondas: caráter adaptativo aumenta as chances de
componentes de planejamento (pacotes não oferecer um melhor resultado ao projeto e ao
detalhados a princípio que são refinados ao negócio. Pontos fracos: Risco de
longo do projeto). Nunca as mudanças são desorganização, pouca documentação e alta
impedidas, apenas devem ser aprovadas no dependência do cliente/usuário, o que muitas
controle de mudança, que dependendo de como vezes não é viável
for implementado pode ser aprovado pelo próprio
66
Gerente de projetos para pequenos impactos.

Mas é claro que ter um controle de mudanças
gera alguma burocracia e atraso.
São burocráticas: geram muita sobrecarga no Simplicidade: partem do princípio de que é
desenvolvimento a ser realizado, preferível fazer algo simples de imediato e pagar
comprometendo a velocidade de um pouco mais para alterá-lo depois, se
desenvolvimento e, muitas vezes, o sucesso do necessário, do que fazer algo complicado de
projeto. imediato e acabar não utilizando depois.
Fonte: COCOMOII, 2009
3.2 Propostas de compatibilização
Uma proposta de compatibilização pode vir de uma série quatro artigos intitulados
“Relating PMBOK® Practices to Agile Practices” escritos por Michele Sliger (2006),
ela é certificada PMP e entende a dificuldade que é percorrer entre as melhores
práticas do PMBOK® e a abordagem ágil, nos artigos, ela descreve as similaridades
entre PMBOK® e os métodos ágeis, não SCRUM especificamente, mas as
abordagens de um modo geral. Ela discute com muita propriedade a maneira de
como trabalhar com PMBOK® e Metodologias Ágeis. Segundo ela, apesar das
diferenças de filosofias entre as duas, muitas das práticas do PMBOK® são
compatíveis com as práticas ágeis. Nos artigos, Sliger (2006) trafega com muita
desenvoltura pelos cinco grupos de processos do guia PMBOK® , com uma visão
não apenas didática, mas ao que parece de quem tem experiência prática sobre o
que está descrevendo. Ela diz que para cada uma das áreas do PMBOK® , suas
práticas têm práticas relativas nas Metodologias Ágeis, porém a forma de executar é
diferente. Michele escreve que muitos autores e profissionais do PMI® declaram que
seu modelo é um guia de melhores práticas e que cada organização deve usar os
seus próprios critérios no uso destas práticas. De acordo com ela, por muito tempo o
PMBOK® tem sido associado ao modelo em cascata, quando não é verdade uma
vez que ele é perfeitamente aplicável com um modelo iterativo.
No planejamento o principal processo é o desenvolvimento do plano do projeto,

definindo como o projeto será executado e controlado, onde contém os planos para
cada uma das áreas. Já nas Metodologias Ágeis o plano é feito e revisitado
continuamente, com um nível de detalhe o suficiente para a realidade daquele
instante, conforme os releases e iterações. Da mesma forma o controle integrado de
67
mudança é natural no dia-a-dia da equipe, e ocorre através das priorizações feitas

pelo cliente no backlog, e durante as reuniões de planejamento e revisão de iteração
e releases.
Considerada uma das áreas de conhecimento mais importantes do PMBOK® e por

isso, o gerenciamento do escopo do projeto recebe grande atenção. Nos métodos
ágeis também é de extrema importância, porém a filosofia é totalmente diferente.
Enquanto o PMBOK® procura blindar o escopo contra mudanças, a abordagem ágil
aceita a mudança. Uma abordagem interessante colocada por Sliger (2006) é a
forma de criar a WBS. Ao invés de conter todo o trabalho para o projeto como
normalmente é feito no PMBOK® , no modelo ágil a WBS pode ser feita no início de
cada release. O primeiro nível poderá conter as iterações e para cada iteração os
pacotes de trabalho são as funcionalidades do bakclog priorizados para o release
dispostos em ordem de prioridade. Durante o início da iteração as funcionalidades
são então quebradas em tarefas. Ver Figura 9.
Figura 9 - WBS (Adaptado). Fonte: Sliger, 2006.
No gerenciamento de riscos do projeto que no PMBOK® significa identificar

possíveis eventos negativos que possam atrapalhar o andamento do projeto e tentar
minimizar sua ocorrência e impacto. Na abordagem ágil o risco é tratado
68
naturalmente no ciclo de vida do produto. É natural identificar e responder aos riscos

continuamente. Isso é feito nas reuniões diárias, nas reuniões de planejamentos e
de revisão e de retrospectiva de releases e iterações. Sobre o gerenciamento da
qualidade, nos dois modelos é previsto o controle de qualidade e controles em geral
durante todo o projeto.
Uma segunda iniciativa pode partir de uma apresentação chamada “Gerenciamento

de Projetos Iterativos e Metodologias Ágeis” de Márcio Tierno (2006). Nessa
apresentação há muitos pontos de reflexão, e dentre alguns pontos interessantes
colocados por ele, a comparação entre sucesso do projeto e sucesso do cliente é
provocadora. Em sua apresentação, sucesso do projeto é entregar dentro do prazo e
custo enquanto que para o cliente, sucesso é atender suas necessidades. Atingindo
os dois sucessos, ou seja, entregando no prazo e no custo e atendendo as reais
necessidades do cliente é sucesso “Total”. Outro ponto de reflexão interessante é o
que diz que os “profissionais não são pagos para codificar, produzir modelos,
documentos ou planos, mas acima de tudo para entregar software funcionando para
o cliente que responda efetivamente às necessidades do negócio”. Outro ponto é
que projetos de software necessitam de ambas as abordagens, tradicional e ágil de
gerenciamento. Para grande marcos, como releases, para atividades que não são
diretamente relacionadas ao software e para dependências entre projetos o
planejamento e acompanhamento tradicional é o mais indicado. Segundo o autor,
software é people intensive, requer muita atividade intelectual, não deve ser tratado
como linha de montagem.
Uma terceira abordagem pode vir do artigo escrito por Alan S. Koch publicado em
2004 intitulado “Are Agile Methods Compatible with the PMBOK?”, ele faz um
mapeamento dos grupos de processos do PMBOK® segundo o desenvolvimento
iterativo, retratado na Figura 10 (KOCK, 2004):
69
®
Figura 10 – Desenvolvimento Iterativo – Grupos de processos do PMBOK . Adaptação da
apresentação de Koch (KOCH, 2004).
Na apresentação, Koch (2004) navega por cada um dos grupos de processo e faz
um paralelo entre os processos do PMBOK® e discutindo o impacto com o enfoque
iterativo. Ele elenca para cada grupo de processo a compatibilidade e
incompatibilidade entre o PMBOK® e as metodologias ágeis e o que pode ser feito.
Koch conclui dizendo que “nada nas metodologias ágeis é incompatível com os
processos do PMBOK® ” e “pode ser oportuno reforçar as metodologias ágeis com
processos do PMBOK® , porém somente onde realmente é necessário e sem
comprometer a agilidade”.
70
4. ESTUDO DE CASO
O estudo de caso que será retratado a seguir, originalmente intitulado “Agile and
PMBOK® Guide Project Management Techniques: closer than you think”, foi escrito
por Peter Bennison em 2008 e publicado no site do PMI® . Ele descreve de maneira
bem objetiva a integração dos dois frameworks em um projeto de referência
realizado para o Governo do Canadá entre 2007-2008. Como em muitos projetos de
TI, enfrentaram desafios de gerenciamento e de aceitação do cliente.
4.1 Metodologias ágeis e o guia PMBOK® . Técnicas de

gerenciamento de projeto: mais perto do que você imagina
4.1.1 Introdução
O projeto apresentado neste trabalho foi parte de um grande plano para revisar e
atualizar a presença na internet de um grande departamento do governo canadense
em 2007-2008. O objetivo do programa foi analisar o website existente, entrevistar
os stakeholders e desenvolver estruturas de governança, procedimentos e
estratégias de desenvolvimento de conteúdo. O plano também desenvolveu
requisitos para o Sistema de Gerenciamento de Conteúdo de Web (WCMS),
estabeleceu e executou o projeto de implementação para o WCMS. O projeto
discutido aqui cobre a parte de implementação.
71
Quando o planejamento da implementação começou, havia alguma incerteza sobre

como seria melhor executá-lo. O governo canadense tem um WCMS preferido - um
produto de prateleira que todos os WCMS são obrigados a usar - mas o cliente não
conhecia bem como configurá-lo e colocá-lo em produção. O fornecedor possuía
uma ampla experiência na instalação, configuração e utilização do produto, mas a
melhor estratégia de gerenciamento do projeto ainda não estava definida. Todos os
projetos de Tecnologia de Informação (TI) do governo devem satisfazer as
exigências da Treasury Board of Canada Secretariat - Enhanced Management
Framework (TBS - EMF), mas o framework tinha poucos exemplos práticos para
orientar seu uso. O fornecedor propôs que SCRUM fosse usado para gerenciar o
projeto, pois esta abordagem se encaixava na escala do projeto, aproximadamente
$2 milhões, além do grande envolvimento do cliente. Os mecanismos iterativos
dentro do SCRUM também permitiam ao fornecedor demonstrar as capacidades do
pacote WCMS gradualmente, assim satisfazendo um requisito indispensável que era
o cliente fazer a manutenção e administração do sistema quando o fornecedor
terminasse o projeto.
4.1.2 Áreas de conhecimento do guia PMBOK® e a abordagem

SCRUM
As seis áreas de conhecimento que foram estudadas neste trabalho estão

delineadas abaixo, com alguns detalhes de como a abordagem usando SCRUM
explicitamente ou implicitamente as tratou.
4.1.3 Gerenciamento de integração do projeto
Gerenciamento de Integração do projeto se refere à premissa, planejamento e

coordenação das atividades de projeto. Os elementos indispensáveis desta área de
72
conhecimento são desenvolver o Termo de Abertura e o escopo preliminar. Em

outras palavras, a abordagem do PMBOK® definiria o escopo do projeto,
cronograma e custo antes de qualquer atividade de desenvolvimento ser iniciada.
SCRUM não tem muito a dizer sobre planejamento e coordenação. De acordo com
Schwaber (2004, p.68), "projetos utilizando SCRUM necessitam de menos
planejamento que projetos utilizando diagramas de Gantt porque aqueles que estão
envolvidos na entrega proporcionam visibilidade do seu progresso no final de cada
sprint". Os defensores do SCRUM sentem que proporcionando apenas uma visão do
projeto e uma lista de funcionalidades com prioridade, os patrocinadores ficarão
satisfeitos desde que estejam envolvidos ativamente. De acordo com Sliger (2006), a
definição do plano do projeto é um exercício de cooperação entre o cliente e o
fornecedor, resultando em "diversas previsões e exercícios de planejamento
realizados de um modo iterativo".
No projeto estudado aqui, os procedimentos de gerenciamento de integração não

foram definidos explicitamente antes que uma abordagem ágil fosse sugerida. O
projeto foi inicialmente planejado seguindo um cronograma limitado (horizonte de
planejamento de aproximadamente seis semanas). Isto resultou em uma série de
pequenos contratos que foram gerados para estabelecer requisitos e escopo inicial.
Mas não foi aprovado formalmente o Termo de Abertura antes que uma quantidade
expressiva de recursos de desenvolvimento de TI estivesse dedicada à solução.
De fato, o Termo de Abertura não foi aprovado antes do final das atividades de
desenvolvimento da solução. A principal razão para este atraso foi o cliente não ver
benefícios, em termos de tempo e esforço, para definir formalmente o Termo de
Abertura, satisfazendo as diretrizes exigidas pelo EMF antes do início da analise e
implementação. Isto não prejudicou o pagamento da fase inicial, mas mesmo assim
causou um impacto no projeto. Por exemplo, sem o Termo de Abertura, os papéis e
responsabilidades não foram definidos formalmente antes que o desenvolvimento já
estivesse bem adiantado. A aprovação do orçamento do projeto foi mais tênue e
negociada mês a mês.
Embora o lado financeiro acabasse sendo acertado, houve uma preocupação depois
da definição de requisitos e antes do início do desenvolvimento, que o projeto não
73
fosse financiado. Entretanto, como já foi mencionado, o material gerado e

apresentado aos patrocinadores do projeto depois que os requisitos iniciais foram
desenvolvidos, mostrou-se suficiente para obter a aprovação. Apesar da falta do
Termo de Abertura bem escrito tenha levado a dificuldades desnecessárias, isto não
afetou o início do processo de execução.
Contra este cenário, SCRUM trouxe efetivamente processo e disciplina nas áreas de
escopo e planejamento. Usando os requisitos desenvolvidos na fase inicial de
análise, a equipe de desenvolvimento realizou uma revisão com o cliente onde cada
requisito foi avaliado em termos de seu valor no negócio e no critério de aceitação
de alto nível.
Esta revisão permitiu à equipe de desenvolvimento realizar duas coisas:
• Primeiro, a equipe avaliou e estimou o esforço necessário para desenvolver

cada funcionalidade. Ao final desta revisão, a equipe estava confiante que
estimaram o esforço para atingir o critério de aceitação.
• Segundo, a equipe pôde criar uma lista ordenada de funcionalidades que
representaria a prioridade dada às funcionalidades individuais e atividades
adicionais.
O Product Backlog formou a base para estimar o custo total de implementação e

preparou o terreno para o desenvolvimento da Work Breakdown Structure (WBS).
Outra diferença relativa ao que foi definido no guia PMBOK® , como recomendado
por Griffiths (2004), é que a WBS foi baseada nas funcionalidades a serem
desenvolvidas em lugar de tarefas.
A WBS estabeleceu o padrão que cada iteração seguiria, incluindo as seguintes

tarefas:
1. Reunião de planejamento da iteração;

2. Desenvolvimento de critérios de aceitação;
3. Desenvolvimento das funcionalidades;
4. Teste de aceitação;
5. Documentação;
6. Reunião de revisão da iteração;
74
7. Reunião de revisão do processo SCRUM.
Estes sete elementos foram repetidos em cinco iterações. O tempo aproximado para
cada iteração foi de 20 dias úteis. A equipe de desenvolvimento e o cliente usaram
as estimativas iniciais para propor uma distribuição das funcionalidades de tal modo
que cada iteração ficou com aproximadamente o mesmo esforço mantendo a
prioridade por valor de negócio.
O Product Backlog também permitiu que a distribuição de trabalho e de

responsabilidades fosse claramente indicada, o que foi essencial desde que havia
uma mistura de pessoal de desenvolvimento do cliente e do fornecedor.
Finalizando, SCRUM trouxe rigor suficiente para suprir as expectativas do cliente

relativas a esta área. Da perspectiva do gerenciamento de integração do projeto,
este projeto confirmou uma observação de Griffiths (2004) que uma abordagem
utilizando o guia PMBOK® pode coexistir com uma abordagem SCRUM. Além disso,
isto mostrou que o Termo de Abertura informal pode ser suficiente para obter a
aprovação do patrocinador do projeto. Isto é independente do fato de usar SCRUM
como metodologia de desenvolvimento.
4.1.4 Gerenciamento de escopo do projeto
Gerenciamento de escopo do projeto, seguindo a definição como uma das áreas de

conhecimento do guia PMBOK® , está em desacordo com SCRUM. Em teoria, o guia
PMBOK® (2008, p. 103) parece estar alinhado com a filosofia do SCRUM
envolvendo gerenciamento de escopo, citando Turner (2002, p. 94), que disse
"Gerenciamento de Escopo de Projeto inclui os processos necessários para garantir
que o projeto contenha todo o trabalho necessário, e somente o trabalho necessário,
para completar o projeto com sucesso." Entretanto, o PMBOK® restringe ainda mais:
"Gerenciamento de escopo de Projeto está principalmente centrado em definir e
controlar o que está e o que não está no projeto." (PMBOK® , 2008, p.103). Na seção
ferramentas e técnicas do capítulo sobre Gerenciamento de Escopo do projeto deixa
75
bem claro que o escopo deve ser gerenciado e controlado utilizando ferramentas
centralizadas e processos de tomada de decisão (PMBOK® , 2008, p.121), mas
como foi notado por Griffiths (2004), as ferramentas que foram implementadas para
gerenciar o escopo (por exemplo: WBS, Análise de variação) são difíceis de atualizar
e rapidamente ficam obsoletas.
O projeto de referência usou o conjunto de ferramentas do SCRUM para gerenciar

as mudanças de escopo. Foram usados o Product Backlog e o critério de aceite de
alto nível para estabelecer a prioridade e o cronograma do desenvolvimento. No
início de cada iteração, o cliente e o fornecedor co-definiram critérios de aceite para
cada funcionalidade a ser desenvolvida. Após cada iteração, o cliente verificou que
as funcionalidades cumpriam o critério de aceite. O cliente também tinha a
oportunidade de refazer as prioridades do próximo conjunto de funcionalidades do
Product Backlog e podia atualizar os requisitos das funcionalidades já desenvolvidas
ou ainda em desenvolvimento, mas consciente que mudanças no esforço resultariam
em custo adicional. Detalhes sobre como estes ajustes em custo foram gerenciados
estão na seção "gerenciamento de custo de projeto".
O projeto de referência revelou uma limitação significativa na abordagem SCRUM

que não está presente em projetos utilizando o PMBOK® : a ausência de um
documento inicial de arquitetura geral. Isto causou um desconforto no cliente
relacionado às mudanças de escopo realizadas durante a implementação. Para
cuidar desta limitação, o fornecedor produziu um documento de discussão do
escopo para descrever as opções para as funcionalidades essenciais do sistema.
Este documento disponibilizava uma opção "gold/silver/bronze" que delineava os
custos e benefícios de diversas abordagens de design para uma funcionalidade.
A abordagem do projeto de referência foi diferente da abordagem de um projeto

tradicional das seguintes maneiras:
• Primeiro, em lugar de um controle estrito de mudanças, existiram três

oportunidades distintas para ajustar o escopo de cada iteração;
• Segundo, em lugar de manter o documento de escopo atualizado, o
projeto não ajustou a WBS inicial, principalmente porque esta foi criada
para orientar o desenvolvimento;
76
• Terceiro, em lugar de entregar um documento de arquitetura de sistema

antes da implementação, esta preocupação do cliente foi tratada através
de um documento justificando as mudanças de rumo e de escopo
ocorridas durante o desenvolvimento.
Em geral, o gerenciamento de escopo de projeto não pode ser realizado usando a

abordagem do PMBOK® em uma implementação usando o SCRUM. Depois da
agitação inicial em torno da geração da WBS do projeto e da documentação
relacionada, os processos SCRUM acabarão tornando o plano inicial obsoleto, a não
ser que exista uma atividade constante para atualizar a WBS. Ou, a WBS pode ser
concebida como um guia, em lugar de uma lista detalhada de tarefas e
cronogramas. De acordo com Sliger (2006, 2º artigo #3), "As práticas de definição do
escopo, criação da WBS e verificação de escopo do guia PMBOK® ocorrem
iterativamente na metodologia ágil". Assim, utilizando esta abordagem iterativa, uma
lista detalhada de tarefas e escopo originalmente definida nos estágios de
planejamento, estará significativamente diferente quando o projeto chegar ao fim.
4.1.5 Gerenciamento do tempo do projeto
Considerando o gerenciamento do tempo, projetos usando SCRUM e PMBOK® são

semelhantes na definição de atividades e estimação/duração de recursos.
Entretanto, para as outras subáreas, as abordagens são diferentes. SCRUM dita que
a equipe do projeto deve colaborar para definir a seqüência, cronograma e controle
do cronograma adequado. Observe que a equipe do projeto inclui tanto os recursos
de desenvolvimento quanto os do cliente que dividem a responsabilidade pela
conclusão em tempo do projeto.
No projeto de referência, o cliente determinou a seqüência do Product Backlog e a

lista de funcionalidades a serem incluídas na solução final. A equipe de
desenvolvimento determinou a estimativa para a solução final e, crucialmente,
implementaram o projeto. Isto permitiu que eles pudessem avaliar rapidamente o
impacto na estimativa de esforço quando ocorresse uma mudança no escopo,
77
porque eles conheciam as hipóteses que foram assumidas. Este exercício de

estimativas foi realizado durante dois dias no início do projeto quando os requisitos
iniciais e os critérios de aceite estavam sendo discutidos. Estas estimativas foram
revisadas no início de cada iteração para verificar sua exatidão, baseando-se nos
resultados das iterações anteriores.
A equipe usou o artefato do SCRUM chamado burndowm chart para garantir que
cada iteração completou as funcionalidades exigidas no período de 20 dias. Ajustes
diários refletiam a avaliação de cada membro da equipe do tempo restante da tarefa
designada a cada um. A atribuição de tarefas foi realizada de acordo com o
interesse/especialidade. O prazo inicial designado a cada tarefa foi baseada na
estimativa inicial mais "um acréscimo" devido a alguma mudança de escopo da
funcionalidade. Diariamente, a equipe podia ver o tempo restante relativo ao
baseline. Cada iteração seguia uma curva "S" de conclusão, e por diversas vezes,
membros da equipe julgaram que não conseguiram progredir o suficiente no
começo. Os motivos para o início vagaroso foram discutidos em iterações
posteriores.
Por exemplo, foi identificado que a estimativa não considerou o número de reuniões
de revisão que ocorriam no começo de cada iteração. Como resultado, tarefas foram
explicitamente adicionadas ou modificadas para garantir que o diagrama capturasse
todas as atividades relacionadas ao projeto.
Por último, o cronograma e o controle do cronograma foram tratados usando

métodos do PMBOK® , comparando o Product Backlog e o baseline a cada iteração
de 20 dias. Devido ao compromisso com a entrega a cada 20 dias, a equipe do
projeto e os patrocinadores puderam facilmente rastrear o desempenho. Quando
uma iteração não cumpria o prazo previsto, ficava claro que a equipe do projeto
deveria avaliar como recuperar este tempo. Todos da equipe podiam facilmente
rastrear as divergências diárias, mensais e do cronograma.
As abordagens usando SCRUM e o PMBK são semelhantes nas definições de

atividades e processos de estimativa. Contudo, a organização do cronograma,
controle e designação de tarefas são compartilhadas no SCRUM, enquanto o
PMBOK® utiliza uma abordagem centralizada.
78
4.1.6 Gerenciamento de custos do projeto
Esta é a principal interface entre o projeto e as funções de controladoria financeira

de uma organização. É difícil para o SCRUM alterar estes processos porque na
maioria das vezes estes existem devido à política ou motivos regulatórios. O
PMBOK® aparentemente está em vantagem nesta área de conhecimento porque os
artefatos e processos gerados através do gerenciamento de Integração, Escopo e
Tempo são todos usados no cálculo do custo do projeto. Além disso, muitos projetos
de TI têm "preço fechado", mas de acordo com Poppendieck e Poppendieck (2003,
p.171) tais contratos estimulam um comportamento self-serving do cliente e um
comportamento defensivo do fornecedor. Estas restrições são os desafios que um
projeto SCRUM deve superar sem perder o espírito de confiança e cooperação entre
cliente/fornecedor que é o alicerce da filosofia de desenvolvimento do SCRUM.
O projeto de referência foi sujeito a restrições de "orçamento fechado" e "despesas

significativas de controladoria de projetos" para garantir que autorizações de tarefas
Task Authorizations (TAs) contra o acordo vigente cumprissem os requisitos de
controladoria e orçamento. Inicialmente, parecia que SCRUM não poderia ser usado
por causa dessa restrição. Entretanto o fornecedor propôs um mapeamento 1-a-1
entre cada iteração e cada TA. Isto é, cada TA cobriria somente as funcionalidades a
serem desenvolvidas em um período de 20 dias. Como o Product Backlog incluiu
estimativas iniciais de esforço, o cliente poderia ver como os contratos se relacionam
com o esforço, mais alguma despesa extra.
No início de cada iteração, um novo TA representando uma estimativa de esforço

revisada e uma nova lista de funcionalidades seria assinada. No final da iteração, o
cliente determinaria se o fornecedor entregou a lista de funcionalidades com a
qualidade acordada e o fornecedor determinaria se os custos de desenvolvimento
estão de acordo com os requisitos de rendimento.
No final da iteração, o fornecedor ou o cliente poderiam ajustar os termos e o escopo

da TA seguinte para refletir uma nova realidade envolvendo requisitos técnicos ou
79
de negócio. Ao longe deste processo, o cliente pôde ver o valor de negócio no

sistema em desenvolvimento, enquanto o fornecedor aprofundou seu conhecimento
sobre os processos e o ambiente técnico do cliente. Enfim, isto permitiu que o
fornecedor e o cliente atuassem como parte de um time, empenhados a concluir o
projeto com sucesso.
Nesta área, o PMBOK® e os requisitos de controladoria financeira têm a primazia,

mas o projeto de referência mostrou que a estrutura de custos existente "ditada" pelo
contrato pôde ser usada para suportar SCRUM. A qualquer momento, se o cliente ou
o fornecedor sentissem que não estavam obtendo o retorno suficiente diante do que
foram investidos, eles tinham a opção de ou mudar para um método mais tradicional
ou simplesmente mudar de parceiro. Felizmente, nenhuma destas opções extremas
foi tomada porque as duas partes concordaram que o projeto gerou valor de negócio
aceitável e mensurável a um custo razoável.
4.1.7 Gerenciamento de qualidade do projeto
Nesta área, SCRUM e o PMBOK® estão alinhados. Ambos reconhecem a

importância do planejamento da qualidade e garantir a satisfação das expectativas
do cliente e do sucesso em geral, e ambos sabem que um resultado inferior ocorre
quando a equipe responsável pela implementação é forçada a cumprir as metas
através de horas extras ou se o processo final de inspeção da qualidade é
apressado para cumprir o cronograma (PMBOK® , 2008, p. 180).
O projeto de referência usou as seguintes medidas de qualidade para assegurar que

o projeto cumpra as necessidades de negócio do cliente:
1. Critérios de aceite detalhados foram elaborados após a reunião de kick-off

de cada iteração para definir objetivos claros de desenvolvimento;
2. O cliente foi responsável pelo teste do sistema após cada iteração para
verificar se o critério de aceite foi satisfeito;
80
3. Como o processo de desenvolvimento foi iterativo e como o product

backlog foi priorizado, então as funcionalidades mais importantes foram
desenvolvidas primeiro, assim foram sujeitas repetidamente a testes
(mesmo que indiretos) porque posteriormente novas funcionalidades
foram adicionadas ao sistema;
4. As primeiras funcionalidades desenvolvidas foram para manutenção de
release para garantir que o código customizado pudesse ser transferido
com segurança entre ambientes de desenvolvimento, teste e produção.
Estes elementos ajudaram a garantir que a qualidade do sistema pudesse ser

testada repetidamente.
Tanto o PMBOK® quanto o SCRUM enfatizam que as metas de qualidade são

elementos importantes de um projeto bem sucedido. As ferramentas e as técnicas
podem variar para cada projeto, mas os passos e procedimentos delineados no
PMBOK® são aplicáveis a projetos usando SCRUM.
4.1.8 Gerenciamento de comunicação do projeto
Aqui, SCRUM e o PMBOK® divergem. O PMBOK® (PMBOK® , 2008, p. 235)

estabelece vários tipos/propósitos de comunicação e discorre sobre o planejamento
do gerenciamento de comunicação com o stakeholder. SCRUM não tem este nível
de formalismo, mas comunicação é um item crítico. SCRUM estabelece reuniões
regulares em cada iteração. Por exemplo, sem reuniões diárias, os membros da
equipe de desenvolvimento não saberiam como está o progresso de cada um. Sem
as reuniões de kick-off das iterações, as expectativas do cliente não poderiam ser
colocadas no escopo ou ser usadas para adequar os critérios de aceite. Sem as
reuniões de revisão de cada iteração, clientes e stakeholders não poderiam revisar o
progresso do projeto.
81
Finalmente, sem reuniões periódicas para verificar o status do projeto com o

executivo responsável, itens relacionados ao projeto não seriam levantados e nem
revistos. SCRUM difere do PMBOK® porque não define um tipo nem um layout
específico de comunicação. Segundo o SCRUM, pode ser suficiente usar um quadro
e caneta para resumir o resultado de uma discussão, ou pode ser necessário gerar
uma proposta formal para registrar as escolhas feitas relativas a um item técnico.
Para cada situação, a melhor ferramenta de comunicação e a abordagem adotada
variam.
No projeto de referência, as reuniões que foram bem sucedidas e que tiveram a

maior presença foram as reuniões semanais para discutir o status do projeto com o
executivo responsável. Ao longo do projeto, os gerentes e arquitetos do fornecedor e
o cliente se reuniam regularmente para discutir o progresso, identificar os riscos,
registrar as decisões e definir as ações a serem tomadas. Estas reuniões eram
informais (mas documentadas) e serviam para acompanhar o progresso do projeto.
As reuniões diárias não foram bem sucedidas, tanto que eram realizadas
esporadicamente. Isto foi surpreendente, uma vez que as reuniões são um item
importante na metodologia SCRUM. A principal razão para não ocorrerem tantas
reuniões da própria equipe é que estes ficavam todos numa única sala e o diálogo
entre os membros era freqüente. Quando surgia algum problema, este era
rapidamente identificado e toda a equipe se envolvia para encontrar uma solução.
Além disso, o progresso da equipe era transparente para todos por causa das
atualizações freqüentes do burndown chart. Finalizando, as reuniões de revisão da
iteração eram moderadamente bem sucedidas. Estas reuniões com o cliente e o
usuário final permitiram que a equipe revisasse e entendesse melhor o sistema
enquanto este era desenvolvido. Estas reuniões ajudavam a estabelecer uma clara e
significativa direção para o desenvolvimento, além de ajudar a deixar o usuário à
vontade com o sistema final.
O projeto de referência mostrou que esta área de conhecimento do PMBOK® foi no

máximo uma parte opcional para um projeto deste tamanho. SCRUM possibilitou
que as formas de comunicação e oportunidades de feedback resolvessem assuntos
sem que fosse necessário recorrer à uma reunião de status com o executivo
responsável.
82
4.1.9 Conclusões
O projeto de referência apresentado neste trabalho demonstrou que diversas áreas

de conhecimento chave do guia PMBOK® são completamente ou parcialmente
suportadas pelo framework SCRUM, incluindo Gerenciamento de Integração do
projeto, Gerenciamento de Tempo do projeto, Gerenciamento de Custo do projeto e
Gerenciamento de Qualidade do projeto. Contudo, existe pouco suporte do SCRUM
para Gerenciamento de Escopo do projeto e Gerenciamento de Comunicações do
projeto como delineado pelo PMBOK® .
Quando se avalia a adequação do SCRUM para um projeto, uma organização deve

determinar se a falta de suporte ao Gerenciamento de Escopo e de Comunicações
do projeto impede seu sucesso. Pelas razões expostas acima, o projeto de
referência não foi afetado de modo significativo por estas limitações. De fato,
SCRUM proporcionou uma quantidade apropriada de estrutura e processo ao
projeto, e foi de fato a razão chave para o sucesso deste projeto.
83
CONCLUSÃO
Neste trabalho, discutimos os méritos e os problemas das abordagens baseadas na

metodologia ágil e no PMBOK® , embora as técnicas de desenvolvimento ágil sejam
consideradas como tendo "potencial" e as filosofias ágeis fundamentalmente não
estejam em desacordo com as áreas chaves do guia PMBOK® .
A resistência à adoção de técnicas ágeis em lugar de procedimento e ferramentas

mais convencionais parece ser gerada basicamente da falta de conhecimento de
quando e como as técnicas ágeis e o guia PMBOK® se alinham ou não.
Não existem muitas pesquisas sobre o relacionamento entre as técnicas de

desenvolvimento ágil e aquelas baseadas no Project Management Body of
Knowledge (PMBOK® ). O objetivo deste trabalho foi aumentar nosso conhecimento
sobre como utilizar as técnicas ágeis para satisfazer as áreas de conhecimento do
PMBOK® e descrevemos algumas propostas para torná-las compatíveis.
Em seguida, discutimos como as técnicas foram aplicadas em um estudo de caso

que notadamente comprovou que é possível utilizar sim SCRUM e PMBOK® juntos
e como as necessidades do cliente foram gerenciadas.
Atualmente, agilidade é chave para alcançar altos níveis de inovação em projetos,

seja utilizando o guia PMBOK® , SCRUM ou um modelo híbrido. O grande desafio
não é iniciar a utilização das boas práticas, mas deixar o time, o cliente e a empresa
prontos para as mudanças de paradigmas que a metodologia ágil traz.
84
REFERÊNCIAS
ABRAHAMSSON, P. et. al. Agile software development methods. Review and

analysis, n. 13, p. 407-438, 2002.
AGILE MANIFESTO. Manifesto for Agile Software Development. Agile Alliance,

2001. Disponível em: <http://www.agilemanifesto.org/>. Acesso em: 10 ago. 2009.
AGILE. Agile Alliance. Disponível em: < http://www. agilealliance. org>. Acesso em:
18 maio 2009.
ANDERSON, D.J., Agile Management for Software Engineering: applying the

theory of constraints for business results, Prentice Hall, 2003.
BECK, K. Programação extrema explicada. São Paulo: Bookman, 2000.
BECK, K.; FOWLER, M. Planning Extreme Programming. Addison Wesley, 2001.
BOEHM, B. A View of 20th and 21st century software engineering, ICSE, 2006.
CÂMARA, F. Um cardápio ágil para todos os gostos. Codificando Net: e-magazine.

n. 3, ano I, set. 2007.
CAMPOMORI, Q.; CORRÊA, T. R. A utilidade da gestão de projetos na

internacionalização de empresas: uma abordagem sobre planejamento, riscos
positivos e negativos. Trabalho de Conclusão de Curso do MBA Executivo em
Gestão Estratégica de Projetos pelo Centro Universitário UNA. Disponível em:
<site1.unibh.br/imgMarketing/revistas/dcjpg/.../getdoc.php? id ...>. Acesso em: 10
ago 2009.
CHAPIEWSKI, G. Como estamos indo com a adoção de SCRUM na Globo.com.

Disponível em: <http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-
scrum-na-globocom/>. Acesso em: 9 jun. 2009.
85
COCKBURN, A.; HIGHSMITH, J. Agile Software Development: the business of

innovation, IEEE Computer, sept., 2001, p. 120-122.
COCOMOII, Qualidade da produção de software. Disponível em:

<www.proqualiti.org.br/revista/revista_ProQualiti_maio2005.pdf>. Acesso em: 10.
set. 2009.
EXTREME PROGRAMMING. Figura 1. Disponível em:

<http://www.extremeprogramming.org>, Acesso em: 10 set. 2009.
FDD. Feature Driven Development. Disponível em:

<http://www.featuredrivendevelopment.com/>. Acesso em: 13 abr. 2009.
FEATURE DRIVEN DEVELOPMENT. Figura 2, Disponível em:

<http://www.nebulon.com/,>. Acesso em: 10 set. 2009.
FIGUEIREDO A. M. As armadilhas do SCRUM. Disponível em:

<www.cin.ufpe.br/~ers/SCRUM_MundoPM-Abril-Maio-2009.pdf >. Acesso em: 20
jun. 2009.
FOWLER, M. The New Methodology. 2005. Disponível em:

<http://www.martinfowler.com/articles/newMethodology.html>. Acesso em: 15 abr.
2009.
GARCIA, M. Visual Studio Team System. Team Foundation Server. São Paulo:
Brasport, 1999.
GRIFFITHS, M. Using agile alongside the PMBOK® . PMI® Global Congress

Proceedings, 2004.
ISOTTON NETO, E. Scrumming: ferramenta educacional para ensino de práticas

do SCRUM. Dissertação (Mestrado em Informática). Faculdade de Informática. Porto
Alegre: Pontifícia Universidade Católica do Rio Grande do Sul, 2008, 123p.
JEFFRIES, R.; ANDERSON, A.; HENDRICSON, C. Extreme Programming

Installed. Upper Saddle River, NJ, Addison-Wesley, 2001.
86
KNIBERG, H, Scrum and XP from the Trenches, How we do Scrum, nov. 2006, p.
90.
KOCH, Al. São ágeis e compatíveis com o PMBOK® ? Pittsburgh Project

Management Institute. 2004. Disponível em:
<http://www.pittsburghpmi.org/documents/meetings/presentations/AgileManifesto-
PMBOK.pdf>. Acesso em: 28 jun. 2009.
LAURINDO, D. Implantação do modelo de referência para melhoria de.

processo de software MR MPS.BR níveis G e F na organização E-
Componentes. 76, 2007. Disponível em:<
www2.dc.uel.br/nourau/document/?down=573>. Acesso em: 10 set. 2009.
MANHÃES TELES, V. Um estudo de caso da adoção das práticas e valores do

Extreme Programming. Dissertação (Mestrado em Informática). Universidade
Federal do Rio de Janeiro. Rio de Janeiro: UFRJ, IM / DCC, 2005, 152p.
MARTINS, J.C.C. Técnicas para gerenciamento de projetos de software. São

Paulo: Brasport, 2009.
MICROSOFT. Microsoft Solutions Framework version 3.0 Overview, July 2003.

Disponível em: http://www.microsoft.com/technet/itsolutions/msf/default.mspx>.
Acesso em: 7 fev. 2009.
MOUNTAIN, G. Software: the SCRUM development process. Disponível em:

<http://www.mountaingoatsoftware.com/Scr>. Acesso em: 10 jun. 2009.
MSF. Agile Software Development Process Guidance. Disponível em:

<http://www.microsoft.com/downloads/details.aspx?FamilyId=9F3EA426-C2B2-4264-
BA0F-35A021D85234&displaylang=en#QuickInfoContainer>. Acesso em: 2 ago.
2009.
NESMA. Netherland Software Metrics Users Association. Qualidade na produção

de software, v. 1, n. 1, 2005. Disponível em: <
www.proqualiti.org.br/revista/revista_ProQualiti_maio2005.pdf>. Acesso em: 10 ago.
2009.
NETO, J. ; BOCOLI, F. SUCESSOSW = CMM2 + PMBOK® . PMI® Journal, n. 5, p.

2-11, maio. 2003.
87
PALMER, S.; FELSING, J. A Practical guide to feature driven development.

Prentice Hall, 2002.
PEREIRA P.; TORREÃO, P.; MARÇAL, A. S. Entendendo SCRUM para gerenciar

projetos de forma ágil. Disponível em: <
http://www.cin.ufpe.br/~ers/SCRUM_MundoPM-Abril-Maio-2007.pdf.>. Acesso em:
10 set 2009.
PMBOK® , A Guide to the Project Management Body of Knowledge – PMBOK®

Guide – Fourth Edition, Project Management Institute (PMI® ), USA, 2008.
PMI® . Project Management Institute, 2004. Disponível em: <http://www.pmi.org>.

Acesso em: 01 abr. 2009.
PMI® -SP. Project Management Institute. Um guia do conjunto de conhecimentos

em gerenciamento de projetos. Disponível em: <www.pmisp.org.br/instituto.asp>.
Acesso em: 10 abr. 2009.
POPPENDIECK, M.; POPPENDIECK, T. Lean desenvolvimento de software: um

kit de ferramentas ágeis. Upper Saddle River, NJ: Addison-Wesley, 2003.
PRESSMAN, R.S. Engenharia de software. 5.ed. São Paulo: MacGraw-Hill, 2002.
RODRIGUES, D.; DEITOS, G.; TRINDADE, M.; ROCHA, T. Projeto Engenharia de

Software MSF: Microsoft Solutions Framework. Dissertação (Mestrado em
Tecnologia e Análise de Desenvolvimento de Sistemas). Faculdade de Tecnologia
SENAC/RS. Disponível em: <giovanideitos.110mb.com/estudos/eng.../MSF%20-
%20Projeto.doc>. Acesso em: 15 ago. 2009.
SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004.
SCRUM. Figura 5. Disponível em:

<http://www.sof4thouse.se/Uploades/Scrum_eng_webb.pdf,>. Acesso em: 10 set.
2009.
SLIGER, M. The software project manager's bridge to agility. Boston: Peterson

Education, 2006.
88
SOARES, S.S. Metodologias Ágeis Extreme Programming e SCRUM para o

Desenvolvimento de Software. Disponível em:
<revistas.facecla.com.br/index.php/reinfo/article/view/146/38>. Acesso em: 20 jul.
2009.
TAVARES, A. Gerência de Projeto com PMBOK® e SCRUM: um estudo de caso.

Monografia (Conclusão de Curso). Gravataí: Faculdade Cenecista Nossa Senhora
dos Anjos, 2008, 65p.
TELES, V.M. Extreme Programming. São Paulo: Novatec Ed, 2004.
TIERNO, M. Gerenciamento de projetos iterativos e metodologias ágeis.

Compuware, 2006. Disponível em:
<www.spinsp.org.br/apresentacao/AgilePMOut.pdf>. Acesso em: 30 jun. 2009.
TURNER, R.; JAIN, A., Agile Meets CMMI: Culture clash or common cause,
proceedings of the Second XP Universe and First Agile Universe Conference on
Extreme Programming and Agile Methods XP/Agile Universe, p. 153-165, 2002.
WILLIAMS, L.; KESSLER, R.R. Strengthening the case for pair programming. IEEE
Software, n. 17, v. 4, p. 19-25, 2003.

Pmi Scrum

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pmi Scrum

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

LEONARDO BRUNO PEREIRA DE ARAUJO

ESTUDO COMPARATIVO DA COMPATIBILIDADE

ENTRE AS MELHORES PRÁTICAS DO PMI® E

ESTUDO COMPARATIVO DA COMPATIBILIDADE

ENTRE AS MELHORES PRÁTICAS DO PMI® E

Trabalho de Conclusão de Curso apresentado

Orientador: Prof. Ms. Antonio Augusto

ESTUDO COMPARATIVO DA COMPATIBILIDADE

ENTRE AS MELHORES PRÁTICAS DO PMI® E

Trabalho de Conclusão de Curso apresentado

Aprovada em ____________ de 200_

Prof. Ms. Antonio Augusto Barbosa Camargos.

Prof.(ª) Ms. ou Dr.

Prof.(ª) Ms. ou Dr.

À minha família, pelo carinho, apoio,

Deus, pelo sentido da vida, saúde e proteção.

Ao professor Augusto Camargos pela dedicação e disponibilidade nos

À minha família, pelo apoio e carinho para a conclusão desse curso.

Palavras-chave: PMI® . Metodologia Ágil. SCRUM. Gerenciamento de projetos.

The great achievements recorded history of mankind since the beginning of

Keywords: PMI® . Agile Methodology. SCRUM. Project Management.

Figura 1 - Extreme Programming ........................................................................... 25

Figura 2 - Feature Driven Development ................................................................. 32

Figura 3 - MSF ...................................................................................................... 35

Figura 4 - MSF ...................................................................................................... 38

Figura 5 - SCRUM ................................................................................................. 40

Figura 6 - Quadro de tarefas.................................................................................. 51

Figura 7 - Formato de Processo ............................................................................ 58

Figura 8 - Grupos de Processos ............................................................................ 58

Figura 9 - WBS ..................................................................................................... 67

Figura 10 - Desenvolvimento Iterativo – Grupos de processos do PMBOK® ........ 69

Gráfico 1 – Sprint Burndown ..................................................................................... 48

Gráfico 2 – Sprint Burndown ..................................................................................... 49

Gráfico 3 – Sprint Burndown ..................................................................................... 50

Tabela 1 - Áreas fundamentais segundo o MSF ...................................................... 38

Tabela 2 - Áreas do conhecimento........................................................................... 59

Tabela 3 - Mapeamento dos processos nos grupos de processos e áreas de

conhecimento. ........................................................................................................... 60

Tabela 4 – Principais diferenças e similaridades entre as metodologias ágeis e

PMBOK® . .................................................................................................................. 64

ALGOL Algorithmic Language

ANS Padrão Nacional Americano

ANSI Instituto de Padrões Nacional Americano

AT&T American Telephone and Telegraph

COBOL Common Business Oriented Language

EUA Estados Unidos da América

EVM Earned Value Management

FBS Feature Breakdown Structure

FDD Feature Driven Development

IBM International Business Machines

Lean Lean Thinking

LHS Limite de Horas da Sprint

MSF Microsoft Solutions Framework

NASA National Aeronautics and Space Administration

OPM3® Organizational Project Management Maturity Model

PMBOK® Project Management Body of Knowledge

PMI® Project Management Institute

PMJ Project Management Journal

PMP Profissionais de Gerenciamento de Projeto

PMP®) Project Management Professional

PMQ Project Management Quarterly

ROI Retorno Financeiro