FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

LEONARDO BRUNO PEREIRA DE ARAUJO

ESTUDO COMPARATIVO DA COMPATIBILIDADE ENTRE AS MELHORES PRÁTICAS DO PMI® E SCRUM

São Paulo 2009

LEONARDO BRUNO PEREIRA DE ARAUJO

ESTUDO COMPARATIVO DA COMPATIBILIDADE ENTRE AS MELHORES PRÁTICAS DO PMI® E 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

LEONARDO BRUNO PEREIRA DE ARAUJO

ESTUDO COMPARATIVO DA COMPATIBILIDADE ENTRE AS MELHORES PRÁTICAS DO PMI® E 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.

saúde e proteção. pelo apoio e carinho para a conclusão desse curso.iii AGRADECIMENTOS Deus. À minha família. pelo sentido da vida. Ao professor Augusto Camargos pela dedicação e disponibilidade nos momentos de orientação e esclarecimentos de dúvidas. .

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

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

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

............................................................................................... 49  Gráfico 3 – Sprint Burndown ...................................... 48  Gráfico 2 – Sprint Burndown ............................8 LISTA DE GRÁFICOS Gráfico 1 – Sprint Burndown ......................................................................... 50  ......................

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

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

11 SDLC TAs TBS-EMF Software Development Life Cycle Task Authorizations Treasury Board of Canada Secretariat .Enhanced Management Framework TI WBS WCMS XP Tecnologia da Informação Work Breakdown Structures Sistema de Gerenciamento de Conteúdo de Web Extreme Programming .

...............................3 Desenvolvimento iterativo ................... 28 1.................................................................................................... 51 2........................1.. 37 1....1 Estórias .................................................6 Refactoring ...............................1.........................................2......................1....... 20 1............ 32 1.........4...............................................................................2 Papéis e responsabilidades ....1..............................4 SCRUM..........1...............................................2 Planejamento da Sprint ..........3..................................................1 O gerenciamento de projeto .................................3........................................................................3....2......1 Extreme Programming ................... PMI® e PMBOK® . 40 1.... 23 1............... 14 1 METODOLOGIAS ÁGEIS ...................4.........................................................................................................4.........1 Release Manager .......................... 27 1............. 29 1.............2 Planejamento ............................................. 30 1.......................................................................................7 Programação em par........... 42 1...............................1..................................................................2 Feature Driven Development .4......................... 30 1.... 25 1..................... 52 2...............................1 Product Backlog ................................... 39 1................................ 42 1......................................2............................................................................ 39 1.............. 26 1..... 42 1..................5 Teste antecipado ......................5 Construir por funcionalidade ...................... 42 1........................................................ 41 1..........................3 Microsoft Solutions Framework .......4...........................1 Desenvolver um modelo geral .........................1............................................. conceitos e fases .................................................................................................................... 34 1.... 33 1.........................12 SUMÁRIO INTRODUÇÃO .............4........................ 53 ...................... 26 1............................3...................2........................................................4 Iterações de uma semana ....3 Artefatos................ 29 1....................................4 Final da Sprint .1 Como funciona? .....2 História ..............8 Envolvimento dos clientes .................... 52 2................................4....................................1...................2...4 Projetar por funcionalidade ................. 33 1........3 Execução e controle da Sprint............ 33 1...........................................................................3...........................2 Construir uma lista de funcionalidades ......3 Planejar por funcionalidade ......................................................................

.....................5 Gerenciamento do tempo do projeto............9 Conclusões ...................................................2 Propostas de compatibilização ..................................................................1 Metodologias ágeis e o guia PMBOK® ....................1..........................6 Gerenciamento de custos do projeto ................................................................. 74 4.......1 Introdução ...... 66 4............. 70 4............................................... 55 2............... SIMILARIDADES E PROPOSTAS DE COMPATIBILIZAÇÃO .........1 Diferenças e similaridades.................................................1................... 56 2............7 Gerenciamento de qualidade do projeto ................................................5 Projeto .......................................................................8 Áreas de conhecimento ........................................1...................................................................................................... 76 4..............................................................................................9 Processos nos grupos e nas áreas de conhecimento ..................1............... 59 2................. 80 4... 81 CONCLUSÃO .............................................................................. 54 2.......................6 Gerenciamento de projeto ..................................4 Gerenciamento de escopo do projeto ............................... DIFERENÇAS...................................................2 Áreas de conhecimento do guia PMBOK® e a abordagem SCRUM ................ 57 2...................... ESTUDO DE CASO ...... 70 4..............................1................7 Grupos de Processos .3 Gerenciamento de integração do projeto .......................... 70 4..........................1.............8 Gerenciamento de comunicação do projeto ........1............ 56 2.......1....................... 70 4....................................13 2.. Técnicas de gerenciamento de projeto: mais perto do que você imagina .......................... 78 4.................................................... 62 3........1..............................................4 PMBOK® .......3 Hoje ............... 83 REFERÊNCIAS .... 70 4............................ 60 3.............................................................................................................................................. 79 4.................. 62 3................................... 84 .....

A criação do COBOL foi notadamente um feito. houve a difusão dos chamados mainframes. capacidade de armazenamento e uma variedade incomum de dispositivos de entrada e saída.14 INTRODUÇÃO A segunda metade do século XX foi marcada por grandes descobertas científicas e em entra elas. profundas modificações na arquitetura. projetados basicamente para cálculos de trajetórias balísticas. que cresciam os sistemas destinados a grandes corporações. . Hewlett-Packard (HP) e a Unisys lançaram seus modelos. a primeira linguagem de programação de alto nível foi Fortran. o surgimento dos computadores. em 1957 foi criada B-0. e continua ainda em uso depois de mais de 40 anos. quando foram anunciados ao mundo. embora tenha sido proposto originalmente como solução para resolver problemas de programação do governo e das forças armadas americanas. o que lhe conferia maior flexibilidade. criada em 1954. que teve inicialmente o seu desenvolvimento fortemente patrocinado pela indústria bélica. no fim dos anos 70. esses computadores eram mantidos em segredo pelo o governo americano até o final da segunda guerra mundial. começaram a reduzir o tamanho de seus mainframes. Empresas como a International Business Machines (IBM). linguagens de programação surgiram desde os anos 50. Lisp e Algorithmic Language (ALGOL) criadas em 1958. aumento significativo na memória. estas máquinas marcaram início da substituição do relês e válvulas pelo o uso de circuitos integrados. e foi da Unisys as primeiras máquinas microprogramáveis. Para acompanhar a evolução dos computadores. e ao mesmo tempo. programas COBOL continuam em uso na maioria das empresas comerciais em todo o mundo e em grandes instituições financeiras. que daria origem a Flow-Matic em 1958. Nos anos 60. de 1959. uma melhora surpreendente no desempenho do hardware. antecessor imediato do Common Business Oriented Language (COBOL).

O software do radar não diferenciou um avião de passageiros de um caça inimigo de ataque. resultou num problema para a Intel.0 por 3145727. ele entrega o mais valioso produto da nossa era – a informação. numa rede de computadores acessível pelo o computador local. 2. Divisão de números com ponto flutuante no microprocessador Pentium. Um problema com os microprocessadores provocou uma falha na divisão de números com ponto flutuante. Por exemplo. mais amplamente. mas também podem causar enormes problemas para quem precisa construir sistemas complexos. Ainda que a falha afetasse poucos usuários. numa operação que lhe custou mais de meio bilhão de dólares. Ao longo do tempo. Foguete Ariane. O navio da marinha americana USS Vicennes derrubou um Airbus 320. ele é o produto e.15 Segundo Pressman (2002) atualmente os softwares e os computadores assumem um duplo papel. um erro de 0. ao mesmo tempo. Como veículo usado para entrega do produto. Para citar alguns bugs famosos: 1. ao dividir 4195835. Quer resida em telefone celular. 1993. 1996. 3.006%. o meio para entregar o produto.0 o resultado apresentado pelo microprocessador era 1.33374 ao invés de 1. Sofisticação e complexidade produzem magníficos resultados quando um sistema é bem-sucedido. para a comunicação da informação (redes) e para a criação e o controle de outros programas (ferramentas e ambientes de software). 290 pessoas morreram. 1988.33382. quer opere em um mainframe. que se viu obrigada a trocar entre três e cinco milhões de chips. Derrubada do Airbus 320. . como produto oferece o potencial de computação presente no computador ou. sistemas baseados em computador se tornaram mais sofisticados e complexos. o software é um transformador da informação. o qual foi confundido por um F-14. o software age como uma base para controle do computador (sistemas operacionais).

em decorrência. Perguntas feitas a 40. que ele carregava. mas os motores do novo foguete incorporavam também. a National Aeronautics and Space Administration (NASA) lançou ao espaço a nave espacial exploratória Mars Climate Orbiter.16 Em junho de 1996.0 bilhões. 20. 1999. A pior falha no sistema elétrico dos Estados Unidos da America (EUA) em toda sua história. o Ariane 4. a qual falhou por razões desconhecidas em dezembro 1999. meio segundo depois o computador principal da missão também apresentou problemas. a espaçonave deveria prover suporte de comunicação para a missão exploratória da espaçonave Mars Polar Lander. mais de 100 centrais geradoras foram desligadas. um bug numa rotina aritmética no computador de vôo que falhou segundos após a decolagem do foguete. A espaçonave perdeu-se no espaço durante o seu vôo para Marte. um bug de software foi identificado como o grande fator determinante para a causa do blackout. 4. sem que ninguém desse conta. a qual custou US$ 125 milhões. 5. O Ariane 5 desintegrou-se 40 segundos após o lançamento. O foguete e o satélite. Blackout no Noroeste dos EUA. Em outubro de 1999. valiam US$ 500 milhões. o blackout deixou mais de 50 milhões de clientes sem energia elétrica. Mars Climate Orbiter. 2003. foi realizado o primeiro vôo do novo foguete da Agência Espacial Européia – o foguete Ariane 5. as perdas econômicas foram estimadas em US$ 6. Vemos então um cenário onde é mais comum o fracasso de um projeto de software do que seu sucesso. 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? . Reutilizaram parte do código de seu predecessor. Dentre as várias tarefas que deveria executar. a internacional. 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.

reconhece cinco grupos de processos de gerenciamento de projetos e nove áreas de conhecimento. IBM. Chiyoda Corporation. As edições anteriores foram publicadas nos anos de 1996. como a própria definição de projeto e do seu ciclo de vida.Project Management Body of Knowledge). Sociedade Computacional de . permitindo aos executivos seniores a perceber "o que está acontecendo" e "para onde as coisas estão indo" dentro das organizações. e muitas outras perguntas e tentar racionalizar os processos de desenvolvimento de sistemas e minimizar impactos negativos em projetos o Project Management Institute (PMI® ). e publica um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK® . Editado na forma de livro.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. 2000 e 2004. Conceitos amplamente utilizados em projetos de desenvolvimento de software. Muitas organizações ao redor do mundo. como NASA. inclusive o português do Brasil. assegura que os recursos disponíveis são alocados da maneira mais eficiente e eficaz. qualidade e reusabilidade? Para tentar responder essas. fundado em 1969 nos EUA e atualmente difundido em mais de 120 países é o maior difusor do gerenciamento de projetos. o Guia PMBOK® está atualmente na quarta edição de 2008 e traduzido oficialmente para diversos idiomas. 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. American Telephone and Telegraph (AT&T). O PMBOK® formaliza diversos conceitos em gerenciamento de projetos. Siemens.

