Resumo: O Gerenciamento de Projetos vem se mostrando em um contexto no qual as organizações públicas tem, cada vez mais, buscando melhorias em seus processos de gestão e otimização de recursos. Este trabalho insere-se nesse contexto, propondo a aplicação da metodologia de Gerenciamento de Projetos Ágil de desenvolvimento de software (SCRUM) às praticas tradicionais de gerenciamento de projetos recomendadas pelo PMBOK na Administração Pública.

Palavras-chave: Administração Pública, Gerenciamento de Projetos Ágil, PMO Ágil, SCRUM

Abstract: The Project Management has proved in a context in which public organizations have, increasingly, seeking improvements in their management processes and optimize resources. This work fits into this context, proposing the application of the methodology of Project Management Agile software development (SCRUM) to traditional practices project management recommended by the PMBOK in Public Administration.

Keywords: Public Administration, Agile Project Management, Agile PMO, SCRUM.

1.     INTRODUÇÃO

As áreas de Tecnologia da Informação (TI), notadamente em organizações da Administração Pública, tem enfrentado uma pressão crescente para reduzir orçamentos, melhorar a qualidade de seus produtos e realizar entregas mais rapidamente. As demandas do negócio se deparam rapidamente com as atuais práticas de TI: complicados requisitos de gestão, nebulosos, fracos na gestão de projetos, arquiteturas complexas, lentas e ciclos de testes. Reconhecendo a necessidade de ser "mais ágil" em resposta a estas pressões, as equipes de TI estão cada vez mais olhando para as práticas ágeis. Isto porque elas destilam a essência de TI em uma coleção eficiente de técnicas e oferecem uma forma de trabalhar intuitivamente atraente.

No entanto, fazer a nuança nas organizações públicas não é algo trivial, ao contrário, pode requerer muito tempo, uma vez que tais práticas contradizem muitos comportamentos. Na abordagem tradicional, existem longas e distintas fases de atividade, incluindo análise, programação, testes e implantação. Estas fases são ligadas entre si por artefatos como casos de uso, codificação, ou casos de teste. Concepção, desenvolvimento e teste são realizados de forma continua em ciclos curtos de entregas através de processos altamente colaborativos. As atividades são mantidas ligadas a pessoas, não a artefatos.

O desenvolvimento ágil de software é realmente uma mudança nos métodos de trabalho e uma mudança no estilo de gestão, e este estilo está voltado para as pessoas e a base de experiência existente, mais do que a própria engenharia, devendo constituir-se em uma verdadeira tendência, uma mudança nos métodos de trabalho e mudança paradigmática na maneira como o software é produzido (ANDERSON, 2003).

A TI é gerenciada pelo alinhamento de todas as partes de entrega com sucesso do software funcionando e empenhada para as próximas entregas. Claramente, "ser Ágil" pode ser uma grande mudança para uma posição diferenciada. O caminho da adoção das práticas ágeis está bem encaminhado, mas mal iluminado.

Cada organização e cada projeto são únicos. Os processos de trabalho ágeis devem ser suficientemente específicos para serem compreensíveis, definidos o suficiente para serem repetitivos, maleáveis o suficiente para mudanças com experiência e suficientemente flexíveis para acomodar uma ampla gama de operações reais. As práticas ágeis devem ser suficientemente amplas para suportar diversas situações ou trarão poucos benefícios. As pessoas envolvidas com estas práticas devem dominá-las rapidamente ou a alteração do processo será entendida como resultado de valor limitado.

Quando estão em processo de transição para as práticas ágeis, os gestores devem estar sintonizados com várias dicotomias. Ao efetuar a mudança, as práticas estão sendo suficientemente empreendidas, ou é um caso de tentar fazer demasiadamente mais rápido? Fazer as pessoas abordarem a mudança com ceticismo saudável, ou elas estão passivamente agressivas em direção à mudança? A transparência na execução expõe problemas ou faz as equipes jogarem com os resultados para esconder desempenho? O reconhecimento por estes pequenos detalhes separam o sucesso da adoção de abordagens ágeis de uma falha na iniciativa por mudança. O desafio para os gerentes iniciantes nas práticas ágeis é converter as forças que resistem à mudança naquelas que permitam mudar.

O cenário global tem mostrado o aumento da competitividade, exigindo cada vez mais agilidade e rapidez das organizações, ao mesmo tempo em que cresce a quantidade de projetos a serem executados, tomando mais difícil o controle de indicadores de desempenho de custos, prazos e qualidade que garantam a utilização consistente da metodologia de gerenciamento de projetos tradicional.

A metodologia de Gerenciamento de Projetos Ágil está voltada para a rapidez de adequação às mudanças e às situações voláteis do ambiente, com um grau de informalidade em seu processo que é merecedor de várias criticas.

Desta forma, o objetivo geral desse trabalho é avaliar as fases, valores e princípios do Gerenciamento de Projetos Ágil em projetos de desenvolvimento de software com o SCRUM.

2.     O GERENCIAMENTO DE PROJETOS

O objetivo deste capítulo e apresentar de forma consistente o estado da arte do gerenciamento de projetos no desenvolvimento de software em seus moldes tradicionais de forma a fundamentar o desenvolvimento do estudo objeto do capítulo seguinte.

2.1  O estado da arte

Atualmente, o gerenciamento de projetos tradicional ainda é o método mais utilizado no desenvolvimento de software. Baseado em processos bem definidos e documentados, estes tem passado por várias melhorias em diversas organizações (BOEHM, 2002). A forma planejada, o nível de detalhamento e a disciplina aplicada aos seus processos permitem a medição e o controle de todas as suas etapas, permitindo que os membros da equipe conheçam claramente os seus papéis e que a evo1uco do projeto venha a ser demonstrada pelos artefatos gerados em cada uma destas fases. Seu ciclo de vida vem a ser definido pelos processos de iniciação, planejamento, execução, controle e fechamento, onde o gerente do projeto é o responsável pela rea1izaco dos objetivos do projeto (PMI®, 2004). Tais processos definem as atividades que deverão ser executadas, os recursos utilizados para a sua realização e os produtos a serem entregues ao cliente.

Por estar baseado no processo, o gerenciamento tradicional depende muito do apoio da alta gerência, da comunicação e da estrutura organizacional, tomando-se estes os requisitos que garantirão o sucesso do empreendimento. (BOEHM, 2002).

Segundo BOEHM (2002), a forca do método tradicional de gerenciamento de projetos está na base histórica criada pela repetição e comparação decorrentes da padronização estabelecida pelo processo:

A partir das informações históricas e da repetição obtém-se a melhoria da capacidade do processo através da padronização, medição e controle do projeto (BOEFIM, 2002).

