Mtodos geis

Autor: Fbio Levy Siqueira Verso: 24/07/2003 25/07/2003 27/07/2003 28/07/2003 29/07/2003 31/07/2003 01/08/2003 03/08/2003 04/08/2003 05/08/2003 06/08/2003 31/08/2003 1/07/2004 Verso original Reviso da Introduo e incio do XP Texto sobre XP Texto sobre SCRUM Texto sobre Crystal Texto sobre FDD Texto sobre DSDM Texto sobre DSDM e reviso das figuras Texto sobre o LD Texto sobre o LD e ASD Texto sobre o ASD Reviso Reviso

ndice
INTRODUO ............................................................................................................... 2 EXTREME PROGRAMMING (XP) ................................................................................... 3 SCRUM.......................................................................................................................... 5 CRYSTAL....................................................................................................................... 8 FEATURE-DRIVEN DEVELOPMENT .............................................................................10 LEAN DEVELOPMENT.................................................................................................. 13 DYNAMIC SYSTEMS DEVELOPMENT METHOD ........................................................... 14 ADAPTIVE SOFTWARE DEVELOPMENT ...................................................................... 17 REFERNCIAS ............................................................................................................ 19

Pgina 1

Mtodos geis

Fbio Levy Siqueira

Introduo
A complexidade e o tamanho dos sistemas computacionais requisitados pelo crescente e vido mercado torna praticamente impossvel constru-los de forma desorganizada. So necessrios mtodos de engenharia de software, ou usando a definio feita por Sommervile [22], uma forma estruturada de se desenvolver software com o objetivo de facilitar a sua produo com alta qualidade e de maneira rentvel.

Dentre os diversos mtodos disponveis, um grupo deles est em grande evidncia atualmente: os mtodos geis. O objetivo desses mtodos, segundo Highsmith e Cockburn [12], o de obter um desenvolvimento de software mais adequado ao ambiente turbulento dos negcios, que exige mudanas rpidas e freqentes. Dessa forma, pregam prticas e princpios bastante diferentes dos outros mtodos tradicionais (ou segundo Highsmith, rigorosos [13]), algo que pode ser facilmente observado no Extreme Programming, o mtodo mais famoso e discutido desse grupo.

interessante observar que o conceito de mtodos geis bastante novo, moldado em fevereiro de 2001 em uma conferncia realizada para discutir as semelhanas entre os ento mtodos de peso leve (lightweight). Nesse encontro se reuniram alguns representantes de mtodos e outros influentes simpatizantes. Apesar das aparentes diferenas entre os diversos mtodos ali representados, os participantes dessa conferncia encontraram alguns pontos em comum em suas ideologias, adotando o nome gil e produzindo um manifesto com os princpios e valores [1].

A autodenominao desse grupo de mtodos para gil, ao invs de peso leve, no um mero detalhe. O termo anteriormente usado, segundo Cockburn, parece mais uma reao a algo do que uma crena [7]. Alm disso, o termo peso leve leva ao entendimento que ou os mtodos s servem para pequenos projetos o que no verdade ou que utilizam processos pequenos e com poucos artefatos o que uma conseqncia dos seus princpios e no o ponto principal dos mtodos. Dessa forma, a nova denominao por gil mais adequada por evidenciar um dos pontos principais desses mtodos: a importncia de ser capaz de responder a mudanas de requisitos dentro do perodo de tempo do projeto [7].

No entanto, a questo das mudanas, apesar de ser um ponto extremamente importante, no o nico em comum entre esses mtodos, podendo ainda citar os seguintes: A busca pelo mnimo necessrio e suficiente de documentao e processo; A importncia das pessoas e da comunicao entre elas; O foco no cliente e tambm na sua participao direta;

Pgina 2

Mtodos geis

Fbio Levy Siqueira

A entrega freqente e com valor ao cliente. Os demais pontos em comum entre os mtodos geis so definidos no manifesto (disponvel em [1]), considerando assim os 4 valores e os 12 princpios ali destacados.

A seguir sero apresentados os principais mtodos geis, considerando os mtodos representados na conferncia original. Pretende-se aqui fornecer apenas a viso geral de cada um dos mtodos, focando nas suas caractersticas principais que os destacam entre a inmeras opes disponveis atualmente.

Extreme Programming (XP)

O Extreme Programming provavelmente o mtodo gil mais famoso e discutido atualmente. Ele causou bastante polmica por ser muito diferente, e algumas vezes conflitante, em relao ao Processo Unificado [14], principalmente ao considerar que o custo da mudana no deve aumentar dramaticamente com o tempo [4], algo que contraria um dos princpios bsicos da engenharia de software [5]. Por ser a premissa tcnica do XP, diversas prticas propostas esto fortemente ligadas a esta, aproveitando as possibilidades criadas por essa afirmao.