na verdade. analisar divergências significantes e prever seus impactos nos projetos e na organização. Baseada no Pensamento Lean (Lean .18 Singapura e o Governo Estadual de Oregon (EUA). lançam mão do Gerenciamento de Projetos para desenvolver processos inovadores. é fazer a diferença e. • Organizações multinacionais que buscam estabelecer práticas uniformes para gerenciar projetos. ou projetos diversos. concorrência acirrada e grande dinamismo no ambiente de negócios (BOEHM. Algumas destas mudanças incluem: • Processos de Downsizing (menos pessoas para fazer mais tarefas). • Acesso à informação mais fácil através de amplas redes de comunicaçã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. exige muito disciplina e organização. ser simples. • Projetos e serviços maiores e mais complexos. Vivemos uma tendência para o desenvolvimento acelerado de aplicações devido ao ritmo das mudanças na tecnologia da informação. no entanto. uma nova abordagem para desenvolvimento de software tem despertado grande interesse entre as organizações de todo o mundo. ter agilidade. apenas recentemente a expressão “Métodos Ágeis” vem ganhando popularidade no Brasil por usar abordagem simplificada no desenvolvimento de sistemas de informação. planejar. Por outro lado. pressões por constantes inovações. Ken Schwaber e John Scumniotales na década de 1990. geralmente de software. monitorar desempenho. Apesar de existir a um bom tempo. • Clientes mais sofisticados que exigem produtos e serviços de maior qualidade. • Competição global e feroz. mas pode ser utilizada para outros tipos. ao contrário do que parece. 2006). como desenvolvimento de produtos físicos. organizar e controlar iniciativas estratégicas. “ser simples” geralmente é confundido com falta de controle e rigidez. Criada por Jeff Sutherland. a SCRUM é uma metodologia ágil para gerenciamento de projetos. • Crescimento tecnológico exponencial.

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. A motivação da pesquisa vem da visibilidade crescente que as Metodologias Ágeis de desenvolvimento de software têm recebido em todo o mundo. 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. o uso das duas abordagens é perfeitamente possível e positiva. e também aqui no Brasil. por sua vez a adoção exclusiva de Metodologias Ágeis. No que se refere a projetos de software. . Sua aplicação não está limitada a projetos de software. e novas estratégias de criação de produtos.19 Thinking). desenvolvimento iterativo e incremental. Alguns mais radicais defendem a adoção puramente de PMBOK® e outros.

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. implantação e manutenção. . correto e entregue dentro dos prazos e custos estipulados ainda é muito difícil. Este modelo é derivado de outras engenharias tradicionais (Civil. Dados de 1995 segundo a Standish Group Chaos Report. das técnicas e ferramentas nos últimos anos. Dentre os projetos que não foram finalizados de acordo com os prazos e custos especificados. HIGHSMITH. e a média de custo foi de 189% a mais do que o previsto.2% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades especificadas. usando como exemplos 8380 projetos. As principais razões destas falhas estavam relacionadas com o processo em cascata (COCKBURN. Considerando todos os projetos que foram entregues além do prazo e com custo maior. mostram que apenas 16. Naval) e foi o primeiro a ser usado pela Engenharia de Software. regimentação e micro gerenciamento usado no modelo em cascata que é composto basicamente por atividades seqüenciais de levantamento de requisitos. Mesmo com a evolução dos computadores. 2001). caracterizados por uma pesada regulamentação. Elétrica. implementação. a média de atrasos foi de 222%.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". 2009). segundo a mesma pesquisa. HIGHSMITH. projeto. porém com prazos maiores. análise. Aproximadamente 31% dos projetos foram cancelados antes de estarem completos e 52.7% foram entregues. na média. 2001). a produção de software confiável. teste. na década de 70 (COCKBURN. custos maiores ou com menos funcionalidades do que especificado no início do projeto (SOARES.

