Estudo Comparativo Da Compatibilidade Entre As Melhores Práticas Do Pmi E Scrum

FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA

LEONARDO BRUNO PEREIRA DE ARAUJO

ESTUDO COMPARATIVO DA 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.

iii

AGRADECIMENTOS

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

iv

RESUMO

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

ABSTRACT

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

LISTA DE FIGURAS

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

 

8

LISTA DE GRÁFICOS

Gráfico 1 – Sprint Burndown ..................................................................................... 48  Gráfico 2 – Sprint Burndown ..................................................................................... 49  Gráfico 3 – Sprint Burndown ..................................................................................... 50 

9

LISTA DE TABELAS

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

10

LISTA DE SIGLAS

ALGOL

Algorithmic Language

ANS

Padrão Nacional Americano

ANSI

Instituto de Padrões Nacional Americano

AT&T

American Telephone and Telegraph

COBOL

Common Business Oriented Language

EUA

Estados Unidos da América

EVM

Earned Value Management

FBS

Feature Breakdown Structure

FDD

Feature Driven Development

HP

Hewlett-Packard

IBM

International Business Machines

Lean

Lean Thinking

LHS

Limite de Horas da Sprint

MSF

Microsoft Solutions Framework

NASA

National Aeronautics and Space Administration

OPM3®

Organizational Project Management Maturity Model

PMBOK®

Project Management Body of Knowledge

PMI®

Project Management Institute

PMJ

Project Management Journal

PMP

Profissionais de Gerenciamento de Projeto

PMP®)

Project Management Professional

PMQ

Project Management Quarterly

ROI

Retorno Financeiro

11

SDLC

Software Development Life Cycle

TAs

Task Authorizations

TBS-EMF

Treasury Board of Canada Secretariat - Enhanced Management Framework

TI

Tecnologia da Informação

WBS

Work Breakdown Structures

WCMS

Sistema de Gerenciamento de Conteúdo de Web

XP

Extreme Programming

12

SUMÁRIO

INTRODUÇÃO ...................................................................................................... 14 1 METODOLOGIAS ÁGEIS .............................................................................. 20 1.1 Extreme Programming .................................................................................. 23 1.1.1 Estórias .................................................................................................... 25 1.1.2 Planejamento ........................................................................................... 26 1.1.3 Desenvolvimento iterativo ...................................................................... 26 1.1.4 Iterações de uma semana ....................................................................... 27 1.1.5 Teste antecipado ..................................................................................... 28 1.1.6 Refactoring .............................................................................................. 29 1.1.7 Programação em par............................................................................... 29 1.1.8 Envolvimento dos clientes ..................................................................... 30 1.2 Feature Driven Development ........................................................................ 30 1.2.1 Desenvolver um modelo geral ............................................................... 32 1.2.2 Construir uma lista de funcionalidades ................................................ 33 1.2.3 Planejar por funcionalidade ................................................................... 33 1.2.4 Projetar por funcionalidade .................................................................... 33 1.2.5 Construir por funcionalidade ................................................................. 34 1.3 Microsoft Solutions Framework ................................................................... 39 1.3.1 Release Manager ..................................................................................... 37 1.4 SCRUM............................................................................................................ 39 1.4.1 Como funciona? ...................................................................................... 40 1.4.2 Papéis e responsabilidades ................................................................... 41 1.4.3 Artefatos, conceitos e fases ................................................................... 42 1.4.3.1 Product Backlog ............................................................................... 42 1.4.3.2 Planejamento da Sprint .................................................................... 42 1.4.3.3 Execução e controle da Sprint......................................................... 42 1.4.3.4 Final da Sprint .................................................................................. 51

2. PMI® e PMBOK® ............................................................................................. 52 2.1 O gerenciamento de projeto ......................................................................... 52 2.2 História ........................................................................................................... 53

13

2.3 Hoje ................................................................................................................. 54 2.4 PMBOK® ......................................................................................................... 55 2.5 Projeto ............................................................................................................ 56 2.6 Gerenciamento de projeto ............................................................................ 56 2.7 Grupos de Processos .................................................................................... 57 2.8 Áreas de conhecimento ................................................................................ 59 2.9 Processos nos grupos e nas áreas de conhecimento ............................... 60

3. DIFERENÇAS, SIMILARIDADES E PROPOSTAS DE COMPATIBILIZAÇÃO ........................................................................................ 62 3.1 Diferenças e similaridades............................................................................ 62 3.2 Propostas de compatibilização .................................................................... 66

4. ESTUDO DE CASO ........................................................................................ 70 4.1 Metodologias ágeis e o guia PMBOK® . Técnicas de gerenciamento de projeto: mais perto do que você imagina .......................................................... 70 4.1.1 Introdução ................................................................................................ 70 4.1.2 Áreas de conhecimento do guia PMBOK® e a abordagem SCRUM ... 70 4.1.3 Gerenciamento de integração do projeto ............................................. 70 4.1.4 Gerenciamento de escopo do projeto ................................................... 74 4.1.5 Gerenciamento do tempo do projeto..................................................... 76 4.1.6 Gerenciamento de custos do projeto .................................................... 78 4.1.7 Gerenciamento de qualidade do projeto ............................................... 79 4.1.8 Gerenciamento de comunicação do projeto ......................................... 80 4.1.9 Conclusões .............................................................................................. 81

CONCLUSÃO ....................................................................................................... 83 REFERÊNCIAS .................................................................................................... 84

14

INTRODUÇÃO

A segunda metade do século XX foi marcada por grandes descobertas científicas e em entra elas, o surgimento dos computadores, que teve inicialmente o seu desenvolvimento

fortemente

patrocinado

pela

indústria

bélica,

projetados

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

15

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

16

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

17

• Por que não podemos achar todos os erros antes de entregar o software aos clientes? • Por que continuamos a ter dificuldade em avaliar o progresso enquanto o software é desenvolvido? • Por que os cronogramas e custos são imprecisos? • Por que não existem dados históricos sobre o processo de desenvolvimento? • Por que a comunicação é deficiente? • Por que os usuários ficam insatisfeitos? • Por que há carência de conceitos quantitativos sobre confiabilidade, qualidade e reusabilidade? Para tentar responder essas, e muitas outras perguntas e tentar racionalizar os processos de desenvolvimento de sistemas e minimizar impactos negativos em projetos o Project Management Institute (PMI® ), fundado em 1969 nos EUA e atualmente difundido em mais de 120 países é o maior difusor do gerenciamento de projetos, e publica um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK® - Project Management Body of Knowledge). Editado na forma de livro, o Guia PMBOK® está atualmente na quarta edição de 2008 e traduzido oficialmente para diversos idiomas, inclusive o português do Brasil. As edições anteriores foram publicadas nos anos de 1996, 2000 e 2004. O PMBOK® formaliza diversos conceitos em gerenciamento de projetos, como a própria definição de projeto e do seu ciclo de vida, reconhece cinco grupos de processos de gerenciamento de projetos e nove áreas de conhecimento. Conceitos amplamente utilizados em projetos de desenvolvimento de software. O Gerenciamento de projetos segundo as melhores práticas do PMI® ajuda as organizações a atenderem as necessidades de seus clientes padronizando tarefas rotineiras e reduzindo o número daquelas que poderiam ser esquecidas, assegura que os recursos disponíveis são alocados da maneira mais eficiente e eficaz, permitindo aos executivos seniores a perceber "o que está acontecendo" e "para onde as coisas estão indo" dentro das organizações. Muitas organizações ao redor do mundo, como NASA, IBM, American Telephone and Telegraph (AT&T), Siemens, Chiyoda Corporation, Sociedade Computacional de

18

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

19

Thinking), desenvolvimento iterativo e incremental, e novas estratégias de criação de produtos. Sua aplicação não está limitada a projetos de software. O objeto dessa pesquisa é uma análise comparativa de ambos os modelos buscando responder dúvidas como: É possível usar modelo Project Management Body of Knowledge (PMBOK® ) com SCRUM em um mesmo projeto? Ou é preciso optar por uma abordagem ou outra? Se for possível, como adaptar o processo para o uso em conjunto? Como trabalhar as áreas e processos do PMBOK® com uma abordagem Ágil? Como gerenciar o escopo? E o tempo? Áreas que parecem conflitantes entre PMBOK® e SCRUM. Alguns mais radicais defendem a adoção puramente de PMBOK® e outros, por sua vez a adoção exclusiva de Metodologias Ágeis. No que se refere a projetos de software, o uso das duas abordagens é perfeitamente possível e positiva. A motivação da pesquisa vem da visibilidade crescente que as Metodologias Ágeis de desenvolvimento de software têm recebido em todo o mundo, e também aqui no Brasil.

20

1 METODOLOGIAS ÁGEIS

As recentes definições sobre metodologias ou métodos ágeis evoluíram a partir da metade de 1990 como parte de uma reação contra métodos considerados "pesados", caracterizados por uma pesada regulamentação, regimentação e micro gerenciamento usado no modelo em cascata que é composto basicamente por atividades

seqüenciais

de

levantamento

de

requisitos,

análise,

projeto,

implementação, teste, implantação e manutenção. Este modelo é derivado de outras engenharias tradicionais (Civil, Elétrica, Naval) e foi o primeiro a ser usado pela Engenharia de Software, na década de 70 (COCKBURN; HIGHSMITH, 2001). Mesmo com a evolução dos computadores, das técnicas e ferramentas nos últimos anos, a produção de software confiável, correto e entregue dentro dos prazos e custos estipulados ainda é muito difícil. Dados de 1995 segundo a Standish Group Chaos Report, usando como exemplos 8380 projetos, mostram que apenas 16,2% dos projetos foram entregues respeitando os prazos e os custos e com todas as funcionalidades

