A necessidade de ser gil

Uma anlise crtica sobre nove mtodos geis

TIC, FACIPE (2003). Engenheiro Qumico pela Alexandre Jos Henrique de UFPE (2001). Analista Consultor da ATI-PE, Gestor de Infraestrutura de TIC da SecretaOliveira Luna ajhol@cin.ufpe.br ria Estadual de Educao e Pesquisador do NUTES-HC-UFPE e GP2-CIn-UFPE. alexluna@mangve.org Doutorando em Cleyverson Cincia da Computao pelo Pereira Costa CIn-UFPE em Governana em TIC (em andacpc@cin.ufpe.br mento). Mestre em Cincia da Computao Mestre em Cincia da Computao pelo CInpelo CIn-UFPE em Gerenciamento de ProjeUFPE (2009). Especialista em Engenharia de tos (2009). MBA em em Teste de Software Software com nfaseGesto Estratgica de pelo CIn-UFPE (2007). Graduado em Cincia da Computao (2005). Pesquisador do GP2-CIn-UFPE. Possui experincia na rea de testes,tendo atuado como Engenheiro de Testes pelo Motorola Brazil Test Center.

Para que serve? De que se trata o artigo?

Em que situao o tema til?

Hermano Perrelli de Moura

hermano@cin.ufpe.br

Possui graduao em Engenharia Eletrnica pela Universidade Federal de Pernambuco (1982), Mestrado em Informtica pela Universidade Federal de Pernambuco (1989) e PhD in Computing Science pela University of Glasgow (1993). certificado PMP (2003) pelo Project Management Institute. Atualmente Professor Adjunto e Vice-Diretor do Centro de Informtica da Universidade Federal de Pernambuco.

u ito s autor e s c omo Ro o s malen e Hoppenbrouwers, Cummins e Sloane et al. tm dito que para sobreviver voracidade do mercado necessrio agilidade nos negcios, porm qual o significado de tal termo? Segundo o Gartner Group, agilidade de negcio estar apto a responder rapidamente e eficientemente s mudanas no mundo dos negcios e, transformar essas mudanas em vantagem competitiva o principal motivo para sua adoo.

Neste contexto, observa-se que cada vez mais organizaes esto adotando a abordagem gil como uma ttica de sobrevivncia nestes tempos economicamente turbulentos. Isto por sua vez levou a uma srie de opinies interessantes examinando quais atitudes e atributos seus times precisam para serem bem sucedidos. Sob esta tica a agilidade de negcio, reconhecida como a habilidade para mudar o sentido do ambiente e responder eficientemente e efetivamente a essa mudana, importante.

Engenharia de Software Magazine - A necessidade de ser gil

M E t o D o Lo G I A S G E I S

Acrescentar agilidade aos processos de gesto, em sua essncia j infere um maior nvel de convergncia entre as iniciativas em TIC (Tecnologias da Informao e Comunicao) e os objetivos do negcio. Contudo, outros benefcios de uma abordagem gil no contexto de negcios podem ser identificados, como, por exemplo: melhor time-to-market e aumento da velocidade de tomada de deciso, o que acaba refletindo numa maior competitividade organizacional. Neste contexto, a chave para realizar a verdadeira agilidade de negcio encorajar os executivos a pensarem nas mudanas de negcio sem se preocupar com as implicaes que as mesmas traro ao legado de TIC existente na organizao. Em outras palavras, a empresa precisa se tornar centrada no negcio e no centrada na TIC. Quando o negcio se torna centrado em si, a organizao se torna hbil a definir, criar e construir novos processos ou funes de negcio. Entretanto, para viabilizar esta viso, essencial que a TIC cumpra o seu papel de se elevar de uma abordagem puramente operacional ou ttica, para uma participao mais estratgica, colaborando de modo concreto, inclusive, nas definies dos objetivos de negcio. Desta forma acredita-se que os mtodos geis tm muito a contribuir nesta direo atravs da simplificao das iniciativas da TIC, sensibilizao e valorizao das pessoas, adoo de uma abordagem iterativa e adaptativa, aplicao prtica de seus princpios, valores, prticas e orientaes sobre sistematizao das iniciativas da gesto em TIC.

ID P1 P2 P3 P4 P5 P6 P7 P8

Princpio A prioridade a satisfao do cliente, mediante o rpido e contnuo fornecimento de software que agregue um valor ao negcio. As mudanas so bem-vindas, mesmo no final do desenvolvimento, principalmente se as alteraes daro vantagem competitiva para os nossos clientes. Fazer entregas frequentes de software que funcionem a partir de um par de semanas a um par de meses, sempre procurando o menor intervalo de tempo entre as entregas. As pessoas de negcio (executivos) e os desenvolvedores devem trabalhar juntos diariamente e ao longo de todo o projeto. Construir o projeto em torno de indivduos motivados. Fornecer todo apoio necessrio ao ambiente do projeto e confiar plenamente na equipe. O dilogo face a face a mais eficiente e eficaz forma de comunicar as informaes dentro da equipe de desenvolvimento. Software que funciona a principal medida de progresso. Os processos geis promovem um desenvolvimento sustentvel. Os promotores, usurios e desenvolvedores devem ser capazes de manter um ritmo de trabalho constante por tempo indeterminado. A ateno contnua qualidade tcnica e ao bom design melhora a agilidade. A simplicidade essencial. preciso saber maximizar o trabalho que NO deve ser feito. As melhores arquiteturas, requisitos e desenhos surgem a partir da prpria Equipe atravs de sua pr-atividade e auto-organizao (inteligncia coletiva e colaborativa1). Em intervalos regulares, a Equipe deve refletir sobre como se tornar mais eficaz, e ajustar o seu comportamento para alcanar este objetivo.

P9 P10 P11 P12

tabela 1. Princpios geis. FONTE: (BECK et al., 2001)

Engenharia de Software
Engenharia de Software uma rea do conhecimento voltada para a especificao, desenvolvimento e manuteno de sistemas de software, aplicando tecnologias e prticas da cincia da computao, gerncia de projetos e outras disciplinas, objetivando organizao, produtividade e qualidade. Pressman destaca que a Engenharia de software abrange trs componentes bsicos: Mtodos: proporcionam os detalhes de como construir o software. Englobam tarefas como planejamento e estimativa de projeto, anlise de requisitos de software e de sistemas, projeto da estrutura de dados, arquitetura de programa e algoritmo de processamento, codificao, teste e manuteno; Ferramentas: existem para sustentar cada um dos mtodos. Algumas ferramentas existentes para apoio so as ComputerAided Software Engineering, conhecidas como ferramentas CASE; Procedimentos: constituem o elo entre mtodos e ferramentas. Definem a sequncia em que os mtodos so aplicados. Desde ento vem prosperando o aparecimento de diversos mtodos, tcnicas e ferramentas para aperfeioar os processos de desenvolvimento de software em todo o mundo. Mesmo com toda esta evoluo, a Engenharia de Software h muito vinha enfrentando problemas relativos a atraso na entrega de projetos, oramento extrapolado, insatisfao de clientes e usurios, alm de conflitos e desgastes entre analistas e