O problema não é a mudança em si. ao invés de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. comunicação e redução de produtos intermediários. avaliar e responder às mudanças. Além disso. que muitas vezes são mutáveis (SOARES.21 A recomendação final foi que o desenvolvimento de software deveria ser baseado em modelos incrementais. o que pode levar a efeitos desastrosos em termos de qualidade de software. Uma característica das metodologias ágeis é que elas são adaptativas ao invés de serem preditivas. muitas organizações não possuem recursos ou inclinação para processos pesados de produção de software. Torna-se necessário. o que poderia evitar muitas das falhas reportadas. entregas e custos são promissores (ISOTTON NETO. então. são de certa forma fatores limitadores aos desenvolvedores. Apesar do uso crescente das metodologias ágeis. 2008). como o modelo em cascata. como documentação extensiva. confiança. Desta forma existem maiores possibilidades de atender aos requisitos do cliente. os resultados iniciais em termos de qualidade. existe a preocupação de gastar menos tempo com documentação e mais com a implementação. elas compartilham algumas características. A idéia das metodologias ágeis é o enfoque nas pessoas e não em processos ou algoritmos (ISOTTON NETO. A maioria das metodologias ágeis nada possui de novo. 2008). . cada qual com as suas particularidades. Com isso. ainda falta uma base maior de projetos para verificar suas vantagens. O que as diferencia das metodologias tradicionais são o enfoque e os valores. Mesmo assim. mesmo porque ela ocorrerá de qualquer forma. Em 2001. como desenvolvimento iterativo e incremental. Enquanto as metodologias ágeis variam em termos de práticas e ênfases. muitas organizações. Além disso. O problema é como receber. 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. Processos orientados a documentação para o desenvolvimento de software. 2009). Por esta razão. particularmente as pequenas. elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto. acabam por não usar nenhum processo. Para ser realmente considerada ágil a metodologia deve aceitar a mudança ao invés de tentar prever o futuro. que não são orientadas à documentação nem tampouco se preocupam apenas com a codificação. utilizar metodologias ágeis.

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. Esses conceitos aproximam-se melhor com a forma que pequenas companhias de Tecnologia da Informação trabalham e respondem a mudanças (SOARES. Atualmente. 2009). Mais tarde. 2009). Darei ênfase na metodologia ágil SCRUM. Segundo Fowler (2005) os conceitos chave do Manifesto Ágil são: • “Indivíduos e interações ao invés de processos e ferramentas. são elas: Extreme Programming (XP).” O Manifesto Ágil não rejeita os processos e ferramentas. a documentação. Nesse estudo. uma organização não lucrativa que promove o desenvolvimento ágil (AGILE. mas simplesmente mostra que eles têm importância secundária quando comparado com os indivíduos e interações. . existem algumas metodologias ágeis. que será objeto de análise desse trabalho de conclusão de curso.” • “Respostas rápidas a mudanças ao invés de seguir planos.” • “Software executável ao invés de documentação. a negociação de contratos ou o planejamento. documento que reúne os princípios e práticas desta metodologia de desenvolvimento. SCRUM e Microsoft Solutions Framework (MSF). algumas pessoas formaram a Agile Alliance. cada uma exposta pela The Agile Alliance.” • “Colaboração do cliente ao invés de negociação de contratos. com a colaboração do cliente e as respostas rápidas a mudanças e alterações.22 todos concordavam que. em suas experiências prévias. Feature Driven Development (FDD). apresentarei quatro propostas ágeis.

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

mas preparando-se para o dia D. após a implantação a equipe fica exausta e pode precisar de várias semanas para se recuperar. 2001).1. ainda haverá tempo para escolher as mais importantes e priorizá-las (JEFFRIES et al. 1. 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. nesta reunião serão abordados os seguintes assuntos (TELES. Deve haver uma reunião no começo de cada semana para fazer o planejamento. Se a equipe chegar à quarta-feira e ficar evidente que os testes não vai executar. 2003). que as estórias não serão concluídas e prontas para serem entregues. Mesmo que o projeto tenha sucesso. . 2004): • Rever o progresso até o momento.27 releases devem ser do menor tamanho possível e que ainda possam produzir algum valor para o negócio (POPPENDIECK. 1 O método do big bang é o mais usado por empresas de software comercial. incluindo o progresso da última semana comparado ao esperado. Numa implementação do tipo big-bang1. POPPENDIECK. A semana deve começar com os desenvolvedores escrevendo testes automatizados que serão executados quando as estórias estiverem concluídas. • O cliente deve apontar as estórias de maior valor. fazendo horas extras e trabalhando em finais de semana. Implantações do tipo big-bang têm altos riscos e grandes custos humanos e econômicos. • Decompor as estórias em tarefas.. a equipe pode gastar meses sem adicionar nenhuma nova funcionalidade ao sistema. e permitir que os membros da equipe se voluntariem a pegar cada uma delas e façam suas estimativas.4 Iterações de uma semana O trabalho deve ser planejado uma semana de cada vez. que serão trabalhadas nesta semana. que é o horizonte da iteração. Se o projeto não tiver sucesso os custos são ainda maiores.

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

Aprende. Isto não é surpresa. você descobre que o ponto de equilíbrio do trabalho muda. refactoring. em vez de acontecer todo no início. as funcionalidades e o escopo mudam ao longo do tempo.7 Programação em par A programação em par é a prática mais popular da XP. A experiência mostra que o programa fonte requer mais refactoring à medida que o projeto evolui.29 seqüência: desenvolver outra rotina de teste ou corrigir o problema encontrado. 1. já que a qualidade do código. Logo este se transforma numa rotina de trabalho: teste.1. 2005). sem alterar seu comportamento. à medida que novas funcionalidades vão sendo construídas. por conta disso. Com a refatoração. Descobre que o projeto. quase todas as implementações de XP começam com esta prática. Esta prática tem vantagens. 2003): • Um programador ajuda o outro a manter o foco na tarefa. • Ajuda a clarear as idéias. 1. com a construção do sistema. a como melhorar o projeto. principalmente nas situações em que a programação apresenta uma complexidade maior (WILLIAMS.1. o sistema precisa vez mais refactoring (FOWLER. A interação resultante leva a um programa que permanece bom à medida que o desenvolvimento continua. ocorre continuamente durante o desenvolvimento. Na programação em par o código-fonte é escrito por duas pessoas trabalhando em conjunto num único computador.6 Refactoring O refactoring implica na melhoria continua do código-fonte. KESSLER. . • Fazer brainstorm para criar melhores abordagens. programação.

30 • Quando um dos programadores fica imobilizado por falta de alternativas o outro pode ajudar assumindo o controle. 1. . 2005). O usuário que participa da equipe pode dar um feedback rápido e ajudar a definir prioridades (MANHÃES TELES.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. Entrega resultados tangíveis e freqüentes. entre eles: Tom De Marco. 1. • 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. 2002): • • • Iterativo. além de acelerar o feedback. Renomados autores participaram da concepção das idéias do FDD. Tim Lister. Jerry Weinberg e Frederic Brooks. definiu a idéia de Feature Definition e Feature List. Enfatiza a qualidade. que também entende o contexto no qual o código foi desenvolvimento. Um de seus maiores desenvolvedores. Em sua essência o FDD é um processo ágil e adaptativo com as seguintes características (ABRAHAMSSOM.1. • Permite que todo o código produzido seja dinamicamente revisado por pelo menos outra pessoa.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. Peter Coad.

ela deve ser decomposta em funcionalidades menores. o processo e a tecnologia serão utilizados com sucesso. FELSING. este trabalho é elaborado com base no conhecimento adquirido durante a modelagem e captura de requisitos funcionais (PALMER. requerendo pouca sobrecarga de trabalho por parte dos programadores. desenvolvido em conjunto com pessoas especializadas no domínio do problema. Os papéis definidos no FDD representam grupos de responsabilidades que um profissional pode assumir no projeto.31 • • Provê relatórios de progresso precisos e significativos. A produtividade pessoal é muito importante. O FDD destaca os seguintes valores: comunicação. Dependendo da complexidade do projeto e da capacitação do profissional. se a estimativa for superior a esta. Na seqüência é esboçado um plano global do projeto e as responsabilidades são divididas entre os membros da equipe. É apreciado pelos clientes. Veja a Figura 2. 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. O próximo passo é desenvolver a lista de funcionalidades ou features que o novo sistema deverá apresentar. O FDD define seis papéis principais para o projeto mais alguns adicionais de suporte. No FDD a primeira etapa é a criação de um modelo de classes e objetos de negócio. 2002). que podem ser executadas em paralelo ou em série. trabalhando no seu projeto técnico e na sua construção. FELSING. ele pode assumir simultaneamente mais de um papel (PALMER. redução da complexidade e a qualidade. O FDD conta com a experiência e capacidade das pessoas para o sucesso do projeto. gerentes e desenvolvedores. Cada grupo de desenvolvedores trabalha numa iteração e aborda um pequeno conjunto de funcionalidades. 2009). . 2002). O projeto vai ser conduzido em iterações. Cada uma deverá ser construída em no máximo duas semanas. se a equipe for composta por pessoas altamente capacitadas. O projeto é conduzido dessa forma até que todas as funcionalidades sejam desenvolvidas (MARTINS.

O líder técnico seleciona um pequeno conjunto de funcionalidades para desenvolver nos próximos dias. Fonte: http://www. e os programadores adicionam código fonte nas classes.com/. Os próximos dois processos são onde a programação realmente acontece. integração e inspeção de código. 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. 2009. O FDD consiste em cinco processos. A equipe trabalha na modelagem dinâmica das funcionalidades e escrevem as estruturas das classes. O projeto começa com a modelagem das classes do domínio do problema. fazem testes de unidade. Depois a equipe faz uma inspeção do projeto técnico.Feature Driven Development (Adaptado). 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.nebulon. identifica os donos das classes envolvidas e os convoca para compor a equipe para a iteração. compostas pelas definições dos métodos e dos atributos.32 Figura 2 . não mais que duas semanas. Os processos do FDD são descritos a seguir (MARTINS. 2009): 1.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 .2.

33 quanto ao escopo do sistema e o seu contexto. Um exemplo de funcionalidade é "calcular o total de vendas".2. como Casos de Uso. À medida que o trabalho se desenvolve a equipe vai construindo o modelo de classes e objetos de negócio. o gerente de desenvolvimento e o líder técnico. Normalmente cada uma corresponde a uma atividade particular de negócio (MARTINS. As funcionalidades são organizadas numa Feature Breakdown Structure (FBS) onde são agrupadas em conjunto e divididas por área de negócio. 2009).2. trabalhando em conjunto.2 Construir uma lista de funcionalidades Com base no conhecimento adquirido na primeira etapa. 2009). cada área é decomposta em atividades. 1. que dão origem a grupos de funcionalidades. Documentos existentes de requisitos são utilizados como referência para este trabalho. Orientado pelo especialista no negócio. 2007). especificação funcional. dentre outros. ele as divide por área de negócio. o líder técnico decompõe as funcionalidades do domínio e constrói uma lista de funcionalidades. . cada vez aumentando mais o nível de detalhe.3 Planejar por funcionalidade No terceiro processo do FDD o gerente de projeto. Cada funcionalidade é definida como uma funcionalidade pequena e de valor para o cliente e é expressa na forma <ação> <resultado> <objeto>. A equipe divide o domínio do problema em áreas e faz vários walkthroughs em cada uma delas. planejam a seqüência de desenvolvimento dos grupos de funcionalidades (atividade de negócio) e dos conjuntos de funcionalidades (área de negócio) (FDD. 1. Cada funcionalidade deverá pertencer a somente um conjunto (atividade) e a somente uma área de negócio. Depois todos os modelos são combinados para formar o modelo final (LAURINDO.

O FDD é definido ao redor de um conjunto central de práticas que embora não sejam inovadoras. Depois o programa fonte passa pelo teste de unidade e inspeção de código. os donos das classes fazem a programação. o código fonte de cada classe pertence a um programador. inspeções.5 Construir por funcionalidade Usando a especificação feita no projeto técnico. A equipe pode implementar somente algumas das práticas. 1. 2007).4 Projetar por funcionalidade As funcionalidades são atribuídas aos lideres técnicos que são responsáveis pelo seu desenvolvimento. mas se não considerar todas elas não obterá todos os benefícios previstos pelo FDD. são utilizadas de forma inovadora: elas reforçam e complementam umas as outras. tangíveis e funcionais. O líder técnico seleciona as próximas funcionalidades para desenvolvimento a partir da sua lista de prioridades.2. 2007). Uma característica marcante do FDD é que este é um processo definido para fazer repetidamente entregas constantes. e compõe seus pacotes de trabalho.34 1. Desenvolvimento por funcionalidade. As práticas propostas são: Modelagem de Objetos do Domínio. 2009).2. Algumas delas podem ser desenvolvidas simultaneamente quando elas estão baseadas no mesmo conjunto de classes (LAURINDO. nestes casos a inspeção de apenas uma amostragem pode ser suficiente para localizar a maioria dos problemas. Há situações em que cenários simples se repetem em várias partes do programa. builds constantes. Finalmente as funcionalidades desenvolvidas são integradas à versão final (MARTINS. mas nem todo código precisa necessariamente passar pela inspeção. gerenciamento de configuração e controle do progresso (LAURINDO. O FDD é um método . Equipes por funcionalidades.

pois defende um Software Development Life Cycle (SDLC) mais curto com iterações de no máximo quatro semanas. Microsoft. técnicas claras para informar o progresso e permitir que as decisões possam ser tomadas em tempo oportuno (LAURINDO. possui técnicas objetivas para lidar com os problemas de desenvolvimento de software. Figura 3 – MSF – Fonte: MSF for Agile Software Development Process Guidance. 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.3 Microsoft Solutions Framework O MSF 4.35 simples.2 possui duas novas instâncias: MSF for Agile Software Development e MSF for CMMI Process Improvement. 1. . contudo preserva a importância dos papéis definidos previamente e abomina a linha "todo mundo pode fazer tudo no projeto". 2007). objetivo e fácil de seguir. Veja a Figura 3. Podemos afirmar que o MSF Agile é a soma de posições equilibradas. 2009). 2009.

2009). a implementação e os testes ocorrem de forma cíclica ao invés de seqüencial. MSF Agile é um processo iterativo e incremental. 2007): • Teoria do controle: Pequenas iterações permitem você calibrar com mais agilidade suas estimativas e reduzir a margem de erro. Incremental é porque se repete sempre aumentando seu resultado. desenvolvedor e analista de testes (CAMARA. resultando em produtos incrementais do conjunto do software. Desvios são tratados com antecedência. 2009). Quando você pensa iterativo e incremental. Metodologias ágeis necessitam que os "stakeholders" estejam presentes o tempo todo durante o projeto. Podemos destacar três itens essenciais em um processo iterativo e incremental (CAMARA. você organiza a "cultura" do seu projeto de forma econômica. usuário. incrementando (RODRIGUES et al. Iterativo é o mesmo que repetível. • Envolvimento do cliente / usuário: Os interessados no resultado do projeto podem ter contato com as telas e funcionalidades rapidamente e continuamente. Estes cenários fazem parte de uma determinada iteração do plano de iterações. Um processo iterativo é geralmente definido como a técnica de desenvolvimento de software que a definição dos requerimentos. Esta iteração agrupa os cenários de desenvolvedores e os cenários de testes. que são efetuados em seguida ao desenvolvimento. pois a informação para a tomada de decisão acontece em períodos curtos (RODRIGUES et al. Desta forma permite você utilizar a máxima: "o menor prejuízo é sempre o primeiro". Esta abordagem de trabalho também propicia o gerenciamento de risco. . pois você terá informações reais para a tomada de decisão. ou seja. Desta forma controla-se a integração de um time com papéis diversos dentro do projeto. o planejamento.36 Um tema muito forte dentro do MSF Agile é integração. com foco absoluto no produto e com elementos de motivação. O retorno rápido das informações de como está seu projeto incrementa a visibilidade e a previsibilidade. 2007). Para isso são constituídos cenários de tarefas de trabalho que englobam atividades planejadas para um desenvolvedor.

um gerente de projeto dá suporte à equipe.1 Release Manager O Modelo de Equipe da MSF tem como princípio fundamental a idéia de "Equipe de Iguais" – Team of Peers.37 • Aprendizado contínuo: O próprio projeto é uma rica lição a cada iteração. significando com isto que não há nenhuma hierarquia entre os membros da equipe. Cada membro da equipe é bem autônomo. a qual atua em consenso do que necessita ser feito para continuar o projeto (CAMARA. Você percebe a evolução da curva de produtividade e acompanha a autonomia técnica crescente dos colaboradores a cada dia dentro do projeto. neste modelo. e espera-se que saibam o que fazer e planejam como vão fazer a entrega de sua parte do trabalho. Por exemplo. 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. 2007). 1999). Para o MSF. . um projeto precisa dos seguintes papéis. 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. Veja a Figura 4.

Microsoft. Cada papel é auto-explanatório. as necessidades do cliente de uma maneira ou de outra (GARCIA. Veja a Tabela 1. Tabela 1 .Áreas fundamentais segundo o MSF Objetivo para o sucesso perante o cliente Entrega dentro dos limites do projeto Construir o que foi pedido Lançar a versão somente depois que problemas são identificados e corrigidos Lançamento sem imprevistos e preparação para a transição para operação em produção Ampliar a eficiência e eficácia do usuário final Satisfazer os clientes Arquitetar a solução para fácil manutenção e outras características Sintoma típico quanto o objetivo não é atingido “O projeto atrasou e ficou acima do orçamento” “O que foi construído na verdade não era o que queríamos” “Esta coisa é imprevisível – continuamos descobrindo novos problemas” “Não conseguimos fazer com que funcione em produção” “É simplesmente muito difícil de usar” “Não atende nossas expectativas. isto é. 1999). O principal é entender que cada papel advoga para um constituinte.38 Figura 4 – MSF – Fonte: MSF for Agile Software Development Process Guidance. 2009 A equipe é estruturada basicamente em sete áreas fundamentais para o sucesso do projeto perante o cliente. Não estamos contentes com o resultado” “Tivemos que pagar muito para adicionar funcionalidade mais Papel responsável pela obtenção do objetivo Gerência de Programa Desenvolvimento Teste Lançamento e Operações Experiência do Usuário Gerência de Produto Arquitetura .

Segundo Schwaber (2004). 1. ele não define o que fazer em toda circunstância. É árduo afirmar quem foi o fundamentador do MSF. Ele também foi influenciado por um relatório de projeto com produtividade acima da média. SCRUM não é um processo previsível. Microsoft. que é ganhar o jogo. com base neste artigo. 1999). visando alcançar os seus objetivos .4 SCRUM As raízes do SCRUM estão num artigo que sumarizam as 10 melhores práticas em empresas japonesas. Steve McConnell e Clementino Mendonça destacam-se entre muitos outros como personagens da história do MSF (GARCIA. quando os jogadores se organizam em círculo para planejar a próxima jogada. quando introduziu algumas das práticas do SCRUM. Este artigo introduziu o termo SCRUM. É uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos. 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. 2009). cujo título é "O jogo do desenvolvimento de novos produtos" que foi publicado na Harvard Business Review em janeiro de 1986. 2009. Para não ficar em branco com nomes. porém o grande patrocinador sempre foi a própria Microsoft.39 de alto nível tarde” Fonte: MSF for Agile Software Development Process Guidance. 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. que dentre outras coisas introduziu a reunião diária (MARTINS. Jeff Sutherland é um dos criadores do SCRUM e era vice-presidente da Easel Corporation em 1994. mas com uma visão de longo prazo. na Borland Corporation. Michael Cusamano. escrito por Takeuchi e Nonuka. que se refere ao jogo de Rugby.

. Entretanto.pdf. mas com certeza os problemas serão mais facilmente identificados. SCRUM é recomendado para projetos de outras áreas além de software principalmente para projetos de pesquisa e inovação (CHAPIEWSKI. não irá resolver todos os seus problemas. O conhecimento das suas práticas permite a aplicação das mesmas de forma variada e este é um dos aspectos positivos do SCRUM.4.se/Uploades/Scrum_eng_webb. Fonte: http://www. Por ser um framework.1 Como funciona? A Figura 5 ilustra o ciclo de desenvolvimento do SCRUM de forma simplificada. a adaptabilidade (SCHWABER. as decisões de quando e como usá-Io.40 Logo. 2009). 2004). o SCRUM não vai dizer exatamente o que fazer. 1. quais táticas e estratégias seguir para obter produtividade e realizar as entregas ficam por conta de quem aplicar.sof4thouse. 2009. Figura 5 – SCRUM. irá servir como um guia de boas práticas para atingir o sucesso. Vale ressaltar que as práticas do SCRUM podem ser aplicadas em qualquer contexto onde pessoas precisem trabalhar juntas para atingir um objetivo comum.

selecionar e estimar as tarefas que o time pode realizar dentro da Sprint. não mais que 15 minutos de duração.2 Papéis e responsabilidades Ele implementa uma estrutura iterativa e incremental através de três papéis principais: o Product Owner. Durante a execução da Sprint.Daily Meeting.4. uma reunião de lições aprendidas. sejam eles novos ou apenas requisitos modificados. com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint (FIGUEIREDO. realiza-se uma Reunião de Planejamento . Ao final da Sprint. chamada de Time-box. e observando o seu progresso usando um gráfico chamado Sprint Burndown.41 O ciclo do SCRUM tem o seu progresso baseado em uma série de iterações bem definidas.Sprint Retrospective.Sprint Review. Antes de cada Sprint. SCRUM torna-se ideal para projetos dinâmicos e suscetíveis a mudanças de requisitos. em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. o SCRUM Team e o SCRUM Master como descrito abaixo (ISOTTON NETO. cada uma com duração de duas a quatro semanas. 2008): . 2009). deve-se realizar uma Reunião de Revisão . 2009). 1. é preciso entender antes os seus papéis. 2009). Logo em seguida. No entanto para aplicá-Io. é feita uma revisão no produto entregue para verificar se tudo realmente foi implementado (PEREIRA et al. responsabilidades.Product Owner para priorizar o trabalho que precisa ser feito. o time controla o andamento do desenvolvimento realizando Reuniões Diárias Rápidas . 2009). realiza-se a Reunião de Retrospectiva .Sprint Planning Meeting em que o time de desenvolvedores tem contato com o cliente . conceitos e artefatos das fases de seu ciclo (FIGUEIREDO. A próxima fase é a Execução da Sprint (MOUNTAIN. Ao final de cada Sprint. chamada Sprints.

4.3. o Auto-organizado: organiza o time e o trabalho entre os membros de forma participativa. o Ao final da Sprint.1 Product Backlog . o Pode mudar os requisitos e prioridades a cada Sprint. 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 Facilita a colaboração entre as funções e áreas e elimina os impedimentos do time. entre os itens priorizados. o Participando das reuniões diárias. o Seleciona. entre 5-9 membros. conceitos e fases 1. revisão da Sprint e planejamento. o Garante que o processo está sendo seguindo.3 Artefatos. • SCRUM Team o Multifuncional. o Aceita ou rejeita o resultado de cada Sprint.4. decide a data de release e o que deve conter nela. • SCRUM Master o Garante que o time esteja totalmente funcional e produtivo. realiza o demo do produto finalizado. o Protege o time de interferências externas. o Prioriza os requisitos de acordo com o seu valor de mercado. 1. o É responsável pelo Retorno Financeiro (ROI) do produto.42 • Product Owner o Define os requisitos do produto.

43 Um dos conceitos mais importantes são o Backlog do produto (ou Product Backlog) e o Backlog de Impedimentos . em tempo ou tamanho. 2004). exemplos: "instalar ambiente para os desenvolvedores". 2009).2 Planejamento da Sprint A atividade que precede o início da Sprint chama-se Sprint Planning Meetinq reunião de planejamento da Sprint. todas elas precisam que cada item seja identificado e estimado. "Instalação de banco de dados do projeto" e etc. . O Product Backlog contém uma lista de itens priorizados que incluem tudo o que precisa ser realizado. mas estão geralmente associados a algum item de Backlog do produto ou ás tarefas do item.4. É lógico que a equipe precisa de tempo para poder estimar com segurança. Com esses atributos.Business Value. é possível ter os itens em uma ordem de priorização (SCHWABER. O Impediment Backlog contém todos os itens que impedem o progresso do projeto e geralmente estão associados a riscos. mas ela deve ser sempre guiada pelo SCRUM Master para que seja produtiva e não disperse e perca o foco (PEREIRA et al. no qual podemos medir o retorno do projeto e priorizar a realização dos itens. É importante ressaltar que cada item no Backlog do produto deve ter um valor de negócio associado . ambos considerados o coração do SCRUM. Deve-se ter cuidado para que essa reunião não extrapole a duração planejada e seu objetivo (PEREIRA et al. abrindo caminho para o time de desenvolvimento executar a realização dos itens do Backlog do produto (SCHWABER. e que a sua ordem de importância seja estabelecida pelo cliente.lmpediment Backlog. Existem muitas formas para gerenciar o Product Backlog e o Impediment Backlog. 2009). que possa ser associado com valor de negócio e para a finalização do projeto. 1. 2004).3. sejam requisitos funcionais ou não. Estes itens não possuem uma priorização. Essa atividade é muita importante e precisa de alguma preparação. O controle desses itens é muito importante e o SCRUM Master é o grande responsável pela liberação desses impedimentos.

pode-se iniciar a reunião de planejamento. Não é mandatário. 2004). que são os itens do Backlog priorizados para a Sprint. 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. Estando preparados os itens acima. Se for necessário. mas precisa saber o motivo do item estar lá. o time seleciona os itens que acha possível de executar durante a Sprint. • Todos os itens devem ter uma nota em função de sua importância. 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. estimando em horas. mas é sugerido que cada tarefa não ultrapasse a duração de 16h. Uma vez que todas as tarefas foram estimadas. a duração de cada uma delas. • Apenas o Product Owner tem o poder de associar a nota de importância de cada item do Product Backlog. • Essa nota serve apenas para organizar os itens por importância. precisamos apenas garantir: • Que o Product Backlog exista e cada item esteja estimado.44 No planejamento da Sprint o Product Backlog deve estar pronto antes de cada reunião. • Deve existir apenas um Product Backlog e um Product Owner. deve-se quebrar a tarefa até que individualmente todas as tarefas estejam dentro do limite de 16h. o time questiona se realmente consegue assumir o . 2006) Não. Para cada item. As dúvidas do time são esclarecidas e ao final temos então o Sprint Backlog. 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. normalmente ele é o autor do mesmo. • O Product Owner deve entender todos os itens do Product Backlog. mas em alguns casos outras pessoas podem ter colocado itens no Backlog. O objetivo da reunião é priorizar os itens que serão executados na Sprint. Com o Product Backlog priorizado. • Ele não precisa saber como cada item deverá ser feito. o time inicia o detalhamento de suas atividades.