especificadas.

Aproximadamente

31%

dos

projetos

foram

cancelados antes de estarem completos e 52,7% foram entregues, porém com prazos maiores, custos maiores ou com menos funcionalidades do que especificado no início do projeto (SOARES, 2009). Dentre os projetos que não foram finalizados de acordo com os prazos e custos especificados, a média de atrasos foi de 222%, e a média de custo foi de 189% a mais do que o previsto. Considerando todos os projetos que foram entregues além do prazo e com custo maior, na média, apenas 61% das funcionalidades originais foram incluídas. Mesmo os projetos cuja entrega é feita respeitando os limites de prazo e custos possuem qualidade suspeita, uma vez que provavelmente foram feitos com muita pressão sobre os desenvolvedores, o que pode quadruplicar o número de erros de software, segundo a mesma pesquisa. As principais razões destas falhas estavam relacionadas com o processo em cascata (COCKBURN; HIGHSMITH, 2001).

21

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

22

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

23

1.1 Extreme Programming

Um dos principais fundadores da Extreme Programming chama-se Kent Beck. O método da XP para gerenciar projetos de desenvolvimento de software começou a ser concebido em meados da década de 1980, quando Kent Beck e Ward Cunninghan trabalharam juntos num grupo de pesquisa na Tektronix. Segundo Kent Beck a XP é uma metodologia que endereça as limitações do processo de desenvolvimento de software. Ela não aborda o processo de gerenciamento do projeto, análise financeira, marketing ou vendas. A XP afeta todas as áreas, mas não as aborda diretamente, é um estilo de desenvolvimento de software cujo foco está na excelência da aplicação das técnicas de programação, comunicação clara e trabalho em equipe (TELES, 2004). De acordo com Beck (1999) a XP é uma forma de promover a excelência no desenvolvimento de software, e distingue-se de outras técnicas pelas seguintes características: • Trabalha com iterações de duração bastante curta, resultando em respostas rápidas, concretas e contínuas; • Usa uma abordagem incremental de planejamento, que resulta em planos abrangentes que podem evoluir durante o ciclo de vida do projeto; • Tem a possibilidade de planejar melhor a implementação das funcionalidades do software, permitindo responder mais rápido às necessidades de mudanças dos negócios; • Usa

mecanismos

automatizados

para

realizar

testes,

que

podem

ser

desenvolvidos pelos programadores, clientes ou pessoal de qualidade para monitorar o progresso do desenvolvimento, permitindo que o sistema evolua e que os defeitos sejam identificados o mais cedo possível; • Confia na comunicação oral, nos testes e nos programas fontes para comunicar a estrutura do sistema; • Trabalha com um processo evolutivo de design que persiste durante a vida do projeto;

24

• Confia na colaboração entre indivíduos ativamente engajados e com talentos específicos; • Usa práticas que atendem às necessidades imediatas dos membros da equipe e de longo prazo do projeto. A XP enfatiza um conjunto de princípios, esses princípios são: Comunicação, Simplicidade, Feedback, Coragem, Respeito, Ser mais humano, Benefício Mútuo, Reutilização, Melhoria Contínua, Diversidade, Qualidade, Desenvolvimento em pequenos passos, Responsabilização. Na XP os papéis são divididos por: testador, designer de interação, arquiteto, gerente de projeto, gerente de produto, executivo, documentador técnico, usuário e programador. Embora exista uma definição para cada papel, uma pessoa pode assumir mais de um papel. A metodologia prevê três fases principais, são elas: a exploração, o compromisso e o direcionamento. Embora cada fase seja descrita de forma seqüencial, o projeto não segue uma seqüência, indo de uma fase para outra. Todo o processo é cíclico, indo de uma fase para outra na medida do necessário. Na fase de exploração o objetivo da equipe é identificar o que o sistema precisa fazer. Nesta fase a equipe executa três atividades básicas: escrever uma estória, estimá-la e decompô-la. Na fase de compromisso a equipe de negócio determina o escopo de cada release do sistema e as datas das entregas. Este trabalho leva em conta as informações fornecidas pela a equipe de desenvolvimento e as necessidades de negócio. Finalmente, na fase de direcionamento o plano é atualizado à medida que as mudanças ocorrem durante a execução. As duas fases anteriores acontecem quase que simultaneamente, enquanto que esta ocorre mais tarde, durante a iteração ou entre as iterações. Veja a Figura 1.

25

Figura 1 - Extreme Programming (Adaptado). Fonte: http://www.extremeprogramming.org, 2009.

Na condução de um projeto a XP propõe a aplicação de um conjunto de práticas, que podem ser divididas em duas categorias: as básicas e as complementares. As básicas deveriam implementadas em qualquer projeto XP e as demais poderiam ser consideradas como opcionais. A XP trabalha com várias práticas, contudo nem todas precisam ser seguidas, e a importância relativa entre elas depende do ambiente de cada projeto e das oportunidades de melhorias que existem. As práticas mais expressivas da XP são descritas a seguir:

1.1.1 Estórias

As estórias representam unidades de funcionalidade da forma como são percebidas pelos usuários, por exemplo, “Como caixa da loja eu vou identificar os produtos que o cliente escolheu e o sistema vai informar o preço”. São textos simples e objetivos para orientar o desenvolvedor sobre o que deve ser programado (JEFFRIES et al., 2001).

26

1.1.2 Planejamento

Na XP é construído um plano geral do projeto que determina, de forma abrangente, quando cada release vai ser concluído e o que vai compor cada um deles (MARTINS, 2009). No inicio de cada iteração, o conteúdo da iteração ou release é detalhado e um plano de implementação é criado. Como cada iteração é relativamente curta, o planejamento é feito logo antes do trabalho ser executado. Desta forma a chance de haver desvios entre o que foi planejado e o que foi executado é menor e, caso ocorra algum desvio, as suas razões podem ser verificadas rapidamente e corrigidas logo no início da próxima iteração (MARTINS, 2009). Normalmente a data de conclusão do projeto é previamente definida, desta forma é possível definir quanto esforço pode ser dedicado para cada estória. As estórias que provêem maior valor para os negócios devem ser trabalhadas prioritariamente (BECK; FOWLER, 2001). Como é difícil avaliar o custo e o valor de cada estória, fica difícil fazer o planejamento do projeto. As informações utilizadas para fazer este tipo de avaliação mudam no tempo. O planejamento não é uma previsão do futuro. No melhor caso, ele expressa tudo que se conhece hoje sobre o que pode acontecer amanhã. O plano representa um ponto de partida (MARTINS, 2009).

1.1.3 Desenvolvimento iterativo

Na XP o software é desenvolvido iterativamente em pequenos releases que adicionam features ao sistema e permitem um retorno rápido do usuário. Os

27

releases devem ser do menor tamanho possível e que ainda possam produzir algum valor para o negócio (POPPENDIECK; POPPENDIECK, 2003). Numa implementação do tipo big-bang1, a equipe pode gastar meses sem adicionar nenhuma nova funcionalidade ao sistema, mas preparando-se para o dia D, fazendo horas extras e trabalhando em finais de semana. Mesmo que o projeto tenha sucesso, após a implantação a equipe fica exausta e pode precisar de várias semanas para se recuperar. Se o projeto não tiver sucesso os custos são ainda maiores. Implantações do tipo big-bang têm altos riscos e grandes custos humanos e econômicos.

1.1.4 Iterações de uma semana

O trabalho deve ser planejado uma semana de cada vez, que é o horizonte da iteração. Deve haver uma reunião no começo de cada semana para fazer o planejamento, nesta reunião serão abordados os seguintes assuntos (TELES, 2004): • Rever o progresso até o momento, incluindo o progresso da última semana comparado ao esperado; • O cliente deve apontar as estórias de maior valor, que serão trabalhadas nesta semana; • Decompor as estórias em tarefas, e permitir que os membros da equipe se voluntariem a pegar cada uma delas e façam suas estimativas. A semana deve começar com os desenvolvedores escrevendo testes automatizados que serão executados quando as estórias estiverem concluídas. Se a equipe chegar à quarta-feira e ficar evidente que os testes não vai executar, que as estórias não serão concluídas e prontas para serem entregues, ainda haverá tempo para escolher as mais importantes e priorizá-las (JEFFRIES et al., 2001). 1

O método do big bang é o mais usado por empresas de software comercial. A idéia é manter o máximo de segredo possível, e só liberar o software para aquisição quando cada pequena parte dele estiver funcionando bem.

28

Podem ser criadas estórias menores, o que elimina a necessidade de decompô-las em tarefas menores. Isto vai gerar mais trabalho para os usuários, que escrevem as estórias. Uma alternativa é trabalhar com uma pilha única de tarefas; assim que um desenvolvedor concluir uma tarefa ele pega a próxima tarefa da pilha. Esta abordagem elimina um problema bastante comum: os desenvolvedores correm para pegar as tarefas “melhores” e sobram as “piores”, que ninguém quer fazer (BECK; FOWLER, 2001).

1.1.5 Teste antecipado

