ES20_tem Artigos Com as Met Ágeis

EDITORIAL

Corpo Editorial

ColaboradoresRodrigo Oliveira [email protected]

Marco Antnio Pereira ArajoEduardo Oliveira Spnola

Capa e DiagramaoRomulo Araujo - [email protected]

Coordenao GeralDaniella Costa - [email protected]

Revisor e SupervisorThiago Vincenzo - [email protected]

Na Webwww.devmedia.com.br/esmag

Ano 2 - 20 Edio - 2010 Impresso no Brasil

Nesta edio a Engenharia de Software Magazine destaca como

tema de capa a agilidade no desenvolvimento e gerenciamen-

to de projetos de software. Para isto, trazemos duas matrias

muito interessantes. Na primeira delas, Mtodos geis de Desenvolvi-

mento de Software, so apresentados o histrico, o conceito, os valores

e os princpios que norteiam os Mtodos geis, assim como so des-

critos os mtodos mais freqentemente 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 dis-

cutidos os fatores crticos de sucesso de projetos de desenvolvimento

de software conduzidos com o uso desses mtodos.

No segundo artigo, Gerenciamento gil de Projetos de Software,

sero apresentados o histrico, a definio, os valores, os princpios e

a estrutura de prticas do Gerenciamento gil de Projetos. Os projetos

de desenvolvimento de software so normalmente caracterizados por

um elevado grau de incertezas iniciais e, conseqentemente, por uma

grande dificuldade de detalhamento do escopo e de elaborao de

um planejamento completo. Neste cenrio de incertezas, abordagens

geis para gerenciamento de projetos de software tm sido vistas

como uma alternativa interessante. Conhecer tais abordagens pode

ser considerado fundamental.

Alm destas matrias, esta edio traz mais quatro artigos:

Uso de Anlise de Pontos de Funo em Ambientes geis Introduo ao Mantis Atividades Aliadas dos Testes de Software User Experience: Obtendo Dados com Testes de Usabilidade

Desejamos uma tima leitura!

Equipe Editorial Engenharia de Software Magazine

Rodrigo Oliveira Spnola [email protected] em Engenharia de Sistemas e Computao (COPPE/UFRJ). Mestre em Engenharia de Software (COPPE/UFRJ, 2004). Bacharel em Cincias da Computa-o (UNIFACS, 2001). Colaborador da Kali Software (www.kalisoftware.com), ten-do ministrado cursos na rea de Qualidade de Produtos e Processos de Software, Requisitos e Desenvolvimento Orientado a Objetos. Consultor para implementao do MPS.BR. Atua como Gerente de Projeto e Analista de Requisitos em projetos de consultoria na COPPE/UFRJ. Colaborador da Engenharia de Software Magazine.

Marco Antnio Pereira Arajo - Editor([email protected])Doutor e Mestre em Engenharia de Sistemas e Computao pela COPPE/UFRJ - Li-nha de Pesquisa em Engenharia de Software, Especialista em Mtodos Estatsticos Computacionais e Bacharel em Matemtica com Habilitao em Informtica pela UFJF, Professor e Coordenador do curso de Bacharelado em Sistemas de Informao do Centro de Ensino Superior de Juiz de Fora, Professor do curso de Bacharelado em Sistemas de Informao da Faculdade Metodista Granbery, Professor e Diretor do Curso Superior de Tecnologia em Anlise e Desenvolvimento de Sistemas da Fundao Educacional D. Andr Arcoverde, Analista de Sistemas da Prefeitura de Juiz de Fora, Colaborador da Engenharia de Software Magazine.

Eduardo Oliveira Spnola([email protected]) Colaborador das revistas Engenharia de Software Magazine, Java Magazine e SQL Magazine. bacharel em Cincias da Computao pela Universidade Salva-dor (UNIFACS) onde atualmente cursa o mestrado em Sistemas e Computao na linha de Engenharia de Software, sendo membro do GESA (Grupo de Engenharia de Software e Aplicaes).