o time passa para o próximo e esse processo continua até que todos os itens do Sprint Backlog sejam validados. Após a estimativa refinada. A relação de 1 homem/dia efetivo = 6 homens/hora efetiva é mais real dependendo do tipo do projeto. Com a simulação a seguir. Este limite é conhecido por LHS (Limite de Horas da Sprint) que pode ser medido utilizando uma fórmula simples (PEREIRA et al. . 2004). É importante deixar sempre uma folga. 2006). apenas se estabelece as estimativas em horas para cada uma. Uma vez ajustados os valores e com o time se comprometendo com a execução das tarefas. Esta sobra é importante. O próximo passo é iniciar a execução da Sprint. é importante considerar isso na fórmula. já que mesmo detalhando a estimativa sempre podem aparecer surpresas (PEREIRA et al. existe um ambiente completo para a produção do resultado final da Sprint. apenas 75% do tempo real do recurso é considerado produtivo para a Sprint. pode se entender melhor como calcular o LHS (KNIBERG. 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.45 compromisso de realizar tarefas dentro da Sprint e finalizar o item selecionado (SCHWABER. É importante lembrar que a Sprint possui um limite de horas disponível. pois fornece uma idéia mais realista da produtividade de cada recurso e também garante uma margem de segurança para eventuais imprevistos. Nesse momento. 2009). Uma vez decidido o item. Isso significa que se devem considerar apenas seis horas efetivas de cada recurso das oito normalmente trabalhadas. pode-se calcular o total de horas necessário para realizar todas as tarefas. não são alocados os recursos para as tarefas.

((3x6) + (4. temos o LHS diário considerando a relação acima sugerida de (MOUNTAIN. Logo.5) + (3)) = 31. e apenas será real se as Sprints forem de tamanhos iguais (SCHWABER.50 h Esses são cálculos bem simples e você vai precisar usá-los apenas antes de cada planejamento da Sprint.46 Para uma Sprint com time-box padronizado em 5 dias e um time possui 5 recursos em que 3 são de 8h. pois todo o projeto é guiado por essa duração.50 (dia) LHS= 5 x 31. 2004) . 2004).5h (1) 8hx50% = 4h x 75% =3h (1) Dias úteis da Sprint = 5 logo. É importante salientar que uma vez estabelecido a duração da Sprint não deve alterar sua data final. mas apenas alocado por 50% de seu tempo. 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. Esta métrica é muito importante. adiantar ou atrasar não é interessante para ninguém. e isso comparado a um histórico. pois o LHS é que vai indicar se você está alocando as horas corretas para a equipe (SCHWABER.50 = 157. um de 6h e outro de 8h. 2009): 8hx75% = 6h (3) 6hx75% = 4. Outro motivo importante para se manter o padrão de duração da Sprint é a relação de produtividade do time dentro da Sprint.

Essas reuniões devem ser rápidas. Todos participam. esse é um dos principais papéis do SCRUM Master. O acompanhamento do progresso é feito realizando reuniões diárias. 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. Um fator importante de sucesso para o time com o uso do SCRUM é o controle da disciplina. que são respondidas por cada membro (PEREIRA et al. O Gráfico 1 ilustra um exemplo: . O time é considerado auto-gerenciável e deve responder como tal. Para isso. mas devem ser apenas ouvintes. e objetivas. chamada de daily meeting. blindar o time de qualquer desvio do objetivo traçado. controla como as tarefas devem ser executadas. Durante a Sprint não deve existir interferência externa. 2007). apenas com os envolvidos. o SCRUM Master e o time.47 1. a equipe trabalha apenas três perguntas.3. 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. No daily meeting.4. não mais que 15 minutos. cada membro da equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e dependência entre elas. (PEREIRA et al. Para esse acompanhamento.3 Execução e controle da Sprint Durante a Sprint. Visitantes são bem-vindos. Durante a execução da Sprint. o time usa um gráfico chamado de Sprint Burndown. 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. pois o daily meeting resume-se ao time. o time. de forma organizada. a alocação de recursos para cada tarefa é dirigida pelo próprio time.

51 O Sprint Burndown é um gráfico muito simples que indica o consumo de horas diárias. Kniberg. p. Mesmo se existir um comportamento linear para os dias. 2003). de uma forma ou de outra o total de horas naquele momento aumentou. O eixo X indica a escala de horas totalizando o valor de horas estimado para a Sprint. Os Gráficos 2 e 3 ilustram algumas dessas oscilações (ANDERSON. Este comportamento indica que algumas estimativas foram erradas ou novas tarefas foram adicionadas.48 Gráfico 1 – Sprint Burndown (adaptado). . 2006. e o eixo Y os dias que representam o tamanho da Sprint de acordo com seu time-box. a soma de horas pode oscilar para cima. Estas oscilações podem ser perigosas e precisam ser acompanhadas diariamente.

Kniberg. Logo.49 Gráfico 2 – Sprint Burndown (adaptado). 2003). é preciso rever as estimativas. p. Talvez seja necessário rever os itens do Product Backlog remanescentes e eliminar aqueles com grau de importância menor (ANDERSON. 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.51 O Gráfico 2 indica que a Sprint irá acabar depois da data final. 2006.

pois basta olhar para ele para realizar a leitura do progresso da Sprint. as decisões sempre devem ser tomadas junto com o Product Owner. nunca apenas pelo time. pois o gráfico indica que a Sprint será concluída antes do esperado.52 O Gráfico 3 ilustra uma situação inversa. Veja sugestão na Figura 6: .50 Gráfico 3 – Sprint Burndown (adaptado). 2006. separando-as em basicamente quatro estados: Para fazer. p. Para Verificar e Concluído. Kniberg. Nesse caso. Em andamento (inclui o nome do responsável por executar a tarefa). dos itens de Backlog da Sprint. Esse "quadro" é muito produtivo. é preciso adicionar novos itens do Product Backlog. inclusive nele pode-se indicar se existe algum impedimento para que as atividades sejam executadas conforme planejado (ANDERSON. O time também possui um "quadro de trabalho" no qual organiza as atividades. 2003). Em ambos os casos.

4. . o time entrega o produto testado e revisado realizando uma demonstração prática. p.3. a reunião de retrospectiva é realizada. podendo ser chamada também de "lições aprendidas". Nela. Nesta. 2007). Kniberg. atendidos e/ou o produto final tenha sido aceito pelo cliente (PEREIRA et al. acontece a reunião de revisão. Após esta reunião.49 1. Estas ações são levadas para a próxima Sprint melhorando o processo e/ou produto.51 Figura 6 – Quadro de tarefas (adaptado). 2006.4Final da Sprint Ao final de cada Sprint. Este é o momento do Product Owner inspecionar o produto final e verificar se o mesmo está como foi pensando. O ciclo do SCRUM é repetido até que todos os itens do Product Backlog tenham sido finalizados. o time levanta tudo de bom e ruim que ocorreu e procura estabelecer pontos de melhoria.

as pessoas perceberam que as técnicas para controle de custo. As organizações modernas estão descobrindo que a utilização do gerenciamento de projetos traz muitas vantagens. técnicas e metodologias avançadas de que dispomos hoje. 2009). Clientes esclarecidos exigem cada vez mais produtos melhores e serviços mais rápidos. seja erguendo pontes. As pressões para acompanhar a velocidade do mercado demandam maior eficiência. Mesmo sem as ferramentas. alocaram materiais e recursos e avaliaram os riscos envolvidos em seus projetos.52 2. as pessoas criaram linhas de tempo. (PMI® -SP. realizando colheitas sazonais ou decidindo como se governar.1 O gerenciamento de projeto As pessoas têm planejado e gerenciado projetos desde o início dos tempos. desenvolvimento da programação. (PMI® -SP. procura e compra de recurso e gerenciamento de riscos poderia ser aplicado a uma variedade de projetos. 2009). Estas idéias foram precursoras do estabelecimento de técnicas de gerenciamento que hoje conhecemos como "Gerenciamento de Projetos Moderno”. Com o passar do tempo. estradas a pavimentar e leis a serem escritas. PMI® e PMBOK® 2. Toda vez que uma civilização criou suas raízes houve projetos a serem gerenciados: prédios a construir. Gerenciar projetos de forma profissional encontrou seu lugar na arena empresarial competitiva e global de hoje. .

O primeiro Capítulo do PMI® foi oficializado e o primeiro Programa de Prêmios Profissionais estabelecido.500 associados e em 1993 este número crescia cerca de 20% ao ano.2 História O Project Management Institute (PMI® ) foi fundado em 1969 por cinco voluntários. uma série de programas educacionais em Gerenciamento de Projeto. o PMI® somava mais de 2. e posteriormente renomeada para Project Management Journal (PMJ). bem como os programas e serviços oferecidos pela associação. a primeira edição do Project Management Quarterly (PMQ) foi publicada. Em 1990. O PMI Today® . 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)". o número de associados do PMI® continuou crescendo. revista mensal do PMI® . Nos anos setenta. com a participação de 83 pessoas. O primeiro livro do PMI® foi co-publicado e nasceu a PMNetwork®. Em função deste crescimento foi estabelecida a Divisão de Publicações do PMI® na Carolina do Norte. Durante os anos noventa foram formados os Grupos de Interesses Específicos.53 2. Geórgia EUA. Durante aquele mesmo ano. boletim informativo mensal do PMI® . Um Código de Ética foi adotado para a profissão e o primeiro Project Management Professional (PMP®) foi credenciado. As publicações do PMI® sobre produtos e serviços cresceram rapidamente durante esta década. os Colleges e o Seminars USA. o primeiro PMI® Seminars & Symposium aconteceu em Atlanta. oficializando sua fundação. um guia englobando todas as áreas do conhecimento que regem as regras do gerenciamento de projetos. Ao final da década. foi impresso pela primeira vez e o Programa de .000 associados no mundo (PMI® -SP 2009). o PMI® somava mais de 8. EUA (PMI® -SP 2009). A Comunidade da Pensilvânia emitiu as Cláusulas de Incorporação do PMI® . O primeiro modelo padrão de Gerenciamento de Projetos foi publicado: o Special Report on Ethics Standards and Accreditation (PMQ). Durante os anos oitenta.

é um padrão globalmente reconhecido para o Gerenciamento de Projetos nos mercados de hoje. serviços financeiros.000 associados. o PMI® tinha mais de 50. outros padrões foram desenvolvidos. o PMI® se tornou.000 associados em 170 países. O PMBOK® Guide é aprovado como um Padrão Nacional Americano (ANS) pelo Instituto de Padrões Nacional Americano (ANSI). Além do guia PMBOK® .000 cópias do guia PMBOK® estavam em circulação (PMI® -SP 2009). Os associados do PMI® são indivíduos praticando e estudando o Gerenciamento de Projeto nas mais diversas áreas. 2003).54 Desenvolvimento Profissional foi estabelecido para que os profissionais credenciados como PMP mantenham sua certificação. No inicio do século 21. Com o passar do tempo.3 Hoje Atualmente o PMI® conta com mais de 250. 2. 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. mais de 10. automobilística. BOCOLI. a principal associação profissional em Gerenciamento de Projetos. construção. estando disponibilizados aos associados (PMI® -SP. engenharia. 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. como aeroespacial. farmacêutica e telecomunicações (PMI® -SP. O PMI® está compromissado com a expansão e melhoria contínua do guia PMBOK® . e continua sendo. 2009): . 2009). administração.000 Profissionais de Gerenciamento de Projeto (PMP) credenciados e mais de 270. O principal documento padrão do PMI® . assim como com o desenvolvimento de padrões adicionais (NETO. tecnologia da informação. 2009). "A Guide to the Project Management Body of Knowledge".

“Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à ® .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® .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 . ele é “Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos”. Está atualmente na quarta edição. “Identificar” significa fornecer uma visão geral. embora não seja o único. 2. Como o próprio nome em português diz. 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. TEIXEIRA. e não uma descrição completa.4 PMBOK® O Project Management Body Of Knowledge ou simplesmente guia PMBOK® é o principal documento de referência do PMI® . 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. lançada em 2008 (CAMPOMORI.

e que existe um consenso geral em relação ao seu valor e sua utilidade. 2.6 Gerenciamento de projeto . serviço ou resultado exclusivo significa que as entregas são únicas. os recursos. p.5 Projeto Projeto é descrito pelo guia PMBOK® (PMBOK® . mas não o projeto. no entanto precisa ter uma data de fim já que um projeto não é eterno. logo para isso é importante ter bem claro quais os objetivos do projeto. serviço ou resultado exclusivo”. a equipe de gerenciamento de projetos é responsável por ® determinar o que é adequado para um projeto específico (PMBOK . ainda assim cada prédio possui sua singularidade. 9). Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos. pois há elementos que os tornam únicos. ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Quando diz produto. Cada prédio é diferente um do outro. Embora haja elementos que se repetem. sejam a data. Algumas destas definições são descritas abaixo. as pessoas que estão envolvidas. pois possuem diferentes proprietários. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades. 2008. O guia exemplifica através do exemplo da construção de prédios. Basicamente quando os objetivos do mesmo são alcançados chegasse ao fim. No guia PMBOK® encontram-se muitas definições e práticas que guiam a gerência de projetos em geral. significa que o projeto deve ter um inicio e fim definidos. O produto gerado pelo projeto até pode ter vida “eterna” e/ou indeterminada. Quando diz temporário. 2008) como “um esforço temporário empreendido para criar um produto. locais diferentes. 2.56 maioria dos projetos na maior parte do tempo. porém projetos podem levar dias. Quando se fala em temporário pensa-se instintivamente em um curto espaço de tempo. construtoras diferentes. meses ou até anos.

cliente.57 O guia define a atividade de gerenciamento de projeto como: “a aplicação de conhecimento. Segundo o PMBOK® processo é: “um conjunto de ações e atividades interrelacionadas realizadas para obter um conjunto pré-especificado de produtos. controlar e executar as atividades do mesmo. 2008). p. É a pessoa que financia e/ou defende o projeto dentro da organização.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. 2008. conforme o projeto (TAVARES. Para isso ele precisa planejar. Dentre os interessados. dentre outros. 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. a equipe do projeto. inclusive o próprio Gerente de Projeto. ou patrocinador do projeto. conforme ilustrado na Figura 7. ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos” (PMBOK® . O termo Stakeholders descreve todas as partes envolvidas ou interessadas no projeto. um dos mais importantes é o Sponsor. resultados ou serviços” (PMBOK® . p. Outros exemplos de partes envolvidas: fornecedores. 38). . 11). habilidades. 2. usuários finais. sociedade. 2008.

conforme Figura 8. ® “Estes grupos de processos não representam necessariamente uma fase do projeto.58 Figura 7 . Fonte: PMBOK .Grupos de Processos. 41). ® Os processos segundo o guia ainda são distribuídos em cinco grupos que se integram entre si. 19. 19.Formato de Processo. p. p. p. Fonte: PMBOK . 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® . Figura 8 . . 2008. 2008. 2008.

ou contratante Fazer uso mais efetivo do pessoal envolvido com o projeto Assegurar que as informações do projeto sejam adequadamente obtidas e transmitidas Assegurar um tratamento seguro ao risco do projeto.Áreas do conhecimento Área do conhecimento Integração Escopo Objetivo Assegurar que todos os elementos do projeto sejam adequadamente coordenados Assegurar que todo o trabalho requerido – e somente aquele requerido – esteja incluído no projeto. para concluí-lo de maneira bem sucedida Assegurar a conclusão do projeto no prazo previsto Assegurar que o projeto seja concluído dentro do orçamento previsto Assegurar que os produtos ou serviços do projeto estejam em conformidade com o solicitado pelo cliente. Gerenciamento de Custos do Projeto. Gerenciamento de Tempo do Projeto. Gerenciamento das Comunicações do Projeto.8 Áreas de conhecimento O guia também organiza os 42 processos em nove áreas de conhecimento. Gerenciamento de Recursos Humanos do Projeto. Gerenciamento de Riscos do Projeto.59 2. Gerenciamento da Qualidade do Projeto. conforme listagem abaixo e Tabela 2: • • • • • • • • • Gerenciamento de Integração do Projeto. análise e resposta Tempo Custos Qualidade Recursos Humanos Comunicações Riscos . Tabela 2 . cuidando de sua identificação. Gerenciamento do Escopo do Projeto. Gerenciamento de Aquisições do Projeto.

20.60 Aquisições Fonte: PMBOK . ® Adquirir bens e serviços de fora da organização promotora 2. 2008. p.Mapeamento dos processos nos grupos de processos e áreas de conhecimento.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. Grupos de Processos Áreas de conhecimento Integração Iniciação Desenvolver Termo de Abertura Planejamento Desenvolver o plano de gerenciamento Execução Dirigir e Gerenciar a Execução do Projeto Controle Monitorar e controlar trabalhos do projeto Desenvolver controle de mudanças integrado Controlar escopo Encerramento Encerrar projeto ou fase Escopo Obter requisitos Definir escopo Criar WBS Definir atividades Sequenciar atividades Estimar recursos por atividades Estimar duração de atividades Desenvolver cronograma Estimar custos Determinar orçamento Planejar qualidade Desenvolver garantia da Qualidade Contratar time do projeto Desenvolver time do projeto Gerenciar time do projeto Tempo Controlar cronograma Custos Controlar custos Qualidade Executar controle de qualidade Recursos Humanos Desenvolver plano de recursos humanos . Tabela 3 .

2008. 21-22 Ao olhar para esta tabela. p. já que boa parte. .61 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 Planejar aquisições Conduzir aquisições Monitorar e controlar riscos Aquisições ® Administrar aquisições Encerrar contrato Fonte: PMBOK . 20 dos processos estão concentrados no grupo de planejamento. é perceptível o forte foco do guia em planejamento.

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

No gerenciamento tradicional de projetos. 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.63 Em contrapartida. ele verifica se os valores e práticas estão sendo adotados. Elas se apresentam como uma coleção de boas práticas. 2005). se há escassez ou . é preferível seguir um líder a ser limitada por um gerente. que parte do princípio de que o planejamento direciona os resultados e que entregar o planejado é sinônimo de sucesso em um projeto. Ao conduzir o projeto. A abordagem ágil esforça-se para reduzir o custo de mudança ao longo do processo de desenvolvimento de software (NESMA. as metodologias ágeis vêm-se consolidando e atraindo novos adeptos. especialmente adequadas para projetos de natureza exploratória desenvolvidos por equipes pequenas. que facilita a comunicação e direciona a equipe. de forma a não gerar documentação além do necessário. 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. certificar-se exatamente sobre o que ele quer. O que muda na abordagem ágil. tácito. Como a abordagem ágil não impõe uma estrutura de gerência no estilo “comando-e-controle”. tornando-se muito mais rápido e sendo executado diversas vezes. a documentação muitas vezes é relegada a segundo plano em prol do conhecimento implícito. Como a abordagem ágil transmite muita confiança na comunicação oral. É necessário buscar um ponto de equilíbrio. e não desencorajá-la por meio da aplicação de procedimentos que restringem e diminuem a criatividade. porém. é que o ciclo fica reduzido em algumas semanas para cada componente funcional desenvolvido. construir a solução e entregá-la ao cliente. 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. calcular o esforço. A abordagem ágil introduz o papel de um orientador. se não existe conflito técnico ou pessoal na equipe. mas destaca a necessidade de líderes para resolver os problemas e necessidades de clientes. o ciclo de vida ágil é semelhante a qualquer outra abordagem de desenvolvimento: descobrir o que o cliente quer. Na sua essência. ela não enfatiza o papel do gerente. Para a equipe.

porém um plano de projeto muito detalhado é. com objetivos claros e foco forte nos valores empresariais – principalmente custos e prazos. mas não no senso rigoroso de um processo baseado em papel ou uma metodologia centrada em controle. uma vez que uma das premissas principais da abordagem ágil é entregar incrementos de funcionalidade específicos em curto espaço de tempo. a aplicação da abordagem ágil para planejamento estratégico ou priorização de projetos não será eficiente. que podem considerar os riscos do projeto como fator de ajuste na busca do ponto de equilíbrio entre elas (COCOMOII. e que primam pela inovação. Ela está sendo refinada e amadurecida a partir de observações sobre o uso . 2009). Também é adequada para o detalhamento do trabalho tático necessário para completar um projeto. o planejamento deve também enfocar e entender o contexto organizacional no qual o projeto está sendo desenvolvido. inadequado. bem como para mudanças mínimas requeridas na manutenção de sistemas É importante destacar que a abordagem ágil não é estritamente uma metodologia. política e diretrizes financeiras. as características do projeto a ser desenvolvido. avaliar custos. Além de identificar as expectativas e requisitos do cliente. necessitando de grande participação do cliente durante todo o processo. Por outro lado. na escolha da abordagem. A dinâmica requerida em projetos de natureza exploratória. 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.64 excesso de recursos. inviabiliza o uso da abordagem tradicional. geralmente. pois o risco de alterar um produto depois da conclusão de uma fase de seu ciclo de vida é bastante alto. valores e princípios. O essencial para contornar as diferenças está em considerar. A abordagem ágil é mais adequada para projetos definidos em alto nível. As atividades fundamentais de planejamento são necessárias. 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. incluindo cultura. Há processo. benefícios e riscos necessários para atender aos requisitos. mas uma visão e um conjunto de atitudes. buscando aplicar a ferramenta correta para o trabalho a ser realizado.

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

3. se necessário. 2009 Simplicidade: partem do princípio de que é preferível fazer algo simples de imediato e pagar um pouco mais para alterá-lo depois. o sucesso do projeto. quando não é verdade uma vez que ele é perfeitamente aplicável com um modelo iterativo. Ela discute com muita propriedade a maneira de como trabalhar com PMBOK® e Metodologias Ágeis. conforme os releases e iterações. definindo como o projeto será executado e controlado. No planejamento o principal processo é o desenvolvimento do plano do projeto. São burocráticas: geram muita sobrecarga no desenvolvimento a ser realizado. De acordo com ela. do que fazer algo complicado de imediato e acabar não utilizando depois. Ela diz que para cada uma das áreas do PMBOK® . Fonte: COCOMOII. Já nas Metodologias Ágeis o plano é feito e revisitado continuamente. ela é certificada PMP e entende a dificuldade que é percorrer entre as melhores práticas do PMBOK® e a abordagem ágil. apesar das diferenças de filosofias entre as duas. comprometendo a velocidade de desenvolvimento e. porém a forma de executar é diferente. ela descreve as similaridades entre PMBOK® e os métodos ágeis. Sliger (2006) trafega com muita desenvoltura pelos cinco grupos de processos do guia PMBOK® . mas as abordagens de um modo geral. Da mesma forma o controle integrado de . Segundo ela. com uma visão não apenas didática. suas práticas têm práticas relativas nas Metodologias Ágeis. por muito tempo o PMBOK® tem sido associado ao modelo em cascata. nos artigos. Mas é claro que ter um controle de mudanças gera alguma burocracia e atraso. com um nível de detalhe o suficiente para a realidade daquele instante.66 Gerente de projetos para pequenos impactos. onde contém os planos para cada uma das áreas. 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. não SCRUM especificamente. mas ao que parece de quem tem experiência prática sobre o que está descrevendo.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). muitas das práticas do PMBOK® são compatíveis com as práticas ágeis. muitas vezes. Nos artigos.