clientes. Isso se dava, dentre outros fatores, principalmente em funo dos mtodos disponveis para o desenvolvimento de software mostrarem-se pesados e burocrticos, ineficientes e improdutivos.

O Manifesto gil
Sob este contexto e percepo, em 11 de fevereiro de 2001, um grupo de profissionais e pesquisadores de TI se reuniram com a finalidade de criar uma mobilizao em torno de uma srie de valores e prticas de desenvolvimento de software que eles intitularam de Manifesto for Agile Software Development. A s s i m , os d ez e s s e t e p r e s e nt e s a s s i n a ra m o s eg u i nt e manifesto: Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar: Indivduos e interao entre eles mais que processos e ferramentas Software em funcionamento mais que documentao abrangente Colaborao com o cliente mais que negociao de contratos Responder a mudanas mais que seguir um plano Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda. Este Manifesto tambm enuncia os doze princpios de um processo gil, como podem ser vistos na Tabela 1.

Mtodos geis
Neste contexto e visando a melhores resultados, as empresas de TIC esto adotando metodologias de desenvolvimento de

Edio 37 - Engenharia de Software Magazine

software mais flexveis e propcias s frequentes mudanas, alm de mais interao durante todo o projeto entre os usurios e o prprio sistema. Estas metodologias so chamadas de geis em contraposio s metodologias pesadas que, tradicionalmente, predominaram na rea, mas que se mostraram ineficientes e improdutivas (FERREIRA e LIMA, 2006). Uma premissa fundamental das metodologias geis o reconhecimento da dificuldade do usurio saber de antemo as funcionalidades que gostaria que o sistema tivesse. Por isso, essas metodologias adotam a estratgia de criar condies favorveis para as interaes e as retroalimentaes entre usurios e Equipe durante todo o projeto. Com isso, as metodologias geis so estruturadas de modo a atender a natureza mutvel e dinmica do processo de construo de software. As metodologias geis propem que os projetos devam ser conduzidos de forma adaptativa, isto , feito atravs de desenvolvimento iterativo e interativo. A ideia central trabalhar com iteraes curtas. Cada iterao entrega ao seu final um produto completo e pronto para ser usado, que contm a implementao de um novo subconjunto de caractersticas. O uso de iteraes curtas permite aos usurios e clientes fazerem uma avaliao do software logo que uma verso inicial colocada em produo. importante salientar que uma das vantagens das metodologias geis em contraposio s metodologias tradicionais a flexibilidade que estas possuem quando inseridas em ambientes que tm caractersticas como: definio dos requisitos com grande volatilidade (mudanas constantes), onde as equipes so pequenas e os prazos so mais curtos, o que por fim caracteriza a necessidade de um desenvolvimento rpido. Dentre as metodologias geis mais difundidas pode-se citar o XP e o SCRUM. Contudo, podemos citar tambm: XPM Extremme Project Management, APM Agile Project Management, FDD - Feature Driven Development, famlia Crystal, DSDM - Dynamic System Development Method, ASD - Adaptative Software Development, dentre outras. Nas sees seg uintes, como resultado de um processo de reviso sistemtica, sero exploradas cada uma destas

metodologias e visitados seus princpios, valores e prticas. No entanto, em funo dos modelos SCRUM e XP j serem bastante conhecidos, os demais modelos sero abordados com maior nfase.

eXtreme Programming XP
O eXtreme Programming ou XP um modelo gil de desenvolvimento de software criado em 1996 por Kent Bech no Departamento de Computao da montadora de carros Daimler Chrysler. Ele possui muitas diferenas em relao a outros modelos, podendo ser aplicado a projetos de alto risco e com requisitos dinmicos (vagos ou em constante mudana), conduzidos por equipes de tamanho mdio e pequeno. Como todo mtodo gil, o XP procura responder com velocidade s mudanas nas especificaes do projeto, com base em princpios, valores e prticas bem definidos. Este mtodo enfatiza o desenvolvimento rpido garantindo a satisfao do cliente e cumprindo as estimativas do projeto. O XP baseia-se em cinco valores para guiar o desenvolvimento: Comunicao, Coragem, Feedback, Respeito e Simplicidade. Segundo Beck, o mtodo oferece ainda 12 prticas, a saber: i) Jogo do planejamento; ii) Verses pequenas; iii) Metfora; iv) Projeto simples; v) Teste; vi) Refatorao; vii) Programao em pares; viii) Propriedade coletiva do cdigo; ix) Integrao contnua; x) 40 horas de trabalho semanal; xi) Cliente presente; e xii) Padres de codificao. A Figura 1 demonstra uma representao do processo do XP, incorporando as prticas, princpios e valores. A comunicao um dos principais valores do XP que visa incentivar uma melhor integrao entre clientes e desenvolvedores, encorajando a interao e o relacionamento interpessoal. Segundo Nawrocki et al. (2002), com o incentivo na participao do cliente no projeto e a liberao de verses frequentes, existe uma probabilidade menor de ocorrncia de erros, assim como permite ao time a antecipao soluo de muitos problemas. A questo da manuteno de sistemas produzidos a partir de um projeto XP bastante questionada quanto sua eficcia devido a pouca documentao pregada pela metodologia. Neste contexto, Nawrocki relata que as fontes de conhecimento em projetos XP so: o cdigo fonte, os casos de teste e a memria dos programadores. O risco em relao a pouca documentao est na perda de memria que ocorre naturalmente quando h sada de desenvolvedores do time, o que se torna um fator mais crtico no caso da manuteno de projetos mais antigos. Nawrocki afirma, ainda, que neste caso, a nica base para a manuteno so o cdigo fonte e os casos de teste.

SCRUM
Figura 1. Fluxo de trabalho em um projeto XP. FONTE: (SIQUEIRA, 2002)

O termo Scrum vem de um estudo feito por Takeuchi e Nonaka (1986). Como resultado deste estudo, foi percebido

10

Engenharia de Software Magazine - A necessidade de ser gil

M E t o D o Lo G I A S G E I S

que projetos de curta durao, usando equipes pequenas e multidisciplinares (cross-functional), produzem melhores resultados. O framework Scrum tem como objetivo, segundo Schwaber, definir um processo para projeto e desenvolvimento de software orientado a objeto, que seja focado nas pessoas e que seja indicado para ambientes em que os requisitos surgem e mudam rapidamente. O Scrum tambm considerado um mtodo especfico para o gerenciamento do processo de desenvolvimento de software. Seu ciclo de vida baseado em trs fases principais. A fase de pr-planejamento, desenvolvimento e a fase de psplanejamento. O pr-planejamento dividido em duas fases secundrias: a fase de planejamento e a de arquitetura do projeto. No Scrum, todo o desenvolvimento feito em iteraes: todo o esforo orientado para que seja apresentado um novo conjunto de funcionalidades ao final de cada iterao, denominada de sprint, para a qual sugerida uma durao de duas a quatro semanas. A Figura 2 apresenta, de forma simplificada, o desenvolvimento de um projeto utilizando o Scrum. O Scrum define trs papis distintos: 1) Equipe responsvel por entregar solues, geralmente formada por um grupo pequeno (entre cinco e nove pessoas) e que trabalha de forma auto-gerenciada; 2) Product Owner responsvel pela viso de negcios do projeto, ele quem define e prioriza o Product Backlog. Geralmente o papel desempenhado pelo cliente; 3) Scrum Master uma mistura de gerente, facilitador e mediador. Seu papel remover obstculos da equipe e assegurar que as prticas de Scrum esto sendo executadas com eficincia. O desenvolvimento do produto, baseado no Scrum inicia com a definio do Backlog pelo Product Owner. Posteriormente o projeto organizado em Sprints e o Product backlog dividido em Sprint Backlogs para que os itens selecionados possam ser desenvolvidos. Ao final da Sprint, a Equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e ento possa se iniciar um novo Sprint.