As rotinas de teste são construídas antes que qualquer código seja escrito. Os critérios para os testes de aceitação são gerados e escritos pela área de negócios assim que os requisitos, na forma de estórias, são documentados, os testes de unidade são criados pelos os desenvolvedores logo antes da programação, e todo programa gerado precisa passar por todos estes testes (JEFFRIES et al., 2001). Esta abordagem vai permitir resolver vários problemas de uma só vez: • Mudança de escopo – é fácil divagar e programar algo apenas porque pode vir a ser necessário no futuro. Ao definir claramente o que o sistema precisa fazer, o programador terá um foco maior ao fazer a programação; • Acoplamento e coesão – se for muito difícil desenvolver uma rotina de teste, isto pode ser um sinal de que há algum problema quanto à forma como o sistema foi projetado, e não um problema com a rotina de teste propriamente dita. Programas com baixo acoplamento e alta coesão são fáceis de testar; • Confiança – é difícil confiar num desenvolvedor que escreve um programa que não funciona. Ao escrever um código que funciona e que pode ser demonstrado através de uma rotina automatizada de teste, o desenvolvedor consegue conquistar a confiança do seu grupo com muito mais facilidade; • Ritmo – é fácil o programador perder-se por horas quando está programando. Ao desenvolver antes a rotina de teste, fica mais claro o que deve ser feito na

29

seqüência: desenvolver outra rotina de teste ou corrigir o problema encontrado. Logo este se transforma numa rotina de trabalho: teste, programação, refactoring.

1.1.6 Refactoring

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

1.1.7 Programação em par

A programação em par é a prática mais popular da XP, quase todas as implementações de XP começam com esta prática. Na programação em par o código-fonte é escrito por duas pessoas trabalhando em conjunto num único computador. Esta prática tem vantagens, principalmente nas situações em que a programação apresenta uma complexidade maior (WILLIAMS; KESSLER, 2003):

• Um programador ajuda o outro a manter o foco na tarefa; • Fazer brainstorm para criar melhores abordagens; • Ajuda a clarear as idéias;

30

• Quando um dos programadores fica imobilizado por falta de alternativas o outro pode ajudar assumindo o controle; • Um ajuda o outro a não perder de vista os valores e as práticas da equipe; • É uma forma de disseminar o conhecimento e transferir experiência; • Permite que todo o código produzido seja dinamicamente revisado por pelo menos outra pessoa, que também entende o contexto no qual o código foi desenvolvimento.

1.1.8 Envolvimento dos clientes

Ao colocar as pessoas com as necessidades de negócio em contato direto com os desenvolvedores facilita a compreensão dos requisitos, além de acelerar o feedback. O usuário que participa da equipe pode dar um feedback rápido e ajudar a definir prioridades (MANHÃES TELES, 2005).

1.2 Feature Driven Development

Criado no final da década 90 em Cingapura por um time liderado por Jeff De Luca é uma simples compilação de práticas estabelecidas nos últimos 30 anos. Um de seus maiores desenvolvedores, Peter Coad, definiu a idéia de Feature Definition e Feature List. Renomados autores participaram da concepção das idéias do FDD, entre eles: Tom De Marco, Tim Lister, Jerry Weinberg e Frederic Brooks. Em sua essência o FDD é um processo ágil e adaptativo com as seguintes características (ABRAHAMSSOM, 2002): •

Iterativo;

•

Enfatiza a qualidade;

•

Entrega resultados tangíveis e freqüentes;

31

•

Provê relatórios de progresso precisos e significativos, requerendo pouca sobrecarga de trabalho por parte dos programadores;

•

É apreciado pelos clientes, gerentes e desenvolvedores;

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

32

Figura 2 - Feature Driven Development (Adaptado). Fonte: http://www.nebulon.com/, 2009.

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

1.2.1 Desenvolver um modelo geral

Neste processo o especialista no domínio do problema e a equipe de desenvolvimento trabalham em conjunto e fazem uma análise inicial de alto nível

33

quanto ao escopo do sistema e o seu contexto. A equipe divide o domínio do problema em áreas e faz vários walkthroughs em cada uma delas, cada vez aumentando mais o nível de detalhe. À medida que o trabalho se desenvolve a equipe vai construindo o modelo de classes e objetos de negócio. Depois todos os modelos são combinados para formar o modelo final (LAURINDO, 2007).

1.2.2 Construir uma lista de funcionalidades

Com base no conhecimento adquirido na primeira etapa, o líder técnico decompõe as funcionalidades do domínio e constrói uma lista de funcionalidades. Orientado pelo especialista no negócio, ele as divide por área de negócio, cada área é decomposta em atividades, que dão origem a grupos de funcionalidades. Cada funcionalidade é definida como uma funcionalidade pequena e de valor para o cliente e é expressa na forma . Um exemplo de funcionalidade é "calcular o total de vendas". Documentos existentes de requisitos são utilizados como referência para este trabalho, como Casos de Uso, especificação funcional, dentre outros. Cada funcionalidade deverá pertencer a somente um conjunto (atividade) e a somente uma área de negócio. As funcionalidades são organizadas numa Feature Breakdown Structure (FBS) onde são agrupadas em conjunto e divididas por área de negócio. Normalmente cada uma corresponde a uma atividade particular de negócio (MARTINS, 2009).

1.2.3 Planejar por funcionalidade

No terceiro processo do FDD o gerente de projeto, o gerente de desenvolvimento e o líder técnico, trabalhando em conjunto, planejam a seqüência de desenvolvimento dos grupos de funcionalidades (atividade de negócio) e dos conjuntos de funcionalidades (área de negócio) (FDD, 2009).

34

1.2.4 Projetar por funcionalidade

As funcionalidades são atribuídas aos lideres técnicos que são responsáveis pelo seu desenvolvimento. O líder técnico seleciona as próximas funcionalidades para desenvolvimento a partir da sua lista de prioridades, e compõe seus pacotes de trabalho. Algumas delas podem ser desenvolvidas simultaneamente quando elas estão baseadas no mesmo conjunto de classes (LAURINDO, 2007).

1.2.5 Construir por funcionalidade

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

35

simples, objetivo e fácil de seguir, possui técnicas objetivas para lidar com os problemas de desenvolvimento de software, técnicas claras para informar o progresso e permitir que as decisões possam ser tomadas em tempo oportuno (LAURINDO, 2007).

1.3 Microsoft Solutions Framework

O MSF 4.2 possui duas novas instâncias: MSF for Agile Software Development e MSF for CMMI Process Improvement. Podemos afirmar que o MSF Agile é a soma de posições equilibradas, pois defende um Software Development Life Cycle (SDLC) mais curto com iterações de no máximo quatro semanas, contudo preserva a importância dos papéis definidos previamente e abomina a linha "todo mundo pode fazer tudo no projeto". Outro quesito de destaque nesta fusão são os testes unitários e a preocupação com a cobertura de 100% do código fonte (MICROSOFT, 2009). Veja a Figura 3.

Figura 3 – MSF – Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009.

36

Um tema muito forte dentro do MSF Agile é integração. Metodologias ágeis necessitam que os "stakeholders" estejam presentes o tempo todo durante o projeto. Para isso são constituídos cenários de tarefas de trabalho que englobam atividades planejadas para um desenvolvedor. Estes cenários fazem parte de uma determinada iteração

do

plano

de

iterações.

Esta

iteração

agrupa

os

cenários

de

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

37

• Aprendizado contínuo: O próprio projeto é uma rica lição a cada iteração. Você percebe a evolução da curva de produtividade e acompanha a autonomia técnica crescente dos colaboradores a cada dia dentro do projeto. Para o MSF, um projeto

precisa

dos

seguintes

papéis,

entendem-se

papéis

como

responsabilidades que devem ser assumidas por algum membro da equipe: o Program Manager o Product Manager o User Experience o Tester o Developer o Architect

1.3.1 Release Manager

O Modelo de Equipe da MSF tem como princípio fundamental a idéia de "Equipe de Iguais" – Team of Peers, significando com isto que não há nenhuma hierarquia entre os membros da equipe. Por exemplo, neste modelo, um gerente de projeto dá suporte à equipe, a qual atua em consenso do que necessita ser feito para continuar o projeto (CAMARA, 2007). Cada membro da equipe é bem autônomo, e espera-se que saibam o que fazer e planejam como vão fazer a entrega de sua parte do trabalho. Esta valorização do poder de cada membro da equipe é um dos conceitos que a maioria dos gerentes tradicionais de projeto precisa aprender ao aplicar o MSF (GARCIA, 1999). Veja a Figura 4.

38

Figura 4 – MSF – Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009

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

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

Entrega dentro dos limites do projeto

“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”

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

“É simplesmente muito difícil de usar” “Não atende nossas expectativas. 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

39

de alto nível tarde” Fonte: MSF for Agile Software Development Process Guidance, Microsoft, 2009.

É árduo afirmar quem foi o fundamentador do MSF, porém o grande patrocinador sempre foi a própria Microsoft. Para não ficar em branco com nomes, Michael Cusamano, Steve McConnell e Clementino Mendonça destacam-se entre muitos outros como personagens da história do MSF (GARCIA, 1999).

1.4 SCRUM

As raízes do SCRUM estão num artigo que sumarizam as 10 melhores práticas em empresas japonesas, escrito por Takeuchi e Nonuka, cujo título é "O jogo do desenvolvimento de novos produtos" que foi publicado na Harvard Business Review em janeiro de 1986. Este artigo introduziu o termo SCRUM, que se refere ao jogo de Rugby, quando os jogadores se organizam em círculo para planejar a próxima jogada. É uma forma de mostrar que o projeto deve ser conduzido em pequenos ciclos, mas com uma visão de longo prazo, que é ganhar o jogo. Jeff Sutherland é um dos criadores do SCRUM e era vice-presidente da Easel Corporation em 1994, quando introduziu algumas das práticas do SCRUM, com base neste artigo. Ele também foi influenciado por um relatório de projeto com produtividade acima da média, na Borland Corporation, que dentre outras coisas introduziu a reunião diária (MARTINS, 2009). Segundo Schwaber (2004), SCRUM não é um processo previsível, ele não define o que fazer em toda circunstância. Ele é usado em trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e oferece um framework e um conjunto de práticas que torna tudo visível. Isso permite aos praticantes do SCRUM saber exatamente o que acontece ao longo do projeto e fazer os devidos ajustes para manter o projeto se movendo ao longo do tempo, visando alcançar os seus objetivos