Apoio

Atendimento ao Leitor

A DevMedia conta com um departamento exclusivo para o atendimento ao leitor.

Se voc tiver algum problema no recebimento do seu exemplar ou precisar de

algum esclarecimento sobre assinaturas, exemplares anteriores, endereo de

bancas de jornal, entre outros, entre em contato com:

Cristiany Queirz Atendimento ao Leitorwww.devmedia.com.br/mancad(21) 2220-5338

Kaline DolabellaGerente de Marketing e [email protected](21) 2220-5338

Publicidade

Para informaes sobre veiculao de anncio na revista ou no site entre em

contato com:

Kaline [email protected]

Fale com o Editor!

muito importante para a equipe saber o que voc est achando da revista: que tipo de artigo

voc gostaria de ler, que artigo voc mais gostou e qual artigo voc menos gostou. Fique a

vontade para entrar em contato com os editores e dar a sua sugesto!

Se voc estiver interessado em publicar um artigo na revista ou no site SQL Magazine,

entre em contato com os editores, informando o ttulo e mini-resumo do tema que voc

gostaria de publicar:

Rodrigo Oliveira Spnola - Colaborador

[email protected]

NDICE

Abordagens geis de Desenvolvimento

05 - Mtodos geis de Desenvolvimento de SoftwareMarisa Villas Boas Dias

22 - Gerenciamento gil de Projetos de Software Marisa Villas Boas Dias

33 - Uso de Anlise de Pontos de Funo em Ambientes geisClio Santana e Cristine Gusmo

Abordagens Tradicionais de Desenvolvimento

41 - Introduo ao MantisRenato de Freitas Matos, Letcia Dias da Silva e Evaldo de Oliveira da Silva

Validao, Verificao e Teste

48 - Atividades Aliadas dos Testes de SoftwareMelissa Barbosa Pontes e Luiz Fernando Rodrigues Corra de Barros

53 - User Experience Antonio Mendes da Silva Filho

Tipo: Projeto Ttulo: Diagrama de Classes na Prtica Partes 14 e 15 Estudo de Caso 3 Autor: Rodrigo Oliveira SpnolaMini-Resumo: Esta aula parte de uma srie sobre a construo de diagrama de classes da UML. O objetivo do conjunto de aulas apresentar de forma prtica como elaborar o diagrama de classes a partir de diferentes estudos de caso. Nestas aulas, finalizada a elaborao do diagrama de classes para o terceiro estudo de caso. Nesta etapa, sero identificadas as operaes e os relacionamentos que sero acrescentados ao diagrama.

Tipo: ProjetoTtulo: Diagrama de Casos de Uso na Prtica Partes 1 a 3 Estudo de Caso 1Autor: Rodrigo Oliveira SpnolaMini-Resumo: Esta aula parte de uma srie sobre a construo de diagra-ma de casos de uso da UML. O objetivo do conjunto de aulas apresentar de forma prtica como elaborar o diagrama de casos de uso a partir de diferentes estudos de caso. Nestas aulas, ser feita uma breve introduo aos diagramas de casos de uso e tambm ser elaborado o diagrama de casos de uso para o primeiro estudo de caso.

4 Engenharia de Software Magazine

Caro Leitor, Para esta edio, temos um conjunto de 5 vdeo aulas. Estas vdeo aulas esto disponveis para download no Portal da Engenharia de Software Magazine e certamente traro uma significativa contribuio para seu aprendizado. A lista de aulas publicadas pode ser vista abaixo:

Caro Leitor

Edio 20 - Engenharia de Software Magazine 5

Marisa Villas Boas Dias

De que se 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. Tam-bm 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 dife-renciadas que exigem, muitas vezes, aborda-gens no tradicionais de desenvolvimento.

Mtodos geis de Desenvolvimento de Software