Figura 2. Ciclo de Vida do Scrum. FONTE: (MOUNTAIN GOAT, 2009)

eXtreme Project Management - XPM

O XPM, ou eXtreme Project Management, prope melhorar o gerenciamento de projetos desenvolvidos segundo o paradigma gil, com nfase no XP. Este mtodo visa em especial os e-projects, ou seja, projetos de software para os quais o tempo e o custo para tornar o produto disponvel no mercado so crticos. A principal diferena do XPM est na atitude em relao s mudanas. Diferentemente da abordagem tradicional, na qual o planejamento direciona os resultados, no XPM so os resultados que direcionam o planejamento, sendo necessrio facilitar a mudana e no desencoraj-la. Segundo BECK, o mtodo definido por 11 regras, descritas a seguir: 1. A gerncia de pessoas e de processos criativos demanda processos de gerenciamento criativos. Tanto gerente quanto a equipe precisam ser criativos no desenvolvimento de um produto inovador, com alto valor para o negcio e maior qualidade;

2. O contexto mais importante do que o contedo. O gerente de projetos no XPM deve estar focado no aspecto empresarial do projeto, ou seja, nos objetivos e nos benefcios do projeto, ao invs dos aspectos tcnicos do produto ou servio que est sendo realizado no projeto; 3. Ciclo de vida do projeto inclui perodo ps-implantao. O que acontece depois que o projeto termina mais importante do que os problemas que acontecem durante o projeto; 4. O gerente de projetos deve ter o perfil mais facilitador e integrador do que o perfil de gerente. Para aumentar as chances de sucesso de um projeto empresarial, o gerente de projetos deve mudar o foco do planejamento tcnico para a facilitao e a integrao do processo de planejamento, com a participao efetiva dos stakeholders; 5. Quanto mais tempo o gerente de projeto permanecer com os stakeholders, melhor. O XPM est mais relacionado ao contexto do projeto no que diz respeito disseminao da informao gerencial do negcio, do que com o seu contedo no que diz respeito s especificaes tcnicas e entregas; 6. Stakeholders funcionam como Gerente Executivo de Projetos. No XPM, os stakeholders devem ter as seguintes responsabilidades adicionais: i) participar das sesses de planejamento do projeto que definem escopo, objetivos, stakeholders e benefcios; ii) assistir o Gerente de Projetos nas disputas polticas e de poder na organizao que influenciam o projeto; e iii) monitorar indicadores crticos do projeto, de custos e de prazo; 7. Se o sucesso do projeto no foi definido no comeo, ele no ser alcanado no final. O sucesso em um projeto est geralmente associado a: i) satisfazer os stakeholders; ii) atingir as exigncias de escopo; iii) permanecer dentro do oramento e dos prazos estabelecidos; iv) agregar valor ao negcio; v) assegurar uma boa qualidade ao produto; e vi) deixar os membros da equipe satisfeitos. Os critrios de sucesso devem ser definidos logo de incio e acompanhados durante todo o desenvolvimento; 8. Planejamento por cenrio ao invs de macroplanejamento. Grande parte dos projetos empresariais possui o nvel de incerteza muito alto, assim como o ritmo de mudanas. Por isso, fazer o planejamento detalhado das fases do projeto fornece uma alta probabilidade de retrabalho e constante replanejamento; 9. Lucro ao invs de papelada burocrtica. No XPM, a documentao a mnima necessria para o desenvolvimento e o acompanhamento do projeto. O importante modelar e

Edio 37 - Engenharia de Software Magazine

11

apresentar o valor agregado de acordo com a qualidade requerida e buscar o equilbrio entre a necessidade de negcio que est sendo atendida e o retorno de investimento que isso traz ao negcio. Mostre os lucros aos stakeholders e nada mais importa; 10. Se o seu projeto no mudou, fique apreensivo. Gerente e equipe devem reunir-se diariamente para avaliar se houve alterao em expectativas de sucesso, escopo, objetivos, riscos, qualidade, stakeholders ou projetos relacionados, bem como verificar se suposies referentes a custo e benefcio continuam pertinentes; 11. Em e-projects, um dia um tempo muito longo. O gerenciamento efetivo de e-projects demanda uma abordagem nova e radical para o gerenciamento de projetos.

Agile Project Management - APM

A abordagem APM - Agile Project Management foi desenvolvida por um grupo de gerentes de vrios projetos XP bem sucedidos da CC Pace Systems. Em sua concepo eles consideraram que a adoo ainda lenta das metodologias geis origina-se principalmente da falta de alinhamento entre as suposies fundamentais da gerncia tradicional e das metodologias de desenvolvimento geis. Tambm alertaram para a necessidade de mudana em relao a estas suposies, propondo o desenvolvimento de um novo framework para o apoio gerencial ao desenvolvimento gil. Na busca deste novo framework, eles passaram a acreditar fortemente na adoo de princpios que explorassem a compreenso do comportamento humano autnomo, adquirida a partir do estudo de sistemas vivos existentes na natureza como revoadas, cardumes e enxames , incluindo nas suposies e prticas de gerncia a noo de sistemas adaptativos complexos (Complex Adaptive Systems CAS). Apesar destes sistemas possurem somente regras e capacidade estratgicas no contexto do prprio sistema (ou grupo em anlise), seu comportamento coletivo caracterizado por uma superposio de ordem, auto-organizao e uma inteligncia coletiva que maior que a soma das partes, alm de regularmente exibirem uma habilidade notvel para se adaptarem a ambientes complexos e dinmicos. Por exemplo, em uma equipe XP, os gerentes de projeto tambm precisam de um conjunto de prticas simples que os guiem, que forneam um framework dentro do qual possam administrar, e no de um conjunto de instrues rgidas. Seguindo estas prticas, o gerente torna-se um lder com capacidade de adaptao, capaz de fixar uma direo, estabelecer regras simples e geradoras do sistema, bem como encorajar uma constante avaliao (feedback), adaptao e colaborao. O framework para gerncia de projeto gil baseado em CAS composto por seis prticas-chave que, juntas, ajudam a administrar equipes de desenvolvimento como sistemas adaptveis complexos, ao mesmo tempo em que proporcionam liberdade para sobrepor estilos prprios de liderana pessoal. Uma descrio resumida destas prticas apresentada a seguir: 1. Viso Direcionada Estabelea uma viso direcionadora para o projeto e reforce-a continuamente, por meio de palavras e aes. importante transmitir e manter no time sempre a viso do todo,