40

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

1.4.1 Como funciona?

A Figura 5 ilustra o ciclo de desenvolvimento do SCRUM de forma simplificada.

Figura 5 – SCRUM, Fonte: http://www.sof4thouse.se/Uploades/Scrum_eng_webb.pdf, 2009.

41

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

1.4.2 Papéis e responsabilidades

Ele implementa uma estrutura iterativa e incremental através de três papéis principais: o Product Owner, o SCRUM Team e o SCRUM Master como descrito abaixo (ISOTTON NETO, 2008):

42

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

1.4.3.1 Product Backlog

43

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

1.4.3.2 Planejamento da Sprint

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

44

No planejamento da Sprint o Product Backlog deve estar pronto antes de cada reunião. Mas o que significa isso? Que todos os requisitos têm que estar perfeitamente definidos e que as estimativas iniciais devem estar corretas? Que todas as prioridades estão finalizadas? (KNIBERG, 2006) Não, precisamos apenas garantir: • Que o Product Backlog exista e cada item esteja estimado; • Deve existir apenas um Product Backlog e um Product Owner; • Todos os itens devem ter uma nota em função de sua importância; • Essa nota serve apenas para organizar os itens por importância; • O Product Owner deve entender todos os itens do Product Backlog, normalmente ele é o autor do mesmo, mas em alguns casos outras pessoas podem ter colocado itens no Backlog; • Ele não precisa saber como cada item deverá ser feito, mas precisa saber o motivo do item estar lá; • Apenas o Product Owner tem o poder de associar a nota de importância de cada item do Product Backlog. Estando preparados os itens acima, pode-se iniciar a reunião de planejamento. O objetivo da reunião é priorizar os itens que serão executados na Sprint, além de dar ao time informação suficiente para que o mesmo possa validar e estimar o esforço em horas para cada item. Vale lembrar que esta reunião é muito crítica para o sucesso do projeto e que uma reunião mal planejada pode afetar em muito o andamento da Sprint e causar danos grandes ao prazo do projeto (SCHWABER, 2004). Com o Product Backlog priorizado, o time seleciona os itens que acha possível de executar durante a Sprint. As dúvidas do time são esclarecidas e ao final temos então o Sprint Backlog, que são os itens do Backlog priorizados para a Sprint. Para cada item, o time inicia o detalhamento de suas atividades, estimando em horas, a duração de cada uma delas. Não é mandatário, mas é sugerido que cada tarefa não ultrapasse a duração de 16h. Se for necessário, deve-se quebrar a tarefa até que individualmente todas as tarefas estejam dentro do limite de 16h. Uma vez que todas as tarefas foram estimadas, o time questiona se realmente consegue assumir o

45

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

46

Para uma Sprint com time-box padronizado em 5 dias e um time possui 5 recursos em que 3 são de 8h, um de 6h e outro de 8h, mas apenas alocado por 50% de seu tempo, temos o LHS diário considerando a relação acima sugerida de (MOUNTAIN, 2009): 8hx75% = 6h (3) 6hx75% = 4,5h (1) 8hx50% = 4h x 75% =3h (1) Dias úteis da Sprint = 5 logo, ((3x6) + (4,5) + (3)) = 31,50 (dia) LHS= 5 x 31,50 = 157,50 h

Esses são cálculos bem simples e você vai precisar usá-los apenas antes de cada planejamento da Sprint, pois o LHS é que vai indicar se você está alocando as horas corretas para a equipe (SCHWABER, 2004). É importante salientar que uma vez estabelecido a duração da Sprint não deve alterar sua data final, pois todo o projeto é guiado por essa duração. Logo, adiantar ou atrasar não é interessante para ninguém. Outro motivo importante para se manter o padrão de duração da Sprint é a relação de produtividade do time dentro da Sprint. A métrica de esforço (velocity) para o grupo de itens que foram priorizados na Sprint é que vai dizer se conseguimos medir para um mesmo time-box o total de itens que foram finalizados por Sprint, e isso comparado a um histórico. Esta métrica é muito importante, e apenas será real se as Sprints forem de tamanhos iguais (SCHWABER, 2004)

47

1.4.3.3 Execução e controle da Sprint

Durante a Sprint, o time, de forma organizada, controla como as tarefas devem ser executadas. Durante a Sprint não deve existir interferência externa, esse é um dos principais papéis do SCRUM Master, blindar o time de qualquer desvio do objetivo traçado. O acompanhamento do progresso é feito realizando reuniões diárias, chamada de daily meeting. Essas reuniões devem ser rápidas, não mais que 15 minutos, e objetivas. Todos participam, o SCRUM Master e o time. Visitantes são bem-vindos, mas devem ser apenas ouvintes, pois o daily meeting resume-se ao time. No daily meeting, a equipe trabalha apenas três perguntas, que são respondidas por cada membro (PEREIRA et al, 2007): • O que foi feito desde ontem? • O que você planeja fazer para amanhã? • Você tem algum impedimento? Todo e qualquer problema encontrado durante o daily meeting deve ser tratado em uma outra reunião, apenas com os envolvidos. Durante a execução da Sprint, a alocação de recursos para cada tarefa é dirigida pelo próprio time, cada membro da equipe seleciona as tarefas que podem realizar e o time estabelece a ordem e dependência entre elas. Um fator importante de sucesso para o time com o uso do SCRUM é o controle da disciplina. O time é considerado auto-gerenciável e deve responder como tal. Para isso, todos os membros do time devem reportar as horas utilizadas em tarefas para que o valor de horas restantes seja calculado corretamente e o time possa verificar o seu progresso. Para esse acompanhamento, o time usa um gráfico chamado de Sprint Burndown, ele exibe o progresso diário do time em função do total de horas estabelecido pela soma de horas das tarefas dos itens do Product Backlog selecionados. (PEREIRA et al, 2007), O Gráfico 1 ilustra um exemplo:

48

Gráfico 1 – Sprint Burndown (adaptado), Kniberg, 2006, p.51

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

49

Gráfico 2 – Sprint Burndown (adaptado), Kniberg, 2006, p.51

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

50

Gráfico 3 – Sprint Burndown (adaptado), Kniberg, 2006, p.52

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

51

Figura 6 – Quadro de tarefas (adaptado), Kniberg, 2006, p.49

1.4.3.4Final da Sprint

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

52

2. PMI® e PMBOK®

2.1 O gerenciamento de projeto

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

53

2.2 História

O Project Management Institute (PMI® ) foi fundado em 1969 por cinco voluntários. A Comunidade da Pensilvânia emitiu as Cláusulas de Incorporação do PMI® , oficializando sua fundação. Durante aquele mesmo ano, o primeiro PMI® Seminars & Symposium aconteceu em Atlanta, Geórgia EUA, com a participação de 83 pessoas. Nos anos setenta, a primeira edição do Project Management Quarterly (PMQ) foi publicada, e posteriormente renomeada para Project Management Journal (PMJ). O primeiro Capítulo do PMI® foi oficializado e o primeiro Programa de Prêmios Profissionais estabelecido. Ao final da década, o PMI® somava mais de 2.000 associados no mundo (PMI® -SP 2009). Durante os anos oitenta, o número de associados do PMI® continuou crescendo, bem como os programas e serviços oferecidos pela associação. Um Código de Ética foi adotado para a profissão e o primeiro Project Management Professional (PMP®) foi credenciado. O primeiro modelo padrão de Gerenciamento de Projetos foi publicado: o Special Report on Ethics Standards and Accreditation (PMQ). As publicações do PMI® sobre produtos e serviços cresceram rapidamente durante esta década. O primeiro livro do PMI® foi co-publicado e nasceu a PMNetwork®, revista mensal do PMI® . Em função deste crescimento foi estabelecida a Divisão de Publicações do PMI® na Carolina do Norte, EUA (PMI® -SP 2009). Em 1990, o PMI® somava mais de 8.500 associados e em 1993 este número crescia cerca de 20% ao ano. Durante os anos noventa foram formados os Grupos de Interesses Específicos, os Colleges e o Seminars USA, uma série de programas educacionais em Gerenciamento de Projeto. O PMI® também marcou presença na rede mundial da Internet e publicou o "A Guide to the Project Management Body of Knowledge

(PMBOK®

Guide)", um guia englobando todas

as áreas do

conhecimento que regem as regras do gerenciamento de projetos. O PMI Today® , boletim informativo mensal do PMI® , foi impresso pela primeira vez e o Programa de

54

Desenvolvimento

Profissional

foi

estabelecido

para

que

os

profissionais

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

2.3 Hoje

Atualmente o PMI® conta com mais de 250.000 associados em 170 países. Os associados do PMI® são indivíduos praticando e estudando o Gerenciamento de Projeto nas mais diversas áreas, como aeroespacial, automobilística, administração, construção, engenharia, serviços financeiros, tecnologia da informação, farmacêutica e telecomunicações (PMI® -SP, 2009). Com o passar do tempo, o PMI® se tornou, e continua sendo, a principal associação profissional em Gerenciamento de Projetos. Os associados e interessados em Gerenciamento de Projetos têm à sua disposição uma extensa relação de produtos e serviços oferecidos pelo PMI® (PMI® -SP, 2009). O PMI® ocupa uma posição de liderança global no desenvolvimento de padrões para a prática da profissão de Gerenciamento de Projetos em todo o mundo. O principal documento padrão do PMI® , "A Guide to the Project Management Body of Knowledge", é um padrão globalmente reconhecido para o Gerenciamento de Projetos nos mercados de hoje. O PMBOK® Guide é aprovado como um Padrão Nacional Americano (ANS) pelo Instituto de Padrões Nacional Americano (ANSI). O PMI® está compromissado com a expansão e melhoria contínua do guia PMBOK® , assim como com o desenvolvimento de padrões adicionais (NETO; BOCOLI, 2003). Além