Alguns dos conceitos mais importantes deste método tradicional de gerenciar projetos estão relacionados com a utilização e aplicação do processo estabelecido e escolhido pela organização. O primeiro define o quanto a contribuição do processo definido e importante para a obtenção dos resultados esperados – capacidade do processo. O segundo está voltado para o grau de preocupação da empresa como um todo na aplicação destes processos – maturidade da organização. O processo deve, ainda, ser monitorado e as melhorias incorporadas, a fim de manter estes processos atualizados em relação às características do ambiente de realização destes projetos – melhoria dos processos.

Contudo, o método tradicional apresenta problemas para aqueles projetos onde devam existir situações críticas que envolvam prazos restritos e com mudança exagerada de requisitos, não conseguindo responder com facilidade e rapidez as mudanças impostas pelos clientes, o que exige uma atuação mais forte e centralizada por parte do gerente de projetos, vindo este a ser o principal responsável pelo sucesso do projeto. Cada membro da equipe tem a definição clara do seu papel e de suas atividades, limitando a influência e uma maior colaboração durante a execução do projeto.

O cliente tem sua participação concentrada nas fases iniciais do projeto quando ocorre o levantamento de requisitos, vendo sua participação diminuir na medida em que o projeto evolui, passando então a realizar apenas as validações das entregas geradas pelo projeto.

A fase de planejamento é extensa e detalhada. E nela que é definido o cronograma com suas atividades, pontos de controle e procedimentos responsáveis por dar direção para a geração dos produtos. O plano será utilizado para medir o progresso durante a fase de execução do projeto e está sujeito às alterações ocorridas com a evolução do trabalho. A comunicação a que é submetida a equipe do projeto está baseada na documentação gerada ao longo das etapas do processo.

Mudanças são necessárias para a sobrevivência das empresas em mercados extremamente competitivos. Estas mudanças organizacionais profundas e, normalmente, de longo prazo delineiam fortemente o caráter da organização, porém, não se deve permitir que a cultura organizacional torne-se engessada, burocrática e em não conformidade com os desejos de seus clientes e de valores que valem de fato a pena. É preciso sim que existam ações transformadoras, onde cada colaborador tenha consciência de ser um agente da manutenção ou transformação da cultura.

O sucesso da implantação de toda e qualquer metodologia será alcançado na mesma medida em que o background da organização esteja preparado para receber as mudanças que uma nova abordagem trará para a organização, garantindo que os processos e pessoas estejam alinhados à sua estratégia de negócio. As pessoas e suas culturas são pontos de suma importância neste processo. É necessário mudar os valores comuns e as crenças dos grupos para que os resultados possam surgir através de processos de melhoria contínuos. Toda mudança tende a ser dificultada na medida em que existem culturas centradas internamente, processos burocráticos e o medo que o ser humano tem do desconhecido. A cultura deve ser compreendida como um processo contínuo, proativo da construção da realidade e que dá vida ao fenômeno da cultura em sua totalidade. Quando compreendida desta forma, a cultura pode não mais ser vista como uma simples variável que as sociedades ou organizações possuem. Em lugar disto, ela deve ser compreendida como um fenômeno ativo, vivo, através do qual as pessoas criam e recriam os mundos dentro dos quais vivem.

1.1.  Escritório de Projetos (PMO)

O conceito do Project Management Office (PMO), o mesmo que Escritório de Gerenciamento de Projetos (EGP), apareceu no final da década de 50 e começo da década de 60 (KERZNER, 2002). Os grandes projetos militares, aeroespaciais e da construção civil caracterizam uma época em que os projetos eram específicos para algumas poucas áreas e eram executados por especialistas e com suas ferramentas especificas, e estes eram focados em controles. Com o surgimento dos primeiros softwares de gestão "amigáveis" no início da década de 70, surgem também projetos de diferentes áreas funcionais, porém isolados um dos outros, sendo a função maior dos escritórios a de dar suporte a estes projetos. Tal visão perduraria ate o inicio da década de 90, quando despontam os softwares de gerenciamento, responsáveis por administrar muitos projetos, complexos e integrados, e com o foco voltado para a estratégia das organizações. Em meados de 2000, o Gerenciamento de Projetos ganha ênfase e o Escritório de Projetos passa a ser o responsável por garantir o uso dos processos de gerenciamento de projetos.

Tabela 1 - Evolução do escritório de projetos. (LEITAO, 2006)

Desde a década de 60 a gestão de projetos apresenta alguma evolução e os escritório de projeto começam a ganhar importância. A partir de 2000 as organizações começam a vivenciar uma época de competição em que a velocidade de disponibilização de novos produtos e serviços tome-se o elemento de fundamental importância para a sobrevivência destas organizações, que deverão ser mais pressionadas por lançar produtos com menores custos e prazos. O cenário contemporâneo deverá mostrar cada vez mais que as organizações e seus escritórios de projetos se sobressaem as demais por aquilo que fazem de melhor, sendo o fator responsável por esta diferenciação do nível de conhecimento que estas organizações detêm em relação às demais. O conhecimento individual deverá ser convertido em conhecimento organizacional. Os modelos tradicionais não deverão atender mais as necessidades das organizações. As metodologias ágeis deverão firmar-se como alternativas e tenderem a se concretizar na medida em que estas mesmas empresas decidam compartilhar seus valores e estimulem a interação entre seus membros, um dos princípios destas metodologias. Toma-se necessário, portanto, a adequação e evolução do escritório de projetos as respectivas metodologias.

Dentre as diversas estruturas de gerenciamento de Projetos existentes nos dias de hoje, provavelmente o PMO (Project Management Office) é a de maior sucesso e das mais estudadas pelas empresas, podendo variar de acordo com o nível de maturidade da organização. A maneira como estes Escritórios de Projetos são estruturados em uma organização vai variar sempre de uma organização para outra. No entanto, dependendo da forma como estes escritórios só implantados nas empresas, poderão ainda proporcionar suporte a metodologia e coaching aos próprios gerentes de projeto. Entre as funções dos escritórios de projeto, existem três principais áreas: desenvolvimento, suporte e controle.

As funções de desenvolvimento envolvem o recrutamento, o treinamento e o desenvolvimento dos gerentes de projeto. As funções de suporte são aquelas que ajudam os gerentes de projeto a fazerem seu trabalho de uma maneira melhor através do oferecimento de assistência e clareza com os processos do gerenciamento de projetos. As funções de controle são aquelas da gerência funcional e incluem: a avaliação de gerentes de projeto, a alocação de gerentes de projeto a projetos, a garantia de que as entregas dos projetos são produzidas e se apresentam com uma qualidade adequada e, o estabelecimento de padrões. As organizações, grandes e pequenas, estão percebendo os benefícios que um controle consistente sobre seus projetos pode oferecer. Porém, deve-­se tomar cuidado para não transformamos o PMO de uma empresa em um departamento puramente burocrático, conforme defende BURGHARDT:

Um PMO não deve se transformar em um mero e degradante acumulador e distribuidor de papéis. Existem muitos aspectos que deveriam ser analisados depois que a decisão de implementação do PMO foi tomada. BURGHARDT (2000).