Falando mais especificamente sobre o mtodo, o Extreme Programming direcionado para times de pequeno a mdio tamanho desenvolvendo software em face a requisitos vagos ou em mudana constante [4]. Para atingir o sucesso nesse tipo de projeto, o XP prega 4 valores fundamentais e 12 prticas que, conforme o prprio nome do mtodo sugere, so levadas ao extremo. Em relao aos valores as premissas bsicas do mtodo que so usadas para direcionar as pessoas nos objetivos do projeto , o XP prega os seguintes: Comunicao: promover a comunicao entre as partes envolvidas do projeto. Simplicidade: fazer algo da forma mais simples possvel e funcional. Retro-alimentao (feedback): permitir a retro-alimentao de informao de forma rpida e freqente [16]. Coragem: capacidade de assumir riscos e desafios em favor do projeto.

Apesar de ser normalmente colocado em segundo plano, o XP tambm define um conjunto de princpios (no total de 15 vide Tabela 1) com o objetivo de concretizar os valores, facilitando o seu uso pelas pessoas envolvidas. O interessante desses princpios o fato deles terem conceitos fortes e muito importantes para entender o XP e utiliz-lo1, como, por exemplo, a

Alguns dos princpios do Extreme Programming so bastante difceis de se aplicar, j que pregam mudanas no

comportamento das pessoas e das idias enraizadas nas empresas, como, por exemplo, a comunicao aberta e honesta, responsabilidade aceitada e medir honestamente.

Pgina 3

Mtodos geis

Fbio Levy Siqueira

adaptao local que prega a adequao do XP s condies de trabalho mostrando que o XP no to fechado como as pessoas costumam v-lo.

Princpios Centrais Retro-alimentao rpida; Simplicidade assumida; Mudana incremental; Abraar as mudanas; Trabalho com qualidade.

Outros Princpios Ensinar aprendendo; Pequeno inicial; Jogar para ganhar Experimentos concretos Comunicao honesta; aberta e investimento Trabalhar com o instinto das pessoas e no contra eles; Responsabilidade aceitada; Adaptao local; Viagem leve; Medir honestamente;

Tabela 1: Os princpios do Extreme Programming.

Os valores e princpios so o esprito do XP, mas necessrio mais que isso para criar um processo eficaz. Nesse mbito foram definidas as prticas que detalham de maneira mais clara como e quando cada desenvolvedor deve atuar e tambm organizando a equipe de desenvolvimento para tornar o processo do XP slido. A seguir so apresentadas essas prticas: O jogo do planejamento (the planning game): define como planejar, combinando prioridade de negcio e estimativas tcnicas [4]. Entregas breves (small releases): entregar algo de valor ao cliente rapidamente e com grande freqncia. Metfora: criar uma metfora que expresse de maneira simples e clara a idia do sistema a ser construdo. Design simples: o design deve ser feito da maneira mais simples possvel, focando no na tarefa atual e no pensando em possibilidades futuras. Teste: os testes devem ser feitos de forma automatizada; os de unidade feitos pelos desenvolvedores antes da implementao da tarefa e os clientes escrevendo os funcionais. Refatoramento (refactoring): o cdigo deve ser continuamente reestruturado pelos desenvolvedores, tirando a duplicao de cdigo e tornando-o mais simples aps uma modificao. Programao em duplas (pair programming): a produo do cdigo deve ser feita em duplas, uma escrevendo o cdigo e a outra auxiliando e pensando de forma mais estratgica. Autoria coletiva (collective ownership): o cdigo pode ser alterado por qualquer desenvolvedor, tornando todos responsveis pelo cdigo do sistema.

Pgina 4

Mtodos geis

Fbio Levy Siqueira

Integrao contnua: as tarefas terminadas devem ser integradas ao j construdo, executando os testes automatizados para verificar a correo do sistema. Semana de 40 horas: os desenvolvedores devem ter o descanso necessrio para executar as tarefas com mais ateno e vontade. Cliente no local (on-site customer): um cliente deve estar disponvel no local para sanar as dvidas que forem aparecendo durante a implementao e com o poder necessrio de deciso. Padro de cdigo: definir um padro para codificao para que o cdigo possa ser entendido de forma mais fcil pelos desenvolvedores. Muitas dessas prticas so alvos freqentes de crticas, como a programao em duplas que seria um desperdcio de pessoal e o refatoramento que seria uma forma de retrabalho devido a um projeto mal feito. No entanto, no adequado julgar as prticas de forma isolada, j que cada uma delas tem um papel no processo, ou como Highsmith define, fortalecendo uma a outra de forma direta e sutil [13]. Por esse mesmo motivo, alterar alguma prtica necessita um profundo entendimento do XP e da equipe de trabalho, para no criar um problema srio no processo. Na Figura 1 apresentada uma representao do processo do XP, incorporando as prticas, princpios e valores.