do

guia

PMBOK® ,

outros

padrões

disponibilizados aos associados (PMI® -SP, 2009):

foram

desenvolvidos,

estando

55

• Project Manager Competency Development Framework - Second Edition (PMCDF) • Organizational Project Management Maturity Model (OPM3®) • Practice Standard for Earned Value Management (EVM) • Practice Standard for Work Breakdown Structures - Second Edition (WBS) • Practice Standard for Scheduling • Practice Standard for Project Configuration Management • The Standard for Program Management • The Standard for Portfolio Management Também foram desenvolvidas extensões para áreas específicas do guia PMBOK® , tais como: • Governo • Construção E vários outros padrões estão sendo construídos para possibilitar o aumento do conhecimento em gerenciamento de projetos.

2.4 PMBOK®

O Project Management Body Of Knowledge ou simplesmente guia PMBOK® é o principal documento de referência do PMI® , embora não seja o único. Como o próprio nome em português diz, ele é “Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos”. Está atualmente na quarta edição, lançada em 2008 (CAMPOMORI; TEIXEIRA, 2009). Como ele mesmo descreve o seu objetivo é: ®

“O principal objetivo do Guia PMBOK é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à

56

maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por ® determinar o que é adequado para um projeto específico (PMBOK , 2008, p. 9).

No guia PMBOK® encontram-se muitas definições e práticas que guiam a gerência de projetos em geral. Algumas destas definições são descritas abaixo.

2.5 Projeto

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

2.6 Gerenciamento de projeto

57

O guia define a atividade de gerenciamento de projeto como: “a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos” (PMBOK® , 2008, p. 11). O papel do Gerente de Projetos é responsável pelo andamento do projeto e por gerenciar as atividades necessárias para o atendimento dos objetivos do mesmo. Para isso ele precisa planejar, controlar e executar as atividades do mesmo. O termo Stakeholders descreve todas as partes envolvidas ou interessadas no projeto, inclusive o próprio Gerente de Projeto. Dentre os interessados, um dos mais importantes é o Sponsor, ou patrocinador do projeto. É a pessoa que financia e/ou defende o projeto dentro da organização. Outros exemplos de partes envolvidas: fornecedores, sociedade, a equipe do projeto, cliente, usuários finais, dentre outros, conforme o projeto (TAVARES, 2008).

2.7 Grupos de processos

O guia PMBOK® (2008) possui 42 processos onde cada um recebe Entradas que são utilizadas por Ferramentas e/ou Técnicas que geram Saídas, conforme ilustrado na Figura 7. Segundo o PMBOK® processo é: “um conjunto de ações e atividades interrelacionadas realizadas para obter um conjunto pré-especificado de produtos, resultados ou serviços” (PMBOK® , 2008, p. 38).

58

®

Figura 7 - Formato de Processo. Fonte: PMBOK , 2008, p. 19.

Os processos segundo o guia ainda são distribuídos em cinco grupos que se integram entre si, conforme Figura 8.

®

Figura 8 - Grupos de Processos. Fonte: PMBOK , 2008, p. 19.

“Estes grupos de processos não representam necessariamente uma fase do projeto, sendo que dependendo do tipo de projeto e sua organização os processos de um grupo de processo podem ser repetidos por fases do projeto” (PMBOK® , 2008, p. 41).

59

2.8 Áreas de conhecimento

O guia também organiza os 42 processos em nove áreas de conhecimento, conforme listagem abaixo e Tabela 2: •

Gerenciamento de Integração do Projeto;

•

Gerenciamento do Escopo do Projeto;

•

Gerenciamento de Tempo do Projeto;

•

Gerenciamento de Custos do Projeto;

•

Gerenciamento da Qualidade do Projeto;

•

Gerenciamento de Recursos Humanos do Projeto;

•

Gerenciamento das Comunicações do Projeto;

•

Gerenciamento de Riscos do Projeto;

•

Gerenciamento de Aquisições do Projeto.

Tabela 2 - Áreas do conhecimento Área do conhecimento

Objetivo

Integração

Assegurar que todos os elementos do projeto sejam adequadamente coordenados

Escopo

Assegurar que todo o trabalho requerido – e somente aquele requerido – esteja incluído no projeto, para concluí-lo de maneira bem sucedida

Tempo

Assegurar a conclusão do projeto no prazo previsto

Custos

Assegurar que o projeto seja concluído dentro do orçamento previsto

Qualidade

Assegurar que os produtos ou serviços do projeto estejam em conformidade com o solicitado pelo cliente, ou contratante

Recursos Humanos

Fazer uso mais efetivo do pessoal envolvido com o projeto

Comunicações

Assegurar que as informações do projeto sejam adequadamente obtidas e transmitidas

Riscos

Assegurar um tratamento seguro ao risco do projeto, cuidando de sua identificação, análise e resposta

60

Adquirir bens e serviços de fora da organização promotora

Aquisições ®

Fonte: PMBOK , 2008, p. 20.

2.9 Processos nos grupos e nas áreas de conhecimento

A Tabela 3 exibe o mapeamento dos 42 processos de gerenciamento de projetos nos cinco grupos de processos e nas nove áreas de conhecimento em gerenciamento de projetos.

Tabela 3 - Mapeamento dos processos nos grupos de processos e áreas de conhecimento. Grupos de Processos Áreas de conhecimento Integração

Iniciação

Planejamento

Execução

Controle

Encerramento

Desenvolver Termo de Abertura

Desenvolver o plano de gerenciamento

Dirigir e Gerenciar a Execução do Projeto

Monitorar e controlar trabalhos do projeto

Encerrar projeto ou fase

Desenvolver controle de mudanças integrado

Escopo

Obter requisitos Definir escopo Criar WBS

Controlar escopo

Tempo

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

Controlar cronograma

Custos

Estimar custos Determinar orçamento

Controlar custos

Qualidade

Planejar qualidade

Desenvolver garantia da Qualidade

Recursos Humanos

Desenvolver plano de recursos humanos

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

Executar controle de qualidade

61

Comunicação

Identificar partes interessadas

Planejar comunicações

Distribuir informações

Reportar performance

Gerenciar expectativas de partes interessadas

Riscos

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

Aquisições

Planejar aquisições

Monitorar e controlar riscos

Conduzir aquisições

Administrar aquisições

Encerrar contrato

®

Fonte: PMBOK , 2008, p. 21-22

Ao olhar para esta tabela, é perceptível o forte foco do guia em planejamento, já que boa parte, 20 dos processos estão concentrados no grupo de planejamento.

62

3. DIFERENÇAS, SIMILARIDADES E PROPOSTAS DE COMPATIBILIZAÇÃO

3.1 Diferenças e similaridades

O PMBOK® tem foco no planejamento e muita disciplina no processo, partindo do princípio de que a aplicação de controle possibilita alcançar o objetivo planejado dentro de limites preestabelecidos de tempo, custo e escopo. Muito deste formalismo provém de necessidades inerentes a grandes projetos ou a restrições severas de confiabilidade, como ocorre em sistemas relacionados a atividades que apresentam risco de vida. Para projetos desta natureza, o formalismo da abordagem tradicional demonstra-se ainda adequado. Para a maioria dos projetos, porém, o gerenciamento tradicional acaba acrescentando somente custo e complexidade, enquanto fornece um falso senso de segurança, uma vez que o gerente está sempre ocupado – exaustivamente

planejando,

medindo

e

controlando.

Muitas

companhias

desperdiçaram cifras enormes com planejamento prematuro, sem desenvolver de forma rápida e iterativa e sem envolver o cliente, fatores que são hoje considerados fundamentais para o sucesso de um projeto de software. Como ele foi concebido para ser um guia genérico, ele desconsidera as peculiaridades da execução de produtos e serviços de software. Sua implantação prática na área de software exige um investimento importante na concepção de um processo adequado, que venha realmente alavancar o negócio e facilitar a vida dos envolvidos, sem requerer trabalho adicional somente para atender aos seus requisitos.

63

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

64

excesso de recursos. Além de identificar as expectativas e requisitos do cliente, avaliar custos, benefícios e riscos necessários para atender aos requisitos, o planejamento deve também enfocar e entender o contexto organizacional no qual o projeto está sendo desenvolvido, incluindo cultura, política e diretrizes financeiras. As atividades fundamentais de planejamento são necessárias, porém um plano de projeto muito detalhado é, geralmente, inadequado. Boehm explica que tanto a abordagem ágil quanto a dirigida por planejamento possuem aspectos positivos e negativos e também compara as duas em relação a uma série de fatores e discute formas de aproximá-las – usando o planejamento para aperfeiçoar métodos ágeis e a agilidade para dar maior eficiência aos métodos dirigidos pelo planejamento – e propõe métodos híbridos, que podem considerar os riscos do projeto como fator de ajuste na busca do ponto de equilíbrio entre elas (COCOMOII, 2009). O essencial para contornar as diferenças está em considerar, na escolha da abordagem, as características do projeto a ser desenvolvido, buscando aplicar a ferramenta correta para o trabalho a ser realizado. A dinâmica requerida em projetos de natureza exploratória, e que primam pela inovação, inviabiliza o uso da abordagem tradicional, pois o risco de alterar um produto depois da conclusão de uma fase de seu ciclo de vida é bastante alto. Por outro lado, a aplicação da abordagem ágil para planejamento estratégico ou priorização de projetos não será eficiente, uma vez que uma das premissas principais da abordagem ágil é entregar incrementos de funcionalidade específicos em curto espaço de tempo. A abordagem ágil é mais adequada para projetos definidos em alto nível, com objetivos claros e foco forte nos valores empresariais – principalmente custos e prazos, necessitando de grande participação do cliente durante todo o processo. Também é adequada para o detalhamento do trabalho tático necessário para completar um projeto, bem como para mudanças mínimas requeridas na manutenção de sistemas É importante destacar que a abordagem ágil não é estritamente uma metodologia, mas uma visão e um conjunto de atitudes, valores e princípios. Há processo, mas não no senso rigoroso de um processo baseado em papel ou uma metodologia centrada em controle. A comparação entre as duas parece ser um pouco vaga devido à abordagem ágil enfatizar menos os processos e mais os seus valores e práticas. Ela está sendo refinada e amadurecida a partir de observações sobre o uso

