Mtodos geis de Desenvolvimento de Software

De que trata o artigo: Neste artigo so apresentados o histrico, o conceito, os valores e os princpios que norteiam os Mtodos geis, assim como so descritos os mtodos mais frequentemente utilizados pelas organizaes. Tambm so exploradas as suas limitaes, as indicaes de aplicao e os resultados obtidos por empresas que j os adotaram. Por fim, so discutidos os fatores crticos de sucesso de projetos de desenvolvimento de software conduzidos com o uso desses mtodos. Para que serve: Apresentar uma viso abrangente sobre o cenrio atual envolvendo metodologias geis. Em que situao o tema til: Conhecer metodologias geis cada vez mais importante na medida em que lidamos cada vez mais com projetos de caractersticas diferenciadas que exigem, muitas vezes, abordagens no tradicionais de desenvolvimento. Como uma resposta s crescentes presses por inovao em prazos cada vez mais reduzidos, s necessidades de constantes mudanas de requisitos e ao mau desempenho de grande parte dos projetos de desenvolvimento de software, houve um movimento na comunidade de desenvolvimento de software que deu origem aos Mtodos geis. Posteriormente, o conceito-base deste movimento evoluiu, de uma abordagem tcnica para o mbito gerencial, criando um novo enfoque de gerenciamento de projetos o Gerenciamento gil de Projetos. Neste artigo so apresentados o histrico, o conceito, os valores e os princpios que norteiam os Mtodos geis, assim como so descritos os mtodos mais frequentemente utilizados pelas organizaes. Tambm so exploradas as suas limitaes, as indicaes de aplicao e os resultados obtidos por empresas que j os adotaram. Por fim, so discutidos os fatores crticos de sucesso de projetos de desenvolvimento de software conduzidos com o uso desses mtodos. Definio e Origem dos Mtodos geis de Desenvolvimento de Software Os Mtodos geis de Desenvolvimento de Software surgiram como uma reao aos mtodos clssicos de desenvolvimento[1] e do reconhecimento da necessidade premente de se criar uma alternativa a estes processos pesados, caracterizados pelo foco excessivo na criao de uma documentao completa (BECK, et al, 2001). Em meados dos anos 90, integrantes da comunidade de desenvolvimento de software comearam a questionar estes processos, julgando-os pouco efetivos e, muitas vezes, impossveis de serem colocados em prtica (HIGHSMITH, 2002). Sintetizando o pensamento deste grupo, Highsmith (Ibid.) menciona que a indstria e a tecnologia sofrem modificaes to aceleradas que acabam por atropelar os mtodos clssicos. Highsmith et al (2002) ainda acrescentam que os clientes, na maioria das vezes, so incapazes de definir de forma clara e precisa, os requisitos do software, logo no incio de um projeto de desenvolvimento, o que inviabiliza a adoo dos mtodos clssicos em muitos projetos. Como resposta a esta situao, muitos especialistas criaram mtodos prprios para se adaptar s constantes mudanas exigidas pelo mercado e s indefinies iniciais dos projetos. O agrupamento desses mtodos deu origem famlia dos Mtodos geis de Desenvolvimento de Software. Sendo assim,

[...] os Mtodos geis podem ser considerados uma coletnea de diferentes tcnicas e mtodos, que compartilham os mesmos valores e princpios bsicos, alguns dos quais remontam de tcnicas introduzidas em meados dos anos 70, como os desenvolvimentos e melhorias iterativos (COHEN et al, 2003, p.2). De fato, Cockburn e Highsmith (2001a) j haviam afirmado que a maioria das prticas propostas pelos Mtodos geis no tem nada de novo e que a diferena recai principalmente sobre o foco e os valores que os sustentam. Segundo Cohen et al (2003), um dos primeiros questionamentos aos mtodos clssicos de desenvolvimento de software foi feito por Schwaber, criador do Scrum. Para entender melhor os mtodos clssicos de desenvolvimento de software baseados no SW-CMM, Schwaber (2002) elaborou um estudo junto aos cientistas da DuPont, que tinha por objetivo responder a seguinte pergunta: Por que os processos definidos e defendidos pelo SW-CMM no promovem entregas consistentes? Aps analisarem seus processos de desenvolviment o de software, os cientistas chegaram concluso que, apesar do SW-CMM buscar a consistncia, a previsibilidade e a confiabilidade dos processos de desenvolvimento de software, muitos destes processos ainda eram, de fato, imprevisveis e impossveis de serem repetidos. A explicao para tal recaa na complexidade dos processos propostos pelo SW-CMM, na conseqente dificuldade de aplicao e tambm na necessidade de mudanas constantes e difceis de serem antecipadas. Schwaber (op. cit.) percebe que para que o desenvolvimento de software seja realmente gil, deve-se aceitar as mudanas, ao invs de dar foco extremo previsibilidade. Quase que simultaneamente, outros especialistas no assunto chegam concluso de que mtodos que respondam s mudanas, to rapidamente quanto estas venham a surgir e que incentivem a criatividade, so a nica maneira de enfrentar e gerenciar os problemas do desenvolvimento de software em ambientes complexos (COCKBURN; HIGHSMITH, 2001a, SCHWABER, 2002). Neste mesmo perodo, modelos de processos aplicados a outras indstrias, comeam a ser analisados para servir como fonte de inspirao ao aprimoramento do processo de desenvolvimento de software (POPPENDIECK, 2001). O Modelo Toyota de Produo[2] foi alvo de ateno especial: enquanto as unidades fabris americanas trabalhavam a 100% de sua capacidade e mantinham grandes volumes de inventrio de matrias-primas e de produtos acabados, a fbrica da Toyota mantinha o nvel de estoque suficiente para um dia de operao e produzia somente o necessrio para atender aos pedidos j colocados. Este modelo traduzido no princpio da Lean Manufacturing, visava utilizao mais eficiente dos recursos e a reduo de qualquer tipo de desperdcio e estava totalmente alinhado filosofia da Administrao da Qualidade Total[3], criada pelo Dr. Edwards Deming (POPPENDIECK, 2001; FERREIRA et al, 2002). Deming (1990) acreditava que as pessoas desejavam fazer um bom trabalho e que os gerentes deveriam permitir que os trabalhadores do cho de fbrica tivessem autonomia para a tomada de decises e a resoluo de problemas. Alm disso, estimulava o estabelecimento de uma relao de confiana com os fornecedores e defendia uma cultura de melhoria contnua dos processos e dos produtos. Enquanto as unidades fabris japonesas geravam produtos cada vez melhores e mais baratos, as fbricas americanas no conseguiam fazer o mesmo. Com base nesta avaliao, Poppendieck (2001) listou 10 prticas que tornavam a Lean Manufacturing to bem-sucedida e que, em seu entendimento, poderiam ser adaptadas e aplicadas ao desenvolvimento de software: 1. Eliminao de gastos eliminar ou reduzir diagramas e modelos que no agregam valor ao produto final; 2. Minimizao de inventrio minimizar artefatos intermedirios, como documentos de requisitos e de desenho;

3. Maximizao do fluxo utilizar o desenvolvimento iterativo para reduo do prazo de entrega do software; 4. Atendimento demanda atender s mudanas de requisitos; 5. Autonomia aos trabalhadores compartilhar a documentao e dizer aos programadores o que precisa ser feito e no como deve ser feito; 6. Atendimento aos requisitos dos clientes trabalhar perto dos clientes, permitindo que eles mudem suas opinies ou seus desejos; 7. Fazer certo da primeira vez testar o quanto antes e refazer o cdigo se necessrio; 8. Abolio da otimizao local gerenciar o escopo de forma flexvel; 9. Desenvolvimento de parceria com os fornecedores evitar relaes conflitantes, tendo em mente que todos devem trabalhar juntos para gerar o melhor software; 10. Cultura de melhoria contnua permitir que o processo seja melhorado, que se aprenda com os erros e se alcance o sucesso. Highsmith (2002) afirma, que de forma independente, Kent Beck e Ron Jeffreis percebem a importncia dos princpios defendidos por Poppendieck (2001) durante um projeto de desenvolvimento de software na Chrysler e criam o projeto Extreme Programming (XP), um dos Mtodos geis de maior expresso atualmente. Simultaneamente, outras histrias comeam a ecoar pelo mundo, como a vivenciada por Alistair Cockburn, que entrevistando profissionais do IBM Consulting Group, percebe que equipes de projetos bem-sucedidos se desculpavam por no ter seguido os processos formais, por no utilizar as ferramentas de alta tecnologia e por ter simplesmente trabalhado de forma prxima e integrada, enquanto membros de projetos malsucedidos afirmavam ter seguido as regras e processos e que no entendiam o que havia dado errado. Com base nesta experincia, Cockburn desenvolveu o Crystal Method, outro Mtodo gil (HIGHSMITH, 2002). Face ao exposto, percebe-se que o mundo do desenvolvimento de software passa por uma importante transformao: os mtodos clssicos so vistos como no adequados a todas as situaes e os especialistas reconhecem a necessidade de criao de novas prticas, orientadas a pessoas e flexveis o suficiente para fazer frente a um ambiente de negcio dinmico (COCKBURN; HIGHSMITH, 2001a). Os principais desafios enfrentados e que devem ser endereados pelos novos mtodos de desenvolvimento de software so assim sumarizados por Cockburn e Highsmith (Ibid.): 1. A satisfao dos clientes passar a ter precedncia frente conformidade aos planos; 2. As mudanas sempre ocorrem o foco deixa de ser como evit-las e passa a ser como abra-las e como minimizar o seu custo ao longo do processo de desenvolvimento; 3. A eliminao das mudanas pode significar menosprezar condies importantes do negcio, ou seja, pode levar ao insucesso de uma organizao; 4. O mercado espera um software inovador, com alta qualidade, que atenda aos requisitos do negcio e que esteja disponvel em prazos cada vez menores. Manifesto para o Desenvolvimento gil de Software No incio de 2001, criadores e representantes dos chamados Mtodos geis de Desenvolvimento de Software Extreme Programming, Scrum, Dynamic Systems Development Method, Adaptative Software Development, Crystal Methods, FeatureDriven Development, Lean Development, entre outros se reuniram nos Estados Unidos para discutir alternativas aos tradicionais processos pesados de desenvolvimento de software (BECK et al, 2001). Estes especialistas foram enfticos em dizer que no eram contra mtodos, processos ou metodologias, sendo que muitos at mencionaram o desejo de resgatar o verdadeiro significado e