Figura 1: O processo executado em um projeto normal do XP (retirado de [21]).

SCRUM
O SCRUM um mtodo gil que utiliza como fundamento principal a classificao retirada da rea de processos de controle industrial, que divide os processos em definidos e empricos. Em

Pgina 5

Mtodos geis

Fbio Levy Siqueira

um processo definido, se tem conhecimento suficientemente detalhado de todos os itens que sero utilizados suas leis de transformao e de mistura. Isso permite criar um processo automatizado, j que possvel prever o resultado de antemo. No caso de um processo emprico, no se sabe exatamente como as partes se relacionam, tratando assim o que acontece internamente como uma caixa preta. Para conseguir obter os resultados desejados em um processo desse tipo o fundamental controlar adequadamente as partes, atuando rapidamente para manter as partes nos limites conhecidos [3].

Dessa idia, o SCRUM analisa o processo de desenvolvimento de software e conclui que, com o conhecimento atual, a classificao mais adequada como processo emprico. Com isso, a utilizao de controle adequado e adaptao rpida aumentariam consideravelmente o sucesso dos projetos, principalmente os maiores e a beira do caos. Essa idia representada na Figura 2 que, segundo Highsmith [13], pode ser generalizada para todos os processos geis e no a apenas ao SCRUM.

Figura 2: Sucesso do projeto e o aumentado com um mtodo gil frente sua complexidade (retirado de [2]).

No entanto, essa avaliao em processo emprico no completamente aceita, sendo conflitante com o CMM do Software Engineering Institute (SEI), que prega a definio de um processo de desenvolvimento de software que continuamente melhorado para uma organizao de software.

Esquecendo as controvrsias e falando mais especificamente sobre o mtodo SCRUM, ele dividido nas fases pr-jogo, jogo e ps-jogo. Na fase de pr-jogo feito o planejamento que

Pgina 6

Mtodos geis

Fbio Levy Siqueira

define principalmente as funcionalidades e suas estimativas, criando assim os backlogs (todo trabalho que ser realizado em um futuro previsvel, bem definido e tambm precisando de futura definio [3]). Nela tambm criada a arquitetura bsica, sendo definida a viso de desenvolvimento do projeto a partir dela [20].

Depois do planejamento feito o jogo, que uma srie de iteraes rpidas de desenvolvimento (de 1 a 4 semanas), chamadas de Sprint (corridas) vide Figura 3. Nelas o primeiro passo realizar uma reunio em que os clientes, os gerentes e os desenvolvedores criam, decidem e priorizam as tarefas do backlog a serem executadas durante nessa iterao, com um determinado objetivo definido. Posteriormente os grupos de desenvolvedores, que devem ser completamente funcionais e de at 10 pessoas, dividem entre eles as tarefas determinadas.

Figura 3: A execuo de um Sprint (retirado de [3]).

Pensando na teoria de processos industriais, essa a fase emprica do processo, o que obriga a existncia de formas de controle. Com isso, diariamente os grupos de desenvolvedores se encontram, discutindo rapidamente (30 minutos) o andamento do projeto. Isso permite ao gerente e aos desenvolvedores terem a viso do processo por inteiro, e tambm a possibilidade do gerente corrigir os problemas que esto atrapalhando o desenvolvimento. Tambm diariamente o software integrado, o que aumenta ainda mais a visibilidade do andamento do desenvolvimento.

Pgina 7

Mtodos geis

Fbio Levy Siqueira

Uma outra forma de diminuir a complexidade do processo a o fato das tarefas e suas prioridades ficarem estveis durante cada uma das iteraes. No entanto no uma estabilidade completa, j que os desenvolvedores podem colocar mais trabalho no backlog que seja considerado por eles necessrio.

Com o trmino do desenvolvimento desse Sprint feita uma reunio com o cliente para verificar o andamento do projeto, demonstrar as funcionalidades prontas e revisar o projeto sob uma perspectiva tcnica [13].

Ao fim de uma iterao, pode ser decidido pela gerncia que o projeto j atingiu seu objetivo, criando uma entrega do produto (fase de ps-jogo). Nesse momento feito todo o treinamento necessrio, gerada toda a documentao, executados os testes de sistema, etc.