Como uma resposta s crescentes presses por inovao em pra-zos cada vez mais reduzidos, s necessidades de constantes mudanas de requisitos e ao mau desempenho de grande parte dos projetos de desenvolvi-mento de software, houve um movimen-to na comunidade de desenvolvimento de software que deu origem aos Mtodos geis. Posteriormente, o conceito-base deste movimento evoluiu, de uma abor-dagem tcnica para o mbito gerencial, criando um novo enfoque de gerencia-mento de projetos o Gerenciamento gil de Projetos.

Neste artigo so apresentados o histri-co, o conceito, os valores e os princpios que norteiam os Mtodos geis, assim como so descritos os mtodos mais frequentemente utilizados pelas organi-zaes. 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 condu-zidos com o uso desses mtodos.

6 Engenharia de Software Magazine - Mtodos geis de Desenvolvimento de Software

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 desenvolvimento1 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 clssi-cos. 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 M-todos 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 introdu-zidas 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 questionamen-tos 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 se-guinte pergunta: Por que os processos definidos e defendidos pelo SW-CMM no promovem entregas consistentes? Aps analisarem seus processos de desenvolvimento 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 complexida-de dos processos propostos pelo SW-CMM, na consequente

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 en-tendida como a extenso do planejamento de negcios de uma empresa, abran-gendo o planejamento da qualidade (JURAN; GRYNA, 1991, p. 210 214).

dificuldade de aplicao e tambm na necessidade de mudan-as 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 simulta-neamente, 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 (COCK-BURN; 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 desenvol-vimento de software (POPPENDIECK, 2001). O Modelo Toyota de Produo2 foi alvo de ateno especial: enquanto as unida-des 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 Total3, 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 pr-ticas 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 interme-dirios, 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;


MEtoDoLoGIAS GEIS

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 independen-te, 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 atu-almente. 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 trabalha-do 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 im-portante 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 en-dereados 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 condi-es 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 SoftwareNo incio de 2001, criadores e representantes dos chamados Mtodos

geis de Desenvolvimento de Software Extreme Programming, Scrum, Dynamic Systems Development Method, Adaptative Software Develop-ment, Crystal Methods, Feature-Driven 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 credibili-dade 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 de-senvolvimento 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 balan-cear 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 Alliance4, sendo publicado o Manifesto para Desenvolvimento gil de Software ou o Manifesto for Agile Software Development (BECK et al, 2001), cujo contedo5 apresentado abaixo:

Ns estamos descobrindo melhores maneiras para desen-volver 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 De-senvolvimento de Software (AGILE ALLIANCE, 2005). Estes princpios so apresentados na Tabela 1 abaixo, de acordo com a ordem originalmente proposta.

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

4 Agile Alliance Organizao sem fins lucrativos criada para auxiliar indiv-duos 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.

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: diferen-temente 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 adap-tados ao longo do projeto, permitindo e, algumas vezes estimu-lado, 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.

Princpios

Nossa maior prioridade satisfazer o cliente atravs da entrega rpida e contnua de um

software de valor

Pessoas de negcio e programadores devem trabalhar juntos, diariamente, ao longo de todo o

projeto

Aceite as mudanas de requisitos, mesmo que numa etapa avanada do desenvolvimento

Entregue novas verses do software frequentemente

O software em funcionamento a medida primria de progresso do projeto

Construa projetos com pessoas motivadas. Oferea a elas o ambiente e todo o apoio necessrios e

acredite em sua capacidade de realizao do trabalho

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

O mtodo mais eficiente e efetivo de distribuir a informao para e entre uma equipe de

desenvolvimento a comunicao face a face

Processos geis promovem desenvolvimento sustentado

A ateno contnua na excelncia tcnica e num bom projeto aprimora a agilidade

Simplicidade essencial

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

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 desenvol-vimento de software, outros especialistas, representantes tanto dos mtodos clssicos quanto dos geis, tm uma postura mais amena, enxergando at mesmo uma possibilidade de integra-o 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,


MEtoDoLoGIAS GEIS

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 organiza-es a alcanar os objetivos propostos pelo SW-CMM.

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; KOPPEN-STEINER, 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 Program-

ming (XP) , indubitavelmente, o Mtodo gil de maior ex-presso, 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 ins-tveis. 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, am-pliando 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, permiti-ram 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.

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 pla-no 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 metfo-ras ou conjunto de metforas para modelagem do sistema;5. Projeto simples: os programadores so estimulados a desen-volver o cdigo do software o mais simples possvel;6. Testes: os programadores devem criar os testes de unida-de 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, realizan-do 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 identifica-o de quem desenvolveu determinada parte do cdigo e a auxiliar a conduo do trabalho.

Requisitos Anlise Projeto Implementao Teste Produo

Hoje

H 30 anos

Cus

to d

a m

udan

a d

o so

ftwar

e

Requisitos Anlise Projeto Implementao Teste Produo

Hoje

H 30 anos

Cus

to d

a m

udan

a d

o so

ftwar

e

Figura 1. Custo da mudana do software (FONTE: BECK, 2004, p. 21-23)


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 carac-tersticas principais que norteiam a aplicao do Extreme Programming, retratado na Tabela 2.

Caracterstica Valores sugeridos

Tamanho da Equipe Equipes formadas por 2 a 10 integrantes

Durao das iteraes Durao usual de duas semanas por iterao

Equipes distribudas Dada que a equipe deve trabalhar preferencialmente no mesmo

local fsico, o XP no indicado para equipes distribudas

Aplicaes de alta criticidade Pode ser utilizado no desenvolvimento de software de baixa,

mdia ou 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, adaptabili-dade e produtividade, em que a escolha das tcnicas de de-senvolvimento 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 desenvol-vimento (SCHWABER; BEEDLE, 2001).

Schwaber (2002) sumariza assim os princpios-chave do Scrum: Equipes pequenas de trabalho, buscando a maximiza-o 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).

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 desenvolvi-mento 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).