Alguns destes aspectos são: o envolvimento da alta gerência, dos gerentes funcionais e dos gerentes de projeto da organização, o compromisso da organização com a metodologia de gerenciamento de projetos e os benefícios que a nova estrutura ira trazer a organização.

O PMO consiste em uma estrutura voltada para a aplicação dos conceitos de gerenciamento de projetos dentro de uma organização, podendo assumir diferentes funções junto à mesma: desde um simples setor para o auxílio no controle de projetos, W um departamento da empresa por onde passam todos os projetos gerenciados pela organização.

1.2.  O papel do PMO nas estruturas organizacionais

Segundo o PMBOK (PMI, 2004), os projetos normalmente fazem parte de uma organização que é major que o projeto. Mesmo quando o projeto é externo (joint ventures, parcerias), ele ainda será influenciado pela organização ou organizações que o iniciaram. A maturidade da organização em relação ao seu sistema de gerenciamento de projetos, sua cultura, seu estilo, sua estrutura organizacional e seu escritório de projetos também pode influenciar o projeto.

Assim como todo e qualquer projeto, a implantação do PMO também é um projeto e certamente um dos passos mais importantes e definir seus objetivos e a razão que levaram a organização a implantá-lo. E preciso também que os stakeholders estejam cientes sobre os papéis e responsabilidades atribuídos ao PMO, que tipos de serviços estarão sendo prestados, a quem ele estará subordinado, sua abrangência e, principalmente, quem é ou são seus patrocinadores.

A importância do PMO nas estruturas organizacionais reside no fato de que existem várias razões de insucesso na sua implantação e que uma delas está diretamente associada à escolha incorreta de onde ele estará posicionado na estrutura organizacional. Algumas vezes o EGP é criado por áreas que geralmente estão ligadas a projetos voltados para atender capacidades internas da empresa, usando-o como instrumento de defesa contra a pressão de outros grupos que os culpam sistematicamente pelos atrasos e a falta de qualidade prometida.

Segundo LESSA (2006), existem cinco tipos de Estruturas Organizacionais, a saber:

                                          I.          Organização Funcional Tradicional: E um agrupamento de pessoas por especialização, o gerente de projetos no tem uma autoridade formal.

                                        II.          Organização Funcional Project Expediter: Serve como um link na comunicação entre o coordenador dos projetos nas áreas funcionais.

                                      III.          Organização Funcional Project Coordinator: É similar ao Project Expediter, exceto que se reporta a um gerente de alto nível com uma autoridade major.

                                     IV.          Organização Matricial (Fraca, Balanceada, e Forte): Na Organização Matricial Fraca é comum verificar-se gerentes de vários projetos, o poder é dividido entre os gerentes funcionais e de projetos onde o único a se dedicar exclusivamente ao projeto é o Gerente de Projetos, enquanto os membros da equipe compartilham atividades nos projetos e em suas atividades funcionais. Já na Organização Matricial Balanceada verifica-se um equilíbrio entre as atividades funcionais e as de projeto, enquanto na Organização Matricial Forte verifica-se uma visão maior na organização com um alto valor na gestão de projetos.

                                       V.          Organização Projetizada: Apresenta como característica uma estrutura separada e vertical estabelecida para cada projeto, todos os membros da equipe se reportam diretamente ao gerente de projeto.

O Gerenciamento de Projetos e a implementação do Escritório de Gerenciamento de Projetos, ou PMO, está diretamente ligado a Estrutura Organizacional da organização fortemente relacionada, sendo dele dependente o seu sucesso.

O PMBOK (PMI, 2004) afirma, ainda, que "a estrutura da organização executora geralmente limita a disponibilidade de recursos em um espectro de uma estrutura funcional a uma estrutura por projeto, com diversas estruturas matriciais intermediárias".

A falta de padronização que possa reportar o desempenho dos projetos da organização faz com que os gerentes de projetos estejam sobrecarregados e sem tempo para análise de dados e tomada de decisão, as lições aprendidas de outros projetos não são registradas / documentadas, reconhece que a gerência de projetos como competência critica para o seu sucesso. Assim, o PMO assume um papel importante nas Estruturas Organizacionais, podendo existir em qualquer uma das estruturas organizacionais, inclusive nas que apresentam uma organização funcional.

Os membros da equipe do projeto se reportarão diretamente ao gerente de projetos ou ao PMO. O gerente de projetos se reporta diretamente ao PMO, neste caso dizemos reportar diretamente a alta organização da empresa, além da flexibilidade do gerenciamento centralizado oferecer ao gerente de projetos major oportunidade de promoção dentro da organização.

3.     A METODOLOGIA DE DESENVOLVIMENTO ÁGIL

Muitas técnicas tem sido discutidas e elaboradas com a intenção de tomar o processo de desenvolvimento de software mais simples, mais fácil de implementar e mais responsivo as necessidades do cliente.

As metodologias ágeis refletem alguns bons exemplos. O excesso de formalidade pode limitar o progresso do projeto, mas por outro lado, o caos total, sem a utilização de processos pode impedir que os objetivos do projeto sejam alcançados, conforme defende PEREIRA (2007). Por outro lado, HIGHSMITH (2004) enfatiza que a ausência de estrutura ou estabilidade pode levar ao caos, mas que a estrutura em demasia gera rigidez. A criação de um processo específico seria justificável em um manufaturamento repetitivo, onde as atividades não são alteradas com frequência, ou nunca são modificadas. Entretanto, se a atividade e mais incerta, o processo teria que ser mais flexível e de fácil adaptação.

As organizações tem buscado a melhoria de seus processos nos últimos anos, objetivando a redução de custos e prazos, o aumento da previsibilidade e major satisfação dos clientes, com um menor número de defeitos no produto final e melhores resultados em seus negócios. As transformações do ambiente também são acompanhadas pelo gerenciamento de projetos.

O PMBOK (PMI, 2004) é um guia de melhores práticas de gerenciamento de projetos que aplicados adequadamente permitem a realização de um projeto com sucesso. Os processos de gerenciamento de projetos são divididos em nove áreas de conhecimento (escopo, prazo custo, qualidade, riscos, comunicação, recursos humanos, aquisição e integração) que organizam a aplicação das técnicas e ferramentas necessárias à realização de um projeto.

Os gerentes de projetos falam de uma "restrição tripla" - escopo, tempo e custo do projeto - no gerenciamento de necessidades conflitantes do projeto. A qualidade do projeto e afetada pelo balanceamento desses três fatores. Projetos de alta qualidade entregam o produto, serviço ou resultado solicitado dentro do escopo, no prazo e dentro do orçamento. A relação entre esses fatores ocorre de tal forma que se algum dos três fatores mudar, pelo menos outro fator provavelmente será afetado. Os gerentes de projetos também gerenciam projetos em resposta a incertezas. Um risco do projeto é um evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo em pelo menos um objetivo do projeto (PMI, 2004).