para que seja mais fcil para cada um compreender, transmitir e mesmo supervisionar a produo das partes e a sua integrao na formao do todo. A viso precisa ser sempre difundida, atualizada e preservada de agentes internos ou externos ao time; 2. Trabalho e Colaborao em Equipe Facilite a colaborao e o trabalho em equipe reforando relacionamentos. Quando o trabalho conjunto aprimora e refora os potenciais individuais complementares, os resultados obtidos podem ser excepcionais. Contudo, conseguir que as pessoas trabalhem de forma colaborativa um desafio e no pode acontecer por imposio; 3. Regras Simples Estabelea e apoie um conjunto de prticaschave (guias). Estabelea e fomente um conjunto de prticas simples que possam fornecer suporte para um comportamento complexo, permitindo equipe trabalhar dentro de uma estrutura flexvel; 4. Informao Aberta Fornea acesso aberto informao. O compartilhamento da informao e o sentimento de propriedade coletiva potencializam os resultados alcanados pela equipe; 5. Toque leve Aplique somente o controle suficiente para manter a ordem emergente. O controle inteligente de equipes requer uma sutil combinao de ordem imposta e emergente; 6. Vigilncia gil Aplique um contnuo monitoramento, aprendizado e adaptao ao ambiente. O trabalho mais criativo e gil ocorre no limiar entre a ordem e o caos imprevisvel o bastante para ser desafiador, mas ordenado o suficiente para no sair de controle.

easY Process - YP
O Departamento de Sistemas e Computao da Universidade Federal de Campina Grande (UFCG) criou em maio de 2003 o easY Process - YP, um processo de software mais simplificado que se apoia em prticas do XP, RUP e Agile Modeling. A necessidade de se criar um novo processo surgiu devido s dificuldades encontradas em se adaptar os processos j existentes para o uso na academia. O Fluxo bsico est ilustrado na Figura 3. Os tempos apresentados nos retngulos desta figura denotam os tempos estimados pelo YP para o avano de cada etapa do processo. A primeira etapa do processo consiste na definio de papis. O YP sugere os seguintes papis: cliente, usurio, testador, desenvolvedor e gerente; podendo uma mesma pessoa desempenhar mais de um papel dentro do processo, principalmente quando se tratam de equipes de desenvolvimento pequenas. Em seguida deve ser realizada uma conversa com o cliente, onde informaes sobre o escopo do problema so capturadas. A partir de ento, a equipe encontra-se apta a gerar o documento de viso, que aps ser validado pelo cliente, funciona como um acordo de trabalho entre cliente e equipe de desenvolvimento. Na fase de inicializao o cliente define as User Stories e so elaborados o projeto arquitetural e o modelo lgico de dados este ltimo apenas se necessrio. O cliente deve priorizar as User Stories e a equipe deve fazer uma estimativa inicial do tempo para implementao de cada uma delas. Baseado nessa estimativa pode-se ento verificar a viabilidade de

12

Engenharia de Software Magazine - A necessidade de ser gil

M E t o D o Lo G I A S G E I S

desenvolvimento do projeto no escopo e tempo definidos. Parte-se ento para o Planejamento, fase composta por dois planos, o de release e o de iterao. Ambos possuem tempo fixo com variao de escopo permitida. Tratando-se do ambiente acadmico so sugeridos trs releases, cada um com duas iteraes de duas semanas, por semestre letivo. O planejamento de um release s ocorre aps o trmino do anterior, e da mesma forma para as iteraes. No planejamento de release alocaram-se as User Stories de acordo com a priorizao do cliente. No planejamento de iterao as User Stories alocadas so quebradas em tarefas, e o cliente deve definir os testes de aceitao para cada User Story. Para auxlio na Figura 3. Fluxo do YP. FONTE: (YP, 2006) gerncia o processo faz uso da Tabela de Alocao de Tarefas (TAT), na qual se especificaram as User Stories parte iterativa dos processos de FDD (projetar por caracterstienvolvidas, tarefas, responsveis, estimativas de tempo, tempo ca e construir por caracterstica) suporta o desenvolvimento real consumido e status da tarefa. Estes dois ltimos atributos gil com adaptaes rpidas s mudanas, de acordo com as so preenchidos apenas no fechamento da iterao. exigncias e as necessidades do negcio. As iteraes do projeto Segundo Garcia, algumas caractersticas importantes do YP e a construo de uma caracterstica (feature) seguem por um so: perodo de uma a trs semanas de trabalho. Participao efetiva do cliente: fator imprescindvel para o A seguir esto descritos sucintamente os cinco processos ilussucesso do projeto; trados na Figura 4. Papis diferentes desempenhados pela mesma pessoa: neces Processo 1: Desenvolver um modelo abrangente Os srio quando se trabalha com equipes pequenas; membros de um projeto devem estar cientes do contexto e das Releases e iteraes curtas: tratando-se do ambiente acadmico exigncias do sistema a ser construdo logo no incio do desenso sugeridos trs releases, cada um com duas iteraes de duas volvimento do projeto. Isso alcanado por meio de casos de uso semanas; ou especificaes funcionais exigidos neste processo; Variao no escopo e no no tempo, tanto no release quanto Processo 2: Construir uma lista de Caractersticas A na iterao. Este um princpio baseado no paradigma gil que equipe identifica as caractersticas, agrupa-as hierarquicamente considera fixos o tempo e os recursos e permite variar dentro de e atribuem prioridades e tamanho. Entre as tarefas deste prouma iterao o escopo; cesso incluem a formao da equipe que ir projetar a lista de Forte enfoque nos testes, em boas prticas de programao, caractersticas; propriedade coletiva de cdigo e refatoramento; Processo 3: Planejar por Caractersticas Um plano de projeto Acompanhamento do progresso do projeto atravs de mtricas construdo e usado nos processos seguintes, determinando a pr-definidas (user stories alcanadas, classes produzidas, testes sequncia de desenvolvimento com as prioridades e as datas que cada caracterstica deve ser completada; realizados) reunidas no Big Chart; Processo 4: Projetar por Caractersticas Um pequeno Manuteno do repositrio de cdigo com ferramentas de grupo de caractersticas selecionado do conjunto de caraccontrole de verso. tersticas. Deste grupo so identificadas as classes que esto envolvidas e os seus respectivos proprietrios. Cada caracteFeature Driven Development FDD rstica selecionada ir passar por esta etapa, em que a equipe Criado por Jeff de Luca e Peter Code, o FDD um mtodo gil de caractersticas define um diagrama de sequncia detalhado e adaptvel ao sistema. Este mtodo no cobre o processo inteiro para ela. Os proprietrios das classes estruturam suas classes de desenvolvimento do software, mas focaliza-o particularmente e mtodos. No final a equipe faz uma inspeo no projeto. Enno projeto e nas fases de construo. tre as tarefas deste processo incluem a formao da equipe de O FDD incorpora o desenvolvimento iterativo e as melhoprojeto e a definio de um guia de domnio, a construo do res prticas da modelagem gil. Os aspectos de qualidade diagrama de sequncia, a estruturao das classes e mtodos e so enfatizados durante todo o processo de desenvolvia inspeo do projeto; mento, i nclu i ndo ent regas f requentes e ta ng veis, bem Processo 5: Construir por Caractersticas Neste processo como monitorao do progresso do projeto no perodo de so realizados a implementao das classes e mtodos, a insdesenvolvimento. peo do cdigo, os testes de unidade e o desenvolvimento de FDD possui cinco processos sequenciais durante o projeto e cada caracterstica ou conjunto delas. o desenvolvimento do sistema, como ilustrado na Figura 4. A