a credibilidade destas palavras. Defendiam a modelagem e a documentao, mas no em excesso. Planejavam, mas reconheciam os limites do planejamento e da previsibilidade num ambiente turbulento (BECK et al, 2001). A essncia deste movimento a definio de novo enfoque de desenvolvimento de software, calcado na agilidade, na flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos produtos e servios de valor ao mercado, em curtos perodos de tempo (HIGHSMITH, 2004, p. xix). Como agilidade deve-se entender a habilidade de criar e responder a mudanas, buscando a obteno de lucro, em um ambiente de negcio turbulento (HIGHSMITH, 2004, p. 16); ou ainda, a capacidade de balancear flexibilidade e estabilidade (Id., 2002). A agilidade no deve ser vista como falta de estrutura, mas est diretamente relacionada capacidade de adaptao a situaes diversas e inesperadas. Highsmith (2004, p. 16) enfatiza que a ausncia de estrutura ou de estabilidade pode levar ao caos, mas que estrutura em demasia gera rigidez. Como resultado do encontro, foi criada a Agile Alliance[4], sendo publicado o Manifesto para Desenvolvimento gil de Software ou o Manifesto for Agile Software Development (BECK et al, 2001), cujo contedo[5] apresentado abaixo: Ns estamos descobrindo melhores maneiras para desenvolver software, praticando e auxiliando os outros a faz-lo. Atravs deste trabalho ns valorizamos: - Os indivduos e suas interaes acima de processos e ferramentas; - Software em produo acima da documentao exaustiva; - Colaborao do cliente acima da negociao de contratos; - Respostas s mudanas acima da execuo de um plano. Ou seja, embora haja valor nos itens direita, ns valorizamos mais os itens esquerda. Segundo Cohen et al (2003, p. 6), este Manifesto tornou-se a pea-chave do movimento pelo desenvolvimento gil de software, uma vez que rene os principais valores dos Mtodos geis, que os distingue dos mtodos clssicos de desenvolvimento. Alm do Manifesto, foram definidos os princpios que regem a maioria das prticas dos chamados Mtodos geis de Desenvolvimento de Software (AGILE ALLIANCE, 2005). Estes princpios so apresentados na Tabela 1 abaixo, de acordo com a ordem originalmente proposta. Princpios 1. Nossa maior prioridade satisfazer o cliente atravs da entrega rpida e contnua de um software de valor 2. Pessoas de negcio e programadores devem trabalhar juntos, diariamente, ao longo de todo o projeto 3. Aceite as mudanas de requisitos, mesmo que numa etapa avanada do desenvolvimento 4. Entregue novas verses do software frequentemente 5. O software em funcionamento a medida primria de progresso do projeto 6. Construa projetos com pessoas motivadas. Oferea a elas o ambiente e todo o apoio necessrios e acredite em sua capacidade de realizao do trabalho 7. As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas 8. O mtodo mais eficiente e efetivo de distribuir a informao para e entre uma equipe de desenvolvimento a comunicao face a face 9. Processos geis promovem desenvolvimento sustentado

Princpios 10. A ateno contnua na excelncia tcnica e num bom projeto aprimora a agilidade 11. Simplicidade essencial 12. Equipes de projeto avaliam seu desempenho em intervalos regulares e ajustam seu comportamento de acordo com os resultados Tabela 1. Princpios dos mtodos geis de desenvolvimento de software (FONTE: AGILE ALLIANCE, 2005.) Pode-se dizer, ento, que os Mtodos geis se caracterizam por serem incrementais, cooperativos, diretos e adaptativos. Incrementais, dadas as pequenas verses e ciclos rpidos de desenvolvimento; cooperativos, por estimular a proximidade com o cliente e a interao entre os programadores; diretos, pela simplicidade de aprendizado e de documentao; e, finalmente, adaptativos, pela habilidade de acomodar mudanas ao longo do projeto (ABRAHAMSSON et al, 2003; FOWLER, 2003). Como principais diferenas entre os Mtodos geis e os clssicos de desenvolvimento de software podem ser citadas (FOWLER, 2003; CHIN, 2004): Os Mtodos geis so adaptativos e no preditivos: diferentemente dos enfoques clssicos que defendem o planejamento integral do escopo no incio do projeto e um controle rgido de mudanas, os planos dos Mtodos geis so elaborados e adaptados ao longo do projeto, permitindo e, algumas vezes estimulado, a incorporao das mudanas requeridas pelo cliente; Os Mtodos geis so orientados a pessoas e no a processos: os processos clssicos tm desenvolvimento de software tm, em geral, a pretenso de funcionar independentemente de quem os executa. J os Mtodos geis levam em considerao os indivduos, sendo elaborados para auxili-las. Um ponto interessante a salientar que enquanto alguns defensores radicais dos Mtodos geis so categricos em criticar e apontar as falhas dos mtodos clssicos de desenvolvimento de software, outros especialistas, representantes tanto dos mtodos clssicos quanto dos geis, tm uma postura mais amena, enxergando at mesmo uma possibilidade de integrao entre as duas abordagens (GLASS, 2001; COHEN et al, 2003; PAULK, 2002; GLAZER, 2001; HIGHSMITH, 2004). Glass (2001) apresenta uma anlise do Manifesto para o Desenvolvimento gil de Software e menciona que, apesar de concordar com os pontos defendidos pelos praticantes dos Mtodos geis, no se deve desprezar os modelos clssicos e que ambos os lados tm pontos importantes a serem considerados e balanceados. Paulk (2002) defende que os princpios dos Mtodos geis devem ser seguidos por todos os profissionais que desenvolvem software, mas lembra que formalismo e disciplina devem ser levados em conta, especialmente quando o software a ser desenvolvido envolve severos requisitos de confiabilidade. Paulk (Id., 2001) analisa o Mtodo gil Extreme Programming (XP) sob a tica do SW-CMM, apontando como este poderia auxiliar as organizaes a alcanar os objetivos propostos pelo SWCMM. Principais Mtodos geis de Desenvolvimento de Software Dentre os principais Mtodos geis de Desenvolvimento de Software podem ser citados: Extreme Programming, Scrum, Dynamic Systems Development Method, Adaptative Software Development, Crystal Method, Feature-Driven Development e Lean Development (COHEN et al, 2003; UDO; KOPPENSTEINER, 2003). A seguir feita uma breve explanao sobre as suas principais caractersticas.

Extreme Programming (XP) De acordo com Cohen et al (2003, p.12) o Extreme Programming (XP) , indubitavelmente, o Mtodo gil de maior expresso, criado nos ltimos anos. Por se tratar do Mtodo gil mais difundido abordado com mais de detalhe neste artigo. O XP um Mtodo gil para pequenas e mdias equipes desenvolverem software, em ambientes com requisitos instveis. Criado em 1998 por Kent Beck, Ron Jeffries e Ward Cuninghan, a partir de um projeto piloto na Chrysler (BECK et al, 1998), o XP vem ganhando cada vez mais adeptos, ampliando sua participao no mercado (HIGHSMITH, 2002). Beck (2000, p.xv) explica que o termo Extreme (extremo) utilizado, dado que o XP rene um conjunto de prticas de desenvolvimento j existentes e reconhecidas como boas prticas no desenvolvimento de software, mas as leva ao extremo, ao limite. Juric (2002) comenta que o XP uma maneira eficiente, de baixo risco, cientfica e divertida de desenvolver software. A premissa bsica do XP que, ao contrrio do que se pensava h 30 anos, o custo de mudana de um software no aumenta exponencialmente com o avanar do projeto (BECK, 2004, p. 21-23). As novas tcnicas desenvolvidas pelos especialistas em software, como os bancos de dados relacionais e a programao modular, entre outras, permitiram uma reduo no custo da mudana (ver Figura 1). Desta forma, no se faz mais necessrio evitar mudanas durante o desenvolvimento, sendo possvel abandonar o Modelo em Cascata e usar o XP.

Figura 1. Custo da mudana do software (FONTE: BECK, 2004, p. 21-23) O XP baseia-se em 12 prticas ou regras concisas e diretas, listadas abaixo (BECK, Ibid.; COHEN et al, 2003, p.12, BECK; FOWLER, 2001, p. 72): 1. Jogo do planejamento: no incio de cada interao, clientes, gerentes e programadores se encontram para definir, estimar e priorizar os requerimentos. A ideia que se elabore um plano aproximado no incio no projeto e se faa um refinamento medida que as necessidades e requisitos se tornem mais conhecidos; 2. Programao em pares: dois programadores utilizando o mesmo equipamento escrevem o cdigo; 3. Pequenas verses: as verses devem ser to pequenas quanto possvel e trazerem valor para o negcio. Uma verso inicial do software deve ser colocada em produo aps um pequeno nmero de iteraes e, em seguida, outras verses devem ser disponibilizadas to logo faa sentido; 4. Metforas: clientes, gerentes e programadores criam metforas ou conjunto de metforas para modelagem do sistema; 5. Projeto simples: os programadores so estimulados a desenvolver o cdigo do software o mais simples possvel;

6. Testes: os programadores devem criar os testes de unidade antes ou mesmo durante o desenvolvimento do cdigo do sistema. Os clientes, por sua vez, escrevem os testes de aceitao. Ao final de cada iterao a bateria de testes deve ser conduzida; 7. Refatorao: tcnica que permite a melhoria de cdigo sem a mudana de funcionalidade (BRASIL, 2001b, p. 186), deve ser executada pela equipe do projeto, o tempo todo; 8. Integrao contnua: os programadores devem integrar os novos cdigos ao software to rapidamente e com a maior frequncia possvel; 9. Propriedade coletiva do cdigo: o cdigo do programa deve ser propriedade de toda a equipe e qualquer integrante pode fazer alteraes sempre que for necessrio; 10. Cliente no local: o cliente deve trabalhar com a equipe de projeto a todo o momento, respondendo perguntas, realizando testes de aceitao e assegurando que o desenvolvimento do software esteja sendo feito a contento; 11. Semana de 40 horas: como trabalhar por longos perodos reduz o desempenho, o contedo de cada iterao deve ser planejado de forma a no haver necessidade de realizao de horas extras, fazendo com que os programadores estejam renovados e ansiosos a cada manh e cansados e satisfeitos noite; 12. Padro de codificao: no incio do projeto deve ser criado um padro de codificao, simples e aceito por toda a equipe, que dever ser seguido de forma a no permitir a identificao de quem desenvolveu determinada parte do cdigo e a auxiliar a conduo do trabalho. Especialistas concordam que o XP no decorrncia da aplicao destas prticas isoladamente, mas sim do resultado de sua combinao (COHEN et al, 2003, p.13). HIGHSMITH (2002) ainda ressalta que cinco princpios constituem a base do XP: comunicao, simplicidade, feedback, coragem e qualidade de trabalho. Cohen et al (2003, p.13) apresentam um resumo de caractersticas principais que norteiam a aplicao do Extreme Programming, retratado na Tabela 2. Caracterstica Tamanho da Equipe Durao das iteraes Equipes distribudas Valores sugeridos Equipes formadas por 2 a 10 integrantes Durao usual de duas semanas por iterao Dada que a equipe deve trabalhar preferencialmente no mesmo local fsico, o XP no indicado para equipes distribudas Pode ser utilizado no desenvolvimento de software de baixa, mdia ou alta criticidade

Aplicaes de alta criticidade