Crystal
Crystal o nome de uma famlia de mtodos que devem ser ajustados para melhor se adaptarem a uma determinada equipe e projeto. Cada mtodo moldado para ter a quantidade exatamente suficiente de processo, capaz de atender os projetos a partir da anlise de trs fatores: a carga de comunicao (representada pelo nmero de pessoas), a criticidade do sistema e a prioridade do projeto. Na Figura 4 so apresentadas apenas duas dimenses, demonstrando qual mtodo da famlia Crystal deve ser utilizado (Clear, Yellow, Orange, Red). Segundo Cockburn [8], existem diversos outros fatores para a escolha de um mtodo, no entanto ao utilizar apenas esses trs j se obtm um resultado bastante adequado.

Pgina 8

Mtodos geis

Fbio Levy Siqueira

Vida (L)

L6

L20

L40

L80

Criticidade do Sistema

Dinheiro Essencial (E)

E6

E20

E40

E80

Dinheiro (D)

D6

D20

D40

D80

Conforto (C)

C6
Clear

C20
Yellow

C40
Orange

C80
Red

Nmero de Pessoas 20%

Figura 4: A distribuio dos mtodos da famlia Crystal a partir de duas dimenses (retirado e adaptado de [9]).

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 [13]. Por exemplo, ao observar os papis no Crystal Clear, notase que existem 6 tipos [9], enquanto que no Orange existem mais de 14 [7].

Apesar das diferenas entre as complexidades dos projetos abordados pelos mtodos da famlia Crystal, eles apresentam em comum valores, princpios e a capacidade de serem ajustados durante o uso (on-the-fly). Os valores denotam a viso do desenvolvimento de software como um jogo cooperativo de inveno e comunicao, com o objetivo primrio de entregar algo til e, em segundo, preparar para o prximo jogo [7]. Dessa forma, os valores pregam que os mtodos so centrados nas pessoas e na comunicao, alm de serem altamente tolerantes a modificaes considerando as diferenas entre as pessoas. Isso permite que sejam utilizadas partes de outros mtodos, como prticas e princpios do XP e o arcabouo do SCRUM. No entanto, existem duas regras que devem ser seguidas, limitando essas modificaes: o desenvolvimento deve ser incremental, com incrementos de at 4 meses, e devem ser realizados workshops de reflexo antes e depois de cada incremento.

Em relao aos princpios, eles so os seguintes (retirado de [7]):

Pgina 9

Mtodos geis

Fbio Levy Siqueira

Comunicao iterativa, face-a-face o canal mais barato e rpido para o intercmbio de informaes. O excesso de peso do mtodo custoso. Times maiores precisam de mtodos mais pesados. A maior cerimnia apropriada para projetos com maior criticidade. Aumentando a retro-alimentao (feedback) e comunicao reduzida a necessidade de itens intermedirios entregues. Disciplina, habilidade e entendimento contra processo, formalidade e documentao. Pode-se perder eficincia em atividades que no so o gargalo do processo.

O interessante dos mtodos Crystal que eles tm uma aparncia de mtodos no-geis. Apesar de terem princpios e valores claramente alinhados com o manifesto de desenvolvimento gil, eles apresentam elementos (papis, documentao, artefatos, etc) que so normalmente vistos em mtodos como o Processo Unificado [14]. Essa caracterstica permite que os mtodos Crystal possam ser mais facilmente utilizados por uma equipe que o Extreme Programming, mas segundo o prprio autor [8], o XP apresenta melhores resultados que o Crystal Clear. Dessa forma, uma equipe pode comear com o Crystal Clear e posteriormente passar para o XP, ou uma equipe que tenha srios problemas de adaptao com o XP pode passar para o Crystal Clear [8].

Feature-Driven Development
O Feature-Driven Development (FDD) um mtodo que tem um foco grande na modelagem (diagrama de classes e seqncia) e utiliza como forma de planejamento e medio as caractersticas, ou melhor, funes com valor ao cliente [17]. A utilizao de caractersticas no processo FDD tem diversas vantagens, o que, segundo Coad et al [6], permite agradar todas as partes envolvidas. Os programadores ficam mais motivados e satisfeitos, uma vez que mudam o foco de trabalho em poucas semanas. Os gerentes reduzem riscos ao entregar resultados freqentes, tangveis e funcionando, alm de poder usar as caractersticas como forma de medio, gerando relatrios com porcentagens. Os clientes recebem freqentemente resultados que eles entendem e tambm podem saber a qualquer momento o andamento do projeto com preciso.