Edio 37 - Engenharia de Software Magazine

13

Em relao s prticas definidas no FDD, elas no so extremamente rgidas, pregando a adaptao ao ambiente de desenvolvimento. No entanto, existe um conjunto de prticas que so fundamentais e que definem o FDD: Modelagem em objetos de domnio: construir um diagrama de classes bsico com os objetos de domnio e suas relaes, definindo assim uma arquitetura bsica para o modelo do sistema; Desenvolvimento por caractersticas: a implementao deve ser orientada pelas caractersticas; Autoria individual: o cdigo de autoria de um dono da classe, o que permite uma maior rapidez na implementao das tarefas associadas; Times da caracterstica: para a implementao de uma determinada caracterstica, o chefe programador recruta os donos das classes que sero usadas. Esse grupo de pessoas o time da caracterstica; Inspees: o meio atravs do qual ocorrem as verificaes de qualidade do cdigo e do projeto; Integrao (build) regular: em um determinado perodo de tempo fixo devem ser integradas as caractersticas j terminadas, permitindo a verificao de erros e tambm criando uma verso atual que pode ser demonstrada ao cliente; Gerncia de configurao: visa gerenciar todo o ciclo de vida dos itens de configurao do projeto, realizando o controle de verses de todos os artefatos criados; Reportar/ Visibilidade dos resultados: permitir que se conhea o progresso do projeto.

Famlia Crystal
Criado por Alistair Cockburn, a famlia de mtodos Crystal prioriza a comunicao entre os participantes do projeto e inclui um nmero diferente de mtodos que atendem projetos

com caractersticas distintas. A famlia Crystal formada por: i) Crystal Clear; ii) Crystal Yellow; iii) Crystal Orange; iv) Crystal Red; e v) Crystal Orange/Web. A escolha de um mtodo deve ser baseada no tipo de projeto. A dimenso e o tamanho de um projeto so representados por smbolos, onde cada um denota uma categoria que especifica o tipo de projeto com relao ao tamanho e a complexidade. A Figura 5 apresenta a distribuio dos mtodos da famlia Crystal a partir da anlise de duas dimenses: a criticidade do produto a ser construdo pelo projeto versus a quantidade de colaboradores envolvidos. Conforme as cores dos membros da famlia Crystal se tornam mais escuras, tem-se um maior peso dos mtodos, o que necessrio devido complexidade dos projetos. Esse peso representado pela quantidade de artefatos e a rigidez da gerncia, itens que so absorvidos entre os 13 elementos definidos para cada mtodo: papis, habilidades, times, tcnicas, atividades, processos, artefatos, produtos de trabalho, padres, ferramentas, personalidades, qualidade e valores da equipe. As regras, caractersticas e valores so comuns em todos os mtodos da famlia Crystal. Segundo Cockburn, dois valores prprios da famlia Crystal so a alta tolerncia e o fato de ser centrada em comunicao e pessoas. A tolerncia relacionase ao comportamento humano com relao s ferramentas e produtos de trabalho utilizados em um projeto Crystal. Segundo Cockburn, os princpios do Mtodo da Famlia Crystal so os seguintes: O time pode reduzir o trabalho em produtos intermedirios, para produzir cdigo rodando mais frequentemente, atravs do uso de canais de comunicao mais ricos entre as pessoas, como o contato face-a-face; Como cada projeto diferente e evolui ao longo do tempo, o conjunto de prticas que a equipe adota tambm deve ser adaptado e evoludo; Os gargalos de mudana no software determinam a utilizao do trabalho sobreposto (aquele que realizado por pessoas distintas do time) e apontam os detentores de informao sobre o projeto. Ou seja, fica fcil identificar quais pessoas do time detm informaes essenciais sobre o projeto e gerenci-los. As duas regras comuns Famlia Crystal, so: O projeto precisa usar desenvolvimento incremental, com incrementos de quatro meses ou menos (com forte preferncia a incrementos de um a trs meses); O time precisa realizar oficinas de reflexo pr e ps-incremento (com forte preferncia para a realizao de oficinas no meio do incremento, tambm). Em outras palavras, antes, durante e aps a finalizao de cada iterao. As duas tcnicas base em Crystal so: A metodologia refinada pela tcnica: usando entrevistas de projeto e oficinas com a equipe para converter e aperfeioar a metodologia de referncia em um conjunto de regras prticas para a conduo do projeto. Estas regras devero ser aperfeioadas pelo time na medida em que o projeto avana;

Figura 4. Processos FDD. FONTE: adaptado de (ABRAHAMSSON et al., 2002)

Figura 5. A distribuio dos mtodos da famlia Crystal a partir de duas dimenses. FONTE: Adaptado de (COCKBURN, 2000)

14

Engenharia de Software Magazine - A necessidade de ser gil

M E t o D o Lo G I A S G E I S

A tcnica usada para aplicar as oficinas de reflexo, que devem ser refinadas pelo prprio time. Ainda de acordo com Cockburn, o time pode substituir as tcnicas acima por outras que julgar melhor no apoio para o cumprimento das suas metas. O cerne da filosofia Crystal considerar o desenvolvimento de software como um jogo cooperativo de inveno e comunicao, com o objetivo principal de fornecimento til de software. Duas consequncias dessa filosofia so que diferentes projetos precisam ser executados de forma diferente, e a quantidade de modelagem e de comunicao que as pessoas precisam fazer apenas a quantidade de que necessitam para fazer o jogo progredir. Os membros da famlia Crystal compartilham: i) valores e princpios; e ii) adaptao on-the-fly, ou seja, ajuste da forma de trabalho durante a execuo do projeto. Uma crtica comum a esta metodologia o excesso de simplicidade, de forma que para grandes projetos recomenda-se o uso de mtodos geis com mais recursos, como por exemplo, o ASD (Adaptative Software Development).