Fonte: Sliger. 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. Ao invés de conter todo o trabalho para o projeto como normalmente é feito no PMBOK® .67 mudança é natural no dia-a-dia da equipe. 2006. e durante as reuniões de planejamento e revisão de iteração e releases.WBS (Adaptado). Figura 9 . Enquanto o PMBOK® procura blindar o escopo contra mudanças. Nos métodos ágeis também é de extrema importância. Ver Figura 9. Na abordagem ágil o risco é tratado . 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. Durante o início da iteração as funcionalidades são então quebradas em tarefas. a abordagem ágil aceita a mudança. o gerenciamento do escopo do projeto recebe grande atenção. Considerada uma das áreas de conhecimento mais importantes do PMBOK® e por isso. porém a filosofia é totalmente diferente. e ocorre através das priorizações feitas pelo cliente no backlog. Uma abordagem interessante colocada por Sliger (2006) é a forma de criar a WBS.

Outro ponto de reflexão interessante é o que diz que os “profissionais não são pagos para codificar. documentos ou planos. 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. mas acima de tudo para entregar software funcionando para o cliente que responda efetivamente às necessidades do negócio”. sucesso do projeto é entregar dentro do prazo e custo enquanto que para o cliente. Outro ponto é que projetos de software necessitam de ambas as abordagens. Isso é feito nas reuniões diárias. a comparação entre sucesso do projeto e sucesso do cliente é provocadora. sucesso é atender suas necessidades. produzir modelos. entregando no prazo e no custo e atendendo as reais necessidades do cliente é sucesso “Total”. requer muita atividade intelectual.68 naturalmente no ciclo de vida do produto. nos dois modelos é previsto o controle de qualidade e controles em geral durante todo o projeto. Segundo o autor. Em sua apresentação. Koch publicado em 2004 intitulado “Are Agile Methods Compatible with the PMBOK?”. tradicional e ágil de gerenciamento. Uma segunda iniciativa pode partir de uma apresentação chamada “Gerenciamento de Projetos Iterativos e Metodologias Ágeis” de Márcio Tierno (2006). Atingindo os dois sucessos. retratado na Figura 10 (KOCK. e dentre alguns pontos interessantes colocados por ele. Nessa apresentação há muitos pontos de reflexão. nas reuniões de planejamentos e de revisão e de retrospectiva de releases e iterações. Uma terceira abordagem pode vir do artigo escrito por Alan S. 2004): . software é people intensive. ele faz um mapeamento dos grupos de processos do PMBOK® segundo o desenvolvimento iterativo. Para grande marcos. ou seja. É natural identificar e responder aos riscos continuamente. como releases. não deve ser tratado como linha de montagem. Sobre o gerenciamento da qualidade.

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® . ® Na apresentação. Ele elenca para cada grupo de processo a compatibilidade e incompatibilidade entre o PMBOK® e as metodologias ágeis e o que pode ser feito. Adaptação da apresentação de Koch (KOCH. .69 Figura 10 – Desenvolvimento Iterativo – Grupos de processos do PMBOK . 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. 2004). porém somente onde realmente é necessário e sem comprometer a agilidade”.