65

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

Tabela 4 - Principais diferenças e similaridades entre as metodologias ágeis e PMBOK® PMBOK São adaptativas: O desenvolvimento também ocorre de forma iterativa e evolutiva, com ondas sucessivas. A principal diferença é que cada iteração corresponde usualmente a uma fase do projeto, o que normalmente não é de curta duração. Pode levar mais do que 4 semanas.

São orientadas a processos e pessoas: Partem do princípio de que processos bem definidos devem ser impostos e executados, para garantir a qualidade do produto resultante. O talento das pessoas é refletido nas estimativas, é valorizado ainda na opinião dos especialistas e é considerado quando se pondera o cronograma com nivelamento de recursos. Ainda o talento do gerente do projeto é estimulado nos dois aspectos: gerente/chefe e líder, motivador, coach. São rígidas: pressupõem que é possível especificar de antemão todos os requisitos do software a ser desenvolvido, dificultando – e muitas vezes impedindo – realizar alterações e comprometendo a evolução natural da solução. Estão mais voltadas para a obtenção do software previamente especificado do que para o sucesso do projeto ou negócio para o qual o software foi apontado como solução. Enfatiza de fato o planejamento prévio da solução global. Porém uma alternativa, caso não se tenha condições de especificar o todo é trabalhar por ondas: componentes de planejamento (pacotes não detalhados a princípio que são refinados ao longo do projeto). Nunca as mudanças são impedidas, apenas devem ser aprovadas no controle de mudança, que dependendo de como for implementado pode ser aprovado pelo próprio

Metodologias Ágeis São adaptativas: Partem do princípio de que o conhecimento sobre o problema aumenta à medida que o sistema vai sendo desenvolvido, levando a uma busca constante por melhores soluções. O desenvolvimento ocorre de forma iterativa e evolutiva, com iterações tão curtas quanto possíveis (de 2 a 4 semanas). Ao final de cada iteração, obtém-se uma versão com a implementação de um novo subconjunto de funcionalidades, pronta para ser colocada em produção. São orientadas a pessoas: Para melhor gerenciar projetos de software, pessoas devem ser tratadas como indivíduos e não como recursos, pois cada pessoa apresenta um ritmo de trabalho único e completamente diferente, que é fruto da sua vivência pessoal. Os membros da equipe escolhem as tarefas que irão desenvolver durante a iteração seguinte, além de estimarem o tempo a ser gasto com elas, o que aumenta a motivação, o comprometimento e a produtividade da equipe. São flexíveis e iterativas: adaptam-se constantemente ao conjunto de requisitos mais atual: a cada iteração, usuários, clientes e desenvolvedores decidem sobre quais características devem ser adicionadas, modificadas e até retiradas do sistema. Além de ser desenvolvido da forma mais iterativa possível, é possível escolher os pontos mais críticos ou que mais agregam valor ao sistema para serem desenvolvidos em primeiro lugar. Estão mais voltadas para o bem do negócio: seu caráter adaptativo aumenta as chances de oferecer um melhor resultado ao projeto e ao negócio. Pontos fracos: Risco de desorganização, pouca documentação e alta dependência do cliente/usuário, o que muitas vezes não é viável

66

Gerente de projetos para pequenos impactos. Mas é claro que ter um controle de mudanças gera alguma burocracia e atraso. São burocráticas: geram muita sobrecarga no desenvolvimento a ser realizado, comprometendo a velocidade de desenvolvimento e, muitas vezes, o sucesso do projeto. Fonte: COCOMOII, 2009

Simplicidade: partem do princípio de que é preferível fazer algo simples de imediato e pagar um pouco mais para alterá-lo depois, se necessário, do que fazer algo complicado de imediato e acabar não utilizando depois.

3.2 Propostas de compatibilização

Uma proposta de compatibilização pode vir de uma série quatro artigos intitulados “Relating PMBOK® Practices to Agile Practices” escritos por Michele Sliger (2006), ela é certificada PMP e entende a dificuldade que é percorrer entre as melhores práticas do PMBOK® e a abordagem ágil, nos artigos, ela descreve as similaridades entre PMBOK® e os métodos ágeis, não SCRUM especificamente, mas as abordagens de um modo geral. Ela discute com muita propriedade a maneira de como trabalhar com PMBOK® e Metodologias Ágeis. Segundo ela, apesar das diferenças de filosofias entre as duas, muitas das práticas do PMBOK® são compatíveis com as práticas ágeis. Nos artigos, Sliger (2006) trafega com muita desenvoltura pelos cinco grupos de processos do guia PMBOK® , com uma visão não apenas didática, mas ao que parece de quem tem experiência prática sobre o que está descrevendo. Ela diz que para cada uma das áreas do PMBOK® , suas práticas têm práticas relativas nas Metodologias Ágeis, porém a forma de executar é diferente. Michele escreve que muitos autores e profissionais do PMI® declaram que seu modelo é um guia de melhores práticas e que cada organização deve usar os seus próprios critérios no uso destas práticas. De acordo com ela, por muito tempo o PMBOK® tem sido associado ao modelo em cascata, quando não é verdade uma vez que ele é perfeitamente aplicável com um modelo iterativo. No planejamento o principal processo é o desenvolvimento do plano do projeto, definindo como o projeto será executado e controlado, onde contém os planos para cada uma das áreas. Já nas Metodologias Ágeis o plano é feito e revisitado continuamente, com um nível de detalhe o suficiente para a realidade daquele instante, conforme os releases e iterações. Da mesma forma o controle integrado de

67

mudança é natural no dia-a-dia da equipe, e ocorre através das priorizações feitas pelo cliente no backlog, e durante as reuniões de planejamento e revisão de iteração e releases. Considerada uma das áreas de conhecimento mais importantes do PMBOK® e por isso, o gerenciamento do escopo do projeto recebe grande atenção. Nos métodos ágeis também é de extrema importância, porém a filosofia é totalmente diferente. Enquanto o PMBOK® procura blindar o escopo contra mudanças, a abordagem ágil aceita a mudança. Uma abordagem interessante colocada por Sliger (2006) é a forma de criar a WBS. Ao invés de conter todo o trabalho para o projeto como normalmente é feito no PMBOK® , no modelo ágil a WBS pode ser feita no início de cada release. O primeiro nível poderá conter as iterações e para cada iteração os pacotes de trabalho são as funcionalidades do bakclog priorizados para o release dispostos em ordem de prioridade. Durante o início da iteração as funcionalidades são então quebradas em tarefas. Ver Figura 9.

Figura 9 - WBS (Adaptado). Fonte: Sliger, 2006.

No gerenciamento de riscos do projeto que no PMBOK® significa identificar possíveis eventos negativos que possam atrapalhar o andamento do projeto e tentar minimizar sua ocorrência e impacto. Na abordagem ágil o risco é tratado

68

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

69

®

Figura 10 – Desenvolvimento Iterativo – Grupos de processos do PMBOK . Adaptação da apresentação de Koch (KOCH, 2004).

Na apresentação, Koch (2004) navega por cada um dos grupos de processo e faz um paralelo entre os processos do PMBOK® e discutindo o impacto com o enfoque iterativo. Ele elenca para cada grupo de processo a compatibilidade e incompatibilidade entre o PMBOK® e as metodologias ágeis e o que pode ser feito. Koch conclui dizendo que “nada nas metodologias ágeis é incompatível com os processos do PMBOK® ” e “pode ser oportuno reforçar as metodologias ágeis com processos do PMBOK® , porém somente onde realmente é necessário e sem comprometer a agilidade”.

70

4. ESTUDO DE CASO

O estudo de caso que será retratado a seguir, originalmente intitulado “Agile and PMBOK® Guide Project Management Techniques: closer than you think”, foi escrito por Peter Bennison em 2008 e publicado no site do PMI® . Ele descreve de maneira bem objetiva a integração dos dois frameworks em um projeto de referência realizado para o Governo do Canadá entre 2007-2008. Como em muitos projetos de TI, enfrentaram desafios de gerenciamento e de aceitação do cliente.

4.1 Metodologias ágeis e o guia PMBOK® . Técnicas de gerenciamento de projeto: mais perto do que você imagina

4.1.1 Introdução

O projeto apresentado neste trabalho foi parte de um grande plano para revisar e atualizar a presença na internet de um grande departamento do governo canadense em 2007-2008. O objetivo do programa foi analisar o website existente, entrevistar os stakeholders e desenvolver estruturas de governança, procedimentos e estratégias de desenvolvimento de conteúdo. O plano também desenvolveu requisitos para o Sistema de Gerenciamento de Conteúdo de Web (WCMS), estabeleceu e executou o projeto de implementação para o WCMS. O projeto discutido aqui cobre a parte de implementação.