usada para prover um melhor entendimento do problema e da soluo; Prototipao: forma de verificar a adequao dos requisitos e facilitar as discusses com o cliente. O prottipo criado deve evoluir juntamente com o projeto; Teste: essa atividade deve ser executada sistematicamente e de forma contnua durante o projeto; Gerncia de configurao: essencial, visto que os produtos so entregues com uma grande frequncia. Em relao ao processo do DSDM, existem cinco fases bsicas, que podem ser vistas na Figura 6, antecedidas por uma fase de pr-projeto e precedidas pelo ps-projeto. No pr-projeto, tem-se como objetivo definir se o projeto deve ou no ser implementado, observando aspectos gerenciais bsicos, como questes financeiras e um plano para o estudo de viabilidade. O estudo de viabilidade em si feito na etapa seguinte, em que se verifica se o DSDM a soluo mais adequada, alm das atividades tradicionais em um estudo desse tipo. Na etapa seguinte, de estudo do negcio, so observados os processos que sero afetados e as suas necessidades de informao (DSDM, 2003), definindo o escopo do projeto. Posteriormente iniciado o desenvolvimento em si, que executado de forma interativa em cada uma das trs fases seguintes: modelagem funcional, projeto e construo e implementao. Como a transio entre essas fases algo bastante complicado, a deciso de quando e como isso deve acontecer acaba sendo feita de projeto a projeto, podendo haver sobreposio e mescla entre elas. Alm disso, a qualquer momento pode haver um refinamento do projeto, fazendo com que se volte a fases anteriores para corrigir problemas, solucionar dvidas, etc. Na primeira fase de desenvolvimento, que cuida do modelo funcional, os requisitos (funcionais e no funcionais) so obtidos, montando uma lista de prioridades e colocando-os no prottipo. Em seguida documentada a maioria dos requisitos dessa forma (visual), atravs de esboos de tela, ao invs da especificao textual. Na fase de implementao feita a transio do sistema do ambiente de desenvolvimento para o operacional, cuidando do treinamento e outras tarefas que sejam necessrias. Ao finalizar as etapas de desenvolvimento com um resultado satisfatrio na realizao dos requisitos, chega-se a fase de psprojeto. Nela feita a manuteno do sistema, realizando as tarefas de alterao praticamente da mesma forma que foi feito o desenvolvimento. A equipe em um projeto DSDM, segundo Abrahamsson et al. (2002), pode variar entre duas a seis pessoas, podendo existir vrias equipes pequenas em um projeto. Em uma equipe de duas pessoas deve existir pelo menos um usurio e um colaborador.

Dynamic Systems Development Method DSDM

O Dynamic Systems Development Method - DSDM uma formulao dos mtodos RAD (Rapid Application Development) organizada por um consrcio de companhias membros que, alm de fornecer servios e treinamentos, tambm cuida do licenciamento de uso do mtodo. As ideias principais do DSDM podem ser observadas no conjunto de princpios que foram definidos para nortear o mtodo: O envolvimento ativo do usurio imperativo; O time deve ter o poder para tomar decises; O foco na entrega frequente de produtos; O encaixe ao propsito do negcio o critrio essencial para a aceitao das entregas; O desenvolvimento iterativo e incremental necessrio para convergir com preciso s solues do negcio; Toda s a s muda n a s du ra nte o de s envolv i mento so reversveis; Requisitos so alinhados em um alto nvel; O teste integrado por todo o ciclo de vida; Uma abordagem colaborativa e cooperativa entre as partes envolvidas essencial. Alm desses princpios, existem algumas tcnicas principais que so usadas durante a execuo de um projeto usando DSDM: Time-box: definio de um perodo fixo para a execuo do projeto, colocando at datas de entrega. Com isso, caso haja alguma funcionalidade que no possa ser implementada durante o perodo estipulado, ela deve ser feita aps o desenvolvimento em si (antes da fase de ps-projeto); MoSCoW: regra bsica para a priorizao de requisitos durante o perodo de desenvolvimento. A ideia fundamental priorizar e implementar os requisitos que sejam considerados principais, deixando os menos importantes para depois; Modelagem: no deve ser uma atividade burocrtica, sendo

Adaptative Software Development ASD

Criado por Jim Highsmith, o mtodo Adaptative Software Development baseia-se tambm em prticas derivadas do RAD, orientando o desenvolvimento para aceitar as mudanas. Este mtodo tem seu foco voltado principalmente para resolver problemas no desenvolvimento de sistemas grandes e complexos.

M E t o D o Lo G I A S G E I S

Edio 37 - Engenharia de Software Magazine

15

O mtodo incentiva fortemente o desenvolvimento incremental, iterativo e com prototipao constante. Sob esse panorama, o ASD prope atualizar o ciclo de desenvolvimento baseado em planejar, projetar e construir, trocando-o por um com as fases de especular, colaborar e aprender. Essa mudana seria necessria devido ao enfoque diferente dos dois ciclos: o primeiro considera a estabilidade no ambiente de negcios, enquanto o segundo foca em ambientes de incerteza e de grande mudana viso comum a todos os mtodos geis. O processo de desenvolvimento guiado por meio de ciclos, compostos por trs fases: especulao, colaborao e aprendizado. Segundo Highsmith, o ASD permite mudanas no projeto, no visualizando as mudanas como um problema, mas sim como uma vantagem. A no resistncia a mudanas enfatiza uma caracterstica dos mtodos geis, que ser adaptativo. Na Figura 7 apresenta-se o ciclo de vida do mtodo ASD. Na fase de especulao realizado o planejamento do projeto, a fase de colaborao apoia a equipe de trabalho nas mudanas do projeto e a fase de aprendizado representa o conhecimento envolvido no projeto, enfatizando o reconhecimento de erros e mudanas durante o desenvolvimento. O enfoque no ciclo ASD mais voltado aos resultados com qualidade, do que s tarefas a serem desempenhadas. As tarefas representam as atividades existentes para o desenvolvimento das funcionalidades. Na Figura 7 apresentam-se as fases do ciclo de vida do mtodo ASD. A primeira fase define a atividade para a iniciao do projeto e a atividade responsvel pelo ciclo de desenvolvimento adaptvel (fase de especulao). A fase de colaborao possui uma atividade utilizada para o desenvolvimento do componente (mdulo) e a fase de aprendizado engloba as atividades de reviso, qualidade e liberao de verses. Na fase de aprendizado

existe um retorno que vai da atividade de reviso de qualidade e volta para a atividade de ciclo adaptvel da fase de especulao, o que representa o ciclo de aprendizado do mtodo. Os ciclos duram em mdia de quatro a oito semanas. O ciclo ASD possui seis caractersticas bsicas que devem ser seguidas em um projeto. Essas caractersticas so apresentadas a seguir: Conduzido misso - as atividades em cada ciclo de desenvolvimento devem ser ajustadas de acordo com o projeto; Baseado em mdulos as atividades no devem ser orientadas a tarefas, mas de preferncia ao desenvolvimento do software, construindo pequenas verses em pequenos perodos; Iterativo o desenvolvimento deve ser bem compreendido e bem definido; Quadro do tempo a ambiguidade em projetos complexos com relao a prazos pode ser evitada com o uso de histricos de projetos anteriores. A gerncia do projeto fora os participantes a tomarem decises inevitveis no incio do projeto; Dirigido aos riscos as mudanas so frequentes no desenvolvimento do software e devem ser avaliadas constantemente para sua adaptao; Tolerante a mudanas as mudanas que proporcionam risco ao projeto devem comear o mais rpido possvel. O ASD prope poucas prticas para o trabalho de desenvolvimento do software, sendo basicamente trs: desenvolvimento iterativo, planejamento (baseado em mdulos) e revises de grupo voltadas para o cliente. Neste mtodo existem poucas prticas para o dia-a-dia do trabalho do time. Basicamente sugerido: i) desenvolvimento iterativo; ii) desenvolvimento e planejamento baseado em funcionalidades (e componentes); iii) avaliaes de grupo com foco no cliente. De fato, talvez o mais significativo problema com ASD seja que suas prticas se tornam difceis de identificar e deixam muitos detalhes em aberto.