Tabela 2. Caractersticas principais para utilizao do XP (FONTE: COHEN et al, 2003, p.13.) Scrum Criado por Ken Schwaber e Jeff Sutherland em 1996, como um mtodo que aceita que o desenvolvimento de software imprevisvel e formaliza a abstrao, o Scrum aplicvel a ambientes volteis (SCHWABER, 2002). uma abordagem emprica baseada na flexibilidade, adaptabilidade e produtividade, em que a escolha das tcnicas de desenvolvimento fica a cargo dos programadores. Segundo Udo e Koppensteiner (2003), o Scrum se destaca dos demais Mtodos geis pela maior nfase dada ao gerenciamento do projeto. H atividades especficas de monitoramento e feedback, em geral, reunies rpidas e dirias com toda a equipe, visando identificao e correo de quaisquer deficincias e/ou impedimentos no processo de desenvolvimento (SCHWABER; BEEDLE, 2001). Schwaber (2002) sumariza assim os princpios-chave do Scrum:

Equipes pequenas de trabalho, buscando a maximizao da comunicao e da troca de conhecimento tcito e informal e minimizao de overhead; Adaptao s solicitaes de mudanas tcnicas ou do cliente / usurio, assegurando a entrega do melhor software possvel; Entregas frequentes de verses que podem ser testadas, ajustadas, executadas, documentadas e liberadas para produo; Diviso do trabalho e das responsabilidades da equipe de projeto em pequenas entregas; Habilidade em entregar um software pronto quando da necessidade do cliente ou do negcio.

As caractersticas principais que norteiam a aplicao do Scrum so apresentadas na Tabela 3 (COHEN et al, 2003, p.15). Caracterstica Tamanho da Equipe Durao das iteraes Equipes distribudas Valores sugeridos O trabalho dividido em equipes de at sete pessoas Durao usual de quatro semanas por iterao Como o projeto pode ser constitudo por vrias pequenas equipes, h a possibilidade de que estas estejam distribudas (descentralizadas) No h meno especfica quanto aplicabilidade do mtodo para desenvolvimento de software de alta criticidade

Aplicaes de alta criticidade

Tabela 3. Caractersticas principais para utilizao do Scrum (FONTE: COHEN et al, 2003, p.16-17.) Crystal Methods Criado por Alistair Cockburn no incio dos anos 90, a partir da crena de que os principais obstculos enfrentados no desenvolvimento de produtos recaam sobre os problemas de comunicao, os Crystal Methods do grande nfase s pessoas, comunicao, s interaes, s habilidades e aos talentos individuais, deixando os processos em segundo plano (UDO; KOPPENSTEINER, 2003; COCKBURN, 2004, COHEN et al, 2003). Correspondem a uma famlia de mtodos organizados por cores, de acordo com o nmero de pessoas envolvidas (tamanho do projeto x necessidade de comunicao), com as prioridades do negcio e com a complexidade e a criticidade do software a ser desenvolvido, conforme mostra a Figura 2. Apesar da estrutura proposta servir como um guia dos processos mais adequados a uma determinada situao, nos Crystal Methods, a definio final dos processos a serem utilizados responsabilidade da equipe de projeto. Mas duas regras principais so sempre seguidas: ciclos de desenvolvimento incrementais com durao de no mximo quatro meses e reunies de reflexo que estimulam a colaborao entre integrantes da equipe de projeto (UDO; KOPPENSTEINER, 2003; COCKBURN, 2004; COHEN et al, 2003).

Figura 2. Esquema dos Crystal Methods (FONTE: COHEN et al, 2003, p. 16) Cohen et al (2003, p.15) apontam as caractersticas principais de projetos que utilizam os Crystal Methods (Tabela 4). Caracterstica Tamanho da Equipe Valores sugeridos A famlia dos Crystal Methods acomoda equipes de qualquer tamanho, preferencialmente compostas por pessoas talentosas At 4 meses para projetos grandes e altamente crticos Os Crystal Methods foram concebidos para atender ao conceito de equipes distribudas Os Crystal Methods atendem a projetos crticos, incluindo aqueles que envolvem risco de vida e de valores monetrios

Durao das iteraes Equipes distribudas Aplicaes de alta criticidade

Tabela 4. Caractersticas principais para utilizao dos Crystal Methods (FONTE: COHEN et al, 2003, p.15.) Dynamic Systems Development Method (DSDM) Originrio da Inglaterra, em meados dos anos 90, o Dynamic Systems Development Method controlado por um consrcio de empresas. Criado a partir do RAD Rapid Application Development, o DSDM o nico mtodo gil compatvel com a ISO 9000. Seu ciclo de vida divido nos seguintes estgios: a) Pr-projeto; b) Anlise de Aderncia; c) Estudo de Negcio; d) Modelagem Funcional; e) Projeto e Desenvolvimento; f) Implementao, e, g) Ps-implementao. A ideia central do DSDM que se deve primeiramente fixar o prazo e os recursos para, em seguida, definir e ajustar o nmero de funcionalidades a serem desenvolvidas (COHEN et al, 2003; UDO; KOPPENSTEINER, 2003). Dadas a sua natureza, o DSDM no enderea um tamanho de equipe especfico e no possui duraes pr-determinadas para suas iteraes (COHEN et al, op. cit.). No foram encontradas na literatura recomendaes especficas para utilizao no desenvolvimento de aplicaes de determinada criticidade ou para equipes centralizadas ou descentralizadas. Feature-Driven Development (FDD)

O Feature-Driven Development, criado por Peter Coad e Jeff DeLuca em 1999, um mtodo de desenvolvimento de software especfico para aplicaes crticas de negcio (PALMER; FELSING, 2001). Diferentemente de outros Mtodos geis, o FDD se baseia em processos bem definidos e que podem ser repetidos. Sua abordagem se concentra nas fases de projeto e construo, com maior nfase na modelagem, em um ciclo de vida iterativo e tambm em atividades de gerenciamento de projetos (UDO; KOPPENSTEINER, 2003). Os princpios-base do FDD so apontados abaixo (HIGHSMITH, 2002): Necessidade de se automatizar a gerao de software para projetos de grande escala; Um processo simples e bem definido fundamental; As etapas de um processo devem ser lgicas e bvias para cada integrante da equipe de desenvolvimento; Bons processos atuam na retaguarda, permitindo que a equipe se dedique ao alcance dos resultados; Ciclos de vida curtos e iterativos so mais indicados. Um projeto conduzido pelo mtodo FDD possui as seguintes etapas: a) Desenvolvimento de um modelo geral; b) Construo da lista de funcionalidades; c) Planejamento por funcionalidades; d) Projeto e desenvolvimento por funcionalidades. A Tabela 5 apresenta as principais caractersticas de um projeto desenvolvido pelo mtodo FDD (COHEN et al, 2003, p.18). Caracterstica Tamanho da Equipe Durao das iteraes Equipes distribudas Valores sugeridos Varivel de acordo com a complexidade das funcionalidades a serem desenvolvidas At 2 semanas O FDD foi criado para trabalhar com equipes mltiplas e, apesar de no haver indicao formal para equipes distribudas, passvel de adaptao Indicado para desenvolvimento de software crtico

Aplicaes de alta criticidade

Tabela 5. Caractersticas principais para utilizao do FDD (FONTE: COHEN et al, 2003, p.15.) Lean Development (LD) Com razes na indstria automotiva dos anos 80, em especial no Modelo Toyota de Produo, o Lean Development considerado o Mtodo gil com maior foco estratgico. Iniciado por Bob Charette, o LD tem como principais objetivos reduzir em um tero o prazo, o custo e o nvel de defeitos no desenvolvimento de software. Para tanto, requer um grande comprometimento da alta administrao e uma predisposio a mudanas radicais (COHEN et al, 2003; UDO; KOPPENSTEINER, 2003). HIGHSMITH (2002) aponta como princpios fundamentais do Lean Development: A satisfao do cliente a prioridade principal; Prover sempre o maior valor possvel para o dinheiro; O sucesso depende da participao ativa dos clientes; Todo projeto baseado no LD requer um esforo conjunto de toda a equipe; Tudo pode ser mudado; Domine, no aponte as solues; Complete, no desenvolva; Prefira uma soluo a 80% hoje, a uma soluo a 100% amanh; O minimalismo essencial; A necessidade determina a tecnologia;

O incremento do produto corresponde a um incremento de funcionalidade e no de tamanho; Nunca force o LD alm de seus limites.

Cohen et al (2003, p. 19) afirma que [...] como o Lean Development mais uma filosofia de gerenciamento que um processo de desenvolvimento, os itens referentes ao tamanho da equipe, durao das iteraes, ao tratamento de equipes centralizadas ou distribudas e criticidade da aplicao no so diretamente endereados pelo mtodo. Adaptative Software Development (ASD) Criado por Highsmith como uma evoluo do RAD Rapid Application Development em 1992, o Adaptative Software Development prope uma forma alternativa de se enxergar o desenvolvimento de software nas organizaes (HIGHSMITH, 2002). O ASD foi projetado para lidar com ambientes repletos de incertezas e complexos. Segundo Udo e Koppensteiner (2003), o mtodo estimula a aprendizagem durante o processo de desenvolvimento e a adaptao constante s novas realidades do negcio e do projeto. Alm disso, encoraja o desenvolvimento iterativo e incremental, com a liberao constante de novas verses. O ASD oferece estrutura e orientao suficiente para evitar que os projetos se tornem caticos, sem, entretanto, trazer uma rigidez indesejada que venha a suprimir a criatividade. Neste mtodo, o papel do gerente de projetos favorecer a colaborao entre a equipe de desenvolvimento e o cliente. De acordo com Highsmith (2002), o ASD indicado para equipes pequenas, mas pode ser adaptado para equipes maiores. Com relao aos demais atributos durao das iteraes, apoio a equipes distribudas e desenvolvimento de aplicaes de alta criticidade no foi encontrada uma indicao precisa na literatura. Resumo das Caractersticas Principais dos Mtodos geis Nos tpicos anteriores foram apresentadas as principais caractersticas de alguns dos chamados Mtodos geis de Desenvolvimento de Software. importante mencionar que estes mtodos foram selecionados por serem os mais citados na literatura. Como visto, apesar dos Mtodos geis terem uma essncia ou valores em comum, h algumas diferenas significativas entre eles. A Tabela 6 apresenta um resumo das principais caractersticas dos Mtodos geis analisados, com uma linha especfica destinada anlise da incorporao ou no de prticas relacionadas ao gerenciamento de projetos. Caracterstica Tamanho da Equipe Durao das iteraes Equipes distribudas XP 2-10 2 semanas No Scrum 1-7 4 semanas Adaptvel Adaptvel Muitas Crystal Methods Varivel <4 meses Sim Todos os tipos Poucas FDD Varivel <2 semanas Adaptvel Adaptvel Muitas Muitas ASD Varivel LD DSDM

No definido

Aplicaes de alta Adaptvel criticidade Prticas de Poucas gerenciamento de projetos