O método tradicional está voltado para o processo sequencial e preocupado com a qualidade do produto a ser entregue. O método ágil volta-se para uma maior rapidez de adequação a estas mudanças e mantém o cliente integrado a equipe, além de proporcionar ciclos mais curtos de desenvolvimento (BOEHM, 2002), o que faz com que os especialistas em gerenciamento de projetos travem grandes discussões.

Contudo, o gerenciamento de projetos está inserido em um contexto de frequentes falhas ocasionadas pelo no cumprimento dos prazos de entrega dos produtos que vão desde a falta de conhecimento dos métodos e técnicas ate uma má uti1izaco das práticas de Gesto de Projeto. Neste cenário, APM - ou Gerenciamento de Projetos Ágil - vem preencher o espaço deixado entre a Gerência de Projetos e os indicadores de desempenho relacionados ao prazo de entrega e qualidade desses projetos. APM é uma abordagem relativamente nova, o que tomam necessários estudos mais detalhados e a aplicação de casos reais para a confirmação de sua real contribuição no gerenciamento de projetos.

Apesar de poder-se notar uma melhora significativa ao longo da última década do século 20 nos projetos de desenvolvimento de sistemas, a pesquisa publicada pela Standish Group Internacional (2003) os resultados insatisfatórios continuam relativamente altos. A pesquisa sugere ainda que, os projetos falham pela falta de conhecimento nas práticas de gerenciamento de projetos e não pela falta de verba ou conhecimento tecnológico. As empresas passaram a adotar boas práticas do gerenciamento de projetos, contribuindo para a melhora dos resultados dos projetos.

3.1  O manifesto ágil

O Manifesto for Agile Software Development (2001) publicado em fevereiro de 2001, por um grupo de 17 pensadores independentes, autores e representantes das técnicas e metodologias ágeis sobre desenvolvimento de software (Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas), e às vezes concorrentes entre si, discutiu, coletou e documentou ideias comuns sobre o desenvolvimento de software, identificando uma abordagem ágil aplicada ao desenvolvimento de projetos, estabelecendo um padrão comum para processos ágeis.

O Manifesto fornece algumas ideias concretas, ao mesmo tempo em que discute que é preciso definir um conjunto de valores baseados na confiança e respeito mútuos e de promover modelos organizacionais baseados em pessoas, colaboração e construção de uma comunidade de organizações em que gostariam de trabalhar.

O movimento ágil não é antimetodologia. De fato, muitos de seus integrantes desejam restaurar a credibilidade da palavra metodologia, querem restabelecer um equilíbrio, abraçam a modelagem, mas não no sentido de um "diagrama empoeirado" em um repositório. A documentação é abraçada por eles, mas não em centenas de páginas de rara manutenção e utilização. E preciso planejar, mas reconhecer os limites deste planejamento em ambientes turbulentos. E preciso entregar produtos ágeis, capazes de serem adaptados de forma fácil e de se ter equipes com características semelhantes.

O "Manifesto Ágil", como passo a ser referenciado, 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 o software estar executável, 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 e médias organizações trabalham e respondem a mudanças.

Os valores considerados pelo Manifesto for Agile Software Development (BECK et al, 2001) são:

                                          I.     A valorização dos indivíduos e as interações sobre a importância dos processos e ferramentas;

                                        II.     O software funcionando sobre uma extensa documentação;

                                      III.     A colaboração dos clientes sobre a negociação em contratos;

                                      IV.     As respostas às mudanças sobre o cumprimento de um piano.

3.2 Princípios do gerenciamento de projetos ágil

O Gerenciamento de Projetos Ágil foi criado a partir dos valores e princípios do Manifesto for Agile Software Development (BECK et al, 2001). Este guia de princípios pode ajudar equipes a decidir quais seriam as práticas mais adequadas no meio empresarial, a gerar novas práticas quando necessário, ou a avaliar alguma prática que venha a surgir e, implantá-la em um gerenciamento ágil.

O gerenciamento de projetos é constituído de seis princípios que juntos criam um ambiente que encoraja a surgir os resultados no projeto. Isolados, eles podem contribuir no andamento do projeto. Estes princípios tratam do valor do produto e do estilo de gerenciamento baseado na liderança e colaboração. No primeiro, são focadas as entregas iterativas e baseadas nas funcionalidades que gerem valor para o cliente, sempre com a busca da excelência técnica. No segundo principio, toma-se claro a necessidade de se encorajar a exploração, construir equipes que possuam elevada capacidade de se adaptar e que simplifiquem o processo. Os princípios do Gerenciamento de Projetos Ágil, segundo o Manifesto for Agile Software Development (BECK et al, 2001) estão descritos a seguir:

                                          I.      A satisfação do cliente a partir de entregas rápidas e continuas de um software valioso, que agregam valor;

                                        II.     Garantir a vantagem competitiva com a mudança de requisitos, mesmo em desenvolvimento bastante avançado;

                                      III.     Entregar frequentemente software funcionando em prazos curtos de algumas semanas;

                                      IV.     Pessoas responsáveis pelo negocio e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto;

                                        V.     Construir projetos em torno de indivíduos motivados, dando-lhes o ambiente e confiança de que necessitam para fazer o trabalho;

                                      VI.     O método mais eficiente e eficaz de transmitir informações em uma equipe é a comunicação pessoal através da conversa "cara-a­cara";

                                    VII.     A medida mais importante sobre o progresso do projeto são as entregas de código que funcionam;

                                  VIII.     Processos ágeis promovem o desenvolvimento sustentável. Patrocinadores, desenvolvedores e usuários devem ser capazes de manter o ritmo constante indefinidamente;

                                      IX.     Atenção continua para a excelência técnica e bom projeto reforçam a agilidade;

                                        X.     Simplicidade - a arte de maximizar o valor de trabalho não feito - é essencial;

                                      XI.     XI. As melhores arquiteturas, requisitos, e projetos emergem de equipes auto-organizadas;

                                    XII.     XII. Em intervalos regulares, a equipe reflete sobre como se tomar mais eficaz e, em seguida, ajusta o seu comportamento.

3.3 Desenvolvimento iterativo

Uma iteração e caracterizada por uma sequência distinta de atividades com baseline e critérios de avaliação planejados. Cada iteração incorpora atividades de modelagem de negócio, requisitos, análise e projeto, implementação, testes e implantação à medida que o projeto vai evoluindo em suas fases de maturação. A cada iteração um conjunto de produtos é gerado. Neste sentido, uma medida boa do progresso e ter o software funcionando no final de cada iteração. Os benefícios do desenvolvimento iterativo podem residir no fato do desenvolvimento lidar com mudanças, o sistema ser integrado continua e progressivamente, os riscos serem atacados mais cedo, porque os elementos são integrados progressivamente. E possível realizar um aprendizado e melhoria continua do processo, gerando produtos mais robustos com o aumento da reusabilidade.

