FACULDADE DE INFORMÁTICA E ADMINISTRAÇÃO PAULISTA LEONARDO BRUNO PEREIRA DE ARAUJO ESTUDO COMPARATIVO DA COMPATIBILIDADE

Transcrição

1 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

2 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

3 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

4 ii Dedico À minha família, pelo carinho, apoio, compreensão e pela participação no processo do curso.

5 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.

6 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.

7 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.

8 LISTA DE FIGURAS Figura 1 - Extreme Programming Figura 2 - Feature Driven Development Figura 3 - MSF Figura 4 - MSF Figura 5 - SCRUM Figura 6 - Quadro de tarefas Figura 7 - Formato de Processo Figura 8 - Grupos de Processos Figura 9 - WBS Figura 10 - Desenvolvimento Iterativo Grupos de processos do PMBOK... 69

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

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

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

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

13 12 SUMÁRIO INTRODUÇÃO METODOLOGIAS ÁGEIS Extreme Programming Estórias Planejamento Desenvolvimento iterativo Iterações de uma semana Teste antecipado Refactoring Programação em par Envolvimento dos clientes Feature Driven Development Desenvolver um modelo geral Construir uma lista de funcionalidades Planejar por funcionalidade Projetar por funcionalidade Construir por funcionalidade Microsoft Solutions Framework Release Manager SCRUM Como funciona? Papéis e responsabilidades Artefatos, conceitos e fases Product Backlog Planejamento da Sprint Execução e controle da Sprint Final da Sprint PMI e PMBOK O gerenciamento de projeto História... 53

14 Hoje PMBOK Projeto Gerenciamento de projeto Grupos de Processos Áreas de conhecimento Processos nos grupos e nas áreas de conhecimento DIFERENÇAS, SIMILARIDADES E PROPOSTAS DE COMPATIBILIZAÇÃO Diferenças e similaridades Propostas de compatibilização ESTUDO DE CASO Metodologias ágeis e o guia PMBOK. Técnicas de gerenciamento de projeto: mais perto do que você imagina Introdução Áreas de conhecimento do guia PMBOK e a abordagem SCRUM Gerenciamento de integração do projeto Gerenciamento de escopo do projeto Gerenciamento do tempo do projeto Gerenciamento de custos do projeto Gerenciamento de qualidade do projeto Gerenciamento de comunicação do projeto Conclusões CONCLUSÃO REFERÊNCIAS... 84

15 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 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.

16 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, O navio da marinha americana USS Vicennes derrubou um Airbus 320, o qual foi confundido por um F 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, Um problema com os microprocessadores provocou uma falha na divisão de números com ponto flutuante. Por exemplo, ao dividir ,0 por ,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.

17 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, 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 Blackout no Noroeste dos EUA, 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?

18 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 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

19 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

20 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.

21 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).

22 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,

23 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.

24 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;

25 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.

26 25 Figura 1 - Extreme Programming (Adaptado). Fonte: 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: 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).

27 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) 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

28 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-bang 1, 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 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.

29 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) 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

30 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 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) 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;

31 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 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;

32 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.

33 32 Figura 2 - Feature Driven Development (Adaptado). Fonte: 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): 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

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

35 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) 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

36 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.

37 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";

38 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 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.

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

40 39 de alto nível tarde Fonte: MSF for Agile Software Development Process Guidance, Microsoft, É á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 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

41 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) Como funciona? A Figura 5 ilustra o ciclo de desenvolvimento do SCRUM de forma simplificada. Figura 5 SCRUM, Fonte:

42 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) 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):

43 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 Artefatos, conceitos e fases Product Backlog

44 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) 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).

45 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

46 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).

47 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)

48 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:

49 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).

50 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).

51 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:

52 51 Figura 6 Quadro de tarefas (adaptado), Kniberg, 2006, p Final 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).

53 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).

54 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 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 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

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

56 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 à

57 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

58 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).

59 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).

60 Á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 Integração Escopo Tempo Custos Qualidade Recursos Humanos Comunicações Riscos Objetivo Assegurar que todos os elementos do projeto sejam adequadamente coordenados Assegurar que todo o trabalho requerido e somente aquele requerido esteja incluído no projeto, para concluí-lo de maneira bem sucedida Assegurar a conclusão do projeto no prazo previsto Assegurar que o projeto seja concluído dentro do orçamento previsto Assegurar que os produtos ou serviços do projeto estejam em conformidade com o solicitado pelo cliente, ou contratante Fazer uso mais efetivo do pessoal envolvido com o projeto Assegurar que as informações do projeto sejam adequadamente obtidas e transmitidas Assegurar um tratamento seguro ao risco do projeto, cuidando de sua identificação, análise e resposta

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

62 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 Monitorar e controlar riscos Aquisições Planejar aquisições Conduzir aquisições Fonte: PMBOK, 2008, p Administrar aquisições Encerrar contrato 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.

63 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.

64 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

65 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

66 65 de práticas ágeis no planejamento e acompanhamento de projetos de software. O objetivo principal da abordagem ágil é simplificar o processo de desenvolvimento, minimizando e dinamizando tarefas e artefatos que são importantes no processo, além do software funcionando. Na realidade, independentemente das metodologias ágeis, outras tendências em gerenciamento de projetos já indicavam certa convergência entre a comunidade de gerência e a comunidade técnica em relação à agilidade. A seguir diferenças marcantes em relação às práticas do PMBOK, destacadas na Tabela 4. Tabela 4 - Principais diferenças e similaridades entre as metodologias ágeis e PMBOK PMBOK Metodologias Ágeis São adaptativas: O desenvolvimento também ocorre de forma iterativa e evolutiva, com ondas sucessivas. A principal diferença é que cada iteração corresponde usualmente a uma fase do projeto, o que normalmente não é de curta duração. Pode levar mais do que 4 semanas. São 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 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

67 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

68 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, 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

69 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):

70 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.