Tabela 6. Caractersticas principais dos mtodos geis selecionados (FONTE: Adaptado de COHEN et al, 2003, p. 23.) Aplicao dos Mtodos geis nas Organizaes H uma grande variedade de Mtodos geis de Desenvolvimento de Software, cada qual sugerindo prticas especficas, cuja adoo traz mudanas s rotinas das organizaes. De acordo com Nerur et al (2005, p.74), [...] as alteraes nos processos de desenvolvimento de software representam um fenmeno complexo de mudana organizacional que no pode ser alcanado pela mera substituio de ferramentas e tecnologias. Estas mudanas tm impacto significativo em vrios aspectos da organizao: na estrutura, na cultura e nas prticas gerenciais. Conhecer a amplitude deste fenmeno fator crtico para o planejamento e o gerenciamento destas mudanas. Sendo assim, antes de uma organizao adotar e implementar qualquer um dos Mtodos geis fundamental que avalie a dimenso do impacto e a sua prontido para tal (AMBLER, 2002c; COHEN et al, 2003; FOWLER, 2003; NERUR et al, 2005). Para facilitar o entendimento e retomar as principais caractersticas e diferenas entre os enfoques clssico e gil de desenvolvimento de software, traado paralelo entre eles na Tabela 7. Estas diferenas entre as abordagens sugerem que as organizaes devem repensar suas metas, seus objetivos e reconfigurar seus componentes humanos, gerencial e tecnolgico, de forma a alcanar uma implementao bem-sucedida dos mtodos geis (NERUR et al, 2005, p.75). Enfocando o componente gerencial, estas diferenas podem demandar at mesmo uma alterao no enfoque de gerenciamento de projetos utilizado para as iniciativas de desenvolvimento de software. Enfoque Clssico Premissa Fundamental O software totalmente especificvel e previsvel e pode ser construdo atravs de um planejamento meticuloso e extensivo Enfoque gil (Mtodos geis) Software adaptativo e de alta qualidade pode ser construdo por pequenas equipes, com o uso de princpios como a melhoria contnua do projeto e o desenvolvimento e testes baseados no rpido feedbacke na aceitao de mudanas Liderana e colaborao Equipes auto-organizadas, encorajando o intercmbio de papis Crtico

Estilo de Gerenciamento Distribuio de Papis Papel do Cliente

Comando e controle Individual, favorecendo a especializao Importante

Modelo de Modelo de ciclo de vida Mtodos geis Desenvolvimento Modelo em Cascata, Espiral e iterativos Tecnologia Sem restries Favorece a tecnologia orientada a objetos

Tabela 7. Comparao entre os enfoques clssico e gil de desenvolvimento de software (FONTE: ADAPTADO DE NERUR et al, 2005, p. 75.) Ambler (2002c) discute os fatores que influenciam a adoo bem-sucedida de Mtodos geis, enfatizando que o ponto mais importante para que isto acontea a existncia de uma compatibilidade entre os conceitos e valores da organizao e

dos Mtodos geis, ou seja, o autor discute claramente a questo da cultura da organizao. Na mesma linha, Nerur et al (2005) destacam que os valores, as normas e os padres estabelecidos e reforados pelas organizaes ao longo do tempo se refletem nas polticas e nas rotinas da empresa e exercem considervel influncia nos processos de tomada de deciso, nas estratgias de soluo de problemas, nas prticas voltadas inovao, nos filtros de informao, nos relacionamentos interpessoais e nas negociaes. Como a cultura e a forma de pensar das pessoas no so facilmente modificveis, pode-se dizer que a adoo de Mtodos geis seja indicada apenas a algumas organizaes (AMBLER, 2002; NERUR et al, 2005). Um segundo fator importante a ser considerado quando da deciso pela implementao de Mtodos geis, de acordo com Ambler (op. cit.) o projeto e as caractersticas do negcio. Questes como Os trabalhos tm sido conduzidos de forma incremental? Qual a motivao da equipe de projeto? Qual o nvel de apoio que a equipe de desenvolvimento pode esperar? Os recursos adequados esto disponveis? Quo volteis so os requisitos do projeto? so fundamentais para esta avaliao. Com relao ao ltimo ponto, Bohem (2002) chega a sugerir que os mtodos clssicos deveriam ser preferidos quando o ndice de alterao de requisitos do projeto for inferior a 1% ao ms. Um terceiro aspecto destacado por Ambler (op. cit.) a necessidade de definio de um champion, ou seja, de um profissional que assuma os desafios do projeto, de forma que a equipe de desenvolvimento possa trabalhar com tranquilidade. Ampliando esta anlise, uma vez que os Mtodos geis valorizam e depositam elevado grau de confiana no conhecimento tcito e na capacidade de tomada de decises de cada indivduo, Bohem ( op. cit.) enfatiza a importncia de se ter tambm uma equipe de projeto bem treinada e composta por especialistas. Com relao a este aspecto, apesar de concordar com a necessidade de formao de uma equipe especializada, Nerur et al (2005) chama a ateno para que no se crie uma cultura de elitismo dentro do grupo de desenvolvimento, que pode afetar o moral e o comprometimento de outros profissionais da empresa, no integrantes da equipe. inegvel tambm que os Mtodos geis trazem consigo uma mudana radical na relao cliente fornecedor. Cockburn e Higsmith (2001a), Bohem (2002) e Nerur et al (2005) apontam o envolvimento e a participao dos clientes como fatores imprescindveis para o sucesso da implementao dos mtodos geis. Os clientes devem estar totalmente comprometidos com o projeto, trabalhar com esprito de colaborao, possuir o conhecimento necessrio, ter autonomia para a tomada de decises, alm de estar disponveis para sanar as dvidas quando necessrio. Entretanto, por se tratar de um item extremamente crtico no processo e que demanda tempo, pacincia e esforo considerveis para o estabelecimento de um ambiente de respeito e confiana mtua entre clientes e fornecedores, mencionado por alguns autores, entre eles Nerur et al (Ibid.), como um dos obstculos utilizao dos Mtodos geis. Compartilhando os pontos discutidos nos pargrafos anteriores, Cohn e Ford (2003, p. 74) acrescentam que transio de um processo clssico com nfase no planejamento execuo controle, para um processo gil, afeta no apenas a equipe de desenvolvimento de software, mas tambm outras equipes, departamentos, assim como o corpo gerencial da organizao. Tomando por base a experincia emprica de implementaes de Mtodos geis em vrias organizaes, abrangendo tanto projetos simples como projetos complexos, equipes centralizadas ou distribudas, os autores sugerem uma abordagem diferenciada junto aos principais envolvidos nos processos programadores, alta gerncia e a rea de Recursos Humanos para que se garanta uma implementao bem-sucedida deste novo enfoque de desenvolvimento de software. Segundo Cohn e Ford (2003, p. 74 - 75), usualmente os programadores respondem implementao de Mtodos geis com um misto de ceticismo, entusiasmo, otimismo, ou mesmo, resistncia. Como este novo enfoque, o desenvolvimento de

software normalmente prioriza a entrega do cdigo gerao de uma documentao extensiva, a adaptao ao planejamento completo e, as pessoas e suas interaes aos processos e ferramentas (BECK et al, 2001). Cohn e Ford (op. cit.) afirmam que h sentimentos controversos entre os integrantes da equipe durante o processo de transio: alguns se sentem perdidos ou sem um direcionamento, pela ausncia de um cronograma formal ou de uma documentao completa de requisitos; outros empolgados, pelo reconhecimento de sua capacidade e pela autonomia concedida; alguns creem erroneamente que a adoo dos Mtodos geis tem o intuito de estimular a microgerncia, dados os encontros e as reunies constantes entre gerentes e equipe, em mtodos como o Scrum e XP. Em face desta situao, Cohn e Ford (2003, p. 75), assim como Ambler (2002c), defendem uma passagem gradual dos processos clssicos de desenvolvimento para os Mtodos geis, tornando o perodo de transio mais tranquilo. A idia de uma equipe formada por talentos, citada por Boehm (2002) ratificada por Cohn e Ford (2003, p. 75) e por Ambler (2002c), que explicam ainda que diferenas grandes de produtividade numa equipe podem trazer impactos negativos ao projeto, uma vez que num Mtodo gil, a equipe se dedica apenas s atividades essenciais para a entrega do software. No se deve esquecer, contudo, que uma pequena queda de produtividade esperada durante a transio, at que toda a equipe esteja ambientada com a nova dinmica de trabalho. Fowler (2003) destaca que a equipe tcnica no pode ser responsvel por todo o trabalho por si s, sendo fundamental o papel dos gerentes, fornecendo o direcionamento, auxiliando a definio das prioridades de negcio, removendo obstculos e negociando os prazos de entrega. Com esta colocao, Fowler (Ibid.) enfatiza a importncia do gerenciamento de projetos mesmo no desenvolvimento de software conduzido com o uso de Mtodos geis. Ao considerar a questo de equipes distribudas, Cohn e Ford (op. cit.) so enfticos em dizer que, mesmo havendo a necessidade de se organizar um projeto de forma descentralizada, deve-se fazer o possvel para que nas primeiras semanas de trabalho, a maior parte da equipe esteja reunida e somente aps este perodo as equipes sejam distribudas. Os autores justificam este ponto ao afirmar que equipes que trabalham segundo os Mtodos geis necessitam tomar decises de forma mais rpida que nos processos tradicionais, mas para tanto, recorrem a uma comunicao mais frequente e normalmente informal. Sem esta proximidade inicial, a comunicao pode ser comprometida. Analisando outro grupo de interessados, Cohn e Ford (2003, p.76) apontam que normalmente a alta gerncia representa um desafio singular adoo dos Mtodos geis. Basicamente as suas preocupaes recaem sobre quatro pontos fundamentais, extremamente vinculados viso do Gerenciamento Clssico de Projetos: 1. Como possvel prometer novas funcionalidades aos clientes? 2. Como mensurar o progresso do projeto? 3. Quando o projeto acaba? 4. Como a utilizao de um Mtodo gil afetar outros grupos? Apesar de pertinentes, a origem destes questionamentos est na dificuldade que muitos gerentes tm em abrir mo do processo clssico de planejamento e controle, da solicitao de compromissos formais de entrega, mesmo sabendo que raramente estes objetivos so cumpridos pelas equipes de desenvolvimento[6]. Cohn e Ford (2003, p.76) e Highsmith (2004) salientam que gerentes que temem que com os Mtodos geis no seja possvel a fixao de datas de entrega de produtos a clientes, deveriam lembrar que, no passado, os planos formais provedores de garantias de p razo, custo e qualidade estavam usualmente errados, superestimados, ou ambos. Em organizaes com histrico de estimativas incorretas de projetos, convencer a alta gerncia sobre os benefcios dos Mtodos geis pode no ser algo difcil, bastando uma avaliao dos resultados passados frente aos objetivos iniciais de prazo, custo e qualidade e a apresentao