Priorizado por produtividade e tolernciaPriorizado por produtividade e tolerncia

Nmero de pessoas envolvidas (+20%)

E1000E500E200E100E40E20E6

C200

D200

V200

C1000C500C100C40C20C6

D1000D500D100D40D20D6

V1000V500V100V40V20V6

E1000E500E200E100E40E20E6

C200

D200

V200

C1000C500C100C40C20C6

D1000D500D100D40D20D6

V1000V500V100V40V20V6Vida (V)

Dinheiro Essencial (E)

Dinheiro (D)

Conforto (C)

Cri

ticid

ade

(def

eito

s cau

sam

per

da d

e ...

.)

1-6 7-20 21-40 41-100 101-200 201-500 501-1000

Priorizado por responsabilidade legalPriorizado por responsabilidade legal

Metodologias diferentes para diferentes ocasies(tamanho do projeto, criticidade do sistema e prioridades)

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

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:


Tamanho da Equipe O trabalho dividido em equipes de at sete pessoas

Durao das iteraes Durao usual de quatro semanas por iterao

Equipes distribudas Como o projeto pode ser constitudo por vrias pequenas equipes, h a

possibilidade de que estas estejam distribudas (descentralizadas)

Aplicaes de alta criticidade No h meno especfica quanto aplicabilidade do mtodo

para desenvolvimento de software de alta criticidade

tabela 3. Caractersticas principais pa ra utilizao do Scrum (FONTE: COHEN et al, 2003, p.16-17.)


MEtoDoLoGIAS GEIS

a) Pr-projeto; b) Anlise de Aderncia; c) Estudo de Neg-cio; 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).


Tamanho da Equipe A famlia dos Crystal Methods acomoda equipes de qualquer

tamanho, preferencialmente compostas por pessoas talentosas

Durao das iteraes At 4 meses para projetos grandes e altamente crticos

Equipes distribudas Os Crystal Methods foram concebidos para atender ao conceito de

