estudo comparativo da compatibilidade entre as melhores práticas do pmi e scrum

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

LEONARDO BRUNO PEREIRA DE ARAUJO

ESTUDO COMPARATIVO DA COMPATIBIL IDADE

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 cliente

Sintoma típico quanto o objetivo não é atingido

Papel responsável pela obtenção do objetivo

Entrega dentro dos limites do projeto “O projeto atrasou e ficou acima do orçamento”

Gerência de Programa

Construir o que foi pedido “O que foi construído na verdade não era o que queríamos”

Desenvolvimento

Lançar a versão somente depois que problemas são identificados e corrigidos

“Esta coisa é imprevisível – continuamos descobrindo novos problemas”

Teste

Lançamento sem imprevistos e preparação para a transição para operação em produção

“Não conseguimos fazer com que funcione em produção”

Lançamento e Operações

Ampliar a eficiência e eficácia do usuário final

“É simplesmente muito difícil de usar”

Experiência do Usuário

Satisfazer os clientes “Não atende nossas expectativas. Não estamos contentes com o resultado”

Gerência de Produto

Arquitetar a solução para fácil manutenção e outras características

“Tivemos que pagar muito para adicionar funcionalidade mais

Arquitetura

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.

Áreas de conhecimento

Grupos de Processos Iniciação

Planejamento

Execução

Controle

Encerramento

Integração

Desenvolver Termo de Abertura

Desenvolver o plano de gerenciamento

Dirigir e Gerenciar a Execução do Projeto

Monitorar e controlar trabalhos do projeto Desenvolver controle de mudanças integrado

Encerrar projeto ou fase

Escopo

Obter requisitos Definir escopo Criar WBS

Controlar escopo

Tempo

Definir atividades Sequenciar atividades Estimar recursos por atividades Estimar duração de atividades Desenvolver cronograma

Controlar cronograma

Custos

Estimar custos Determinar orçamento

Controlar custos

Qualidade

Planejar qualidade

Desenvolver garantia da Qualidade

Executar controle de qualidade

Recursos Humanos

Desenvolver plano de recursos humanos

Contratar time do projeto Desenvolver time do projeto Gerenciar time do projeto

61

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.

Comunicação

Identificar partes interessadas

Planejar comunicações

Distribuir informações Gerenciar expectativas de partes interessadas

Reportar performance

Riscos

Planejar gerenciamento de riscos Identificar riscos Preparar analise qualitativa de riscos Preparar analise quantitativa de riscos Planejar respostas para riscos

Monitorar e controlar riscos

Aquisições

Planejar aquisições

Conduzir aquisições

Administrar aquisições

Encerrar contrato

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 ocorre de forma iterativa e evolutiva, com ondas sucessivas. A principal diferença é que cada iteração corresponde usualmente a uma fase do projeto, o que normalmente não é de curta duração. Pode levar mais do que 4 semanas.

São adaptativas: Partem do princípio de que o conhecimento sobre o problema aumenta à medida que o sistema vai sendo desenvolvido, levando a uma busca constante por melhores soluções. O desenvolvimento ocorre de forma 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 do princípio de que processos bem definidos devem ser impostos e executados, para garantir a qualidade do produto resultante. O talento das pessoas é refletido nas estimativas, é valorizado ainda na opinião dos especialistas e é considerado quando se pondera o cronograma com nivelamento de recursos. Ainda o talento do gerente do projeto é estimulado nos dois aspectos: gerente/chefe e líder, motivador, coach.

São orientadas a pessoas: Para melhor gerenciar projetos de software, pessoas devem ser tratadas como indivíduos e não como recursos, pois cada pessoa apresenta um ritmo de trabalho único e completamente diferente, que é fruto da sua vivência pessoal. Os membros da equipe escolhem as tarefas que irão desenvolver durante a iteração seguinte, além de estimarem o tempo a ser gasto com elas, o que aumenta a motivação, o comprometimento e a produtividade da equipe.

São rígidas: pressupõem que é possível especificar de antemão todos os requisitos do software a ser desenvolvido, dificultando – e muitas vezes impedindo – realizar alterações e comprometendo a evolução natural da solução. Estão mais voltadas para a obtenção do software previamente especificado do que para o sucesso do projeto ou negócio para o qual o software foi apontado como solução. Enfatiza de fato o planejamento prévio da solução global. Porém uma alternativa, caso não se tenha condições de especificar o todo é trabalhar por ondas: componentes de planejamento (pacotes não detalhados a princípio que são refinados ao longo do projeto). Nunca as mudanças são impedidas, apenas devem ser aprovadas no controle de mudança, que dependendo de como for implementado pode ser aprovado pelo próprio

São flexíveis e iterativas: adaptam-se constantemente ao conjunto de requisitos mais atual: a cada iteração, usuários, clientes e desenvolvedores decidem sobre quais características devem ser adicionadas, modificadas e até retiradas do sistema. Além de ser desenvolvido da forma mais iterativa possível, é possível escolher os pontos mais críticos ou que mais agregam valor ao sistema para serem desenvolvidos em primeiro lugar. Estão mais voltadas para o bem do negócio: seu caráter adaptativo aumenta as chances de oferecer um melhor resultado ao projeto e ao negócio. Pontos fracos: Risco de desorganização, pouca documentação e alta dependência do cliente/usuário, o que muitas vezes não é viável

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 desenvolvimento a ser realizado, comprometendo a velocidade de desenvolvimento e, muitas vezes, o sucesso do projeto.

Simplicidade: partem do princípio de que é preferível fazer algo simples de imediato e pagar um pouco mais para alterá-lo depois, se necessário, do que fazer algo complicado de 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.

estudo comparativo da compatibilidade entre as melhores práticas do pmi e scrum

Documents