dos benefcios potenciais da nova abordagem. J nos casos em que a equipe de desenvolvimento entrega seus projetos sistematicamente no prazo e no custo, a utilizao dos Mtodos geis pode ser justificada com vistas reduo de prazos de entrega, reduo das equipes de trabalho, o que significaria um ganho para a organizao. Apesar dos Mtodos geis proporem uma mudana do paradigma de comando e controle para liderana e colaborao, conforme explica Nerur et al (2005, p.75), isto no significa que sejam alheios necessidade de mensurao do progresso dos projetos. Segundo Cohn e Ford (2003, p.77), os Mtodos geis podem oferecer um acompanhamento adequado do projeto, por meio da utilizao de relatrios especficos a cada iterao, que contm datas-chave, comparao de resultados reais versus planejados, mtricas principais e at mesmo a identificao dos riscos do projeto. Estas so prticas do gerenciamento de projetos, mas que neste caso, so aplicadas a cada interao e no ao projeto como um todo. Outra preocupao bastante comum alta gerncia, refletida na terceira questo, que aparentemente um projeto realizado segundo um Mtodo gil tende a no ter fim, uma vez que as iteraes podem continuar enquanto houver itens prioritrios, definidos pelo cliente, a serem desenvolvidos. Cohn e Ford (2003, p.77) apontam como soluo para esta questo, a definio de um intervalo de prazo e custo, vinculado a um escopo macro, que servem como uma estimativa preliminar do projeto, a ser considerada durante a execuo do projeto. A equipe deve buscar entregar uma verso bsica e funcional do software, no prazo mnimo deste intervalo e, a partir da, so negociadas entregas complementares (outras iteraes). Desta forma, Cohn e Ford (2003, p. 77), afirmam que possvel minimizar o desconforto quanto finalizao do projeto. Considerando a quarta questo, a implementao de um Mtodo gil pode afetar alm da equipe de desenvolvimento, os gerentes, os clientes e, at mesmo, reas ou departamentos internos empresa que, numa anlise inicial, no tm nenhum vnculo aparente com o projeto. Sendo assim, fundamental que a alta gerncia tenha cincia de quais grupos ou departamentos sero afetados pela adoo dos Mtodos geis, para que se estabelea um consenso quanto forma de trabalho e se evite desgastes ou problemas futuros. Neste contexto, deve-se destacar a importncia da participao da rea ou departamento de Recursos Humanos no processo de transio para a utilizao dos Mtodos geis (COHN; FORD, 2003, p. 78). Representantes desta rea devem ser envolvidos logo no incio da implementao, para que tenham cincia da nova forma de trabalho e forneam todo o apoio necessrio, sanando dvidas e amenizando ansiedades dos envolvidos no processo de mudana. Complementando esta anlise, COHEN et al (2003, p. 31) selecionam um conjunto de lies aprendidas, que consideram teis quando da deciso pela adoo de um Mtodo gil, algumas das quais rebatem as crticas mais comuns atribudas a este novo enfoque de desenvolvimento de software: Os Mtodos geis podem ser aplicados a equipes de qualquer tamanho, entretanto, deve-se ter em mente que quanto maior a equipe, maior a dificuldade de comunicao; Experincia importante para que um projeto gil seja bem-sucedido, mas a experincia tcnica em desenvolvimento de software muito mais importante que a experincia prvia com os Mtodos geis; Os Mtodos geis requerem menos treinamento formal que os mtodos clssicos. Tcnicas como a programao em pares minimizam a necessidade de treinamento, pois as pessoas aprendem umas com as outras. Os treinamentos formais podem ser realizados por meio de auto-estudo; Um software crtico e de alta confiabilidade pode ser construdo com a utilizao de Mtodos geis. Neste caso, fundamental que os requisitos de desempenho sejam explicitados logo no incio do projeto e os nveis adequados de teste planejados. Ao solicitar feedback constante, incentivar a

participao dos clientes e a definio de prioridade por eles, os Mtodos geis tendem a antecipar resultados e minimizar os riscos do projeto; Os trs principais fatores crticos de sucesso para um projeto gil so: cultura, pessoas e comunicao. Os Mtodos geis exigem uma compatibilidade cultural para serem bem-sucedidos; profissionais competentes so fundamentais: os Mtodos geis usam menos tcnicos, porm mais qualificados; equipes centralizadas facilitam a comunicao e a interao prxima com cliente fator base para seu funcionamento; Os Mtodos geis permitem a identificao rpida de eventuais problemas no projeto, atravs de pequenos sinais, como a queda da motivao da equipe nas reunies dirias, atrasos nas entregas das iteraes e a gerao de documentao desnecessria; A documentao deve ser considerada um custo e sua extenso deve ser determinada pelo cliente. Deve-se buscar desenvolver uma comunicao mais efetiva, mantendo a documentao formal em um patamar mnimo necessrio.

A forma como um Mtodo gil introduzido em uma organizao e os cuidados tomados durante este processo podem determinar o sucesso ou o fracasso da iniciativa. Outro importante desafio enfrentado pelos gerentes das organizaes refere-se escolha do Mtodo gil mais apropriado para o momento e o projeto em questo, em face da variedade de mtodos atualmente disponveis no mercado (NERUR et al, 2005, p.77). Ambler (2002c) e Cohn e Ford (op. cit.) mencionam que, se aps uma anlise detalhada, os Mtodos geis no se apresentarem totalmente compatveis com o projeto ou com os princpios da organizao, mas suas idias ainda assim despertarem interesse, pode-se partir para uma adoo parcial. Nesta estratgia, deve-se identificar os pontos de melhoria prioritrios no processo clssico de desenvolvimento de software e aplicar algumas prticas dos Mtodos geis, visando ao aprimoramento. Obtendo-se um resultado positivo, procede-se a uma nova seleo de reas de melhoria e implantao de novas tcnicas, at que todo o Mtodo gil tenha sido adotado. Por fim, Highsmith (2004), Cohn e Ford (2003) e Nerur et al (2005) ressaltam que muitas das inseguranas e incertezas inerentes a este processo de transio podem ser minimizadas com a adoo de um enfoque de gerenciamento de projetos adequado e compatvel com o desenvolvimento de software conduzidos com o uso de Mtodos geis. Resultados da Aplicao dos Mtodos geis Como os Mtodos geis de Desenvolvimento de Software so relativamente recentes, poucos so os dados empricos disponveis referentes aos resultados de sua aplicao nas organizaes, alguns dos quais so apresentados a seguir. Pesquisa realizada por Reifer (2002, p. 14-17) em 32 organizaes, representando 28 empresas de dez segmentos de mercado distintos, apontou que dentre elas, 14 organizaes adotavam Mtodos geis, todas motivadas por um histrico de baixo desempenho dos projetos de desenvolvimento de software quanto ao cumprimento dos objetivos de prazo e custo. Surpreendentemente, a maioria das empresas analisadas era classificada como nvel dois ou superior, na escala de maturidade nos processos de desenvolvimento de software proposta pelo SW-CMM, ou seja, possuam processos relativamente maduros. No entanto, estas empresas buscavam algo novo, que pudesse reverter o quadro de mau desempenho consistente de seus projetos. A distribuio destas empresas entre os segmentos de atuao, assim como alguns detalhes quanto ao incio da prtica, quantidade de projetos realizados com o uso dos Mtodos geis e ao estgio de implementao do novo mtodo so apresentados na Tabela 8.

Indstria

# Empresas que utilizam Mtodos geis 1 2 1 5 1 2 14

# de Incio da Projetos Utilizao de Mtodos geis 1 3 2 15 1 4 5 31 2001 2000 2000 2000 2000 2000 2000 n/a

Estgio da Implementao Descoberta Piloto Piloto Produo Piloto Produo Produo n/a

Aeroespacial Computao Consultoria Comrcio Eletrnico Pesquisa Software Total

Telecomunicaes 2

Tabela 8. Caractersticas das empresas pesquisadas (FONTE: ADAPTADO DE REIFER, 2002, p. 15.) Os projetos pesquisados so qualificados como de pequeno porte (com menos de 10 participantes), em geral, internos, de baixo risco, com durao menor que 12 meses, mas que exigiam elevado grau de flexibilidade. Com relao aos resultados, 50% das organizaes que responderam a pesquisa conseguiram mensurar os ganhos obtidos com a utilizao de Mtodos geis de Desenvolvimento de Software de forma concreta, sendo que muitas, por possurem mtricas anteriores, realizaram comparaes bastante efetivas. Reifer (2002, p.15) aponta como principais ganhos, j normalizados entre todos os participantes, os seguintes itens: Incremento de produtividade: ganhos de 15% a 23% de produtividade frente aos indicadores da indstria; Reduo de custos: 5% a 7% de reduo de custos quando comparado aos indicadores da indstria; Reduo do tempo de entrega: 25% a 50% de reduo de prazo comparando-se com projetos anteriores realizados pelas empresas; Melhoria de qualidade: cinco empresas que possuam dados concretos apontaram que a taxa de defeitos estava no mesmo nvel dos projetos anteriores quando da liberao de produtos e aplicaes. As demais organizaes analisadas, que no possuam indicadores formais, mensuraram seus ganhos atravs da opinio dos principais interessados nos projetos, listando como benefcios da utilizao dos Mtodos geis, o alto grau de motivao dos profissionais envolvidos, a elevao da moral da equipe e alguns outros argumentos intangveis. De forma unnime, todas as organizaes afirmaram sua inteno de continuar ou mesmo de estender a utilizao dos Mtodos geis, considerando-a uma experincia bastante proveitosa e bem-sucedida. Mas apesar dos resultados animadores, Reifer (2002, p.15), chama a ateno para que no sejam tiradas concluses precipitadas, nem se faa uma generalizao dos resultados, dados o tamanho da amostra (14 organizaes) e o tipo de projetos envolvidos (projetos pequenos, de baixo risco, em ambiente relativamente controlado). Maurer e Martel (2002) relataram o caso de uma companhia Bitonic Solutions Inc. sediada no Canad, cuja equipe de sistemas, composta por nove profissionais, desenvolveu uma aplicao para comrcio eletrnico. O processo de desenvolvimento foi iniciado segundo uma abordagem orientada a objetos ad hoc, sendo adotado o mtodo gil Extreme Programming (XP), depois de determinado perodo. Para a mensurao da produtividade do desenvolvimento, os autores