71

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

4.1.2 Áreas de conhecimento do guia PMBOK® e a abordagem SCRUM

As seis áreas de conhecimento que foram estudadas neste trabalho estão delineadas abaixo, com alguns detalhes de como a abordagem usando SCRUM explicitamente ou implicitamente as tratou.

4.1.3 Gerenciamento de integração do projeto

Gerenciamento de Integração do projeto se refere à premissa, planejamento e coordenação das atividades de projeto. Os elementos indispensáveis desta área de

72

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

73

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

74

7. Reunião de revisão do processo SCRUM. Estes sete elementos foram repetidos em cinco iterações. O tempo aproximado para cada iteração foi de 20 dias úteis. A equipe de desenvolvimento e o cliente usaram as estimativas iniciais para propor uma distribuição das funcionalidades de tal modo que cada iteração ficou com aproximadamente o mesmo esforço mantendo a prioridade por valor de negócio. O Product Backlog também permitiu que a distribuição de trabalho e de responsabilidades fosse claramente indicada, o que foi essencial desde que havia uma mistura de pessoal de desenvolvimento do cliente e do fornecedor. Finalizando, SCRUM trouxe rigor suficiente para suprir as expectativas do cliente relativas a esta área. Da perspectiva do gerenciamento de integração do projeto, este projeto confirmou uma observação de Griffiths (2004) que uma abordagem utilizando o guia PMBOK® pode coexistir com uma abordagem SCRUM. Além disso, isto mostrou que o Termo de Abertura informal pode ser suficiente para obter a aprovação do patrocinador do projeto. Isto é independente do fato de usar SCRUM como metodologia de desenvolvimento.

4.1.4 Gerenciamento de escopo do projeto

Gerenciamento de escopo do projeto, seguindo a definição como uma das áreas de conhecimento do guia PMBOK® , está em desacordo com SCRUM. Em teoria, o guia PMBOK® (2008, p. 103) parece estar alinhado com a filosofia do SCRUM envolvendo gerenciamento de escopo, citando Turner (2002, p. 94), que disse "Gerenciamento de Escopo de Projeto inclui os processos necessários para garantir que o projeto contenha todo o trabalho necessário, e somente o trabalho necessário, para completar o projeto com sucesso." Entretanto, o PMBOK® restringe ainda mais: "Gerenciamento de escopo de Projeto está principalmente centrado em definir e controlar o que está e o que não está no projeto." (PMBOK® , 2008, p.103). Na seção ferramentas e técnicas do capítulo sobre Gerenciamento de Escopo do projeto deixa

75

bem claro que o escopo deve ser gerenciado e controlado utilizando ferramentas centralizadas e processos de tomada de decisão (PMBOK® , 2008, p.121), mas como foi notado por Griffiths (2004), as ferramentas que foram implementadas para gerenciar o escopo (por exemplo: WBS, Análise de variação) são difíceis de atualizar e rapidamente ficam obsoletas. O projeto de referência usou o conjunto de ferramentas do SCRUM para gerenciar as mudanças de escopo. Foram usados o Product Backlog e o critério de aceite de alto nível para estabelecer a prioridade e o cronograma do desenvolvimento. No início de cada iteração, o cliente e o fornecedor co-definiram critérios de aceite para cada funcionalidade a ser desenvolvida. Após cada iteração, o cliente verificou que as funcionalidades cumpriam o critério de aceite. O cliente também tinha a oportunidade de refazer as prioridades do próximo conjunto de funcionalidades do Product Backlog e podia atualizar os requisitos das funcionalidades já desenvolvidas ou ainda em desenvolvimento, mas consciente que mudanças no esforço resultariam em custo adicional. Detalhes sobre como estes ajustes em custo foram gerenciados estão na seção "gerenciamento de custo de projeto". O projeto de referência revelou uma limitação significativa na abordagem SCRUM que não está presente em projetos utilizando o PMBOK® : a ausência de um documento inicial de arquitetura geral. Isto causou um desconforto no cliente relacionado às mudanças de escopo realizadas durante a implementação. Para cuidar desta limitação, o fornecedor produziu um documento de discussão do escopo para descrever as opções para as funcionalidades essenciais do sistema. Este documento disponibilizava uma opção "gold/silver/bronze" que delineava os custos e benefícios de diversas abordagens de design para uma funcionalidade. A abordagem do projeto de referência foi diferente da abordagem de um projeto tradicional das seguintes maneiras: •

Primeiro, em lugar de um controle estrito de mudanças, existiram três oportunidades distintas para ajustar o escopo de cada iteração;

•

Segundo, em lugar de manter o documento de escopo atualizado, o projeto não ajustou a WBS inicial, principalmente porque esta foi criada para orientar o desenvolvimento;

76

•

Terceiro, em lugar de entregar um documento de arquitetura de sistema antes da implementação, esta preocupação do cliente foi tratada através de um documento justificando as mudanças de rumo e de escopo ocorridas durante o desenvolvimento.

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

4.1.5 Gerenciamento do tempo do projeto

Considerando o gerenciamento do tempo, projetos usando SCRUM e PMBOK® são semelhantes na definição de atividades e estimação/duração de recursos. Entretanto, para as outras subáreas, as abordagens são diferentes. SCRUM dita que a equipe do projeto deve colaborar para definir a seqüência, cronograma e controle do cronograma adequado. Observe que a equipe do projeto inclui tanto os recursos de desenvolvimento quanto os do cliente que dividem a responsabilidade pela conclusão em tempo do projeto. No projeto de referência, o cliente determinou a seqüência do Product Backlog e a lista de funcionalidades a serem incluídas na solução final. A equipe de desenvolvimento determinou a estimativa para a solução final e, crucialmente, implementaram o projeto. Isto permitiu que eles pudessem avaliar rapidamente o impacto na estimativa de esforço quando ocorresse uma mudança no escopo,

77

porque eles conheciam as hipóteses que foram assumidas. Este exercício de estimativas foi realizado durante dois dias no início do projeto quando os requisitos iniciais e os critérios de aceite estavam sendo discutidos. Estas estimativas foram revisadas no início de cada iteração para verificar sua exatidão, baseando-se nos resultados das iterações anteriores. A equipe usou o artefato do SCRUM chamado burndowm chart para garantir que cada iteração completou as funcionalidades exigidas no período de 20 dias. Ajustes diários refletiam a avaliação de cada membro da equipe do tempo restante da tarefa designada a cada um. A atribuição de tarefas foi realizada de acordo com o interesse/especialidade. O prazo inicial designado a cada tarefa foi baseada na estimativa inicial mais "um acréscimo" devido a alguma mudança de escopo da funcionalidade. Diariamente, a equipe podia ver o tempo restante relativo ao baseline. Cada iteração seguia uma curva "S" de conclusão, e por diversas vezes, membros da equipe julgaram que não conseguiram progredir o suficiente no começo. Os motivos para o início vagaroso foram discutidos em iterações posteriores. Por exemplo, foi identificado que a estimativa não considerou o número de reuniões de revisão que ocorriam no começo de cada iteração. Como resultado, tarefas foram explicitamente adicionadas ou modificadas para garantir que o diagrama capturasse todas as atividades relacionadas ao projeto. Por último, o cronograma e o controle do cronograma foram tratados usando métodos do PMBOK® , comparando o Product Backlog e o baseline a cada iteração de 20 dias. Devido ao compromisso com a entrega a cada 20 dias, a equipe do projeto e os patrocinadores puderam facilmente rastrear o desempenho. Quando uma iteração não cumpria o prazo previsto, ficava claro que a equipe do projeto deveria avaliar como recuperar este tempo. Todos da equipe podiam facilmente rastrear as divergências diárias, mensais e do cronograma. As abordagens usando SCRUM e o PMBK são semelhantes nas definições de atividades e processos de estimativa. Contudo, a organização do cronograma, controle e designação de tarefas são compartilhadas no SCRUM, enquanto o PMBOK® utiliza uma abordagem centralizada.

78

4.1.6 Gerenciamento de custos do projeto

Esta é a principal interface entre o projeto e as funções de controladoria financeira de uma organização. É difícil para o SCRUM alterar estes processos porque na maioria das vezes estes existem devido à política ou motivos regulatórios. O PMBOK® aparentemente está em vantagem nesta área de conhecimento porque os artefatos e processos gerados através do gerenciamento de Integração, Escopo e Tempo são todos usados no cálculo do custo do projeto. Além disso, muitos projetos de TI têm "preço fechado", mas de acordo com Poppendieck e Poppendieck (2003, p.171) tais contratos estimulam um comportamento self-serving do cliente e um comportamento defensivo do fornecedor. Estas restrições são os desafios que um projeto SCRUM deve superar sem perder o espírito de confiança e cooperação entre cliente/fornecedor que é o alicerce da filosofia de desenvolvimento do SCRUM. O projeto de referência foi sujeito a restrições de "orçamento fechado" e "despesas significativas de controladoria de projetos" para garantir que autorizações de tarefas Task Authorizations (TAs) contra o acordo vigente cumprissem os requisitos de controladoria e orçamento. Inicialmente, parecia que SCRUM não poderia ser usado por causa dessa restrição. Entretanto o fornecedor propôs um mapeamento 1-a-1 entre cada iteração e cada TA. Isto é, cada TA cobriria somente as funcionalidades a serem desenvolvidas em um período de 20 dias. Como o Product Backlog incluiu estimativas iniciais de esforço, o cliente poderia ver como os contratos se relacionam com o esforço, mais alguma despesa extra. No início de cada iteração, um novo TA representando uma estimativa de esforço revisada e uma nova lista de funcionalidades seria assinada. No final da iteração, o cliente determinaria se o fornecedor entregou a lista de funcionalidades com a qualidade acordada e o fornecedor determinaria se os custos de desenvolvimento estão de acordo com os requisitos de rendimento. No final da iteração, o fornecedor ou o cliente poderiam ajustar os termos e o escopo da TA seguinte para refletir uma nova realidade envolvendo requisitos técnicos ou