Para que seja possvel gerenciar de forma adequada as caractersticas, o FDD define papis, prticas e um processo de maneira bastante simples. Em relao aos papis, apesar de serem definidos diversos como, por exemplo, o gerente e o arquiteto chefe, existem dois papis que so principais: o dono da classe e o chefe programador. O chefe programador um desenvolvedor que cuida da implementao de algumas das caractersticas, criando um time

Pgina 10

Mtodos geis

Fbio Levy Siqueira

para o desenvolvimento atravs da verificao de quais so as classes que sero usadas e recrutando seus respectivos donos. Com isso, podem existir (dependendo do tamanho da equipe) diversos times de desenvolvimento, o que pode fazer com que os desenvolvedores trabalhem em mais de um time (recomenda-se no mximo 3) durante uma iterao. O interessante que o chefe programador tambm dono de algumas classes, podendo ser recrutado para a participao de um time liderado por outro chefe programador.

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 [17]: 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: a forma de verificao 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: manter verses de todos os artefatos criados. Reportar/Visibilidade dos resultados: permitir que se conhea o progresso do projeto.

Essas prticas so incorporadas nos 5 processos que so descritos atravs de uma forma textual direta e objetiva (disponvel em [15]) em que definido o critrio de entrada, as tarefas associadas, formas de verificao e o critrio de sada. A viso geral dos processos e seu sequenciamento apresentado na Figura 5.

Pgina 11

Mtodos geis

Fbio Levy Siqueira

Desenvolver um modelo geral

Construo da lista de caractersticas

Planejamento por caracterstica

Projeto por caracterstica

Construo por caracterstica

Figura 5: Os processos do FDD (retirado e adaptado de [6]).

O primeiro processo o desenvolvimento de um modelo geral, incorporado em um modelo de domnio em que so colocadas apenas as classes e suas relaes, com o detalhamento suficiente para apenas dar forma ao sistema. Esse processo tem como objetivo diminuir o refatoramento, uma vez que gera um arcabouo para a construo do sistema nos demais processos, mantendo assim uma integridade conceitual [17].

No segundo processo feita a construo de uma lista de caractersticas, agrupando, priorizando e dando pesos a elas. Essa lista obtida atravs da transformao de mtodos criados anteriormente no modelo para uma caracterstica e alterando, removendo e adicionando para se obter uma lista que represente adequadamente as expectativas do cliente. Um outro ponto importante que as caractersticas devem ser breves, preocupando com o perodo de desenvolvimento que no deve ultrapassar duas semanas o que pode obrigar a uma decomposio de uma caracterstica.

O terceiro processo a criao de um plano feito apenas pelos desenvolvedores sem o cliente que foca na implementao. Esse plano deve considerar as dependncias entre as caractersticas, a carga da equipe de desenvolvimento e a complexidade das caractersticas [15].

Aps esse processo iniciada a implementao das caractersticas de forma iterativa atravs de dois processos: o projeto por caracterstica e a construo por caracterstica. No processo de projeto so criados os times (da caracterstica) que devem desenvolver um diagrama de seqncia que reflete a caracterstica a ser implementada. Com isso, o chefe programador deve refinar o modelo de objeto atravs do que foi obtido no diagrama de seqncia e os donos das classes devem escrever a documentao dos mtodos. No processo seguinte, o de construo por caracterstica, os programadores devem implementar o que foi discutido na etapa anterior (mtodos, classes, etc) e criar os testes de unidade.

Pgina 12

Mtodos geis

Fbio Levy Siqueira

Lean Development
O Lean Development (LD) um mtodo baseado na viso da produo Lean, da rea de manufatura e processos. Essa forma de produo seria o estgio seguinte produo em massa, pregando a customizao em massa, com a ambio de diminuir consideravelmente os gastos: metade do esforo, do espao, do investimento em ferramentas, etc [13]. No mbito do desenvolvimento de software essas propostas seguem a mesma linha, filosofia e ambio. Dessa forma, o LD no se preocupa em pregar prticas de desenvolvimento ao contrrio do XP , j que seu foco no ponto de vista estratgico, direcionado primordialmente ao nvel gerencial da organizao e no ao nvel de instrumentao, no caso, os desenvolvedores.

A idia geral dessa forma da produo Lean a observao dos problemas da mudana de requisitos sob uma nova perspectiva: as decises do cliente devem ser adiadas ao mximo, deixando para que elas sejam feitas quando houver um maior conhecimento do assunto [18]. E quando as decises forem feitas, a implementao deve ser rpida, evitando que as condies externas afetem uma funcionalidade antes dela ser entregue.