O desenvolvimento baseado no modelo cascata é um modelo de desenvolvimento de software sequencial através das fases que o compõe. O modelo em cascata demanda uma substancial integração e esforço de teste para alcançar o fim do ciclo de vida, um período que pode se estender por vários meses ou anos. Os requisitos de sistema identificados demoram muito tempo ate serem implementados e testados, podendo atrasar a resolução de problemas, sendo uma das causas das falhas do projeto em cascata.

No método ágil, ao contrário, deve-se produzir um desenvolvimento completo e teste num período de 4 semanas. Enfatiza-se a obtenção de pequenos pedaços de funcionalidades executáveis para agregar valor ao negócio cedo, antecipando a resolução de riscos ao projeto e continuamente agregar novas funcionalidades através do ciclo de vida do projeto.

O ciclo de vida do desenvolvimento iterativo é dividido em fases e iterações. Por fase podemos entender como sendo o espaço de tempo entre dois marcos significativos do projeto, durante o qual objetivos são atingidos, artefatos elaborados e decisões sobre passar ou não para a próxima fase são tomadas. As fases indicam a maturidade do sistema. Cada uma das fases é dividida em iterações. Mudanças de requisitos e táticas são acomodadas, sendo mais fácil melhorar e refinar o produto, aumentando sua robustez, inclusive com a realização de testes e integrações acontecendo muito mais cedo, contribuindo para um maior aprendizado das organizações na medida em que o ciclo de vida evolui.

A filosofia ágil está voltada para o desenvolvimento iterativo. Ou seja, obter as exigências iniciais e criar um código que funcione, seguidos por mais exigências e por mais códigos que funcione, identificando uma iteração como um "pacote de tempo" que possui um custo fixo e um conjunto de funcionalidades que pode variar, onde estas funcionalidades serão priorizadas pelo cliente e comporão a iteração.

A flexibilidade é identificada na medida em que funcionalidades priorizadas pelo cliente poderão ser descartadas, se classificadas no final da lista. Assim, e possível existir funcionalidades que sejam perdidas, mas nunca as datas.

3.4  .As práticas PMIBOK x Metodologia Ágil

3.4.1 O ciclo PDCA do Gerenciamento de Projetos Tradicional

O ciclo de vida do gerenciamento de projetos tradicional é definido pelos processos de iniciação, planejamento, execução, controle e fechamento, onde o gerente do projeto e o responsável pela realização dos objetivos do projeto (PMI, 2004). Estes processos especificam as atividades ou tarefas que serão executadas, as pessoas que irão realizá-las e os principais produtos a serem entregues ao cliente durante o desenvolvimento do projeto. A metodologia de desenvolvimento aplicada nesta modalidade de desenvolvimento de software são os modelos em cascata ou espiral, embora se perceba um crescimento do modelo iterativo e incremental.

Os processos citados acima foram mapeados pelo PMBOK de acordo com o ciclo PDCA (Plan-Do-Check-Act) modificado por DEMING em 1999 (PMI, 2004), onde o planejamento corresponde ao Plan, a Execução ao Do e o Controle ao Check e Act. Os processos de iniciação e fechamento correspondem ao início e término do ciclo, respectivamente.

3.4.2 O ciclo PDCA do Gerenciamento de Projetos Ágil

O modelo de estrutura do Gerenciamento de Projetos Ágil é composto das fases: Visão, Especular, Explorar, Adaptar e Fechar. Estas fases refletem tanto as atividades quanto os seus resultados, como são descritas a seguir (HIGHSMITH, 2004):

                                          I.     Visão: E a tradicional Inicia1izaco do projeto. Determinar os objetivos do projeto, a equipe do projeto e definir como eles irão trabalhar junto. Esta fase ë a etapa crítica para o sucesso do projeto. Primeiramente, precisa-se saber o que será produzido, ter uma visão do produto e o escopo do projeto. Segundo, quem estará envolvido no projeto desde clientes a stakeholders. E terceiro, como eles trabalharão juntos.

                                        II.     Especular: Indica um futuro incerto, mas mesmo assim tenta-se planejá-lo. O Gerenciamento de Projetos Ágil consiste mais, nos conceitos de visão e exploração do que especular e fazer. Isto mostra a alta volatilidade dos projetos atuais. Nesta fase é desenvolvido um planejamento, seguido por planejamentos específicos em cada iteração.

                                      III.     Explorar: Tem o objetivo de entregar as características testadas, em um curto espaço de tempo, procurando reduzir o risco e as incertezas do projeto. Entregas são feitas sob a forma de incrementos de funcionalidades do produto e, são divididas entre os ciclos do projeto.

                                      IV.     Adaptar: Analisa os resultados entregues, o ambiente de negócio atual, o desempenho da equipe e adapta o que for necessário, para a próxima iteração.

                                        V.     Fechar: Conclui o projeto e passa o aprendizado adiante. E outra atividade, menos glamorosa, é a de finalizar os itens em aberto, finalizar a documentação e a produção do material de suporte.

As fases Especular, Explorar e Adaptar se alternam a cada iteração para assim poder produzir um produto mais robusto. A Especulação, quando d retomada, assume o papel de planejar o ciclo mais uma vez, levando em consideração os resultados alcançados. Uma vez finalizado o produto, entra-se na fase fechar (HIGHSMITH, 2004).

3.4.3 Áreas de conhecimento do gerenciamento de projetos aplicáveis

A possibilidade de mudança do gerenciamento de projetos tradicional para o gerenciamento de projetos ágil requer uma atenção especial em cinco áreas de conhecimento definidas pelo PMBOK (PMI, 2004), são elas: Gerenciamento de Recursos Humanos, Gerenciamento da Qualidade, Gerenciamento da Integração, Gerenciamento do Escopo e Gerenciamento do Tempo.

Tanto a abordagem ágil quanto a abordagem tradicional identificam as três restrições de um projeto como sendo: custo, tempo (agenda) e escopo. Para a abordagem tradicional, no entanto, o escopo do projeto deve ser fixado para que tempo e custo possam ser estimados. Já as abordagens ágeis se manifestam acreditando que o escopo estará em constante mudança, então tempo e custo devem ser fixados. Em abordagens ágeis a estratégia de Comando-controle deve ser substituída por facilitação, colaboração e suporte.

Uma abordagem segundo as áreas do conhecimento do PMBOK (PMI, 2004) nos leva a perceber que: a preocupação está na definição do escopo em um alto nível que permita o entendimento do trabalho, inclusive com a participação do cliente para a priorização das funcionalidades; o cronograma é orientado ao produto que será produzido em iterações curtas que contribuem para uma redução dos conflitos pela cumplicidade no processo; as alterações são incorporadas dentro da iteração mais apropriada e de comum acordo com o cliente, podendo elevar o custo final; os padrões a serem seguidos devem ser estabelecidos no inicio do projeto e estarem concentrados na programação em pares; a monitoração e o controle dos riscos ocorrem durante todo o processo de desenvolvimento; a comunicação é colaborativa e direta entre todos os membros da equipe, o que exige certo grau de maturidade por parte da organização, do cliente e da equipe; todos os participantes do projeto executam suas tarefas, planejam e tomam decisões em conjunto, compartilhando suas experiências; o processo de aquisição deve ser evitado em função da volatilidade dos requisitos; a atuação colaborativa da equipe com o cliente favorece um major grau de informalidade e o conhecimento implícito é privilegiado; o papel do gerente de projetos é voltado para o papel de facilitador ou coordenador das atividades.

