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.

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

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

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

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

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

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

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 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

O principal é entender que cada papel advoga para um constituinte. Microsoft. as necessidades do cliente de uma maneira ou de outra (GARCIA.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 . Cada papel é auto-explanatório.Á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. Veja a Tabela 1. Tabela 1 . isto é. 1999).

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

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

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

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

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

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

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

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

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

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

Logo. pois muitos imprevistos não apareceram durante a preparação da Sprint. . 2006. Kniberg. e a indicação é que não será possível terminar o que foi previsto. 2003). p.51 O Gráfico 2 indica que a Sprint irá acabar depois da data final. é preciso rever as estimativas.49 Gráfico 2 – Sprint Burndown (adaptado). Talvez seja necessário rever os itens do Product Backlog remanescentes e eliminar aqueles com grau de importância menor (ANDERSON.

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

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

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

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

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

“Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à ® . 2. 2009). embora não seja o único. Como o próprio nome em português diz.4 PMBOK® O Project Management Body Of Knowledge ou simplesmente guia PMBOK® é o principal documento de referência do PMI® . lançada em 2008 (CAMPOMORI. e não uma descrição completa. “Identificar” significa fornecer uma visão geral.Second Edition (PMCDF) • Organizational Project Management Maturity Model (OPM3®) • Practice Standard for Earned Value Management (EVM) • Practice Standard for Work Breakdown Structures . 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.55 • Project Manager Competency Development Framework .Second Edition (WBS) • Practice Standard for Scheduling • Practice Standard for Project Configuration Management • The Standard for Program Management • The Standard for Portfolio Management Também foram desenvolvidas extensões para áreas específicas do guia PMBOK® . tais como: • Governo • Construção E vários outros padrões estão sendo construídos para possibilitar o aumento do conhecimento em gerenciamento de projetos. Está atualmente na quarta edição. TEIXEIRA. ele é “Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos”.

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

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

2008. Fonte: PMBOK . Figura 8 . 19. 19.Grupos de Processos. p.58 Figura 7 . Fonte: PMBOK . . 41). 2008. sendo que dependendo do tipo de projeto e sua organização os processos de um grupo de processo podem ser repetidos por fases do projeto” (PMBOK® . 2008. ® Os processos segundo o guia ainda são distribuídos em cinco grupos que se integram entre si.Formato de Processo. p. conforme Figura 8. p. ® “Estes grupos de processos não representam necessariamente uma fase do projeto.

Gerenciamento das Comunicações 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. Gerenciamento de Aquisições do 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 Tempo do Projeto. Tabela 2 . Gerenciamento da Qualidade do Projeto. Gerenciamento de Riscos do Projeto. Gerenciamento do Escopo do Projeto. Gerenciamento de Recursos Humanos do Projeto. 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. Gerenciamento de Custos do Projeto. análise e resposta Tempo Custos Qualidade Recursos Humanos Comunicações Riscos . conforme listagem abaixo e Tabela 2: • • • • • • • • • Gerenciamento de Integração do Projeto.8 Áreas de conhecimento O guia também organiza os 42 processos em nove áreas de conhecimento.59 2. cuidando de sua identificação.

® Adquirir bens e serviços de fora da organização promotora 2. Tabela 3 .Mapeamento dos processos nos grupos de processos e áreas de conhecimento. p. 2008. 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 .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.60 Aquisições Fonte: PMBOK . 20.

já que boa parte. é perceptível o forte foco do guia em planejamento. . 2008. p. 20 dos processos estão concentrados no grupo de planejamento. 21-22 Ao olhar para esta tabela.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 .

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

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

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

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

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

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

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

2004).69 Figura 10 – Desenvolvimento Iterativo – Grupos de processos do PMBOK . ® Na apresentação. Koch (2004) navega por cada um dos grupos de processo e faz um paralelo entre os processos do PMBOK® e discutindo o impacto com o enfoque iterativo. . porém somente onde realmente é necessário e sem comprometer a agilidade”. 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. 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® .

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

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

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

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

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

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

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

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

Como o Product Backlog incluiu estimativas iniciais de esforço. Entretanto o fornecedor propôs um mapeamento 1-a-1 entre cada iteração e cada TA. um novo TA representando uma estimativa de esforço revisada e uma nova lista de funcionalidades seria assinada. Estas restrições são os desafios que um projeto SCRUM deve superar sem perder o espírito de confiança e cooperação entre cliente/fornecedor que é o alicerce da filosofia de desenvolvimento do SCRUM. O projeto de referência foi sujeito a restrições de "orçamento fechado" e "despesas significativas de controladoria de projetos" para garantir que autorizações de tarefas Task Authorizations (TAs) contra o acordo vigente cumprissem os requisitos de controladoria e orçamento.1. No final da iteração. No final da iteração. Isto é. o cliente poderia ver como os contratos se relacionam com o esforço.6 Gerenciamento de custos do projeto Esta é a principal interface entre o projeto e as funções de controladoria financeira de uma organização. No início de cada iteração.171) tais contratos estimulam um comportamento self-serving do cliente e um comportamento defensivo do fornecedor. 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. 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. Além disso. Escopo e Tempo são todos usados no cálculo do custo do projeto. mais alguma despesa extra. 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. É difícil para o SCRUM alterar estes processos porque na maioria das vezes estes existem devido à política ou motivos regulatórios. muitos projetos de TI têm "preço fechado". p.78 4. Inicialmente. mas de acordo com Poppendieck e Poppendieck (2003.

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

as expectativas do cliente não poderiam ser colocadas no escopo ou ser usadas para adequar os critérios de aceite. 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. Sem as reuniões de revisão de cada iteração. os membros da equipe de desenvolvimento não saberiam como está o progresso de cada um.8 Gerenciamento de comunicação do projeto Aqui. SCRUM não tem este nível de formalismo. Estes elementos ajudaram a garantir que a qualidade do sistema pudesse ser testada repetidamente.1. mas os passos e procedimentos delineados no PMBOK® são aplicáveis a projetos usando SCRUM. sem reuniões diárias.80 3. teste e produção. Por exemplo. Como o processo de desenvolvimento foi iterativo e como o product backlog foi priorizado. mas comunicação é um item crítico. 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. SCRUM estabelece reuniões regulares em cada iteração. 2008. 4. As ferramentas e as técnicas podem variar para cada projeto. 4. p. Sem as reuniões de kick-off das iterações. O PMBOK® (PMBOK® . então as funcionalidades mais importantes foram desenvolvidas primeiro. . SCRUM e o PMBOK® divergem. 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.

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

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

. o cliente e a empresa prontos para as mudanças de paradigmas que a metodologia ágil traz. 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. discutimos os méritos e os problemas das abordagens baseadas na metodologia ágil e no PMBOK® . O grande desafio não é iniciar a utilização das boas práticas. agilidade é chave para alcançar altos níveis de inovação em projetos. 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. mas deixar o time. 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. 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. Atualmente. seja utilizando o guia PMBOK® . embora as técnicas de desenvolvimento ágil sejam consideradas como tendo "potencial" e as filosofias ágeis fundamentalmente não estejam em desacordo com as áreas chaves do guia PMBOK® . Em seguida.

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

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

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

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

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

Sign up to vote on this title
UsefulNot useful