Por ser uma forma de produo passada para a rea de Engenharia de Software, necessrio que ocorra uma adaptao adequada de seus princpios com a preocupao de manter a filosofia para esse outro ambiente de produo. Dessa forma, a seguir so apresentados esses princpios, derivados para a viso do software segundo Poppendieck [19]: Eliminar o desperdcio: ao observar o processo produtivo por inteiro. Amplificar o aprendizado: aumentando a retro-alimentao, atravs de ciclos rpidos e iterativos. Atrasar o compromisso: deixar suas opes disponveis pelo maior tempo possvel, para que as decises sejam feitas com o mximo de conhecimento sobre o assunto [18]. Entregar rapidamente: as entregas devem estar alinhadas com os anseios do cliente em um determinado momento de tempo. A demora para entregar pode fazer com que o resultado no seja mais o que o cliente precise ou deseje. D poder ao time: a equipe de desenvolvimento deve ter o poder de decidir, algo necessrio devido rapidez da implementao. Construa com integridade: o software deve satisfazer ao cliente realizando o que ele deseja (integridade percebida), ter um ncleo coeso (integridade conceitual) e manter-se til com o tempo. Veja o todo: a viso dos implementadores deve ser do produto como um todo e no apenas de uma parte ou subsistema.

Pgina 13

Mtodos geis

Fbio Levy Siqueira

Uma adaptao mais prtica e voltada para implementao desses princpios para a Engenharia de software feita por Charette apud Highsmith [13]. Dessa forma, foi interpretada a produo Lean para criar o mtodo de desenvolvimento de software conhecido por LD. A seguir, colocado o conjunto de princpios que regem esse mtodo [13]: 1. A satisfao do cliente a maior prioridade. 2. Sempre provenha o melhor valor para o dinheiro. 3. Sucesso depende na participao ativa do cliente. 4. Todo projeto LD um esforo do time. 5. Tudo pode ser mudado. 6. As solues devem ser de domnio e no pontuais. 7. Complete, no construa. 8. 80% da soluo hoje melhor do que 100% da soluo amanh. 9. Minimalismo essencial. 10. As necessidades determinam a tecnologia. 11. O crescimento do produto o crescimento de caractersticas, e no de tamanho. 12. Nunca force o LD para fora de seus limites.

Em relao ao processo de desenvolvimento, so definidas trs etapas principais: incio, o estado de crescimento regular (steady-state), e transio e renovao. No incio o foco anlise de valor ao cliente, o estudo do negcio e projeto de viabilidade [13], com isso feita uma anlise de riscos e outras etapas de escopo gerencial.

Na etapa de estado de crescimento regular o objetivo realizar o desenvolvimento de forma iterativa e incremental em perodos fechados (time-boxes) de 90 dias no mximo. Cada iterao realiza um pouco das fases tradicionais de desenvolvimento (anlise, projeto, implementao e testes), integrando continuamente o software. A grande diferena em relao aos outros mtodos a utilizao em larga escala de templates (solues de domnio) para aumentar a velocidade de produo e sua reutilizao (condizente com o princpio 7).

Na etapa de transio feita a entrega, focando na documentao e treinamento, pensando ainda na evoluo do sistema.

Dynamic Systems Development Method

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. A nfase do DSDM, que se conceitua mais como um arcabouo do que um mtodo, na criao de

Pgina 14

Mtodos geis

Fbio Levy Siqueira

prottipos que evoluem para o sistema, utilizando para isso a colaborao muito prxima do cliente.

As idias principais do DSDM podem ser observadas no conjunto de princpios que foram definidos para nortear o mtodo [10]: O envolvimento ativo do usurio imperativo. O time deve ter o poder para tomar decises. O foco na entrega freqente 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. Todas as mudanas durante o desenvolvimento 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. possvel notar com esses princpios que o cliente e o negcio so os pontos essenciais do mtodo, enquanto que os aspectos tcnicos, como a programao, so pouco abordados, o que fica ainda mais evidente na descrio do processo. Esse enfoque e o fato do DSDM ser visto como um arcabouo faz com que existam solues para mescl-lo a outros mtodos, sendo possvel a utilizao em conjunto, por exemplo, com o XP ou o RUP, mas ainda mantendo os princpios definidos no DSDM.

Alm desses princpios, existem algumas tcnicas principais que so usadas durante a execuo de um projeto usando DSDM [10]: Time-boxes: 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 idia fundamental priorizar e implementar os requisitos que sejam considerados principais, deixando os menos importantes para depois. Modelagem: no deve ser uma atividade burocrtica, sendo 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 freqncia.
Pgina 15

Mtodos geis

Fbio Levy Siqueira

Em relao ao processo do DSDM, existem 5 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 monetrias 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 [10], definindo o escopo do projeto.