a) Gerenciamento dos Recursos Humanos

O PMBOK (PMI, 2004) define o planejamento organizacional como o processo onde papéis e responsabilidades são atribuídos e o desenvolvimento de time como o desenvolvimento do conjunto de competências e habilidades apropriadas para cada membro do time.

A forma ágil de se fazer isso é estabelecer times cross-functional e permitir que eles sejam autogerenciados. Com times autogerenciados muitos imaginam que o papel de gerente de projeto passa a ser ameaçado. Ao contrário, este passa a ser muito mais importante para o projeto e para o time, agindo como um "líder servidor" descrito na década de 80 por Robert Greenleaf, e não mais como o gerente "comando-controle".

b) Gerenciamento da Qualidade

Pelo fato do código ser incrementado durante o desenvolvimento de cada iteração, a abordagem ágil traz o controle de qualidade novamente para dentro da análise e desenvolvimento do produto, estando a qualidade agora presente desde as primeiras fases do projeto ao invés de ficar aguardando "o pior" no final do projeto. Todo o time tem seu papel no controle de qualidade em práticas ágeis, todos estão envolvidos em garantir que a entrega valorizará o retomo do investimento (ROT) do cliente.

c) Gerenciamento da Integração

Em Gerenciamento de Integração um entregável chave é o documento de Piano do Projeto que é elaborado e mantido peio gerente de projeto. Em abordagens ágeis este entregável é substituído por uma série de atividades de visão e planejamento que são executadas em ciclos iterativos. O controle de mudanças também é algo que sofre mudanças bem grandes nas abordagens ágeis, pois aqui este e integrado nas rotinas diárias de um time ágil. As mudanças do produto são gerenciadas através de um repositório de funcionalidades que e gerenciado pelo gerente de produto do cliente. Este e responsável por manter esta lista com funcionalidades priorizadas de acordo com o valor de negócio que elas representam para o ciente. Isto é ø que garante o ROT.

No final de cada iteração, o time realiza as reuniões de revisão e retrospectiva para colher as percepções de cada membro da equipe. O time (cliente, desenvolvedores, arquitetos, gerente de projeto, testadores) é o Change Control Board.

d) Gerenciamento de Escopo e Tempo

A abordagem ágil trabalha com tempo (agenda) e custo fixo, e para implementar as funcionalidades de alto valor para o negócio do cliente. O escopo do projeto pode, e deve ser fixo se: clientes não necessitassem de novas funcionalidades, não houvesse mudanças de mercado nem mudanças de tecnologia e se o cliente realmente conhecesse tudo que precisa no início de um projeto. Planejamento, definição, verificação e controle de escopo são matérias que recebem grande atenção no PMBOK (PMT, 2004).

Abordagens ágeis também comecem uma grande atenção para estas matérias, mas com uma filosofia de gerenciamento de escopo bem diferente. A abordagem tradicional trabalha duro para prevenir (e evitar) mudanças de escopo, enquanto abordagens ágeis aguardam e "abraçam" estas mudanças.

4.     SCRUM: UMA METODOLOGIA AGIL

O objetivo deste capítulo é descrever de forma sucinta o SCRUM como uma metodologia ágil e sugerir de forma consistente um modelo de escritório de gerenciamento de projetos capaz de planejar, executar e controlar os projetos que necessitem de uma maior agilidade, além dos aspectos organizacionais envolvidos neste ambiente de gerenciamento.

4.1 Entendendo o SCRUM

O SCRUM foi criado no início de 1990 por Ken Schwaber e Jeff Sutherland para ajudar as organizações a lutar com complexos projetos de desenvolvimento. O trabalho de Jeff Sutherland com as primeiras ideias do SCRUM e de Ken Schwaber com metodologias transformados em vários anos de conversa, colaboração e pesquisas culminaram em um documento que ambos escreveram descrevendo SCRUM. Sete anos mais tarde, Ken Schwaber e 16 outros se juntaram, em Fevereiro de 2001, descobriram o que tinham em comum e escreveram o Manifesto Ágil. Eles fundaram a Agile Alliance, uma organização sem fins lucrativos, dedicada a criação de software ágil.

SCRUM é um processo ágil que permite manter o foco na entrega do major valor de negócio, no menor tempo possível. Isto permite a rápida e continua inspeção do software em produção (em intervalos de duas a quatro semanas). As necessidades do negócio é que determinam as prioridades do desenvolvimento de um sistema. As equipes se auto-organizam para definir a melhor maneira de entregar as funcionalidades de major prioridade. Entre cada duas a quatro semanas todos podem ver o real software em produção, decidindo se o mesmo deve ser liberado ou continuar a ser aprimorado por mais um "Sprint".

4.2 Conceitos

• Product backlog: E uma lista de produtos priorizada pelo proprietário do produto e que servirá de entrada para uma Sprint.

• Sprint: A Sprint é um "time-box" de 30 dias no qual o time multifuncional do projeto ira produzir uma parte do produto definido pelo cliente. Este time será o responsável por estimar o trabalho a ser realizado em uma Sprint e dizer o que será desenvolvido naquele time-box.

• Planning meeting: E a reunião de planejamento do Sprint. Ela ocorre no inicio de cada Sprint e pode ser composta por qualquer pessoa, além da equipe do projeto, que poderá ser convidada a participar da reunião a fim de agregar valor a reunião desde que tenha sido aprovada a sua participação pelo proprietário do produto. Em um primeiro momento o proprietário do produto e o time fazem a revisão do Product Backlog, com a intenção de discutir o propósito e as metas de cada item. O time, então, define os itens que serão desenvolvidos na próxima Sprint e a meta. Em seguida, o proprietário do produto deverá detalhar algum item ou esclarecer dúvidas quanto ao objetivo do mesmo. O time elabora a estratégia de desenvolvimento para que a meta da Sprint seja atingida. Ao final desta reunião eles devem saber responder como construir as funcionalidades do produto durante o Sprint. Essas estratégias são geradas a partir do detalhamento dos itens do Product Backlog. As tarefas geradas através desse detalhamento e chamada de Sprint Backlog, onde os membros do time deverão escolher suas tarefas e estimá-las em horas.

• Daily meeting: Reunião diária iniciada a partir do inicio da Sprint, que é realizada sempre no mesmo local e horário, com o facilitador e os membros do time, com duração exata de 15 minutos, para que cada um dos membros do time possam relatar os progressos e obstáculos que forem surgindo em seu caminho.

• Review: Momento em que os membros da equipe identificam se existe diferença entre o que deveria ser entregue e o que está sendo entregue.