Anlise Comparativa
Cada mtodo gil possui caractersticas que influenciam no funcionamento e no desenvolvimento do projeto de software. Algumas caractersticas podem ser encontradas em vrios mtodos e outras so especficas de cada um.
Desenvolvimento dirigido por planejamento Desenvolvedor com habilidades variadas Nveis de capacidade do cliente podem variar Figura 6. O Processo DSDM. FONTE: Adaptado de (DSDM, 2003) Abordagem gil Desenvolvedor gil, educado, disposto e colaborador Clientes mais representativos e autorizados

Confiana em conhecimento documentado, explcito Confiana em conhecimento interpessoal,tcito Requisitos conhecidos e altamente estveis Projetado para requisitos atuais e previsveis Retrabalho e reestruturaes de cdigo so caros Equipes e produtos maiores Premia a garantia da qualidade obtida Requisitos emergentes, mudana rpida Projetado para requisitos atuais Retrabalho e reestruturaes de cdigo so baratos Equipes e produtos menores Premia o valor rpido obtido

Figura 7. Ciclo de vida do ASD. FONTE: Adaptado de (HIGHSMITH, 2002b).

tabela 2. Comparao entre os pressupostos do desenvolvimento dirigido por planejamento e da abordagem gil. FONTE: Adaptado de (MAGALHES et al., 2005)

16

Engenharia de Software Magazine - A necessidade de ser gil

M E t o D o Lo G I A S G E I S

Mtodos XP SCRUM XPM

Pontos chave Desenvolvimento dirigido pelo cliente, equipes pequenas e verses frequentes. Enxuto, auto-organizvel, ciclo de desenvolvimento de at 15 dias. Complementa a carncia de abordagem gerencial do XP. Recomendada aplicao conjunta.

Principais Caractersticas

Limitaes/ Falhas

Refatorao do software melhora o desempenho e Pouca ateno no uso de prtica de gerenciamento. responsvel pelas mudanas. Viso do produto bem definida e repetvel. Carente de testes de integrao e omisso em relao a aspectos de implementao. Voltado para e-Projects. Os resultados direcionam o As prticas so muito subjetivas. necessrio alto grau planejamento e as mudanas so encorajadas. de maturidade do Gerente de Projeto para coloc-las em

APM

prtica. Acredita fortemente na adoo de princpios que explorem Considera que o comportamento coletivo caracterizado Requer muita experincia do Gerente na liderana de a compreenso do comportamento humano autnomo. por uma superposio de ordem, auto-organizao e uma pessoas para se extrair o melhor resultado do mtodo. No inteligncia coletiva que maior que a soma das partes. Processo simplificado que se apoia em prticas do XP, RUP Visa aplicao em projetos acadmicos, ou comerciais de e Agile Modeling. pequeno ou mdio porte. Formado por cinco processos e iteraes curtas. Mtodo simples, desenvolvimento por caractersticas e modelagem de objeto. Vrios mtodos com caractersticas diferentes. Capacidade de selecionar o mtodo mais adaptvel ao projeto. Uso do RAD, equipe com autonomia para tomar decises. Utiliza a prototipao e possui vrios papis (responsveis) para execuo de uma atividade no mtodo. Foca no ciclo adaptvel, colaborativo e no desenvolvimento Oriundo da filosofia de Sistemas Adaptativos. iterativo. recomendado para Equipes pouco maduras. Recomendado para projetos de escopo pequeno,que possam ser concludos em at quatro meses. Foco restrito ao projeto e implementao. Dificuldade no uso de estimativas. Somente os membros da equipe tm acesso aos procedimentos do mtodo, no envolvendo o cliente. Baseia-se mais nos conceitos e na cultura gil do que em prticas geis.

YP FDD Crystal DSDM ASD

tabela 3. Comparao entre os mtodos geis revisados. FONTE: Adaptado de (ABRAHAMSSON et al., 2002)

Na Tabela 2 apresenta-se um estudo comparativo entre os pressupostos do desenvolvimento dirigido por planejamento (tradicional) e da abordagem gil realizado por Magalhes et al. (2005). Na Tabela 3 apresenta-se um estudo comparativo dos mtodos geis, partindo do estudo realizado por Abrahamsson et al. (2002) e complementado por este trabalho, apontando os pontos chaves, as principais caractersticas e as falhas entre os mtodos aqui apresentados. A contribuio acrescentada ao trabalho comparativo de Abrahamsson et al. (2002) diz respeito mais precisamente complementao da anlise com o acrscimo dos mtodos: XPM, APM e YP, bem como a uma reviso da anlise original sob a tica dos objetivos deste artigo. Com base na Tabela 2 ficam perceptveis as vantagens resultantes da abordagem gil no que diz respeito capacidade do time em responder de forma rpida e precisa s mudanas naturais que fazem parte do ambiente dos negcios, onde esto inseridos os projetos. Contudo, para adoo de uma abordagem gil, as organizaes precisam estar dispostas a mudar a sua percepo em relao a seus clientes, a reavaliar a forma como encaram seus projetos e a assumir alguns riscos. Alm disso, os times tambm precisam estar dispostos a aprender e amadurecer durante o processo, refinando suas prticas e aumentando o grau de integrao e comunicao com o cliente.

gil, seus princpios e valores comuns a todos os mtodos geis. No decorrer deste artigo foram apresentados nove mtodos geis, abordando seu processo de desenvolvimento e as prticas existentes em cada um. Alm disso, foi apresentado tambm um estudo comparativo dos processos de desenvolvimento gil abordados. A reviso sistemtica realizada neste artigo a respeito de metodologias geis est diretamente associada com a necessidade de identificao dos princpios, valores e boas prticas geis que possam ser adequados e aplicados aos negcios de cada organizao. Espera-se que os resultados da anlise comparativa, bem como o conjunto de conhecimentos explorados neste artigo sirvam de base para a formao de uma viso crtica sobre a aplicao de mtodos geis na indstria de software, assim como no comportamento das equipes envolvidas neste contexto. Possibilitando, desta forma, a gerao de um senso analtico sobre em que circunstncias cada um dos mtodos aqui explorados melhor se adquam natureza dos projetos em andamento em nossas organizaes. E permitindo, inclusive, uma reflexo sobre a pertinncia de utilizao combinada de alguns mtodos geis, em funo das caractersticas das variveis envolvidas em cada projeto, como: cliente, equipe, restries e premissas, dentre outras.

Concluses
Neste artigo foram apresentadas reflexes sobre porque adotar uma abordagem gil para os processos de negcio das organizaes. Foram apresentadas algumas definies sobre processo de desenvolvimento de software, assim como a origem da formao da Aliana gil, atravs do Manifesto

D seu feedback sobre esta edio! A Engenharia de Software Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que voc, leitor, acha da revista! D seu voto sobre este artigo, atravs do link: www.devmedia.com.br/esmag/feedback

Edio 37 - Engenharia de Software Magazine

17