Pr-Projeto Estudo de viabilidade Estudo do negcio

Ps-Projeto

Modelo funcional

Implementao

Projeto e construo

Figura 6: O processo do DSDM (adaptado de [10]).

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, documentando a maioria dessa forma ao invs da textual [13]. No entanto, o foco apenas a viso bsica dos requisitos, uma vez que os detalhes deles sero desenvolvidos na fase de projeto e construo, em que o objetivo obter o sistema testado. Na fase de implementao

Pgina 16

Mtodos geis

Fbio Levy Siqueira

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 ps-projeto. Nela feita a manuteno do sistema, realizando as tarefas de alterao praticamente da mesma forma que foi feito o desenvolvimento.

Adaptive Software Development

O Adaptive Software Development (ASD) tem como base principal um mtodo RAD (Rapid

Application Development), o RADical Software Development, evoluindo-o ao incorporar

conceitos da teoria de sistemas adaptativos complexos. 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 [11] viso comum a todos os mtodos geis.

Com esse novo ciclo de desenvolvimento, seria mais fcil se adequar a esse ambiente turbulento, trocando uma fase de planejamento, algo baseado na tentativa de predio, por algo mais factvel ao ambiente de incerteza: o especular. O foco nesse caso seria explorar e experimentar, sem abandonar o planejamento por completo, mas assumindo sua falta de preciso. A prxima fase do ciclo prope o trabalho colaborativo entre as partes envolvidas, criando um fluxo de informao suficiente para que possam ser resolvidos rapidamente os problemas tcnicos e de requisitos de negcios. Essa forma de trabalho necessria devido grande quantidade de informao que deve ser coletada e trabalhada para um sistema complexo, alm da turbulncia do ambiente. Por fim, necessrio que haja retro-alimentao para que seja possvel aprender com os erros anteriores, corrigindo-os para as prximas iteraes. Isso pode ser realizado atravs de grupos de foco do cliente e retrospectivas do projeto.

Para que o desenvolvimento seja realmente adaptativo necessrio que esse novo ciclo tenha as seguintes caractersticas: Enfoque na misso: fazer com que a equipe tenha um objetivo definido e permitindo que sejam feitas decises com maior embasamento. Baseado em caractersticas: o objetivo entregar resultados mais palpveis ao cliente, atravs de caractersticas implementadas no sistema ao invs de outras formas de produtos (como, por exemplo, documentao).

Pgina 17

Mtodos geis

Fbio Levy Siqueira

Iterativo: a construo deve focar na evoluo do produto. Perodos fechados (time-boxes): a equipe deve ter um objetivo definido em um determinado perodo, priorizando e decidindo para que seja entregue o combinado no prazo adequado. Dirigido a riscos: necessrio analisar e avaliar os riscos do projeto continuamente, assim como em um desenvolvimento em espiral. Tolerante a mudanas: incorporar as mudanas que forem aparecendo durante o projeto, para que o sistema tenha maior valor ao cliente.

Sob essa perspectiva de um novo ciclo e suas caractersticas necessrias, o ASD define o seu ciclo de vida para projetos. Com isso, as fases do ciclo especular-colaborar-aprender so preenchidas com algumas prticas, conforme colocado na Figura 7.

Ciclo de Aprendizagem

Iniciao do Projeto

Ciclo de planejamento adaptativo

Desenvolvimento concorrente de caractersticas

Reviso de qualidade

Perguntas e Respostas Final e

Release

Especular

Colaborar

Aprender

Figura 7: Ciclo de vida do ASD (adaptado de [13]).

Na fase de especular so feitas algumas atividades gerenciais, com a iniciao do projeto e o planejamento iterativo de seu desenvolvimento. Na iniciao recomendada a utilizao de sesses JAD (joint application development), para que sejam definidos os objetivos do projeto, requisitos, problemas, riscos e tambm estimando o tamanho e o escopo. A seguir deve-se definir os perodos de implementao para todo o projeto, o nmero de ciclos necessrios, um objetivo ou tema para cada um deles, as caractersticas que sero implementadas, as tecnologias utilizadas e, se desejado, uma lista de tarefas. A maioria dessas definies deve ser feita em conjunto com o cliente, obtendo seu consentimento.

Na fase seguinte do ciclo, feita a implementao do sistema em paralelo. Dessa forma, os desenvolvedores devem tentar promover ao mximo a comunicao e colaborao entre as pessoas e entre times, como, por exemplo, ao realizar discusses em lousas ou em conversas pessoais, ou at aplicar prticas como a programao em pares e autoria coletiva do XP. Os gerentes devem facilitar essas prticas, se preocupando com a concorrncia na implementao.