• Retrospective: Representa a ferramenta mais importante para que o sucesso seja alcançado, pois o time comenta tudo aquilo que funcionou e no funcionou dentro da Sprint. O time visualiza os itens citados, discute sobre cada um deles e planeja ações para a próxima Sprint.

4.3 Papéis

• Product owner (proprietário do produto)

E o responsável por definir as funcionalidades do produto e decidir as datas de lançamento e conteúdo, assumindo a responsabilidade pela rentabilidade (ROT) e priorizando as funcionalidades de acordo com o valor de mercado. Ajusta funcionalidades e prioridades e aceita ou rejeita o resultado dos trabalhos.

• Scrum Master (Gerente do Projeto)

Representa a gerência para o projeto. E o responsável pela aplicação dos valores e práticas do SCRUM, devendo remover obstáculos e garantir a plena funcionalidade e produtividade da equipe. Garante, ainda, a colaboração entre os diversos papeis e funções, servindo de escudo para interferências externas.

• Developers (Equipe)

Sua composição está voltada para um grupo entre 5 e 9 pessoas, formada por programadores, testadores, desenvolvedores de interfaces, etc., que atuam em tempo integral. O administrador de base de dados, por exemplo, 6 uma função que constitui exceção a este grupo. A equipe SCRUM é auto-organizável e as trocas entre seus membros só ocorre na mudança de "Sprints".

A produtividade da equipe deriva de fazer as coisas certas primeiro, a partir de uma lista priorizada pelo proprietário do produto das atividades a serem realizadas, e fazer estas coisas de forma muito eficaz. A maximização desta produtividade está diretamente relacionada às medições de linhas de código por dia ou pontos-de-função por pessoa/mês, que são definidos pela própria equipe. E a equipe que define o planejamento e execução das atividades que estão sob sua responsabilidade. O Gerente do Projeto ou qualquer outro membro pode orientar, aconselhar e informar a equipe, mas é da responsabilidade da equipe gerir a si própria. O trabalho da equipe é concentrado em um período de 30 dias, onde haverá muita integração e disseminação de informações entre os seus membros. A equipe faz o que for necessário para cumprir o seu compromisso. Cada um de seus membros possui várias qualificações, o que facilita o trabalho de seleção própria por parte de cada membro das atividades a serem executadas. A equipe tem que descobrir o seu próprio trabalho.

4.4 O ciclo de vida SCRUM

No SCRUM, os projetos são organizados em ciclos (iterações), tipicamente mensais, denominados Sprint. O Sprint representa um Time Box, dentro do qual é executado um conjunto de atividades.

A lista de todas as funcionalidades a serem implementadas em um projeto é denominada Product Backlog. Essa lista não precisa estar completa no início do projeto, podendo crescer e sofrer mudanças ao longo do amadurecimento dos usuários e do produto a ser entregue.

No início de cada Sprint, é realizada uma reunião de planejamento denominada Sprint Planning Meeting. E nessa reunião que o Product Owner, ou proprietário do produto a ser entregue, prioriza os itens do Product Backlog.

O Scrum Team seleciona as atividades que terá a capacidade de completar durante o Sprint. Estas atividades são, em seguida, transferidas do Product Backlog a Sprint Backlog, onde serão quebradas em uma ou mais tarefas, facilitando a divisão do trabalho entre os membros da equipe.

A cada dia do Sprint é realizada uma breve reunião diária chamada de Daily Scrum, na qual deve ser disseminado o conhecimento adquirido no dia anterior, identificados os impedimentos verificados e priorizado o trabalho que se inicia, contribuindo para que a equipe permaneça no caminho.

Ao final de cada Sprint é realizada a Sprint Review Meeting, na qual o Scrum Team apresenta, normalmente em forma de "demonstração", as funcionalidades concluídas em um Sprint. O objetivo do Sprint, que foi determinado no Sprint Planning Meeting, é avaliado neste momento. Nessa reunião podem participar o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e ate membros de outros projetos.

Finalmente, é realizada uma Sprint Retrospective, uma espécie de retrospectiva para identificar o que funcionou bem durante um Sprint, o que poderá ser melhorado e quais as ações deverão ser tomadas para esta melhora. A equipe, então, parte para a definição de um novo Sprint, reiniciando o ciclo.

4.5 O PMO Ágil

As organizações visualizam no PMO a solução dos seus problemas. E bem verdade que o PMO pode vir a assumir muitos produtos e serviços potenciais, porém, esta posição estará sempre relacionada às necessidades da organização e da visão e comprometimento de seu patrocinador. O PMO é responsável por adquirir e implementar a metodologia de gerenciamento de projetos que será utilizada por toda a organização durante a execução de cada um de seus projetos. O Escritório de Gerenciamento de Projetos acrescenta um valor significativo à organização e aos seus projetos. O modelo de PMO deve estar alinhado às expectativas da organização para que sua implantação e continuidade sejam asseguradas. O PMO é a casa do time do projeto, devendo ser, ainda, o local onde devam ser conduzidas, planejadas, organizadas, controladas e finalizadas as atividades dos projetos.

Sob esta ótica, d interessante observar que "os projetos reúnem e vendem conhecimento" (KERZNER, 2002), ficando facilitada a centralização dos conhecimentos adquiridos ao longo dos projetos, e que as melhores práticas de um projeto especifico podem ser reutilizadas em projetos futuros. Cabe ressaltar que as organizações em sua grande maioria não se interessam ou mesmo não conseguem fazer com que o conhecimento individual dos seus colaboradores seja convertido em conhecimento organizacional. O "Conhecimento" tem ganhado relevância e trazido vantagem competitiva sustentável em todos os setores de atuação das organizações.

Dentre as diversas estruturas de gerenciamento de Projetos existentes nos dias de hoje, provavelmente o PMO é a de major sucesso e das mais estudadas pelas empresas, podendo variar de acordo com o nível de maturidade da organização. Porém, deve-se tomar cuidado para não transformarmos o PMO de uma empresa em um departamento puramente burocrático. BURGHARDT (2000) diz que um PMO não deve se transformar em um mero e degradante acumulador e distribuidor e papéis.

Os tradicionais escritórios de gerenciamento de projetos são responsáveis por prover controles e equilíbrio para o desenvolvimento e organizações de TI quanto aos orçamentos e calendário dos projetos. A supervisão e gestão que vem do PMO direcionam determinados comportamentos em gestores de projetos e, portanto, no projeto.

Do mesmo modo, um PMO Ágil prevê certos controles e equilíbrio, mas incide principalmente sobre o bem-estar global do projeto. Esta diferença de "tom", não só direciona diferentes comportamentos, mas também pode contribuir para apoiar a transformação radical no seio da organização. A forca motriz toma-se encapsulada na diferença de perspectiva entre tradicionais ganhos de valor inquiridos e do valor inquirido pela agilidade alcançada.