79

de negócio. Ao longe deste processo, o cliente pôde ver o valor de negócio no sistema em desenvolvimento, enquanto o fornecedor aprofundou seu conhecimento sobre os processos e o ambiente técnico do cliente. Enfim, isto permitiu que o fornecedor e o cliente atuassem como parte de um time, empenhados a concluir o projeto com sucesso. Nesta área, o PMBOK® e os requisitos de controladoria financeira têm a primazia, mas o projeto de referência mostrou que a estrutura de custos existente "ditada" pelo contrato pôde ser usada para suportar SCRUM. A qualquer momento, se o cliente ou o fornecedor sentissem que não estavam obtendo o retorno suficiente diante do que foram investidos, eles tinham a opção de ou mudar para um método mais tradicional ou simplesmente mudar de parceiro. Felizmente, nenhuma destas opções extremas foi tomada porque as duas partes concordaram que o projeto gerou valor de negócio aceitável e mensurável a um custo razoável.

4.1.7 Gerenciamento de qualidade do projeto

Nesta área, SCRUM e o PMBOK® estão alinhados. Ambos reconhecem a importância do planejamento da qualidade e garantir a satisfação das expectativas do cliente e do sucesso em geral, e ambos sabem que um resultado inferior ocorre quando a equipe responsável pela implementação é forçada a cumprir as metas através de horas extras ou se o processo final de inspeção da qualidade é apressado para cumprir o cronograma (PMBOK® , 2008, p. 180). O projeto de referência usou as seguintes medidas de qualidade para assegurar que o projeto cumpra as necessidades de negócio do cliente: 1. Critérios de aceite detalhados foram elaborados após a reunião de kick-off de cada iteração para definir objetivos claros de desenvolvimento; 2. O cliente foi responsável pelo teste do sistema após cada iteração para verificar se o critério de aceite foi satisfeito;

80

3. Como o processo de desenvolvimento foi iterativo e como o product backlog foi priorizado, então as funcionalidades mais importantes foram desenvolvidas primeiro, assim foram sujeitas repetidamente a testes (mesmo que indiretos) porque posteriormente novas funcionalidades foram adicionadas ao sistema; 4. As primeiras funcionalidades desenvolvidas foram para manutenção de release para garantir que o código customizado pudesse ser transferido com segurança entre ambientes de desenvolvimento, teste e produção. Estes elementos ajudaram a garantir que a qualidade do sistema pudesse ser testada repetidamente. Tanto o PMBOK® quanto o SCRUM enfatizam que as metas de qualidade são elementos importantes de um projeto bem sucedido. As ferramentas e as técnicas podem variar para cada projeto, mas os passos e procedimentos delineados no PMBOK® são aplicáveis a projetos usando SCRUM.

4.1.8 Gerenciamento de comunicação do projeto

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

81

Finalmente, sem reuniões periódicas para verificar o status do projeto com o executivo responsável, itens relacionados ao projeto não seriam levantados e nem revistos. SCRUM difere do PMBOK® porque não define um tipo nem um layout específico de comunicação. Segundo o SCRUM, pode ser suficiente usar um quadro e caneta para resumir o resultado de uma discussão, ou pode ser necessário gerar uma proposta formal para registrar as escolhas feitas relativas a um item técnico. Para cada situação, a melhor ferramenta de comunicação e a abordagem adotada variam. No projeto de referência, as reuniões que foram bem sucedidas e que tiveram a maior presença foram as reuniões semanais para discutir o status do projeto com o executivo responsável. Ao longo do projeto, os gerentes e arquitetos do fornecedor e o cliente se reuniam regularmente para discutir o progresso, identificar os riscos, registrar as decisões e definir as ações a serem tomadas. Estas reuniões eram informais (mas documentadas) e serviam para acompanhar o progresso do projeto. As reuniões diárias não foram bem sucedidas, tanto que eram realizadas esporadicamente. Isto foi surpreendente, uma vez que as reuniões são um item importante na metodologia SCRUM. A principal razão para não ocorrerem tantas reuniões da própria equipe é que estes ficavam todos numa única sala e o diálogo entre os membros era freqüente. Quando surgia algum problema, este era rapidamente identificado e toda a equipe se envolvia para encontrar uma solução. Além disso, o progresso da equipe era transparente para todos por causa das atualizações freqüentes do burndown chart. Finalizando, as reuniões de revisão da iteração eram moderadamente bem sucedidas. Estas reuniões com o cliente e o usuário final permitiram que a equipe revisasse e entendesse melhor o sistema enquanto este era desenvolvido. Estas reuniões ajudavam a estabelecer uma clara e significativa direção para o desenvolvimento, além de ajudar a deixar o usuário à vontade com o sistema final. O projeto de referência mostrou que esta área de conhecimento do PMBOK® foi no máximo uma parte opcional para um projeto deste tamanho. SCRUM possibilitou que as formas de comunicação e oportunidades de feedback resolvessem assuntos sem que fosse necessário recorrer à uma reunião de status com o executivo responsável.

82

4.1.9 Conclusões

O projeto de referência apresentado neste trabalho demonstrou que diversas áreas de conhecimento chave do guia PMBOK® são completamente ou parcialmente suportadas pelo framework SCRUM, incluindo Gerenciamento de Integração do projeto, Gerenciamento de Tempo do projeto, Gerenciamento de Custo do projeto e Gerenciamento de Qualidade do projeto. Contudo, existe pouco suporte do SCRUM para Gerenciamento de Escopo do projeto e Gerenciamento de Comunicações do projeto como delineado pelo PMBOK® . Quando se avalia a adequação do SCRUM para um projeto, uma organização deve determinar se a falta de suporte ao Gerenciamento de Escopo e de Comunicações do projeto impede seu sucesso. Pelas razões expostas acima, o projeto de referência não foi afetado de modo significativo por estas limitações. De fato, SCRUM proporcionou uma quantidade apropriada de estrutura e processo ao projeto, e foi de fato a razão chave para o sucesso deste projeto.

83

CONCLUSÃO

Neste trabalho, discutimos os méritos e os problemas das abordagens baseadas na metodologia ágil e no PMBOK® , embora as técnicas de desenvolvimento ágil sejam consideradas como tendo "potencial" e as filosofias ágeis fundamentalmente não estejam em desacordo com as áreas chaves do guia PMBOK® . A resistência à adoção de técnicas ágeis em lugar de procedimento e ferramentas mais convencionais parece ser gerada basicamente da falta de conhecimento de quando e como as técnicas ágeis e o guia PMBOK® se alinham ou não. Não existem muitas pesquisas sobre o relacionamento entre as técnicas de desenvolvimento ágil e aquelas baseadas no Project Management Body of Knowledge (PMBOK® ). O objetivo deste trabalho foi aumentar nosso conhecimento sobre como utilizar as técnicas ágeis para satisfazer as áreas de conhecimento do PMBOK® e descrevemos algumas propostas para torná-las compatíveis. Em seguida, discutimos como as técnicas foram aplicadas em um estudo de caso que notadamente comprovou que é possível utilizar sim SCRUM e PMBOK® juntos e como as necessidades do cliente foram gerenciadas. Atualmente, agilidade é chave para alcançar altos níveis de inovação em projetos, seja utilizando o guia PMBOK® , SCRUM ou um modelo híbrido. O grande desafio não é iniciar a utilização das boas práticas, mas deixar o time, o cliente e a empresa prontos para as mudanças de paradigmas que a metodologia ágil traz.

84

REFERÊNCIAS

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

85

COCKBURN, A.; HIGHSMITH, J. Agile Software Development: the business of innovation, IEEE Computer, sept., 2001, p. 120-122. COCOMOII, Qualidade da produção de software. Disponível em: <www.proqualiti.org.br/revista/revista_ProQualiti_maio2005.pdf>. Acesso em: 10. set. 2009. EXTREME PROGRAMMING. Figura 1. Disponível , Acesso em: 10 set. 2009.

em:

FDD. Feature Driven Development. Disponível . Acesso em: 13 abr. 2009.

em:

FEATURE DRIVEN DEVELOPMENT. Figura . Acesso em: 10 set. 2009.

em:

2,

Disponível

FIGUEIREDO A. M. As armadilhas do SCRUM. Disponível em: <www.cin.ufpe.br/~ers/SCRUM_MundoPM-Abril-Maio-2009.pdf >. Acesso em: 20 jun. 2009. FOWLER, M. The New Methodology. 2005. Disponível em: . Acesso em: 15 abr. 2009. GARCIA, M. Visual Studio Team System. Team Foundation Server. São Paulo: Brasport, 1999. GRIFFITHS, M. Using agile alongside the PMBOK® . PMI® Global Congress Proceedings, 2004. ISOTTON NETO, E. Scrumming: ferramenta educacional para ensino de práticas do SCRUM. Dissertação (Mestrado em Informática). Faculdade de Informática. Porto Alegre: Pontifícia Universidade Católica do Rio Grande do Sul, 2008, 123p. JEFFRIES, R.; ANDERSON, A.; HENDRICSON, C. Extreme Installed. Upper Saddle River, NJ, Addison-Wesley, 2001.

Programming

86

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

87

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

88

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