. 4. O plano também desenvolveu requisitos para o Sistema de Gerenciamento de Conteúdo de Web (WCMS). Como em muitos projetos de TI.70 4. estabeleceu e executou o projeto de implementação para o WCMS. procedimentos e estratégias de desenvolvimento de conteúdo.1 Metodologias ágeis e o guia PMBOK® . Técnicas de gerenciamento de projeto: mais perto do que você imagina 4. enfrentaram desafios de gerenciamento e de aceitação do cliente. 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. originalmente intitulado “Agile and PMBOK® Guide Project Management Techniques: closer than you think”.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. foi escrito por Peter Bennison em 2008 e publicado no site do PMI® . O projeto discutido aqui cobre a parte de implementação. ESTUDO DE CASO O estudo de caso que será retratado a seguir.1. entrevistar os stakeholders e desenvolver estruturas de governança. O objetivo do programa foi analisar o website existente.

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. com alguns detalhes de como a abordagem usando SCRUM explicitamente ou implicitamente as tratou. Todos os projetos de Tecnologia de Informação (TI) do governo devem satisfazer as exigências da Treasury Board of Canada Secretariat .1.mas o cliente não conhecia bem como configurá-lo e colocá-lo em produção.um produto de prateleira que todos os WCMS são obrigados a usar . planejamento e coordenação das atividades de projeto. Os elementos indispensáveis desta área de . configuração e utilização do produto.3 Gerenciamento de integração do projeto Gerenciamento de Integração do projeto se refere à premissa.71 Quando o planejamento da implementação começou. além do grande envolvimento do cliente. mas o framework tinha poucos exemplos práticos para orientar seu uso. O fornecedor possuía uma ampla experiência na instalação. mas a melhor estratégia de gerenciamento do projeto ainda não estava definida. 4.EMF).1.Enhanced Management Framework (TBS . havia alguma incerteza sobre como seria melhor executá-lo. pois esta abordagem se encaixava na escala do projeto. aproximadamente $2 milhões. O governo canadense tem um WCMS preferido . O fornecedor propôs que SCRUM fosse usado para gerenciar o projeto. Os mecanismos iterativos dentro do SCRUM também permitiam ao fornecedor demonstrar as capacidades do pacote WCMS gradualmente. 4.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.

Os defensores do SCRUM sentem que proporcionando apenas uma visão do projeto e uma lista de funcionalidades com prioridade. O projeto foi inicialmente planejado seguindo um cronograma limitado (horizonte de planejamento de aproximadamente seis semanas).68). sem o Termo de Abertura. os procedimentos de gerenciamento de integração não foram definidos explicitamente antes que uma abordagem ágil fosse sugerida. SCRUM não tem muito a dizer sobre planejamento e coordenação. Isto não prejudicou o pagamento da fase inicial. a abordagem do PMBOK® definiria o escopo do projeto. Embora o lado financeiro acabasse sendo acertado. mas mesmo assim causou um impacto no projeto. para definir formalmente o Termo de Abertura. De fato. p. 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. os papéis e responsabilidades não foram definidos formalmente antes que o desenvolvimento já estivesse bem adiantado. De acordo com Schwaber (2004. satisfazendo as diretrizes exigidas pelo EMF antes do início da analise e implementação. De acordo com Sliger (2006). No projeto estudado aqui. Em outras palavras. Por exemplo. "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". resultando em "diversas previsões e exercícios de planejamento realizados de um modo iterativo". o Termo de Abertura não foi aprovado antes do final das atividades de desenvolvimento da solução. os patrocinadores ficarão satisfeitos desde que estejam envolvidos ativamente. a definição do plano do projeto é um exercício de cooperação entre o cliente e o fornecedor. houve uma preocupação depois da definição de requisitos e antes do início do desenvolvimento. cronograma e custo antes de qualquer atividade de desenvolvimento ser iniciada. A principal razão para este atraso foi o cliente não ver benefícios. A aprovação do orçamento do projeto foi mais tênue e negociada mês a mês. que o projeto não . Isto resultou em uma série de pequenos contratos que foram gerados para estabelecer requisitos e escopo inicial. em termos de tempo e esforço.72 conhecimento são desenvolver o Termo de Abertura e o escopo preliminar.

Reunião de planejamento da iteração. como já foi mencionado. Ao final desta revisão. incluindo as seguintes tarefas: 1. a equipe pôde criar uma lista ordenada de funcionalidades que representaria a prioridade dada às funcionalidades individuais e atividades adicionais. Contra este cenário. o material gerado e apresentado aos patrocinadores do projeto depois que os requisitos iniciais foram desenvolvidos. • Segundo. 4. a equipe avaliou e estimou o esforço necessário para desenvolver cada funcionalidade. Reunião de revisão da iteração. Apesar da falta do Termo de Abertura bem escrito tenha levado a dificuldades desnecessárias. 3. A WBS estabeleceu o padrão que cada iteração seguiria. 5. Documentação. Esta revisão permitiu à equipe de desenvolvimento realizar duas coisas: • Primeiro. mostrou-se suficiente para obter a aprovação. como recomendado por Griffiths (2004). Outra diferença relativa ao que foi definido no guia PMBOK® . Desenvolvimento de critérios de aceitação. a equipe estava confiante que estimaram o esforço para atingir o critério de aceitação.73 fosse financiado. 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. Teste de aceitação. 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). Desenvolvimento das funcionalidades. Entretanto. 6. Usando os requisitos desenvolvidos na fase inicial de análise. . é que a WBS foi baseada nas funcionalidades a serem desenvolvidas em lugar de tarefas. isto não afetou o início do processo de execução. 2. SCRUM trouxe efetivamente processo e disciplina nas áreas de escopo e planejamento.