equipes distribudas

Aplicaes de alta criticidade Os Crystal Methods atendem a projetos crticos, incluindo aqueles

que envolvem risco de vida e de valores monetrios

tabela 4. Caractersticas principais para utilizao dos Crystal Methods (FONTE: COHEN et al, 2003, p.15.)

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 encon-tradas 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 M-todos 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; KOPPENS-TEINER, 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 se-guintes 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).

Lean Development (LD)Com razes na indstria automotiva dos anos 80, em especial

no Modelo Toyota de Produo, o Lean Development considera-do 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 comprometimen-to 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 Develop-ment 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 Ra-

pid 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 de-senvolvimento e a adaptao constante s novas realidades do negcio e do projeto. Alm disso, encoraja o desenvolvimento


Tamanho da Equipe Varivel de acordo com a complexidade das funcionalidades a

serem desenvolvidas

Durao das iteraes At 2 semanas

Equipes distribudas O FDD foi criado para trabalhar com equipes mltiplas e, apesar

de no haver indicao formal para equipes distribudas,

passvel de adaptao

Aplicaes de alta criticidade Indicado para desenvolvimento de software crtico

tabela 5. Caractersticas principais para utilizao do FDD (FONTE: COHEN et al, 2003, p.15.)


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 criativi-dade. 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 maio-res. 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 geisNos 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 pr-ticas relacionadas ao gerenciamento de projetos.

Aplicao dos Mtodos geis nas OrganizaesH uma grande variedade de Mtodos geis de Desenvol-

vimento de Software, cada qual sugerindo prticas especfi-cas, 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

Caracterstica XP Scrum Crystal Methods FDD ASD LD DSDM

Tamanho da Equipe 2-10 1-7 Varivel Varivel Varivel

No definidoDurao das iteraes 2 semanas 4 semanas < 4 meses < 2 semanas

Equipes distribudas No Adaptvel Sim Adaptvel

Aplicaes de alta criticidade Adaptvel Adaptvel Todos os tipos Adaptvel

Prticas de gerenciamento de projetos Poucas Muitas Poucas Muitas Muitas

tabela 6. Caractersticas principais dos mtodos geis selecionados (FONTE: Adaptado de COHEN et al, 2003, p. 23.)

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

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 com-patibilidade 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 neces-sidade 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. Amplian-do 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 especialis-tas. Com relao a este aspecto, apesar de concordar com a


MEtoDoLoGIAS GEIS

Enfoque Clssico Enfoque gil (Mtodos geis)

Premissa Fundamental O software totalmente especificvel e previsvel e pode ser

construdo atravs de um planejamento meticuloso e extensivo

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

feedback e na aceitao de mudanas

Estilo de Gerenciamento Comando e controle Liderana e colaborao

Distribuio de Papis Individual, favorecendo a especializao Equipes auto-organizadas, encorajando o intercmbio de papis

Papel do Cliente Importante Crtico

Modelo de Desenvolvimento Modelo de ciclo de vida Modelo em Cascata, Espiral e iterativos Mtodos geis

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

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. Cock-burn 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 compro-metidos 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 ante-riores, 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 centrali-zadas 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 desenvolvi-mento 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 inte-grantes 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 reu-nies 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 pro-cessos 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 ne-gativos 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 direciona-mento, 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 descen-tralizada, 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 de-cises 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 solicita-o de compromissos formais de entrega, mesmo sabendo que raramente estes objetivos so cumpridos pelas equipes de desenvolvimento6. Cohn e Ford (2003, p.76) e Highsmith (2004) salientam que gerentes que temem que com os Mto-erentes que temem que com os Mto-dos 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 prazo, custo e qualidade estavam usualmente errados, superestimados, ou ambos. Em organizaes com histrico de estimativas incor-retas 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 cola-borao, 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, compara-o 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, refle-tida na terceira questo, que aparentemente um projeto realizado segundo um Mtodo gil tende a no ter fim, uma

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

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, vincu-lado 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 desenvolvimen-to, os gerentes, os clientes e, at mesmo, reas ou departa-mentos 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 quan-to 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 Huma-nos 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 consi-deram 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 qual-quer 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 desenvolvimen-to 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 ex-plicitados 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;