Referncias ABRAHAMSSON, P.; SALO, O.; RONKAINEN, J.; WARSTA, J. (2002). Agile Software Development Methods. Review and analysis. ESPOO (Technical Research Centre of Finland) 2002. VTT Publications n. 478, 112p, 2002. APM (2003). CC PACE Systems.Agile Project Management Explained White paper. Disponvel em: < http://www.ccpace.com/Resources/documents/AgileProjectManagement.pdf >. BECK, K ; FOWLER, M. (2000). Planning extreme programming. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2000. Disponvel em: < http://www.mip.sdu.dk/~brianj/Extreme%20 Programming%20Explained%20-%20Kent%20Beck%3B%20Addison-Wesley,%201999.pdf >. BECK, KENT et al. (2001). Agile Manifesto, 2001. Disponvel em: <http://www.agilemanifesto.org>. BECK K. (1999). Programao Extrema Explicada. Bookman, 1999. COCKBURN, A. (2000). Agile Software Development Draft version: 3b. Highsmith Series Editors, 2000. Disponvel em: <http://zsiie.icis.pcz.pl/ksiazki/Agile%20Software%20Development.pdf>. CUMMINS, F.A (2008). Building the Agile Enterprise: With SOA, BPM and MBM, 2008. Paperback, 336 pages, publication date:SEP-2008.ISBN-13:978-0-12-374445-6.Disponvel em:< http://books.google. com/books?hl=pt-BR e lr= e id=S6bla9Oy7SYC e oi=fnd e pg=PR13 e dq=%22agile+governance%22 e ots=k05jBK84BQ e sig=Yy6IpvSQ9TNKELMr3Ohv3dR_7UA >. DSDM (2003). DYNAMIC SYSTEMS DEVELOPMENT METHOD LTD. DSDM Consortium, 2003. Site do consrcio responsvel pelo DSDM e onde esto disponveis diversas informaes sobre o mtodo. Disponvel em: <http://www.dsdm.org/>. FERREIRA, RB; LIMA, FPA (2006). Metodologias geis: Um Novo Paradigma de Desenvolvimento de Software. II Workshop Um Olhar Sociotcnico sobre a Engenharia de Software WOSES, 2006, Vila Velha - ES. Disponvel em: <http://www.cos.ufrj.br/~handrade/woses/woses2006/pdfs/10Artigo10WOSES-2006.pdf>. GARCIA, F. P. et al. (2004). easYProcess: Um Processo de Desenvolvimento para Uso no Ambiente Acadmico. XII WEI-Workshop de Educao em Computao. Campina Grande: UFCG, 2004. Disponvel em: < http://www.dsc.ufcg.edu.br/~yp/Download/ArtigoYPWEI.pdf>. HIGHSMITH, J. (2000). Retiring Lifecycle Dinosaurs. Software Testing e Quality Engineering 2, n.4, July/August 2000. HIGHSMITH, J. (2002a). Agile Software Development Ecosystems. Addison Wesley, 2002. HIGHSMITH, J. (2002b).What Is Agile Software Development? Agile Software Development. CROSSTALK.The Journal of Defense Software Engineering. Outubro, 2002. p. 4-9. JACOBSEN, CATRINE M. (2001).XPM from idea to realization - critical approach to the concept of XPM Disponvel em: <http://www.glyn.dk/download/synopsisXPM.pdf >. . LOJKINE, J. (1996).A revoluo informacional So Paulo, Editora Cortez, 1996. . LUFTMAN, J.N.; LEWIS, P.R. e OLDACH, S.H. (1993).Transforming The Enterprise:The Alignment Of Business And Information Technology Strategies IBM Systems Journal, v.32, n.1, p.198-221, 1993. . LUNA,AlexandreJ.H.DEO.;COSTA,CleyversonP.andNOVAES,MagdalaA.(2010).DesenvolvimentoDistribudo de uma Aplicao de Telessade com a Metodologia gil SCRUM.In Revista Cientfica Tecnologus 4,no.1:6. Disponvel em:<http://www.unibratec.com.br/revistacientifica/n4_artigos.html>. MAGALHES, ANA L. C. DE C.; ROUILLER, ANA C.; VASCONCELOS, ALEXANDRE M. L. (2005). O Gerenciamento de Projetos de Software Desenvolvidos Luz das Metodologias geis: Uma Viso Comparativa. Revista ProQuality Qualidade na Produo de Software vol. 1, n. 1 Lavras, Universidade Federal de Lavras, maio de 2005. Disponvel em: < http://www.proqualiti.org.br/ revista/revista_ProQualiti_maio2005.pdf#page=29 >. NAWROCKI, J.; JASINSKI, M.; WALTER, B.; WOJCIECHOWSKI. (2002). Extreme Programming Modified: Embrace Requirements Engineering Practices. In: RE 2002, International Conference on Requirements Engineering, IEEE, 8 p., 2002. OLIVEIRA, E. S. (2003).Uso de Metodologias geis no Desenvolvimento de Software Monografia . apresentada no Programa de Ps-Graduao em Engenharia de Software da UFMG, 2003. PALMER,S.R.;FELSING,J.M.A (2002).Practical Guide to Feature-Driven Development.Prentice Hall,2002. PRESSMAN, Roger S. (2006). Engenharia de Software: Uma abordagem prtica. Mc Graw Hill 6edio, 2006. ROOSMALEN, MW VAN e HOPPENBROUWERS, S (2008). Supporting Corporate Governance with Enterprise Architecture and Business Rule Management: A Synthesis of Stability and Agility. Proceedings of ReMoD, 2008. Disponvel em: < http://ftp.informatik.rwth-aachen.de/ Publications/CEUR-WS/Vol-342/paper2.pdf >. SCHWABER, Ken e BEEDLE, Mike (2002). Agile Software Development with SCRUM. Prentice Hall, PTR Upper Saddle River, NJ, USA, 2002. SCOTT, DONNA (2000). Operation Zero Downtime, a Gartner Group Report, Donna Scott, 2000. Disponvel em: <http://www.gartner.com/>. SLOANE, E; BECK, R e METZGER, S (2008). AGSOA - Agile Governance for Service Oriented Architecture (SOA) Systems: A Methodology to Deliver 21st Century Military Net-Centric Systems of Systems. Systems Conference, 2008 2nd Annual IEEE, 2008. Disponvel em: < http://ieeexplore. ieee.org/xpls/abs_all.jsp?arnumber=4518995 >. SOARES, M. S. (2004). Comparao entre Metodologias geis e Tradicionais para Desenvolvimento de Software. INFOCOMP Journal of Computer Science,Vol. 3, n. 2, p. 8-13, 2004. SOMMERVILLE, IAN (2007). Engenharia de Software. Pearson Education - 8 Edio, So Paulo, 2007. STAPLETON, JENNIFER (1997).DSDM:The Method in Practice.Pages: 192.Medium: Hardcover, 1997. ISBN:0201178893. TAKEUCHI, H. AND I. NONAKA (1986).The New New Product Development Game. Harvard Business Review, 1986 (January-February). THOMSETT, ROB (2002). Radical Project Management. Prentice Hall, 2002. ISBN-13: 978-0-13009486-5. Disponvel em: <http://my.safaribooksonline.com/0130094862>. YP (2006). easY Process. Disponvel em: <http://www.dsc.ufcg.edu.br/~yp/>.

18

Engenharia de Software Magazine - A necessidade de ser gil

Engenharia