e somente o trabalho necessário. seguindo a definição como uma das áreas de conhecimento do guia PMBOK® . 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.1. o que foi essencial desde que havia uma mistura de pessoal de desenvolvimento do cliente e do fornecedor. p. Na seção ferramentas e técnicas do capítulo sobre Gerenciamento de Escopo do projeto deixa . Da perspectiva do gerenciamento de integração do projeto. p." (PMBOK® . para completar o projeto com sucesso. Estes sete elementos foram repetidos em cinco iterações. Reunião de revisão do processo SCRUM. 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 Gerenciamento de escopo do projeto Gerenciamento de escopo do projeto. 103) parece estar alinhado com a filosofia do SCRUM envolvendo gerenciamento de escopo. O Product Backlog também permitiu que a distribuição de trabalho e de responsabilidades fosse claramente indicada. citando Turner (2002.103). Em teoria. Além disso. 4. está em desacordo com SCRUM. que disse "Gerenciamento de Escopo de Projeto inclui os processos necessários para garantir que o projeto contenha todo o trabalho necessário. Finalizando. 2008. 94). 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. p. este projeto confirmou uma observação de Griffiths (2004) que uma abordagem utilizando o guia PMBOK® pode coexistir com uma abordagem SCRUM.74 7." Entretanto. SCRUM trouxe rigor suficiente para suprir as expectativas do cliente relativas a esta área. o guia PMBOK® (2008.

o cliente e o fornecedor co-definiram critérios de aceite para cada funcionalidade a ser desenvolvida. o cliente verificou que as funcionalidades cumpriam o critério de aceite. Análise de variação) são difíceis de atualizar e rapidamente ficam obsoletas. Após cada iteração. A abordagem do projeto de referência foi diferente da abordagem de um projeto tradicional das seguintes maneiras: • • Primeiro. No início de cada iteração. Segundo. p. as ferramentas que foram implementadas para gerenciar o escopo (por exemplo: WBS. Este documento disponibilizava uma opção "gold/silver/bronze" que delineava os custos e benefícios de diversas abordagens de design para uma funcionalidade. Para cuidar desta limitação. 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. principalmente porque esta foi criada para orientar o desenvolvimento. o projeto não ajustou a WBS inicial. mas consciente que mudanças no esforço resultariam em custo adicional. 2008. em lugar de manter o documento de escopo atualizado.75 bem claro que o escopo deve ser gerenciado e controlado utilizando ferramentas centralizadas e processos de tomada de decisão (PMBOK® . Detalhes sobre como estes ajustes em custo foram gerenciados estão na seção "gerenciamento de custo de projeto". O projeto de referência usou o conjunto de ferramentas do SCRUM para gerenciar as mudanças de escopo. . o fornecedor produziu um documento de discussão do escopo para descrever as opções para as funcionalidades essenciais do sistema.121). Isto causou um desconforto no cliente relacionado às mudanças de escopo realizadas durante a implementação. 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. Foram usados o Product Backlog e o critério de aceite de alto nível para estabelecer a prioridade e o cronograma do desenvolvimento. existiram três oportunidades distintas para ajustar o escopo de cada iteração. mas como foi notado por Griffiths (2004). em lugar de um controle estrito de mudanças.

em lugar de entregar um documento de arquitetura de sistema antes da implementação.1.5 Gerenciamento do tempo do projeto Considerando o gerenciamento do tempo. Em geral. Depois da agitação inicial em torno da geração da WBS do projeto e da documentação relacionada. . 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. crucialmente. 2º artigo #3). em lugar de uma lista detalhada de tarefas e cronogramas. implementaram o projeto. "As práticas de definição do escopo. 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. Assim. 4. cronograma e controle do cronograma adequado. utilizando esta abordagem iterativa. os processos SCRUM acabarão tornando o plano inicial obsoleto. as abordagens são diferentes. uma lista detalhada de tarefas e escopo originalmente definida nos estágios de planejamento. a não ser que exista uma atividade constante para atualizar a WBS. No projeto de referência. Entretanto. Ou. para as outras subáreas.76 • Terceiro. projetos usando SCRUM e PMBOK® são semelhantes na definição de atividades e estimação/duração de recursos. estará significativamente diferente quando o projeto chegar ao fim. o gerenciamento de escopo de projeto não pode ser realizado usando a abordagem do PMBOK® em uma implementação usando o SCRUM. o cliente determinou a seqüência do Product Backlog e a lista de funcionalidades a serem incluídas na solução final. De acordo com Sliger (2006. a WBS pode ser concebida como um guia. A equipe de desenvolvimento determinou a estimativa para a solução final e. Isto permitiu que eles pudessem avaliar rapidamente o impacto na estimativa de esforço quando ocorresse uma mudança no escopo. criação da WBS e verificação de escopo do guia PMBOK® ocorrem iterativamente na metodologia ágil". SCRUM dita que a equipe do projeto deve colaborar para definir a seqüência.

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. ficava claro que a equipe do projeto deveria avaliar como recuperar este tempo. tarefas foram explicitamente adicionadas ou modificadas para garantir que o diagrama capturasse todas as atividades relacionadas ao projeto. Todos da equipe podiam facilmente rastrear as divergências diárias. 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. mensais e do cronograma. Os motivos para o início vagaroso foram discutidos em iterações posteriores. As abordagens usando SCRUM e o PMBK são semelhantes nas definições de atividades e processos de estimativa. comparando o Product Backlog e o baseline a cada iteração de 20 dias. a equipe podia ver o tempo restante relativo ao baseline. Por último. A atribuição de tarefas foi realizada de acordo com o interesse/especialidade. Quando uma iteração não cumpria o prazo previsto. Ajustes diários refletiam a avaliação de cada membro da equipe do tempo restante da tarefa designada a cada um. controle e designação de tarefas são compartilhadas no SCRUM. Devido ao compromisso com a entrega a cada 20 dias. 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. o cronograma e o controle do cronograma foram tratados usando métodos do PMBOK® . a organização do cronograma. enquanto o PMBOK® utiliza uma abordagem centralizada. Cada iteração seguia uma curva "S" de conclusão. Estas estimativas foram revisadas no início de cada iteração para verificar sua exatidão. membros da equipe julgaram que não conseguiram progredir o suficiente no começo. . Diariamente.77 porque eles conheciam as hipóteses que foram assumidas. 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. e por diversas vezes. Por exemplo. a equipe do projeto e os patrocinadores puderam facilmente rastrear o desempenho. Contudo. Como resultado.

6 Gerenciamento de custos do projeto Esta é a principal interface entre o projeto e as funções de controladoria financeira de uma organização. Isto é. No final da iteração. No início de cada iteração. Como o Product Backlog incluiu estimativas iniciais de esforço. 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.78 4.171) tais contratos estimulam um comportamento self-serving do cliente e um comportamento defensivo do fornecedor. Além disso. No final da iteração. Entretanto o fornecedor propôs um mapeamento 1-a-1 entre cada iteração e cada TA. 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. mas de acordo com Poppendieck e Poppendieck (2003. Inicialmente. Escopo e Tempo são todos usados no cálculo do custo do projeto. É difícil para o SCRUM alterar estes processos porque na maioria das vezes estes existem devido à política ou motivos regulatórios. p. cada TA cobriria somente as funcionalidades a serem desenvolvidas em um período de 20 dias. parecia que SCRUM não poderia ser usado por causa dessa restrição. o cliente poderia ver como os contratos se relacionam com o esforço. mais alguma despesa extra.1. 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 . O PMBOK® aparentemente está em vantagem nesta área de conhecimento porque os artefatos e processos gerados através do gerenciamento de Integração. muitos projetos de TI têm "preço fechado". 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. um novo TA representando uma estimativa de esforço revisada e uma nova lista de funcionalidades seria assinada.

7 Gerenciamento de qualidade do projeto Nesta área. 2008. Enfim. SCRUM e o PMBOK® estão alinhados. A qualquer momento. mas o projeto de referência mostrou que a estrutura de custos existente "ditada" pelo contrato pôde ser usada para suportar SCRUM. 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. enquanto o fornecedor aprofundou seu conhecimento sobre os processos e o ambiente técnico 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. 180). o cliente pôde ver o valor de negócio no sistema em desenvolvimento. 2. Ambos reconhecem a importância do planejamento da qualidade e garantir a satisfação das expectativas do cliente e do sucesso em geral.79 de negócio. isto permitiu que o fornecedor e o cliente atuassem como parte de um time. Nesta área. Ao longe deste processo. 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. p. o PMBOK® e os requisitos de controladoria financeira têm a primazia. . 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® . Felizmente. 4. O cliente foi responsável pelo teste do sistema após cada iteração para verificar se o critério de aceite foi satisfeito. eles tinham a opção de ou mudar para um método mais tradicional ou simplesmente mudar de parceiro. se o cliente ou o fornecedor sentissem que não estavam obtendo o retorno suficiente diante do que foram investidos. empenhados a concluir o projeto com sucesso.