MEtoDoLoGIAS GEIS

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-sucedi-dos; 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 do-cumentao formal em um patamar mnimo necessrio.

A forma como um Mtodo gil introduzido em uma orga-nizao e os cuidados tomados durante este processo podem determinar o sucesso ou o fracasso da iniciativa. Outro im-portante 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 as-sim despertarem interesse, pode-se partir para uma adoo parcial. Nesta estratgia, deve-se identificar os pontos de melhoria prioritrios no processo clssico de desenvolvi-mento 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 dispon-veis 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 organiza-es, 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 de-sempenho dos projetos de desenvolvimento de software quanto ao cumprimento dos objetivos de prazo e custo. Surpreendente-mente, 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.

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 respon-deram 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 produ-tividade frente aos indicadores da indstria; Reduo de custos: 5% a 7% de reduo de custos quando com-parado 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 con-cretos apontaram que a taxa de defeitos estava no mesmo nvel dos projetos anteriores quando da liberao de produtos e aplicaes.

Indstria # Empresas que utilizam Mtodos geis # de Projetos Incio da Utilizao de Mtodos geis Estgio da Implementao

Aeroespacial 1 1 2001 Descoberta

Computao 2 3 2000 Piloto

Consultoria 1 2 2000 Piloto

Comrcio Eletrnico 5 15 2000 Produo

Pesquisa 1 1 2000 Piloto

Software 2 4 2000 Produo

Telecomunicaes 2 5 2000 Produo

Total 14 31 n/a n/a

tabela 8. Caractersticas das empresas pesquisadas (FONTE: ADAPTADO DE REIFER, 2002, p. 15.)


As demais organizaes analisadas, que no possuam indi-cadores formais, mensuraram seus ganhos atravs da opinio dos principais interessados nos projetos, listando como benef-cios 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 anima-dores, 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 desenvol-vimento foi iniciado segundo uma abordagem orientada a objetos ad hoc, sendo adotado o mtodo gil Extreme Program-ming (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 desenvolvi-mento 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 NLOC / esforo # Mtodos /

esforo

# Classes / esforo

Mdia anterior ao uso do XP 10,2 0,36 0,05

Mdia com uso do XP 17 1,45 0,21

% de Variao 66,3% 302,1% 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 Ex-treme 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 dese-jados. 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 resulta-dos, 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 atri-budos, principalmente, adoo da prtica de programao em pares.

Em 2001, pesquisa conduzida pelo Cutter Consortium (COCKBURN; HIGHSMITH, 2001b), com mais de 200 profis-sionais 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 com-parado pesquisa similar realizada em 2000; Os projetos de desenvolvimento realizados segundo o en-foque 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 crtica7, voltado coordenao de equipes da Hewlett-Packard dis-tribudas 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 adapta-es 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 balan-ceamento 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 tran-quila. 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 aplica-o que visava reformulao do pagamento de bonificao s

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 quali-dade do software no for extremamente alta (TURK et al, 2005, p.29).


MEtoDoLoGIAS GEIS

empresas publicitrias, garantindo maior controle ao processo. O projeto foi iniciado segundo o enfoque clssico de desen-volvimento 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 auferin-do resultados positivos, quanto qualidade, produtividade e motivao de seus profissionais, com a adoo dos Mtodos geis para o desenvolvimento de software.

Limitaes dos Mtodos geisNeste 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 princi-pais 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), Boger et al (2001) e McBreen (2003), introduziram uma viso mais crtica, apontando limi-taes 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 an-corados, 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 defen-didos 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.