Pgina 18

Mtodos geis

Fbio Levy Siqueira

Por fim, devem ser feitas revises da qualidade pela gerncia, avaliando o que foi entregue pelos desenvolvedores. Essas informaes so retro-alimentadas ao ciclo, permitindo que sejam feitos planejamentos mais adequados posteriormente. Alm disso, deve-se avaliar o desempenho das iteraes, observando os seguintes aspectos [13]: Qualidade resultante sob a perspectiva do cliente. Qualidade resultante sob a perspectiva tcnica. O funcionamento do time de desenvolvimento e as prticas que os seus membros empregam. O status do projeto. Essas informaes permitem o maior entendimento do andamento do projeto e suas perspectivas, alm de serem teis para as concluses que devem ser tiradas ao final do projeto, em seu post-morten.

Referncias
[1] AGILE ALLIANCE WEB SITE. Manifesto for Agile Software Development. 2001. Manifesto com os princpios e valores dos mtodos geis de desenvolvimento. Disponvel em: <http://agilemanifesto.org/>. Acesso em: 24 de mar. 2003. [2] ADVANCED DEVELOPMENT METHODS, INC. SCRUM Software Development Process: Building The Best Possible Software. ADM, 1995. [3] ADVANCED DEVELOPMENT METHODS, INC. ControlChaos.com. 2003. Pgina do mtodo gil SCRUM. Disponvel em: <http://www.controlchaos.com>. Acesso em: 28 de jul. 2003. [4] BECK, K. Extreme Programming Explained: Embrace Change. Addison Wesley, 1999. [5] BOEHM, B. Software Engineering. IEEE Transactions on Computers 25. Dez. 1976, n. 12, p.1226-41. [6] COAD, P.; LEFEBVRE, E.; DE LUCA, J. Java Modeling In Color With UML: Enterprise Components and Process. Prentice Hall, 1999. [7] COCKBURN, A. Agile Software Development. Addison Wesley, 2002. [8] COCKBURN, A. Crystal Light Methods Comments By Alistar Cockburn. Cutter Consortium Whitepaper, 2002. [9] COCKBURN, A. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison Wesley. Rascunho. Disponvel em:

<http://members.aol.com/humansandt/crystal/clear/>.

Pgina 19

Mtodos geis

Fbio Levy Siqueira

[10] DYNAMIC SYSTEMS DEVELOPMENT METHOD LTD. DSDM Consortium, 2003. Site do consrcio que cuida do DSDM e onde esto disponveis diversas informaes sobre o mtodo. Disponvel em: <http://www.dsdm.org/>. Acesso em: 1 de ago. 2003. [11] HIGHSMITH, J. Retiring Lifecycle Dinosaurs. Software Testing & Quality Engineering 2, n.4, July/August 2000. [12] HIGHSMITH, J.; COCKBURN, A. Agile Software Development: The Business of Innovation. IEEE Computer, November 2001, p.120-122. [13] HIGHSMITH, J. Agile Software Development Ecosystems. Addison Wesley, 2002. [14] JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The Unified Software Development Process. Addison-Wesley, 1999. [15] NEBULON PTY. LTD. Nebulon Pty. Ltd. Pgina do Feature-Driven Development, com o processo e outras informaes. Disponvel em: <http://www.nebulon.com>. Acesso em: 31 de jul. de 2003. [16] NEWKIRK, J. Introduction to Agile Processes and Extreme Programming. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING, 2002. Anais Eletrnicos. Disponvel em: <http://www.acm.org>. Acesso em: 24 de mar. 2003. [17] PALMER, S. R.; FELSING, J. M. A Practical Guide to Feature-Driven Development. Prentice Hall, 2002. [18] POPPENDIECK, M. Lean Software Development. C++ Magazine, 2003. Disponvel em: <http://www.poppendieck.com/>. Acesso em: 4 de ago. 2003. [19] POPPENDIECK, M.; POPPENDIECK, T. Lean Software Development. Addison-Wesley, 2003. Introduo disponvel em: <http://www.poppendieck.com/>. Acesso em: 4 de ago. 2003. [20] RISING, L.; JANOFF, N. S. The Scrum Software Development Process for small Teams. IEEE Software, v.17, n.4, July/August 2000, p.26-32. [21] SIQUEIRA, F. L.; GIORGI, R. P.; USHISIMA, R. T. Mtodo de Comparao e anlise de metodologias para o desenvolvimento de um sistema de discusso e colaborao. Escola Politcnica, 2002. [22] SOMMERVILLE, I. Software Engineering. 6 ed. Addison Wesley, 2001.

Pgina 20