Tanto o PMBOK® quanto o SCRUM enfatizam que as metas de qualidade são elementos importantes de um projeto bem sucedido. 235) estabelece vários tipos/propósitos de comunicação e discorre sobre o planejamento do gerenciamento de comunicação com o stakeholder. 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. SCRUM e o PMBOK® divergem. teste e produção. Sem as reuniões de kick-off das iterações. então as funcionalidades mais importantes foram desenvolvidas primeiro. Como o processo de desenvolvimento foi iterativo e como o product backlog foi priorizado. As ferramentas e as técnicas podem variar para cada projeto.8 Gerenciamento de comunicação do projeto Aqui. O PMBOK® (PMBOK® . . clientes e stakeholders não poderiam revisar o progresso do projeto. assim foram sujeitas repetidamente a testes (mesmo que indiretos) porque posteriormente novas funcionalidades foram adicionadas ao sistema. mas os passos e procedimentos delineados no PMBOK® são aplicáveis a projetos usando SCRUM. 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. Estes elementos ajudaram a garantir que a qualidade do sistema pudesse ser testada repetidamente. mas comunicação é um item crítico.1. 4. 4.80 3. sem reuniões diárias. SCRUM estabelece reuniões regulares em cada iteração. 2008. Por exemplo. p. SCRUM não tem este nível de formalismo. os membros da equipe de desenvolvimento não saberiam como está o progresso de cada um.

Finalizando. 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. 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. sem reuniões periódicas para verificar o status do projeto com o executivo responsável. tanto que eram realizadas esporadicamente. . itens relacionados ao projeto não seriam levantados e nem revistos. Quando surgia algum problema. 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. SCRUM difere do PMBOK® porque não define um tipo nem um layout específico de comunicação. além de ajudar a deixar o usuário à vontade com o sistema final. registrar as decisões e definir as ações a serem tomadas. Ao longo do projeto. Segundo o SCRUM. uma vez que as reuniões são um item importante na metodologia SCRUM. No projeto de referência. este era rapidamente identificado e toda a equipe se envolvia para encontrar uma solução. a melhor ferramenta de comunicação e a abordagem adotada variam. Para cada situação. Além disso.81 Finalmente. pode ser suficiente usar um quadro e caneta para resumir o resultado de uma discussão. identificar os riscos. ou pode ser necessário gerar uma proposta formal para registrar as escolhas feitas relativas a um item técnico. os gerentes e arquitetos do fornecedor e o cliente se reuniam regularmente para discutir o progresso. Estas reuniões eram informais (mas documentadas) e serviam para acompanhar o progresso do projeto. 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. as reuniões de revisão da iteração eram moderadamente bem sucedidas. As reuniões diárias não foram bem sucedidas. 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. Isto foi surpreendente. o progresso da equipe era transparente para todos por causa das atualizações freqüentes do burndown chart. Estas reuniões ajudavam a estabelecer uma clara e significativa direção para o desenvolvimento.

uma organização deve determinar se a falta de suporte ao Gerenciamento de Escopo e de Comunicações do projeto impede seu sucesso. Gerenciamento de Tempo do projeto.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. Quando se avalia a adequação do SCRUM para um projeto. e foi de fato a razão chave para o sucesso deste projeto. Contudo.1. incluindo Gerenciamento de Integração do projeto. Pelas razões expostas acima. . o projeto de referência não foi afetado de modo significativo por estas limitações. Gerenciamento de Custo do projeto e Gerenciamento de Qualidade do projeto. existe pouco suporte do SCRUM para Gerenciamento de Escopo do projeto e Gerenciamento de Comunicações do projeto como delineado pelo PMBOK® . De fato.82 4. SCRUM proporcionou uma quantidade apropriada de estrutura e processo ao projeto.

O grande desafio não é iniciar a utilização das boas práticas. mas deixar o time. . 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. Em seguida. 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® ).83 CONCLUSÃO Neste trabalho. SCRUM ou um modelo híbrido. 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® . discutimos os méritos e os problemas das abordagens baseadas na metodologia ágil e no PMBOK® . seja utilizando o guia PMBOK® . o cliente e a empresa prontos para as mudanças de paradigmas que a metodologia ágil traz. 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. agilidade é chave para alcançar altos níveis de inovação em projetos. Atualmente. 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.

CHAPIEWSKI. riscos positivos e negativos. AGILE MANIFESTO. Planning Extreme Programming. Trabalho de Conclusão de Curso do MBA Executivo em Gestão Estratégica de Projetos pelo Centro Universitário UNA. 2009.. et. 2009. Programação extrema explicada. Manifesto for Agile Software Development. R.agilemanifesto. D.. set. 2007. n. n. p. Disponível em: < http://www. al. Disponível em: <http://www. 407-438. ANDERSON. 2001.. agilealliance. T.84 REFERÊNCIAS ABRAHAMSSON.unibh.com. org>. Agile software development methods. Q. 2003. 3. Addison Wesley. F.. Codificando Net: e-magazine. Acesso em: 10 ago. CORRÊA. A utilidade da gestão de projetos na internacionalização de empresas: uma abordagem sobre planejamento. Review and analysis. 2002.br/2008/05/27/como-estamos-indo-com-a-adocao-descrum-na-globocom/>. 13. M.. Prentice Hall.php? id . Acesso em: 10 ago 2009. ano I.. FOWLER. São Paulo: Bookman. BECK. Agile Management for Software Engineering: applying the theory of constraints for business results. P.blog. Agile Alliance. CÂMARA. 2000. Acesso em: 9 jun. ICSE.J.. A View of 20th and 21st century software engineering. B.>. Disponível em: <http://gc. . AGILE. G. Agile Alliance.br/imgMarketing/revistas/dcjpg/. Disponível em: <site1. Como estamos indo com a adoção de SCRUM na Globo./getdoc. Um cardápio ágil para todos os gostos. K. Acesso em: 18 maio 2009. BOEHM. 2001. 2006. K. CAMPOMORI.org/>. BECK.

br/revista/revista_ProQualiti_maio2005.proqualiti.extremeprogramming. C. Extreme Installed. 2001. 1999. Programming . Acesso em: 15 abr. 2009. 123p. Acesso em: 13 abr. ISOTTON NETO. 2009.featuredrivendevelopment. A.org. 120-122. Disponível <http://www. M. p. sept. FEATURE DRIVEN DEVELOPMENT. Visual Studio Team System. Disponível em: <www. Acesso em: 20 jun. HENDRICSON.martinfowler. São Paulo: Brasport. Addison-Wesley. 2. Scrumming: ferramenta educacional para ensino de práticas do SCRUM. Faculdade de Informática.pdf >..com/articles/newMethodology. GRIFFITHS. M.>. 2009. JEFFRIES. M. HIGHSMITH.pdf>. Disponível em: <www. J. The New Methodology..org>. E. Disponível em: em: em: FIGUEIREDO A. 2001. Disponível em: <http://www.cin. Acesso em: 10 set. Qualidade da produção de software. As armadilhas do SCRUM.ufpe. NJ. Agile Software Development: the business of innovation. 2008. FOWLER..com/>. Figura <http://www. Dissertação (Mestrado em Informática). Team Foundation Server. R. 2009. GARCIA.85 COCKBURN. Feature Driven Development. IEEE Computer. FDD. A. set. 2005..com/. M. Porto Alegre: Pontifícia Universidade Católica do Rio Grande do Sul. 2009. EXTREME PROGRAMMING. Acesso em: 10 set. Figura 1. Using agile alongside the PMBOK® . ANDERSON.html>. 2004. PMI® Global Congress Proceedings.br/~ers/SCRUM_MundoPM-Abril-Maio-2009. Disponível <http://www. Upper Saddle River.nebulon. Acesso em: 10. COCOMOII. 2009.

aspx?FamilyId=9F3EA426-C2B2-4264BA0F-35A021D85234&displaylang=en#QuickInfoContainer>.86 KNIBERG. n. 5. Scrum and XP from the Trenches. KOCH. Acesso em: 7 fev. p.com/technet/itsolutions/msf/default. 2004. Disponível em: <http://www.br/revista/revista_ProQualiti_maio2005. . 2009. 2-11. 1.pittsburghpmi. Universidade Federal do Rio de Janeiro. São Paulo: Brasport. Acesso em: 10 set.org. 2005.dc. n. 2006. July 2003. PMI® Journal. 2009. Acesso em: 28 jun. Disponível em: http://www. SUCESSOSW = CMM2 + PMBOK® .BR níveis G e F na organização EComponentes. Disponível em:< www2. How we do Scrum. H. 2009. 2009. v. F.mspx>. maio. J. NESMA.mountaingoatsoftware. NETO. Rio de Janeiro: UFRJ. processo de software MR MPS. 2009.proqualiti.pdf>. São ágeis e compatíveis com o PMBOK® ? Pittsburgh Project Management Institute. Acesso em: 2 ago. Agile Software Development Process Guidance. MARTINS. IM / DCC. nov. Acesso em: 10 jun. Técnicas para gerenciamento de projetos de software. 2005. J.microsoft.br/nourau/document/?down=573>. 2007. 1. Um estudo de caso da adoção das práticas e valores do Extreme Programming. 90. . 152p.C. 2009. Implantação do modelo de referência para melhoria de. Disponível em: <http://www. V.C.microsoft.org/documents/meetings/presentations/AgileManifestoPMBOK. Qualidade na produção de software. MANHÃES TELES. LAURINDO. Netherland Software Metrics Users Association. 2009.uel. Acesso em: 10 ago. MOUNTAIN. D. Disponível em: <http://www. BOCOLI. MICROSOFT. Disponível em: < www. Microsoft Solutions Framework version 3.com/Scr>. 76. Software: the SCRUM development process.pdf>. Dissertação (Mestrado em Informática). G. 2003. MSF.com/downloads/details. Al.0 Overview. p.

Dissertação (Mestrado em Tecnologia e Análise de Desenvolvimento de Sistemas). TORREÃO. 2009. Figura 5.pmisp. Um guia do conjunto de conhecimentos em gerenciamento de projetos. PEREIRA P.S. 2006. D. A. 2003. S... J.. 2009. Prentice Hall. Lean desenvolvimento de software: um kit de ferramentas ágeis.se/Uploades/Scrum_eng_webb. M. SCHWABER. The software project manager's bridge to agility. Disponível em: <http://www.. M. 2009. TRINDADE. Acesso em: 10 set 2009. DEITOS.. Acesso em: 01 abr. Faculdade de Tecnologia SENAC/RS. 2002. FELSING.pmi.pdf.ed. Boston: Peterson Education. T.. NJ: Addison-Wesley.cin. Entendendo SCRUM para gerenciar projetos de forma ágil. M./MSF%20%20Projeto. . São Paulo: MacGraw-Hill. Engenharia de software.>.110mb. RODRIGUES. G.doc>. PMI® . Project Management Institute. 2008. 5.. Acesso em: 10 abr. Microsoft Press.. Project Management Institute. PMI® -SP. Acesso em: 15 ago.sof4thouse. 2004.com/estudos/eng. POPPENDIECK. 2004. 2009. Disponível em: <www. Projeto Engenharia de Software MSF: Microsoft Solutions Framework.. Project Management Institute (PMI® ). Agile Project Management with Scrum. ROCHA. R.asp>.br/~ers/SCRUM_MundoPM-Abril-Maio-2007. PRESSMAN.org. T. Acesso em: 10 set. SLIGER. Upper Saddle River. Disponível em: < http://www. PMBOK® .pdf.org>. A Practical guide to feature driven development. 2002. P. MARÇAL.br/instituto.>. SCRUM. USA. S.87 PALMER. Disponível em: <http://www. K. Disponível em: <giovanideitos.ufpe. POPPENDIECK. A Guide to the Project Management Body of Knowledge – PMBOK® Guide – Fourth Edition.

A. Compuware. Gerenciamento de projetos iterativos e metodologias ágeis.php/reinfo/article/view/146/38>. Acesso em: 30 jun.org. TAVARES.M.br/index. p. R.spinsp. . Disponível em: <revistas. JAIN. 19-25.. 2009. 2006. L. Extreme Programming. A. proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods XP/Agile Universe.. R. Monografia (Conclusão de Curso).pdf>.facecla. n. Gerência de Projeto com PMBOK® e SCRUM: um estudo de caso.S.R. WILLIAMS.br/apresentacao/AgilePMOut. 2002. Metodologias Ágeis Extreme Programming e SCRUM para o Desenvolvimento de Software. M. 2009. 2008. Gravataí: Faculdade Cenecista Nossa Senhora dos Anjos. V. 2004. v. 65p. 4. TURNER.com. TIERNO. p. 153-165. Strengthening the case for pair programming. KESSLER. Disponível em: <www.88 SOARES. IEEE Software. 17. Agile Meets CMMI: Culture clash or common cause. TELES.. 2003. Acesso em: 20 jul. S. São Paulo: Novatec Ed.