Sendo assim, para que se possa entender tais limitaes, deve-se primeiramente visualizar os pressupostos identifica-dos pelos autores (TURK et al, 2005, p. 22), que se encontram retratados na Tabela 10.

PRINCPIOS PRESSUPOSTOS

PRTICAS LIMITAES

Baseados em

Derivados de

Tm

Sustentam

So baseadas em

Levam a

PRINCPIOS PRESSUPOSTOS

PRTICAS LIMITAES

Baseados em

Derivados de

Tm

Sustentam

So baseadas em

Levam a

Figura 3. Relacionamento entre princpios, prticas, pressupostos e limitaes (FONTE: TURK et al, 2005, p. 8.)

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 pres-supostos 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, deter-minados 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 ferra-mentas 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 orga-nizar 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 mes-mas 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 volu-me 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 anda-mento 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 comple-ta 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 docu-mentao 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 reutiliz-veis. 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

Pressupostos Detalhamento

Pressuposto da visibilidade A visibilidade do projeto s pode ser alcanada atravs da entrega de um software funcionando

Pressuposto da iterao Um projeto pode ser sempre estruturado em iteraes curtas e de perodos fixos

Pressuposto da interao com o cliente A equipe do cliente est disponvel para interao frequente, quando solicitado pelos programadores

Pressuposto da comunicao da equipe Os programadores esto localizados em local que permita a comunicao frequente e intensiva entre si

Pressuposto da comunicao face a face A comunicao face a face o mtodo mais produtivo de comunicao com o cliente e entre os

programadores

Pressuposto da documentao Desenvolver uma documentao extensiva e consistente (relativamente completa) e modelos de

software contraproducente

Pressuposto da mudana dos requerimentos Requisitos sempre sofrem modificaes, devido a mudanas de tecnologia, necessidades dos

clientes, domnios de negcio ou mesmo aquisio de novos clientes

Pressuposto do custo da mudana O custo da mudana no aumenta dramaticamente com o passar do tempo

Pressuposto da experincia da equipe Os programadores tm a experincia necessria para definir e adaptar seus processos apropriadamente

Pressuposto da auto-avaliao As equipes almejam a auto-avaliao

Pressuposto da auto-organizao As melhores arquiteturas, requisitos e projetos emergem de equipes auto-organizadas

Pressuposto da garantia de qualidade A avaliao dos artefatos de software (produtos e processos) pode se restringir a entrevistas frequentes

e informais, revises e testes de codificao

Pressuposto do desenvolvimento da aplicao especfica O reuso e a generalidade no devem ser objetivos do desenvolvimento de uma aplicao especfica.

Pressuposto do redesenho contnuo O software pode ser continuamente 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.)

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 es-pecificao formal, testes intensivos e abrangentes e outras tcnicas de anlise e avaliao dos mtodos clssicos de de-senvolvimento 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 reque-rem 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 ge-ral, 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


MEtoDoLoGIAS GEIS

na documentao. Sendo assim, no desenvolvimento gil, o conhecimento tcito e reside apenas na mente de cada inte-grante 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 uti-lizado. 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 teorica-mente 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 co m 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 suces-so 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 cumpri-mento de seus objetivos.

Em 2003, um estudo de carter exploratrio desenvolvido por Lazaveric (classificado pelo prprio autor como sem si-milar 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 (LAZARE-VIC, 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 per-mitiu 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 desen-volvido 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 hiper-produtividade. O terceiro fator encontrado diz respeito entrega de um prottipo logo no incio do projeto. Para Lazarevic (Ibid.), a maioria dos respondentes interpre-tou 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 Pro-gramming (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 utili-zao 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 parti-cipantes (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 pro-fissionais 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 neces-sidade 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 Gerenciamen-to 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.

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 . 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 . Acesso em julho de 2005.

AMBLER, S. W. Quality in an agile world.

ES20_tem Artigos Com as Met Ágeis

Documents

Transcript of ES20_tem Artigos Com as Met Ágeis