A diferença chave e estabelecida em uma visão centrada no projeto para a abordagem tradicional em oposição a uma visão centrada no produto para a abordagem ágil. A visão tradicional refere-se ao ato de completar o plano do produto e a viso ágil obviamente refere-se ao produto em si. Para entender melhor esta diferença é preciso garantir que compreendemos as motivações por trás das ações e decisões que cada PMO tem. Por isso, e preciso olhar para algumas das características especificas de cada escritório de projeto, tradicional e ágil.

Nas organizações que utilizam metodologias tradicionais dirigidas ao planejamento para executar seus projetos, ha geralmente um PMO para proporcionar uma fonte de controle e equilíbrio. Nestas organizações, o PMO toma-se a força mais influente da organização com relação à execução de programas e a abordagem por que sio realizadas. No sentido clássico de "você é o que você mensura", quando o PMO solicita que os gerentes de projeto cheguem à revisão preparados para discutir orçamento, o progresso e os trabalhos realizados ate a data - as variáveis essenciais para cálculos de valor agregado - os gerentes de projeto começarão a centrar suas atividades e suas equipes sobre estas medidas.

Este tipo de medição só traduz indicadores passados à equipe dizendo quão bem que tem feito, ao contrário dos indicadores de condução, sugerindo a equipe aonde eles chegarão. Em última análise, o resultado do cálculo de valor agregado diz o quão bem ou mau negócio foi realizado ate a data, mas no podemos recomendar-lhes exatamente como as coisas vão sair. O efeito disto e que toda a equipe Se preocupa mais sobre onde eles estão, mas não o suficiente sobre o que eles estão oferecendo de valor para negócio.

5.     CONSIDERAÇÕES FINAIS

O método tradicional de gerenciamento de projetos está consolidado no mercado e os resultados de sua aplicação são evidentes nos diversos ambientes de projeto. Para as organizações públicas mais conservadoras, existe a possibilidade de mesclar as características dos métodos tradicionais e ágeis permitindo uma avaliação gradativa dos pontos positivos e negativos das duas abordagens.

Na abordagem ágil as exigências de desenvolvimento podem mudar em algum ponto. Isto é bom em um ponto de vista de desenvolvimento, mas o gerenciamento de mudanças do escopo e também utilizado para beneficiar o cliente. O patrocinador do cliente concordou em financiar o projeto, baseado em receber uma determinada solução, por um determinado custo em uma determinada data. Se a equipe do projeto continuar a aceitar as mudanças do escopo por conta própria, o projeto poderá requerer mais tempo e um custo muito mais elevado do que o concordado pelo patrocinador.

Um dos desafios das metodologias ágeis deve ser o de implementar estratégias de gestão de riscos sem tomar a metodologia complexa e pesada. Outro desafio é fazer com que as metodologias ágeis possam ser utilizadas em grandes empresas e equipes, eliminando os problemas de comunicação interna as equipes e existentes de forma comum em grandes empresas onde os funcionários estejam dispersos geograficamente.

Apesar de verificar-se um crescimento no uso das metodologias ágeis, ainda no puderam ser verificados casos de sucesso de seu uso em projetos grandes e crípticos. Torna-se necessário, então, uma maior adoção das organizações na sua utilização, para que melhores sejam os resultados empíricos em termos de vantagens, desvantagens e riscos.

Por ser um ambiente de desenvolvimento dinâmico, em constantes mudanças e menos orientado a documentação, a Web toma-se mais adequada para a utilização das metodologias ágeis do que as metodologias tradicionais.

A utilização de SCRUM em projetos ajuda a construir tão somente aquilo que O cliente valoriza, contribuindo para que os produtos sejam criados mais adaptados ao cliente. As equipes tomam-se mais efetivas na definição das atividades, gerando major comprometimento, motivação e confiança. Ha um major estimulo a colaboração entre os membros da equipe, o que permite que o time esteja mais coeso, na medida em que cada membro sabe o que os demais estão fazendo, toma-se natural o compartilhamento e disseminação do conhecimento, cada pessoa da equipe escolhe o que vai fazer, as responsabilidades estão visíveis, existe transparência e alinhamento para atender o objetivo do projeto. Toda a equipe passa a ter conhecimento daquilo que está sendo construído e com que finalidade.

O uso de SCRUM não é difícil. Contudo, toma-se mais importante fazer com que o time, o cliente e a organização estejam prontos para as mudanças de paradigmas que a metodologia ágil é capaz de proporcionar. A ausência ou a falta de uma cultura organizacional que esteja comprometida com o planejamento e acompanhamento de projeto pode prejudicar a qualidade no produto final dos projetos.

Este trabalho apenas introduziu brevemente alguns comentários sobre os métodos tradicional e ágil de gerenciamento de projetos com o intuito de permitir que parâmetros que auxiliem na definição da melhor estratégia venham a ser estabelecidos e aplicados no gerenciamento de projeto, permitindo as organizações públicas atender as necessidades e expectativas das áreas demandantes de softwares.

6.     REFERENCIAS BIBLIOGRAFICAS

ANDERSON, D. J; SCHRAGENHEIM, E. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall, 2003.

BECK, K. et al. Manifesto for Agile Software Development, 2001. Disponível em <http://www.agilemanifesto.org>. Acesso em: 09 nov. 2016

BOEHM, B. W; TUMER R. Balancing Agility and Discipline. Boston; Addison Wesley, 2002.

BURGHARDT, M. Projektmanagement: Le4faden für die Planung, Uberwachung and Steuerung von Entwicklungsprojekten. Berlin und München: Siemens Aktiengesellschaft, 2000.

FIGUETREDO, A.M. Gerenciamento de Projetos Ágeis. Golden Cross, 2007.

HIGHSMITH, J. Agile Project Management: Creating Innovative Products. Boston: Addison Wesley, 2004.

KERZNER, H. Project Management: A system approach to planning scheduling and controlling. John Wiley & Sons, 2002.

LEITAO, Rogério S. Escritório de Projetos: Definindo uma estratégia para projetos de TI, 2006.

LESSA, L. O Papel do PMO nas Estruturas Organizacionais. Belo Horizonte: PMI Chapter MG, 2006. Disponível em: <http://www.pmimg.org.br/Geral/visualizador Conteudo.aspx?cod_areaconteudo=423>. Acesso em: 14 fev. 2015.

PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body Of Knowledge - PMBOK Guide. 3 ed. Pennsylvania: 2004.

VARGAS, Ricardo. Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos. 6 ed. Rio de Janeiro: BRASPORT, 2005.

PERBIRA, P et al. Entendendo Scrum para Gerenciar Projetos de Forma Ágil. Curitiba: Revista Mundo PM, 2007.

STANDISH GROUP INTEMACIONAL. Latest Standish Group chaos report shows project success rates have improved by 50%, 2003. Disponível em: < http://www.businesswire.com/news/home/20030325005636/en/Latest-Standish-Group-CHAOS-Report-Shows-Project>. Acessado em: 28 nov. 2016.