definiram trs indicadores principais, cujos valores foram divididos pelo esforo despendido para execuo (em horas), a saber: Novas linhas de cdigo (NLOC) Nmero de novos mtodos (# mtodos); Nmero de novas classes (# classes). Maurer e Martel (2002) coletaram mtricas do desenvolvimento nos dois perodos (anterior e posterior ao uso do XP) e reportaram ganhos de produtividade que variaram de 66,3% a 302,1%, conforme mostra a Tabela 9. Indstria Mdia anterior ao uso do XP Mdia com uso do XP % de Variao NLOC / esforo 10,2 17 66,3% # Mtodos / esforo 0,36 1,45 302,1% # Classes / esforo 0,05 0,21 282,6%

Tabela 9. Ganhos de produtividade com XP em projetos Web (FONTE: ADAPTADO DE MAURER; MANTEL, 2002.) Poole e Huisman (2001) relataram o uso bem-sucedido do Extreme Programmming (XP) na companhia Iona Technologies, no desenvolvimento de um middleware. Os autores mencionaram que a empresa no possua um processo de desenvolvimento e manuteno de software definido, sendo que a falta de qualidade no processo acabava por se refletir na qualidade do produto. Um processo de reengenharia de software foi iniciado em 1997 sem, entretanto, alcanar os resultados desejados. Em 2000, a companhia decidiu implementar, de forma gradativa, as prticas do XP em seu processo de manuteno de software. A Iona Technologies alcanou excelentes resultados, reportando ganhos de produtividade na ordem de 67%, o que possibilitou uma reduo no seu quadro de pessoal de 36 para 25 profissionais. A empresa obteve tambm ganhos de qualidade, com uma queda bastante significativa do nmero de erros encontrados pelos clientes, que passaram de 33 erros ao ms para quatro erros ao ms. Estes resultados foram atribudos, principalmente, adoo da prtica de programao em pares. Em 2001, pesquisa conduzida pelo Cutter Consortium (COCKBURN; HIGHSMITH, 2001b), com mais de 200 profissionais de diferentes empresas dos Estados Unidos, Europa, ndia e Austrlia, sobre o uso dos mtodos clssicos e geis de desenvolvimento de software chegou a trs concluses interessantes: Um aumento do nmero de empresas que utilizavam algum Mtodo gil de Desenvolvimento de Software, quando comparado pesquisa similar realizada em 2000; Os projetos de desenvolvimento realizados segundo o enfoque gil apresentaram melhor desempenho em termos de atendimento aos requisitos do negcio, satisfao do cliente e qualidade, que os projetos conduzidos nos moldes clssicos; Os Mtodos geis receberam melhor pontuao no quesito moral dos profissionais, resultado este considerado, na poca, surpreendente pelo fato de apenas 12% dos respondentes serem analistas ou programadores. Similarmente a Reifer (2002), Cockburn e Highsmith (2001b) no generalizam estas concluses, mas consideram, em especial o terceiro item, um indcio bastante positivo da contribuio dos Mtodos geis em relao motivao das equipes de projeto.

A aplicao bem-sucedida do mtodo Extreme Programming (XP) no desenvolvimento de um sistema de misso crtica[7], voltado coordenao de equipes da Hewlett-Packard distribudas ao redor do mundo, foi relatada por Gawlas (2004, p. 18-24). O autor aponta que o processo de desenvolvimento, pelo mtodo XP, foi dividido em sete etapas, cada qual com um resultado e um prazo inicial pr-determinados. Vrias adaptaes foram feitas ao longo do projeto. Alm de destacar prticas relacionadas ao XP, Gawlas (2004, p. 18-24) chama a ateno para a abordagem de gerenciamento de projetos utilizada, caracterizada como uma combinao entre o conhecimento e a experincia da equipe de projeto e a necessidade de balanceamento entre o enfoque gil e o Gerenciamento Clssico de Projetos adotado pela companhia. Aps nove meses e dentro do prazo previsto, o software entrou em produo com poucos defeitos, que puderam ser corrigidos de forma rpida e tranquila. Gawlas (2004, p. 18-24) salienta tambm que um ponto de destaque foi a motivao da equipe de projeto. Bonato (2004, p. 107-172), por sua vez, apresenta um caso de adoo do Extreme Programming (XP) em renomada empresa jornalstica brasileira, para o desenvolvimento de uma aplicao que visava reformulao do pagamento de bonificao s empresas publicitrias, garantindo maior controle ao processo. O projeto foi iniciado segundo o enfoque clssico de desenvolvimento de software, utilizado pela companhia. Contudo, logo no incio do projeto, a equipe se deparou com problemas como a impossibilidade de detalhamento prvio de requisitos e com a dificuldade de entregar o software no prazo, dada a documentao bastante extensiva exigida pelo processo. Neste momento, houve uma deciso pela adoo do XP, buscando aliar qualidade e produtividade diante de requisitos instveis. Ao final, o projeto foi considerado um sucesso, com ganhos de qualidade (mensurados por uma reduo de 62,9% no nmero de erros reportados pelos usurios aps a implementao, quando comparados com outros projetos conduzidos pelo Jornal) e com ganhos de produtividade estimados em 4%, quando comparados mdia da indstria (BONATO, 2004, p. 131-135). Assim como nos outros relatos, Bonato (Ibid.) destaca o elevado grau de motivao da equipe de projeto. Apesar dos vrios estudos expostos, no foi encontrada na literatura uma pesquisa extensa o suficiente, que permita a generalizao dos benefcios resultantes do emprego dos Mtodos geis. No entanto, no se pode negar que os estudos realizados at o momento, alguns dos quais aqui retratados, apontam que determinadas organizaes esto de fato auferindo resultados positivos, quanto qualidade, produtividade e motivao de seus profissionais, com a adoo dos Mtodos geis para o desenvolvimento de software. Limitaes dos Mtodos geis Neste trabalho, to importante quanto listar a aplicao e os benefcios obtidos com o uso dos Mtodos geis, apresentar as limitaes e obstculos sua utilizao. Dentre os autores que escreveram sobre os Mtodos geis de Desenvolvimento de Software, alguns apresentaram e discutiram os principais conceitos e valores que regem este novo enfoque, como Abrahamsson et al (2003), Bohem e Turner (2003), Glass (2001), Cohen et al (2003), Cockburn e Highsmith (2001a; 2001b), Udo e Koppensteiner (2003), Fowler (2003); outros, como Turk et al (2003; 2005), Nerur et al (2005), Bogeret al (2001) e McBreen (2003), introduziram uma viso mais crtica, apontando limitaes ao emprego dos Mtodos geis. Dentre as obras com enfoque crtico acima citadas, a de Turk et al (2005) se destaca das demais por sua ampla abordagem, voltada identificao tanto dos pressupostos bsicos sobre os quais os princpios e prticas dos Mtodos geis esto ancorados, quanto das limitaes, decorrentes de sua aceitao, conforme mostra a Figura 3. Com base nestes pressupostos, identificados aps anlise detalhada de publicaes referentes aos diferentes Mtodos geis e dos valores e princpios defendidos pela Agile Alliance e retratados no documento Manifesto para o Desenvolvimento gil de Software(BECK et al, 2001), Turk et al (2003, p. 43-46) pontuam as limitaes dos Mtodos geis.

Figura 3. Relacionamento entre princpios, prticas, pressupostos e limitaes (FONTE: TURK et al, 2005, p. 8.) Sendo assim, para que se possa entender tais limitaes, deve-se primeiramente visualizar os pressupostos identificados pelos autores (TURK et al, 2005, p. 22), que se encontram retratados na Tabela 10. Pressupostos 1. Pressuposto da visibilidade 2. Pressuposto da iterao 3. Pressuposto da interao com o cliente 4. Pressuposto da comunicao da equipe 5. Pressuposto da comunicao face a face 6. Pressuposto da documentao Detalhamento A visibilidade do projeto s pode ser alcanada atravs da entrega de um software funcionando Um projeto pode ser sempre estruturado em iteraes curtas e de perodos fixos A equipe do cliente est disponvel para interao frequente, quando solicitado pelos programadores Os programadores esto localizados em local que permita a comunicao frequente e intensiva entre si A comunicao face a face o mtodo mais produtivo de comunicao com o cliente e entre os programadores Desenvolver uma documentao extensiva e consistente (relativamente completa) e modelos de software contraproducente Requisitos sempre sofrem modificaes, devido a mudanas de tecnologia, necessidades dos clientes, domnios de negcio ou mesmo aquisio de novos clientes O custo da mudana no aumenta dramaticamente com o passar do tempo

7. Pressuposto da mudana dos requerimentos

8. Pressuposto do custo da mudana

Pressupostos 9. Pressuposto da experincia da equipe 10. Pressuposto da autoavaliao 11. Pressuposto da autoorganizao 12. Pressuposto da garantia de qualidade

Detalhamento Os programadores tm a experincia necessria para definir e adaptar seus processos apropriadamente As equipes almejam a auto-avaliao As melhores arquiteturas, requisitos e projetos emergem de equipes autoorganizadas A avaliao dos artefatos de software (produtos e processos) pode se restringir a entrevistas frequentes e informais, revises e testes de codificao O reuso e a generalidade no devem ser objetivos do desenvolvimento de uma aplicao especfica.

13. Pressuposto do desenvolvimento da aplicao especfica

14. Pressuposto do redesenho O software pode ser continuamente contnuo redesenhado e assim mesmo, manter sua estrutura e integridade conceitual. Tabela 10. Sumrio dos pressupostos relativos aos princpios propostos pela Agile Alliance (FONTE: TURK et al, 2005, p. 22.) Ao abordar as limitaes dos Mtodos geis, Turk et al (2005, p. 23), iniciam a discusso afirmando que [...] nenhum processo gil uma bala de prata (apesar dos altos brados dos entusiastas). Os autores defendem que, uma vez que os pressupostos apresentados acima no so atendidos por todas as organizaes ou por todos os ambientes de desenvolvimento, os Mtodos geis em seus formatos atuais apresentam sim limitaes. Para minimiz-las, a depender do contexto, determinados mtodos necessitam de extenses ou incorporaes de prticas e princpios, usualmente associados os enfoques preditivos e clssicos de desenvolvimento de software. As principais limitaes apontadas por Turk et al (2005, p. 23-34) so apresentadas nos pargrafos a seguir. A primeira limitao identificada diz respeito ao suporte a equipes distribudas. A disperso geogrfica acarreta vrios problemas que inexistem quando os integrantes da equipe de desenvolvimento e do cliente encontram-se prximos. A comunicao se torna mais difcil, h necessidade de ferramentas e tecnologia especiais. Em ambientes distribudos, os pressupostos de interao com o cliente, comunicao da equipe, comunicao face a face ficam comprometidos. O uso de documentao formal pode se fazer necessrio, para organizar o trabalho realizado em vrias localidades por diferentes equipes (TURK et al, 2005, p. 25-26). Turk et al (2005, p. 26-27) apontam a questo da subcontratao como outra limitao dos Mtodos geis, sendo que Nerur et al (2005, p. 76) estendem a discusso para a negociao de contratos de forma geral. A transferncia do desenvolvimento de software a um subcontratado pressupe o estabelecimento de um contrato de prestao de servios bem definido. No entanto, as bases de um contrato tradicional no so as mesmas utilizadas pelos Mtodos geis. Mesmo seguindo um enfoque iterativo e incremental, os contratos de forma geral prevem marcos, um nmero fixo de iteraes, com duraes e entregveis pr-definidos e clusulas restritivas a mudanas, o que no se adequa a vrios pressupostos dos Mtodos geis. Turk et al (2005, p. 26-27) apontam como sada, a criao de um contrato contendo uma parte fixa e outra varivel para acomodar ambas as expectativas. A dificuldade de apoio a grandes projetos e grandes equipes outra limitao apontada por alguns autores. Vrios autores apontam que quanto maior a equipe,

maior a complexidade da comunicao e menos gil se torna o processo (HIGHSMITH, 2004; COHEN et al, 2003, TURK et al, 2005, p. 27-28; NERUR et al, 2005, p.76). O tamanho das equipes restringe a eficincia e a frequncia das interaes face a face, havendo necessidade de uma maior estruturao e organizao da equipe e da definio de vrias linhas e formas de comunicao. O volume de documentao requerido maior e, de forma geral, a agilidade tende a diminuir. Isto no quer dizer que grandes projetos no possam utilizar Mtodos geis, mas h que se adotar prticas complementares para garantir o bom andamento dos trabalhos. Discutindo outro item, a gerao de componentes total ou parcialmente reutilizveis (cdigos de programas, documentos de anlise e desenho, entre outros) pressupe a viso completa da soluo (e no apenas do software a ser desenvolvido naquele momento) e a nfase no controle de qualidade. Os Mtodos geis tm por premissa a manuteno de uma documentao mnima, o que dificulta a determinao do potencial de reuso de um determinado artefato, alm de ter por foco o desenvolvimento de solues para problemas especficos e no o desenvolvimento de cdigos mais genricos e reutilizveis. Desta forma, os Mtodos geis de Desenvolvimento de Software no so os mais adequados gerao de artefatos reutilizveis (TURK et al, 2005, p. 28-29). A adoo de Mtodos geis no desenvolvimento de sistemas de misso crtica outro ponto comentado por Turk et al (2005, p. 29-30). Aplicaes desta natureza requerem que a qualidade de todos os seus componentes seja intensivamente testada e que estes sejam projetados de forma a no haver falhas que impossibilitem a correo ou o uso seguro de um determinado equipamento. Neste contexto, os pressupostos relacionados documentao, garantia da qualidade e ao aprimoramento contnuo dos Mtodos geis no so mais vlidos. Uma especificao formal, testes intensivos e abrangentes e outras tcnicas de anlise e avaliao dos mtodos clssicos de desenvolvimento de software se tornam necessrias, apesar de os autores ressaltarem que a adoo de algumas prticas dos Mtodos geis seja interessante, para aumentar a qualidade e a confiabilidade do produto final (TURK et al, Ibid.). O desenvolvimento de um software grande e complexo, com numerosas linhas de cdigos (milhares ou milhes) e alto grau de integrao entre seus vrios componentes outra situao em que a aplicabilidade dos Mtodos geis contestada. Segundo Turk et al (2005, p. 30-31), projetos deste porte requerem elevado esforo de gerenciamento e controle, processos estruturados e formais, para garantir o perfeito entendimento do software e a integrao de todas as suas partes. Os testes tambm devem ser cuidadosamente planejados. De forma geral, no possvel o desenvolvimento deste tipo de software de forma incremental e a adoo da premissa de desenvolvimento contnuo pode ser comprometida, haja vista a complexidade e a extenso do cdigo. Complementando a anlise, Nerur et al (2005, p.76) e TURK et al (2005, p. 13-15) chamam a ateno questo da dependncia entre as organizaes e suas equipes geis de desenvolvimento, em especial no que diz respeito gesto do conhecimento, vital nos dias de hoje, e relao de poder. Os Mtodos geis de Desenvolvimento de Software encorajam o pensamento direto e o corte em todo e qualquer esforo desnecessrio, inclusive na documentao. Sendo assim, no desenvolvimento gil, o conhecimento tcito e reside apenas na mente de cada integrante de equipe. Em alguns casos, as organizaes tornam-se dependentes desta equipe e muitas vezes h uma mudana no balano do poder, entre os gerentes e os programadores, sendo os ltimos os detentores das informaes. Para minimizar este impasse, Nerur et al (op. cit.) e TURK et al (op. cit.) sugerem que seja claramente definido o que deve ser documentado e o que pode ser mantido como conhecimento tcito. O pressuposto de interao com os clientes outro ponto amplamente discutido e criticado por vrios autores. Turk et al (2005, p. 12) esclarece que os Mtodos geis pressupem que os clientes esto sempre disponveis para participar,

esclarecer dvidas e tomar decises junto equipe de desenvolvimento, o que na prtica nem sempre se mostra vivel. Nerur et al (2005, p. 76) complementam que o ambiente pluralista de tomada de decises (que envolve clientes e equipe de desenvolvimento), estimulado pelos Mtodos geis, torna o processo decisrio mais lento e difcil, quando comparado ao enfoque clssico, em que o gerente do projeto o responsvel por tal. Nerur et al (Ibid.) destacam que o sucesso dos Mtodos geis depende de se encontrar clientes que almejem e tenham disponibilidade para uma participao ativa no processo de desenvolvimento, que sejam colaborativos, representativos e comprometidos e que disponham da autonomia e do conhecimento adequados ao projeto H que se mencionar ainda, a questo da manuteno de software, qualificada como algo to problemtica quanto o desenvolvimento propriamente dito e ainda pouco abordada pelos Mtodos geis (RUS et al, 2002; COHEN et al, 2003). Todas estas limitaes apontadas por autores e estudiosos do assunto (TURK et al, 2003 e 2005; NERUR et al, 2005; BOGER et al, 2001; McBREEN, 2003) devem ser avaliadas quando da definio mtodo de desenvolvimento de software a ser utilizado. Contudo, apesar de sua importncia, no podem ser consideradas como nica verdade, uma vez que a literatura aponta exemplos de projetos conduzidos com o uso de Mtodos geis que foram bem-sucedidos, apesar das condies teoricamente adversas sua utilizao. Entre estes exemplos podem ser citados: o desenvolvimento de um software de misso crtica com o uso do XP (GAWLAS, 2003) e a utilizao do XP e do Scrum em projetos com mais de 100 pessoas distribudas em mais de um continente (Fowler, 2003). Fatores Crticos de Sucesso de Projetos de Desenvolvimento de Software Realizados com o Uso dos Mtodos geis Poucas so as referncias na literatura que discutem a questo dos fatores crticos de sucesso de projetos conduzidos com o uso de Mtodos geis. Cohen et al (2003, p. 31) destacam que so trs os principais fatores crticos de sucesso para um projeto conduzido segundo um enfoque gil, a saber: cultura, pessoas e comunicao. Cockburn e Highsmith (2001b), autores que defendem uma viso dos Mtodos geis centrada nas pessoas, identificam a competncia individual como o fator primordial para o sucesso de projetos conduzidos de acordo com os Mtodos geis. Mencionam que [...] se as pessoas forem boas o suficiente, podem usar praticamente qualquer processo e atingir seus objetivos. Se as pessoas no forem boas o bastante, no h processo que possa reparar esta inadequao (COCKBURN; HIGHSMITH, 2001b, p. 131). A falta de apoio executivo e dos principais usurios, por outro lado, apontada como um grande empecilho para o alcance do sucesso de um projeto, levando at mesmo excelentes profissionais ao no cumprimento de seus objetivos. Em 2003, um estudo de carter exploratrio desenvolvido por Lazaveric (classificado pelo prprio autor como sem similar na rea at aquele momento) identificou os principais fatores crticos de sucesso de projetos de desenvolvimento de software conduzidos com o uso de Mtodos geis (LAZAREVIC, 2003). A pesquisa foi realizada por meio da aplicao de um questionrio a profissionais que haviam gerenciado ou participado de projetos com tais caractersticas, integrantes de cinco grupos da internet especializados na troca de experincia e na discusso dos principais Mtodos geis. Apesar de obter uma taxa de resposta de apenas 4% (o autor acredita que este nmero deva ser maior, dado que muitos dos integrantes dos referidos grupos encontravam-se inativos), a pesquisa permitiu a identificao de fatores crticos de sucesso para tais projetos que se mostraram bastante alinhados s colocaes de autores como Cockburn e Higsmith (2001b), Cohen et al (2003) e Reifer (2002). A existncia de programadores motivados foi identificada como a chave para o sucesso dos projetos pesquisados, sendo considerado o fator crtico mais importante para projetos conduzidos com o uso de Mtodos geis. O segundo fator

crtico de sucesso identificado foi o grau de propriedade coletiva do cdigo. A propriedade coletiva pressupe que qualquer integrante da equipe pode alterar o cdigo desenvolvido por outrem e contribuir para a soluo e encoraja a sinergia, a colaborao e o trabalho em equipe. A descoberta deste segundo fator est totalmente alinhada ao primeiro item. Lazarevic (2003, p. 28) destaca que [...] atingir um estgio em que os resultados do grupo sejam melhores que a contribuio de cada indivduo o corao de muitos Mtodos geis. Ainda, de acordo com Sutherland (2001), quando os indivduos se ajudam mutuamente e contribuem para o todo, a equipe de desenvolvimento atinge o estado de hiperprodutividade. O terceiro fator encontrado diz respeito entrega de um prottipo logo no incio do projeto. Para Lazarevic (Ibid.), a maioria dos respondentes interpretou esta questo luz das necessidades de mudanas de requisitos, ou seja, da necessidade de um desenvolvimento incremental do software. Nesse mesmo estudo, Lazaveric (2003, p. 24) menciona que os projetos desenvolvidos segundo os mtodos Extreme Programming (XP) e Dynamic Software Development Model (DSDM) foram mais bem-sucedidos, mas este resultado no se mostrou estatisticamente significativo. Como informao adicional desta pesquisa, tem-se que a maioria dos respondentes possua de um a quatro anos de experincia em Mtodos geis, o que confirma que a utilizao destes mtodos no desenvolvimento de software um fenmeno relativamente novo. O tamanho das equipes dos projetos analisados variava entre quatro e vinte integrantes, sendo que apenas 10% dos projetos tiveram mais de 50 participantes (LAZAREVIC, 2003, p. 26). Como muitos outros autores (REIFER, 2002; COCKBURN; HIGHSMITH, 2001b), Lazarevic (2003, p. 29) no considera seu estudo representativo, no devendo assim ser generalizado. Mas o enfoque diferenciado de seu trabalho, em especial, sua abrangncia (obteno de dados de diferentes projetos, de profissionais provenientes de distintas organizaes), certamente contribui para a ampliao do conhecimento na rea. Ampliando a viso dos fatores crticos de sucesso, Chin (2004), assim como Cohn e Ford (2003), Highsmith (2004) e Nerur et al (2005), ressaltam que no se pode esquecer o inegvel valor do gerenciamento de projetos na entrega de um projeto de desenvolvimento de software bem-sucedido. Apesar de alguns Mtodos geis j possurem componentes de gerenciamento de projetos inseridos em suas prticas, como por exemplo o Scrum, o FDD e o ASD, Thomsett (2002, p. 17) indica a necessidade de uma abordagem mais ampla e, preferencialmente, em separado das questes tcnicas. Analisando os fatores crticos de sucesso identificados, percebe-se que esto estritamente relacionados valorizao da competncia individual e comunicao (REIFER, 2002; COCKBURN; HIGHSMITH, 2001b; LAZAREVIC, 2003) e entrega rpida de valor (LAZAREVIC, 2003). Todos estes itens correspondem a caractersticas marcantes dos Mtodos geis de Desenvolvimento de Software e o tambm do Gerenciamento gil de Projetos, o que pode sugerir que talvez este seja o enfoque de gerenciamento de projetos mais apropriado para o desenvolvimento de software conduzido com o uso de um Mtodo gil. Referncias ABRAHAMSSON, P et al. New directions on agile methods: a comparative analysis. In: Proceedings of the 25th International Conference on Software Engineering. [S.l.]. IEEE Software Society, 2003, p. 244-254. AGILE ALLIANCE. Manifesto for agile software development. Disponvel em <http://www.agilemanifesto.org/>. Acesso em janeiro, 2005. AMBLER, S. W. Agile modeling: effective practices for extreme programming and the unified process. John Wiley & Sons, Inc., 2002a.

AMBLER, S.W. Lessons in agility from internet-based development. IEEE Software, [S.l.], v. 19, n. 2, 2002b, p. 6673. AMBLER, S.W. When does(nt) agile modeling make sense. Apr, 2002c. Disponvel em <http://www.agilemodeling.com/essays/whendoesAmWork.htm>. Acesso em julho de 2005. AMBLER, S. W. Quality in an agile world. Software Quality Professional, [S.L.], v. 7, n. 4, sep. 2005. BECK, K. Embrance Change with Extreme Programming. IEEE Computer Magazine, [S.l.], Oct 1999, p. 70-77. ______. Extreme programming explained. Boston: Addison-Wesley, 2000. BECK, Kent. et al. Chrysler goes to extremes. Oct, 1998. Disponvel em <http://www.xprogramming.com/publications/dc9810cs.pdf>. Acesso em julho, 2005. BECK, Kent et al. Manifesto for agile software development. Feb. 2001. Disponvel em <http://www.agilemanifesto.org/>. Acesso em janeiro, 2005. BECK, Kent; FOWLER, M. Extreme programming applied. Boston: AddisonWesley, 2001. BECK, Kent; MEE, R. Enhancing brazilian softwares global competitiveness. Jan, 2003. Disponvel em: <http://www.xispe.com.br/wiki/wiki.jsp?topic=EnhancingBrazilsSoftwareGlobalCom petitiveness>. Acesso em novembro, 2004. BOGER, M. et al. Extreme modeling. In: SUCCI, G.; Marchesi, M. (eds). Extreme programming examined. Boston: Addison-Wesley, 2001. BOHEM, Barry. Get ready for agile methods, with care. IEEE Computer Magazine, [S.l.], Jan. 2002, p. 64-69. BOHEM, Barry.; TURNER, Richard. Balancing discipline and agility: evaluating and integrationg plan-driven methods. In: Proceedings of the 26th Conference on Agile Development. IEEE COMPUTER SOCIETY, [S.l.], May 2004, p. 718-719. BONATO, A. S. F. Uma experincia de aplicao do processo Extreme Programming em pequenos projetos. So Paulo, 2004. Dissertao (Mestrado em Engenharia) Programa de Ps-Graduao em Engenharia, Escola Politcnica da Universidade de So Paulo. BRASIL. Ministrio da Cincia e Tecnologia. Secretaria de Poltica de Informtica. Levantamento do universo de Associadas Softex. Braslia - DF, 2001a. ______. Ministrio da Cincia e Tecnologia. Secretaria de Poltica de Informtica. Qualidade e Produtividade no Setor de Software Brasileiro. Braslia DF, 2001b. CHIN, Gary. Agile project management: how to succeed in the face of changing project requirements. NY: Amacon, 2004.

COCKBURN, A. Crystal clear: a human-powered methodology for small teams . Boston: Addison-Wesley, 2004. ______. Agile software development. Boston: Addison-Wesley, 2001. ______. Learning from agile software development part one. Crosstalk, The Journal of Defense Software Engineering, [S.l.], October 2002. COCKBURN, A.; HIGHSMITH, J. Agile software development: the business of inovation. IEEE Computer Magazine, [S.l.], p. 131-133, sep 2001a. ______. Agile software development: the people factor. IEEE Computer Magazine, [S.l.], p. 131-133, nov 2001b. COHEN, David et al. Agile software development: a DACS state of art report. NY: Data Analysis Center for Software - Fraunhoufer Center for Experimental Software Engineering Maryland and The University of Maryland, 2003. Disponvel em <http://www.thedacs.com/techs/agile/>. Acesso em abril, 2005. COHEN, Dennis. J.; GRAHAM, Robert. J. Gesto de projetos: MBA executivo. Trad. Afonso Celso da Cunha Serra. Rio de Janeiro: Campos, 2002. COHN, Martin. The scrum development process. Disponvel em <www.mountaingoatsoftware.com/scrum> Acesso em julho, 2005. COHN, Martin; FORD, Doris. Introducing an agile process to an organization . IEEE Computer Magazine, June 2003, [S.l.], p. 74-78. DEMING, W. E. Qualidade: a revoluo da administrao. Rio de Janeiro: Marques Saraiva, 1990. FERREIRA, A. A., REIS, A. C. F., PEREIRA, M. I. Gesto empresarial: de Taylor aos nossos dias. So Paulo: Thomson, 2002, p. 146-164. FOWLER, Martin. The new methodology. April, 2003. Disponvel em <http://www.martinfowler.com/articles/newMethodology.html>. Acesso em julho, 2005. GAWLAS, J. Mission critical development with XP & agile process: common code ownership and lots of testing. Dr. Dobbs Journal, [S.l.], p. 21-24, Jan. 2004. GLASS, Robert. Extreme programming: the good, the bad and the bottom line. IEEE Software, [S.l.], Nov. 2001, p. 111-112. GLAZER, H. Dispelling the process myth: having a process does not mean sacrificing agility or criativity. Crosstalk, The Journal of Defense Software Engineering, [S.l.], Nov. 2001. HIGHSMITH, Jim. Adaptative management: patterns for the e-business era. Cutter IT Journal, [S.l.], v. XII, n. 9, sep. 1999. HIGHSMITH, Jim. Agile software development ecosystems. Boston: AddisonWesley, 2002. ______. Agile project management: creating innovative products. Boston: Addison-Wesley, 2004.

HIGHSMTIH, Jim et al. Extreme programming: e-business application delivery. Feb. 2002. Disponvel em <http://www.cutter.com/freestuff/ead0002.pdf>. Acesso em julho, 2004. JURAN, J. M.; GRYNA, F. M. Controle da qualidade handbook: conceitos, polticas e filosofia da qualidade. So Paulo: Makron, McGraw-Hill, 1991 JURIC, R. Extreme Programming and its Development Practices. In: Proceedings of 22nd international conference on information technology interfaces. 2002, p. 97104. LAZAREVIC, George. An exploratory study of the new product development utilized by software companies using agile product development approach. Oct. 2003. Disponvel em <http://www.agilealliance.org/articles/articles/agileOct.pdf>. Acesso em agosto, 2005. MAURER, Frank.; MARTEL, Sebastien. Extreme programming: rapid development for web-based applications. IEEE Internet Computing, [S.l.], v. 6, n. 1, p. 86 90, Jan. 2002. ______. On the productivity of agile software practices: an industrial case study. Abr. 2004. Disponvel em: <http://sern.ucalgary.ca/ milos/papers/2002/MaurerMartel2002c.pdf>. Acesso em Agosto, 2005. McBREEN, P. Questioning extreme programming. Boston: Addison-Wesley, 2003. NERUR, S. et al. Challenges of migrating to agile methodologies: organizations must carefully assess their readiness before treading the path of agility. Communication of the ACM, [S.l.], v.48, n.5, p 73-78, May 2005. PALMER, S. R.; FELSING, M. A practical guide to feature-driven development. [S.l.]: Pearson Education, 2001. PAULK, Mark. C. ExtremepProgramming from a SW-CMM perspective. IEEE Software, [S.l.], v. 18, n. 6, p. 1926, Nov. 2001. ______. Agile methodologies and process discipline. Crosstalk - The Journal of Defense Software Engineering, [S.l.], v. 15, n. 10, p. 1528, Oct. 2002. POPPENDIECK. M. Lean programming. Software Development Magazine. MayJune, 2001 Disponvel em <http://www.agilealliance.org/articles/articles/LeanProgramming.htm>. Acesso em julho, 2005. POPPENDIECK. M.; POPPENDIDIECK. T. Lean software development. Boston: Addison-Wesley, 2003. REIFER, Donald J. How good are agile methods? IEEE Software, [S.l.], p. 14-17, jul-ago, 2002. RUS, I. et al. Process diversity in software maintenance guest editorss introduction. Software Maintenance Research and Practice, Dec. 2002. SCHWABER, K.; BEEDLE, M. Agile software development with scrum. NJ: Pretence Hall, 2001.

SCHWABER, K. Controlled chaos: living on the edge. 2002. Disponvel em <http://www.agilealliance.org/articles/articles/ap.pdf>. Acesso em junho, 2005. THOMSETT, R. Radical Project Management. NJ: Prentice Hall, 2002. TURK, D. et al. Limitations of agile software processes. Jan, 2003. Disponvel em <http://www.agilealliance.org/articles/articles/LimitationsofAgile.pdf> Acesso em Agosto, 2005. ______. Assumptions underlying agile software development process . Colorado State University, 2005. UDO, N., KOPPENSTEINER, S. Will agile change the way we manage software projects? Agile from a PMBoK guide perspective. Projectway, [S.l.], 2003.

[1] Entre os mtodos clssicos de desenvolvimento de software podem ser citados o Modelo em Cascata e os modelos iterativos e em Espiral (COHEN et al, 2003). [2] Modelo Toyota de Produo para maiores informaes ver Correa e Gianesi (1993) e Ferreira et al (2002). [3] A Administrao da Qualidade Total ou Total Quality Management pode ser entendida como a extenso do planejamento de negcios de uma empresa, abrangendo o planejamento da qualidade (JURAN; GRYNA, 1991, p. 210 214). [4] Agile Alliance Organizao sem fins lucrativos criada para auxiliar indivduos e organizaes que utilizam os Mtodos geis para o desenvolvimento de software. [5] We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: - Individuals and interaction over process and tools; - Working software over comprehensive documentation; - Customer collaboration over contract negotiation - Responding to change over following a plan. That is, while there is a value in the items on the right, we value the items on the left more. [6] Pesquisa publicada pelo STANDISH GROUP INTERNATIONAL (2003), referente a projetos de desenvolvimento de software, aponta que usualmente os projetos ultrapassam em 82% os prazos inicialmente previstos. Em 1999, este ndice de atraso chegou ao valor aproximado de 222%. [7] Sistema (ou software) de misso crtica aquele em que a vida, a sade ou a segurana das pessoas ou organizaes podem ser comprometidas se a qualidade do software no for extremamente alta (TURK et al, 2005, p.29).