2 MTODOS GEIS

O desafio mais comum dentro do desenvolvimento de software, entregar um produto que atenda as reais necessidades do cliente, dentro do prazo e oramento previstos. E como suporte a esta atividade, a Engenharia de Software oferece vrios mtodos que auxiliam os desenvolvedores durante o processo de desenvolvimento. A indstria do software sempre contou com mtodos cujo processo de desenvolvimento era baseado em um conjunto de atividades predefinidas, descritas como processos prescritivos (AMBLER 2004), onde muitas vezes, o trabalho comeava com o levantamento completo de um conjunto de requisitos, seguido por um projeto de alto-nvel, de uma implementao, de uma validao e, por fim de uma manuteno (SOMMERVILLE 2003). Entretanto, segundo Fowler (2001), estes mtodos so considerados muito burocrticos e eficientes para projetos grandes e que no sofram muitas mudanas em seus requisitos. A partir da dcada de 90, comearam a surgir novos mtodos sugerindo uma abordagem de desenvolvimento gil onde os processos adotados tentam se adaptar s mudanas, apoiando a equipe de desenvolvimento no seu trabalho (BECK, et. al., 2001). Estes novos mtodos surgiram como uma reao aos mtodos tradicionais5 de desenvolvimento de software, ganhando com o passar dos anos um nmero cada vez maior de adeptos. Com o intuito de definir um manifesto para encorajar melhores meios de desenvolver software, em fevereiro de 2001 um grupo inicial de 17 metodologistas, entre eles, Robert C. Martin, Jim Highsmith, Kent Beck, Mike Beedle, Alistair Cockburn, Martin Fowler, Steve Mellor, Ken Schwaber, Jeff Sutherland, e outros, formou a Aliana para o Desenvolvimento gil de Software, tambm conhecida como Aliana gil, que formulou um manifesto contendo um conjunto de princpios que definem critrios para os processos de desenvolvimento gil de software (AMBLER 2004).

Segundo Fowler (2003), os mtodos que utilizam processos prescritivos so conhecidos como mtodos tradicionais.

19

O Manifesto gil baseado em quatro valores, definindo preferncias e encorajando o enfoque em certas reas. A seguir sero apresentados os valores do Manifesto gil de acordo com Beck et. al.(2001). Indivduos e interaes valem mais que processos e ferramentas. Um software funcionando vale mais que uma documentao extensa. A colaborao do cliente vale mais que a negociao de contrato. Responder as mudanas vale mais que seguir um plano.

Para auxiliar as pessoas a compreender o enfoque do desenvolvimento gil, os membros da Aliana gil refinaram as filosofias contidas em seu manifesto em uma coleo de doze princpios (BECK, et. al. 2001), aos quais os mtodos geis de desenvolvimento de software devem se adequar. Estes princpios so: 1. A prioridade satisfazer ao cliente atravs de entregas de software de valor contnuas e freqentes. 2. Receber bem as mudanas de requisitos, mesmo em uma fase avanada, dando aos clientes vantagens competitivas. 3. Entregar softwares em funcionamento com freqncia de algumas semanas ou meses, sempre na menor escala de tempo. 4. As equipes de negcio e de desenvolvimento devem trabalhar juntas diariamente durante todo o projeto. 5. Manter uma equipe motivada fornecendo ambiente, apoio e confiana necessrios para a realizao do trabalho. 6. A maneira mais eficiente da informao circular dentro da equipe atravs de uma conversa face-a-face. 7. Ter o software funcionando a melhor medida de progresso. 8. Processos geis promovem o desenvolvimento sustentvel. Todos envolvidos devem ser capazes de manter um ritmo de desenvolvimento constante.

20

9. Ateno contnua a excelncia tcnica e a um bom projeto aumentam a agilidade. 10. Simplicidade essencial. 11. As melhores arquiteturas, requisitos e projetos provm de equipes organizadas. 12. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz e ento se ajustar e adaptar seu comportamento. De acordo com Fowler (2001), os mtodos geis podem ser considerados como um meio termo entre a ausncia de processo e o processo exagerado. Como exemplo pode-se citar a gerao de documentao. A documentao continua fundamental, mas a preocupao deve ser em no desperdiar tempo com a criao de documentos que no sero teis. O planejamento tambm deve ser utilizado, mas com a conscincia de que os planos podem sofrer alteraes (FOWLER, 2001). Basicamente os mtodos geis se diferem dos tradicionais em 2 aspectos: a) so adaptativos ao invs de prescritivos; b) so orientados s pessoas ao invs dos processos. Vale salientar que os mtodos geis no so contra os modelos de processo de desenvolvimento tradicionais. Eles propem uma alternativa que busca a melhoria do processo, tornando-o mais gil e menos burocrtico. Existem vrios mtodos classificados como geis a disposio das equipes de desenvolvimento. Tais mtodos possuem em comum o fato de serem aplicados em projetos no muito complexos, utilizando ciclos iterativos curtos, planejamento guiado por funcionalidades, retroalimentao constante, tolerncia a mudanas, proximidade da equipe, intimidade com o cliente, e um foco no ambiente geral de trabalho do time (HIGHSMITH 2001). Entretanto, ao longo do estudo realizado neste trabalho, constatou-se que os mtodos geis estudados, da mesma forma que apresentam caractersticas comuns, apresentam tambm algumas diferenas, principalmente no que diz respeito s prticas utilizadas durante o processo de desenvolvimento e os papis da equipe. Sendo assim,

21

ser a partir da anlise destas semelhanas e diferenas que este trabalho apresentar uma proposta de unificao para os mesmos. A escolha dos mtodos geis para fazerem parte do framework no se deu de forma aleatria e sim de forma seqencial medida que cada um deles foi surgindo como oportunidade de estudo. Entretanto, o tempo disponvel para o desenvolvimento do presente trabalho no possibilitou que fossem incorporados outros mtodos geis alm dos citados anteriormente, sendo assim optou-se por selecionar uma primeira frao dos mtodos geis existentes para fazerem parte do framework que ser apresentado neste trabalho. Convm salientar que existe a inteno de dar continuidade a esta pesquisa de forma que o framework contemple outros mtodos considerados geis. Nas prximas sees sero apresentadas as principais caractersticas dos mtodos geis XP, Scrum, FDD, ASD e AM. Incluindo, uma viso geral, as suas prticas, seu processo de desenvolvimento, bem como os papis de cada um dos envolvidos no projeto.

2.1 Extreme Programming (XP)

O Extreme Programming (Programao Extrema) um mtodo eficiente, flexvel e de baixo risco para equipes pequenas e mdias que desenvolvem software com requisitos dinmicos ou em constante mudana (BECK, 2000). O criador do XP foi Kent Beck que aplicou pela primeira vez o mtodo em 1996 em um projeto chamado Chrysler Comprehensive Compensation (C3) para a empresa DaimlerChrysler. O XP segue um conjunto de valores, princpios e prticas bsicas adotado durante o processo de desenvolvimento por uma equipe dividida em papis especficos, visando alcanar eficincia e efetividade (BECK, 2000). Segundo Highsmith (2002a), a adoo do XP pelo mercado de desenvolvimento de software, se encontra em constante crescimento frente aos mtodos tradicionais devido reduo de custos, rapidez no desenvolvimento e adequao a mudana dos requisitos.

22

2.1.1 Os Valores do XP
Beck (2000) afirma que o sucesso de qualquer projeto depende da adoo de um estilo, que contempla um conjunto consistente de valores que servem para necessidades tanto humanas quanto comercias. A seguir sero apresentados os quatro valores adotados pela XP, de acordo com Beck (2000): Comunicao: o primeiro valor do XP. O objetivo uma comunicao rpida e ao mesmo tempo eficaz entre os stakeholders, por exemplo: d-se preferncia sala de discusso (chat) a correio (e-mail), telefonemas a chat, conversas face-a-face a telefonemas, trabalhar na mesma sala a ter salas isoladas. Simplicidade: o segundo valor do XP. O objetivo simplificar continuamente o software. Simplicidade e comunicao esto diretamente relacionadas, pois quanto maior a comunicao, mais fcil a identificao do que realmente necessita ser feito e vice-versa, e como conseqncia tem-se um software mais simples. Feedback: o terceiro valor do XP. Todo problema evidenciado o mais cedo possvel, tanto pelo cliente como pela equipe de desenvolvimento, para que possa ser corrigido. O feedback concreto trabalha junto com a comunicao e a simplicidade. Coragem: Quando combinada com os trs primeiros valores extremamente valiosa. preciso coragem para pedir ajuda quando necessrio, reconstruir e simplificar o cdigo que est funcionando, bem como para expor ao cliente que o prazo estimado para implementar determinada funcionalidade no suficiente.

2.1.2 As Prticas do XP
A maioria das prticas sugeridas pelo XP causa polmica primeira vista e muitas no fazem sentido se aplicadas isoladamente. Segundo Beck (2000), nenhuma prtica consegue se manter por si s. a sinergia de seu conjunto que sustenta o processo de desenvolvimento do XP. A seguir sero apresentadas estas prticas de acordo com Beck (2000), Jeffries (2001), Astels (2002) e Fowler (2001): Jogo do Planejamento - Os participantes do jogo do planejamento so o cliente e os programadores. O cliente decide sobre: escopo, prioridade, composio e datas

23

das entregas. As responsabilidades dos programadores incluem: estimativas de tempo de desenvolvimento para cada funcionalidade, avaliao dos riscos tcnicos e deciso sobre o processo de trabalho. O jogo do planejamento do XP divide-se em duas etapas chaves: Planejamento da Entrega e Planejamento da Iterao (JEFFRIES, 2001). O Planejamento da Entrega uma atividade onde o cliente apresenta as funcionalidades desejadas aos programadores, e os programadores estimam a sua dificuldade. Com as estimativas das dificuldades disponveis e com o conhecimento da importncia das funcionalidades, o cliente apresenta um plano para o projeto contendo estas informaes. Inicialmente, nem as prioridades nem as estimativas so verdadeiramente slidas, at que a equipe comece realmente a executar o trabalho. O Planejamento da Iterao onde a equipe de desenvolvimento (programadores) recebe orientao atravs das user stories (histrias de usurio) que apresentam informaes a respeito das funcionalidades do sistema (BECK, 2000). A equipe de desenvolvimento constri um software em iteraes que duram de 1 a 4 semanas, entregando um software executvel e til no fim de cada iterao. Durante o Planejamento da Iterao, o cliente apresenta as user stories desejadas para a prxima iterao. Os programadores dividem as user stories em tarefas e estimam o tempo de desenvolvimento (em um nvel mais detalhado que no Planejamento da Entrega). Entregas Freqentes - Ao trmino de cada iterao feita uma entrega, que deve ser to pequena quanto possvel, contendo as user stories mais importantes (BECK, 2000). A equipe libera um software rodando, com as user stories escolhidas pelo cliente para aquela iterao. O cliente poder utilizar este software para avaliao ou para liberar aos usurios finais (JEFFRIES, 2001). O principal objetivo desta prtica que o progresso do software pode ser monitorado tanto pelo cliente quanto pelos programadores. Metfora - O projeto de software no XP guiado por uma metfora simples (BECK, 2000). A metfora ajuda a manter toda a equipe em sintonia com o projeto. Segundo Astels (2002), cada projeto do XP deve fazer uso de no mnimo uma metfora para orientar a equipe e fornecer um contexto compartilhado. Tendo uma metfora compartilhada, todos compartilham de uma viso geral do sistema e do problema que deve ser solucionado. 24

Projeto Simples - O XP mantm o projeto o mais simples possvel. Se o projeto for simples, ele permanece gil e flexvel. Para manter um projeto simples, necessria uma reviso contnua (ASTELS, 2002). A equipe XP no desenvolve um grande projeto inicial, mas projeta continuamente durante todo o tempo (FOWLER, 2001).

Testes - Os programadores escrevem testes de unidade e os clientes testes de aceitao freqentemente com o objetivo de tornar o software cada vez mais confivel. No XP, os testes de unidade so escritos anteriormente ao processo de codificao e s aps so executados. Os testes de unidade tm como funo, obrigar os programadores a analisar melhor o que efetivamente ser codificado. Para cada user story escrito no mnimo um teste de aceitao. Os mesmos so escritos com base na seguinte questo: O que precisaria ser conferido para se ter certeza de que uma determinada user story est OK?. Os clientes escrevem textualmente as respostas para este questionamento e executam os testes no incremento entregue. Os resultados destes testes devem ser publicados para toda a equipe.

Refactoring - O XP usa um processo contnuo de melhoria de projeto chamado refactoring. Refactoring a tcnica empregada na reestruturao do cdigo, cujo principal objetivo fazer com que o mesmo fique mais reutilizvel e compreensvel, sem que haja mudana no seu comportamento (FOWLER, 2001). Deve-se fazer refactoring onde for possvel e sempre que possvel.

Programao em pares: Segundo Jeffries (2001), Todo software produzido em XP construdo por dois programadores, sentados lado a lado, na mesma mquina. Esta prtica assegura que todo cdigo produzido revisado por, pelo menos, outro programador. O resultado um aumento na velocidade do desenvolvimento, com testes mais eficazes e um cdigo otimizado. importante observar que existem dois papis em cada par. O parceiro que est com o teclado e o mouse responsvel por pensar na melhor forma de implementar o mtodo corrente. Enquanto o outro parceiro analisa estrategicamente se a abordagem utilizada ir funcionar, se existe algum teste que ainda no foi trabalhado e se existe alguma forma para simplificar o cdigo (BECK, 2000).

Propriedade coletiva - A qualquer momento, qualquer um que perceba uma oportunidade de agregar valor a alguma parte do cdigo deve faz-lo. Segundo Beck 25

(2000), em um projeto XP todos so responsveis por todo o sistema. Isto no quer dizer que todos devam conhecer o cdigo igualmente bem, mas todos devem saber o mnimo de cada parte. Um bom sistema de controle de verses importante para garantir a aplicao desta prtica. Integrao contnua - As equipes XP mantm o sistema integrado todo o tempo. O cdigo integrado e testado depois de algumas horas, no mximo depois de um dia de desenvolvimento. A forma mais simples para fazer isto ter um servidor dedicado para a integrao (BECK, 2000). Tambm nesta prtica, um sistema de controle de verses importante. Cada par de programadores responsvel por integrar seu prprio cdigo. Isto pode ser feito quando os testes de unidade tenham sido executados 100% em cada funcionalidade planejada. A integrao contnua evita ou descobre problemas de compatibilidade cedo. Semana de 40-horas - No recomendvel fazer horas extras por perodos maiores que uma semana. Como tambm no produtivo passar a noite acordado e trabalhar no dia seguinte. Um programador quando est cansado raciocina mais lentamente e fica mais distrado, a conseqncia disto pode ser o desenvolvimento de cdigo com erros, erros que vo dar trabalho para serem corrigidos e exigir mais horas extras. De acordo com Beck (2000), a sobrecarga de trabalho sintoma de srios problemas no projeto. Cliente presente - Um cliente real deve estar sempre disponvel, no somente para auxiliar, mas para fazer parte da equipe. Beck (2000) define por cliente real aquele cliente que realmente ir utilizar o sistema quando ele estiver em produo. Assim, o cliente poder fornecer detalhes do sistema quando surgirem dvidas. Se o cliente estiver sempre por perto, significa que toda e qualquer dvida pode ser prontamente esclarecida permitindo um controle maior do que est realmente sendo implementado. Entretanto, algumas vezes, no possvel que o cliente esteja no mesmo local de trabalho que os programadores. Ainda assim, possvel trabalhar com XP, desde que se tenha um canal aberto de comunicao. Nestes casos, indicado o uso de ambientes colaborativos atravs da Internet. Padres de codificao - As equipes XP seguem um padro de codificao comum a todos os membros. Desta forma, todo cdigo no sistema pode ser visto como se 26

fosse escrito por um nico programador. As particularidades do padro no so importantes: o que importante que todo o cdigo deve parecer familiar, em defesa da propriedade coletiva (JEFFRIES, 2001). A padronizao do cdigo mantm o mesmo consistente e fcil para toda a equipe entender e/ou fazer o refactoring. No importa qual o padro, o importante que exista um. O padro deve ser adotado voluntariamente por toda a equipe (BECK, 2000).

2.1.3 As Fases do Processo do XP

Segundo Beck (2000), o projeto ideal em XP aquele que inicia por uma curta fase de desenvolvimento, seguida de anos de produo e refinamentos simultneos e finalmente encerra quando o projeto no faz mais sentido. Durante todo o processo de desenvolvimento, podero ser feitas reunies dirias para que todos conheam aquilo em que todos esto trabalhando. O mtodo sugere que estas reunies sejam realizadas em p, garantindo mais agilidade BECK (2000). Como pode ser observado na Figura 1, o ciclo de vida do XP bastante curto e, primeira vista, difere dos padres dos modelos de processo convencionais.

Explorao

Planejamento

Iteraes para Entrega

Produo

Fim do Projeto
Breve documentao e reunio de avaliao do trabalho

Arquitetura do sistema e User Stories p/ a prxima iterao so priorizadas e estimadas

User Stories selecionadas

sim Existem mais user stories?

no

Modelagem - Programao Teste - Integrao se testes ok Entrega do incremento se verso no pronta para uso

Se testes no ok Mais testes

User Stories

se verso pronta para uso

Sistema colocado em produo

Manuteno

Figura 1. As Fases do Processo XP

27

2.1.3.1 Explorao O objetivo da fase de Explorao entender o real escopo do sistema. Este entendimento deve ser o suficiente para que ele possa ser estimado (BECK 2000). A fase de Explorao comea com o cliente escrevendo as user stories (Figura 2). Wake (2002) considera que user stories menores tendem a ter um risco menor. Ento, se uma user story for muito grande, o cliente deve dividir a user story em user stories menores. O segredo para o cliente escrever user stories teis, segundo Beck (2000), dar um feedback rpido logo nas primeiras user stories, para que ele aprenda a especificar o que os programadores precisam e no especificar o que eles no precisam.

Data: 22/12/2000

Nova: X

Dificuldade: Mdia Prioridade do Usurio: Alta Risco: Tcnico: Joo Camargo Estimativa do Tcnico: 20 h

Nmero da Histria: 005 - Criar Recibo Referncia Anterior: 001 Efetuar Venda

Descrio: Manter um recibo aberto com uma descrio breve de cada item escaneado e seu preo. Quando a venda for concluda, incluir o total na parte inferior do recibo. Notas: Acompanhamento da tarefa Data Estado

A realizar

Comentrio

Figura 2. Exemplo de User Story. (adaptado de BECK, 2000).

Em paralelo s user stories, os programadores esto experimentando ativamente as diferentes tecnologias e as possveis configuraes, explorando as possibilidades para a arquitetura do sistema. Leva-se de 1 a 2 semanas testando a arquitetura, contudo esta deve ser testada de vrias maneiras, ou seja, diferentes pares podem testar diferentes tecnologias e comparar, ou dois pares podem testar a mesma tecnologia e comparar as diferenas emergentes. Se este perodo no for suficiente para estes testes, ento a mesma deve ser classificada como um risco para o projeto. Portanto, durante a fase de explorao pode-se convidar um especialista na tecnologia 28

escolhida, o qual no ir perder tempo com pequenos problemas, pois sabe por experincia como resolv-los. Beck (2000) ressalta que esta pequena explorao na arquitetura auxilia os programadores a terem uma idia da implementao quando o usurio apresentar suas user stories, pois como ser visto na prxima fase, os programadores precisam estimar cada tarefa de programao. Quando uma tarefa feita, eles precisam repassar para o calendrio o tempo gasto para executar aquela tarefa. A prtica da estimativa cria confiana na equipe para quando eles realmente tiverem que estimar o tempo de implementao. 2.1.3.2 Planejamento O objetivo da fase de Planejamento definir a menor data e o maior conjunto de user stories que sero realizadas na primeira entrega. Esta definio feita de acordo com estimativas entre cliente e programadores (BECK, 2000). Assim que as user stories so coletadas, o Jogo de Planejamento conduzido. O cliente decide quais user stories so vitais e que devem fazer parte da primeira entrega. Desta forma, pode-se elaborar uma lista priorizada das user stories. Se houver uma boa preparao durante a fase de Explorao, so necessrios apenas alguns dias para a fase de Planejamento. Wake (2002) apresenta alguns passos para auxiliar a fase de Planejamento durante o Jogo de Planejamento: o cliente classifica as user stories por valor: alto, mdio ou baixo; os programadores qualificam as user stories por risco (opcional): alto, mdio ou baixo; os programadores estimam o tempo para o desenvolvimento das user stories. O tempo empiricamente determinado, ou seja, baseado na experincia dos programadores; clientes escolhem as user stories para a prxima entrega.

29

2.1.3.3 Iteraes para Entrega Segundo Beck (2000), os compromissos so divididos para serem executados em iteraes que duram de 1 a 4 semanas. Para cada user story executada que faz parte da iterao escrito um ou mais de teste(s) de aceitao pelo cliente. E antes da implementao os programadores escrevem os testes de unidade. Segundo Ambler (2004), nesta fase que ocorre o maior trabalho de desenvolvimento, incluindo modelagem, programao, escrita e execuo dos testes de unidade e aceitao e integrao. A primeira iterao mostra como a arquitetura do sistema ir se comportar. Ento, as user stories escolhidas devem ser as que influenciaro diretamente na mesma. A pergunta chave para ser trabalhada nesta fase : Qual a coisa de maior valor para a equipe para ser trabalhada nesta iterao? (BECK, 2000). Uma importante caracterstica do XP que ele recomenda que sejam implementadas somente as funcionalidades que estejam marcadas para a iterao corrente (WELLS, 2001). Desta forma, o prazo final de cada iterao ser seriamente respeitado, permitindo analisar qual a real velocidade do projeto durante a mesma. Ento, o conjunto de user stories que faro parte da nova iterao estar melhor estimado. No final de cada iterao o cliente ter completado a execuo de todos os testes de aceitao e os programadores executam os testes de unidade escritos antes da implementao. No final de cada iterao, o cliente receber uma nova verso do sistema e o mesmo estar pronto para entrar em produo. 2.1.3.4 Produo Esta fase comea no final da primeira iterao e segundo Ambler (2004), entrar em produo significa lanar o sistema no ambiente real de trabalho do cliente. Devem-se implementar novos testes para provar se o sistema est estvel o suficiente para entrar em produo. Pode ser necessrio apenas ajustar o desempenho. E este o melhor momento para realizar estes ajustes, pois se tem mais conhecimento do projeto, assim como existe a possibilidade de realizar estimativas reais de sobrecarga de produo do sistema.

30

Segundo Beck (2000), esta fase no significa que o sistema est concludo, o software continuar evoluindo, pois como o sistema est em produo, o cliente ainda pode descobrir novas necessidades ou mesmo alter-las, neste caso o processo reinicia novamente na fase de Planejamento. 2.1.3.5 Manuteno De acordo com Ambler (2004), a fase de Manuteno o estado normal de um projeto XP, e compreende as fases de Planejamento, Iteraes para a Entrega (a partir da segunda iterao) e Produo at a entrega final do sistema. Como conseqncia, esta fase inclui atividades, como a operao e o suporte ao sistema atravs de um help desk por exemplo BECK (2000). 2.1.3.6 Fim do Projeto Beck (2000) considera que Morrer bem to importante quanto viver bem. Isto uma verdade para o XP como para as pessoas. Quando no mais existir novas estrias, o momento de finalizar o projeto. o momento de escrever algumas pginas (de 5 a 10 pginas) sobre as funcionalidades do sistema, onde o resultado ser um documento para auxiliar os desenvolvedores na realizao de alguma alterao futura no sistema, se for o caso. Uma boa razo para finalizar o projeto o cliente estar satisfeito com o sistema e no ter mais nada que consiga prever para o futuro. Toda a equipe que trabalhou no sistema deve ser reunida para uma reavaliao. Aproveitando a oportunidade para analisar o que pode ter causado problemas no sistema e o que fez o projeto avanar.

2.1.4 A Equipe do XP
O XP sugere a adoo de diferentes papis para a execuo do projeto. A seguir, estes papis so apresentados de acordo com Beck (2000). O Programador o corao do XP e responsvel por: Estimar prazos das user stories; Escrever e executar os testes de unidade; Implementar o sistema; Trabalhar em par; Fazer refactoring sempre que necessrio; Solicitar ao cliente que esclarea ou divida uma estria quando necessrio.

31

O Cliente outro papel essencial do XP. Enquanto o programador sabe como programar, o cliente sabe o que deve ser programado. Suas responsabilidades so: Definir as funcionalidades do software; Escrever as user stories; Definir as prioridades para as user stories; Escrever e executar os testes de aceitao e esclarecer dvidas sempre que solicitado. O Testador no XP tem o papel realmente focado no cliente. Tem por responsabilidade: Auxiliar os clientes a escrever os testes aceitao; Executar os testes que forem solicitados e publicar os resultados para a equipe. O Rastreador a conscincia da equipe, sua responsabilidade : Coletar sinais vitais do projeto (mtricas) 1 ou 2 vezes por semana; Manter todos informados do que est acontecendo e tomar atitudes sempre que as coisas parecerem ir mal. O Treinador responsvel pelo processo de desenvolvimento como um todo. Notifica as pessoas quando elas esto se desviando do processo e conduz a equipe novamente para o mesmo. O treinador tem a funo de: Garantir que o projeto permanea extremo; Ajudar com o que for necessrio; Manter a viso do projeto; Formular e comunicar uma tarefa na qual um programador deseja trabalhar. O Consultor um membro externo que possui o conhecimento tcnico especfico necessrio e responsvel por auxiliar a equipe na resoluo de problemas especficos. O Gerente a pessoa que precisa transmitir coragem, confiana e saber cobrar o que de responsabilidade de cada um. O gerente tem vrias responsabilidades: Gerenciar a equipe e seus problemas; Agendar as reunies de planejamento; Garantir que as reunies fluam como planejado; Escrever o que foi definido nas reunies; Manter o rastreador informado dos acontecimentos das reunies e buscar recursos. Segundo Beck (2000), existem alguns inconvenientes que podem fazer o mtodo fracassar, entre eles: grandes equipes, sistemas muito complexos, escolha de tecnologias que no suportam adequadamente modificaes, rotinas e ambientes de trabalho imprprios e o mais importante, a cultura empresarial. Beck (2000) sugere que o mtodo seja adotado gradualmente para no causar grande impacto dentro da organizao e que a equipe de desenvolvimento seja composta 32

por, no mximo, 10 pessoas. O ambiente fsico tambm importante, a equipe deve trabalhar em um mesmo lugar, possibilitando uma melhor comunicao. Algumas empresas que utilizam o mtodo XP com sucesso so: Ford, Symantec, BMW, Borland, entre outras, (ASTELS, 2002).

2.2 SCRUM
O Scrum6 um mtodo gil que possui como objetivo principal a entrega de um software de qualidade dentro de iteraes, formadas por pequenos intervalos de tempo definidos chamados Sprints7 que possuem aproximadamente um ms de durao (BEEDLE, 1998). O mtodo baseado em princpios semelhantes aos do XP: requisitos pouco estveis ou desconhecidos, e iteraes curtas para promover visibilidade ao desenvolvimento, resultando em flexibilidade, receptividade e confiabilidade (SCHWABER e BEEDLE 2002).

2.2.1 As Prticas do Scrum

De acordo com Schwaber e Beedle (2002), o Scrum no requer ou fornece qualquer mtodo especfico para desenvolvimento de software, apenas estabelece um conjunto de regras e prticas gerenciais que devem ser adotadas para o sucesso de um projeto que utilize o mtodo A seguir, sero apresentadas as prticas do Scrum de acordo com Schwaber e Beedle (2002). Product Backlog: define tudo o que necessrio no produto final baseado no conhecimento atual. o ponto de partida do Scrum onde so definidas as funcionalidades, as prioridades, a tecnologia e as estratgias. A definio destes itens pode ser feita por qualquer pessoa ou setor envolvidos no projeto. Para algum item ser adicionado ao Product Backlog necessrio que a equipe esteja de acordo. Os itens do Product Backlog so documentados (Figura 3) com as seguintes

A origem do termo Scrum uma metfora a uma ttica utilizada do jogo de Rugby para recuperar a bola perdida. 7 O termo sprint em ingls quer dizer corrida de curta distncia.

33

informaes: uma descrio sucinta, uma estimativa, que dever sempre ser estipulada em horas, um responsvel e uma prioridade (muito alta, alta e mdia). Para facilitar a visualizao sugerido que os itens sejam separados por prioridade.

Prioridade Muito Alta

Item 1 2 3

Descrio Conexo com o Banco de Dados ... Cadastro de Usurios

Tempo Estimado 40 ... ...

Responsvel Ana ... Joo

Alta 4 5 6 Mdia 7 8
9

..

Impresso de Relatrios ...

...

...

Figura 3. Exemplo de Itens do Product Backlog

Sprint: Considerada a parte mais importante do Scrum. onde so executados os itens definidos no Product Backlog. Cada Sprint deve durar no mximo 30 dias. No existem processos pr-definidos dentro de uma Sprint, mas sim reunies peridicas (Reunies Dirias do Scrum) que coordenam a realizao das atividades existentes. criado um Sprint Backlog com os itens selecionados para serem trabalhados na Sprint corrente. Ao final de cada Sprint, segundo Beedle (1998), criada uma pequena verso do software, com o objetivo de mostrar ao cliente o que est sendo desenvolvido. Na Sprint acontece a integrao da parte software que foi desenvolvida com as outras partes j implementadas e so feitos testes, garantindo um progresso real das atividades. Uma nova Sprint comea com um novo conjunto de itens no Sprint Backlog, sendo assim, dentro do desenvolvimento Scrum, podem acontecer N Sprints. Schwaber (1995) ressalta que o desenvolvimento dos itens dentro de uma Sprint no segue nenhum processo pr-definido, enquanto Abrahamsson (2002) sugere o uso das fases tradicionais de desenvolvimento de software: anlise, projeto, implementao, testes e entrega. Outra sugesto seria a combinao de outros mtodos geis que possuem processos definidos nesta fase.

34

Sprint Backlog: o ponto de partida para cada Sprint. Consiste em um conjunto de funcionalidades selecionadas do Product Backlog para serem implementadas durante a Sprint. Os itens so selecionados pelo Scrum Team em conjunto com o Scrum Master e o Dono do Produto na Reunio de Planejamento da Sprint, de acordo com as prioridades dos itens. Quando todos os itens do Sprint Backlog estiverem prontos, um novo incremento do sistema entregue.

Reunio de Planejamento da Sprint: Cada Sprint inicia com uma reunio chamada de Reunio de Planejamento da Sprint, que tem por objetivo analisar os itens do Product Backlog a fim de prioriz-los para o desenvolvimento e, assim, definir o Sprint Backlog.

Reunies Dirias do Scrum: De acordo com Linda (2000), as Reunies Dirias do Scrum so realizadas diariamente ou em dias alternados e possuem durao de 15 a 30 minutos, no mximo. Este tempo suficiente para identificar os problemas, mas no para definir solues. Discusses para resoluo de obstculos so feitas mais tarde, onde somente os envolvidos no problema participam. Segundo Schwaber e Beedle (2002), durante as Reunies Dirias do Scrum so levantadas as trs seguintes questes para cada membro da equipe: O que foi finalizado desde a ltima reunio? (So registradas quais tarefas foram completadas e quais ainda esto pendentes). Quais as dificuldades encontradas durante o trabalho? (So registradas todas as dificuldades encontradas para mais tarde encontrar uma maneira de resolv-las). Quais atividades pretende-se realizar at a prxima reunio? (So escolhidas as tarefas mais importantes. Devido ao curto espao de tempo entre as reunies, as tarefas so geralmente pequenas). A reunio tambm possibilita que todas as pessoas fiquem informadas sobre o

progresso e as dificuldades encontradas. Reviso da Sprint: No ltimo dia de cada Sprint, o Scrum Team e o Scrum Master apresentam o incremento para o cliente, gerente e Dono do Produto numa reunio informal. Os participantes avaliam o incremento do produto e decidem sobre as 35

atividades seguintes. Na reunio podero ser adicionados novos itens ao Product Backlog.

2.2.2 As Fases do Processo do Scrum

Como em todos processos de desenvolvimento de software, no Scrum h uma etapa onde so definidos os requisitos, uma onde acontece o desenvolvimento dos mesmos e por fim acontece a entrega final do sistema. A Figura 4 ilustra as fases do processo Scrum.

PreGame

Desenvolvimento
Requisitos completos

PostGame

Updates Regulares

Sprint Backlog Anlise Projeto Implementao Testes Entrega Integrao

Teste do Sistema

Planejamento Product Backlog Arquitetura Prtica: Product Backlog

Objetivos p/ o prximo Sprint Requisitos

Entrega Final

Documentao

Sprint

Novo Incremento

Figura 4. Fases do Processo Scrum A seguir, as fases do Scrum so apresentadas de acordo com Schwaber e Beedle (2002). 2.2.2.1 PreGame A fase de PreGame possui duas sub-fases: Planejamento e Arquitetura. A sub-fase de Planejamento inclui a definio do sistema que est sendo desenvolvido. O Product Backlog criado contendo todos os requisitos que so conhecidos at o momento. Os requisitos so priorizados e logo aps calculado o 36

esforo necessrio para a sua implementao. O Product Backlog constantemente atualizado com novos itens ou com itens mais detalhados, bem como com estimativas mais precisas e novas ordens de prioridade. O Planejamento inclui tambm a definio da equipe, ferramentas e outros recursos, avaliao dos riscos e treinamentos necessrios. A cada iterao, o Product Backlog atualizado revisado pela Equipe Scrum. Na sub-fase de Arquitetura, feito um projeto do sistema baseado nos itens atuais do Product Backlog. No caso de alguma alterao nos itens atuais, so identificadas as mudanas necessrias para implementar os itens do Product Backlog juntamente com os problemas que podero surgir com estas alteraes. realizada uma reunio para revisar o projeto e reavaliar a proposta de implementao, logo aps, so tomadas decises com base nesta reviso. 2.2.2.2 Desenvolvimento Tambm conhecida por GamePhase, nesta fase o sistema desenvolvido atravs de vrias Sprints, onde as funcionalidades so desenvolvidas ou modificadas em ciclos iterativos com a finalidade de produzir novos incrementos. Nesta etapa so utilizadas as prticas da Sprint, Sprint Backlog, Reunio de Planejamento da Sprint, Reunies Dirias do Scrum e Reviso da Sprint. 2.2.2.3 PostGame Na fase de PostGame, acontece a entrega final do software. Nela, os requisitos esto completos. Neste caso, no podem ser encontrados, tampouco adicionados novos itens. hora de realizar mais testes de sistema e gerar uma breve documentao.

2.2.3 A Equipe do Scrum

De acordo com Schwaber e Beedle (2002), existem quatro papis identificados no Scrum. Estes possuem tarefas e propsitos distintos durante o processo e suas prticas. A seguir, sero apresentadas as responsabilidades associadas a estes papis. O Scrum Master assegura que o projeto est sendo desenvolvido de acordo com as prticas e regras do Scrum. Tem como responsabilidades: Organizar as reunies dirias; Representar o gerente do projeto e o tcnico; Gerenciar todo processo do Scrum

37

na empresa; Assegurar que qualquer impedimento ser resolvido e interagir com todos os envolvidos no projeto. O Dono do Produto a pessoa responsvel pelo Product Backlog. Para desempenhar este papel necessrio que o Dono do Produto execute as seguintes funes: Tomar as decises finais relacionadas ao Product Backlog; Liberar e escolher os itens que sero trabalhados no Sprint Backlog e calcular o esforo para o desenvolvimento de cada item. O Scrum Team, em conjunto com o Scrum Master, executa as aes necessrias para atingir os objetivos de cada Sprint. O Scrum Team deve ter no mximo sete pessoas e possui as seguintes responsabilidades: Determinar a criao do Sprint Backlog; Revisar os itens do Product Backlog e os impedimentos que por ventura venham a surgir; Trabalhar nos itens do Sprint Backlog e sugerir o que necessita ser acrescentado ou removido no projeto. O Cliente participa ativamente na fase da elaborao dos itens que iro compor o Product Backlog. Segundo Schwaber e Beedle (2002), no existem restries quanto ao tamanho e complexidade de projetos para a utilizao do Scrum. Entretanto, em projetos maiores podem ocorrer problemas em relao ao gerenciamento das mudanas dos requisitos, em relao as equipes de desenvolvimento e trocas de pessoal. Caso exista a necessidade de equipes com mais de 7 pessoas (quantidade mxima recomendada), sugerido que as equipes sejam divididas em equipes menores. Caso haja equipes mltiplas, o projeto no deve iniciar com todas as equipes ao mesmo tempo, e sim, com uma nica equipe. O restante das equipes devem ser incorporadas ao projeto aps a primeira Sprint. Por se tratar de um mtodo que no necessita de um alto investimento financeiro, o Scrum pode ser uma boa alternativa para as organizaes que desejam acelerar o seu processo de desenvolvimento.

38

2.3 Feature Driven Developent (FDD)

O Feature Driven Development (Desenvolvimento Dirigido a Caractersticas) foi desenvolvido por Peter Coad e Jeff De Luca e foi utilizado pela primeira vez no desenvolvimento de um grande e complexo projeto de um sistema bancrio em 1998. Como os outros mtodos geis, o FDD focado em pequenas iteraes que geralmente duram 2 semanas, onde ao final ocorre a entrega de uma parte do sistema funcionando (HIGHSMITH 2002a). Segundo Palmer (2002), uma caracterstica uma funcionalidade definida pelo cliente. A seguir sero apresentadas as prticas, as fases do processo de desenvolvimento do mtodo, os papis que compe a sua equipe e por fim algumas consideraes a respeito da sua aplicabilidade.

2.3.1 As Prticas do FDD

Segundo Abrahamsson (2002), o FDD consiste em um conjunto de prticas que devem ser usadas para garantir o sucesso da utilizao do mtodo em um projeto de software. A seguir sero apresentadas as prticas segundo Palmer (2003): Modelagem dos Objetos de Domnio: Consiste na construo de diagramas de classes UML8 (Unified Modeling Language) que descrevem os objetos relevantes dentro do domnio do problema, bem como os relacionamentos entre eles. Para complementar os diagramas de classe UML, so desenvolvidos diagramas de seqncia UML que descrevem explicitamente como os objetos interagem para cumprir suas responsabilidades. Desenvolver um modelo dos objetos de domnio fora a resoluo de problemas prematuramente, mantendo a integridade conceitual do sistema e reduzindo a quantidade de tempo que uma equipe gasta para fazer o refactoring das suas classes, caso precise adicionar uma nova caracterstica. Uma cnica sugerida pelos autores para modelar os objetos de domnio a Object Modeling in Color with UML9.

8 9

Para maiores informaes sobre a UML consultar BOOCH (1999). Tcnica proposta por Peter Coad no livro Java Modeling in Color with UML (Unified Modeling Language) que consiste na utilizao de cores, padres e estratgias para a representao de diagramas de classe.

39

Desenvolvendo atravs de caractersticas:

feita a identificao das

caractersticas do sistema atravs de modelos de casos de uso, user stories (que podem ser incorporadas do XP) ou qualquer outra ferramenta que sirva para descrever os requisitos do sistema. Tradicionalmente, as caractersticas identificadas so divididas em grupos representados atravs de uma lista hierrquica. Aps ser definida a lista de caractersticas, inicia-se o projeto e a construo de cada uma delas. Uma vez identificadas, as caractersticas sero utilizadas para guiar o desenvolvimento no FDD, o objetivo mostrar o progresso atravs da implementao das mesmas. A caracterstica ou conjunto de caractersticas selecionadas para serem implementadas durante a iterao devem ser executadas dentro de 2 semanas. Este o limite mximo. Segundo Palmer (2003), toda caracterstica poderia ser descrita utilizando o seguinte padro: <ao> <artigo> <resultado> <preposio> <artigo> <objeto>. Por exemplo, calcular o total da venda. Todas as caractersticas devem ser agrupadas de acordo com a mesma rea do negcio, onde o nome do grupo deve obedecer ao seguinte padro: <ao verbo no particpio> <artigo> <objeto>. Por exemplo, Comprando um produto ou Realizando o pagamento. Propriedade Individual da Classe: Esta prtica sugere que exista um responsvel para cada classe ou conjunto de classes. Algumas vantagens da propriedade individual da classe so: o Um indivduo responsvel pela integridade conceitual de uma classe. Quando novos mtodos forem adicionados a esta classe o proprietrio ter segurana de que o objetivo da classe ser mantido e que as modificaes sero feitas corretamente. O proprietrio do cdigo pode executar uma atualizao mais rapidamente do que um outro desenvolvedor que no esteja familiarizado com esta parte do cdigo. o O proprietrio do cdigo tende a fazer sempre melhor o que de sua total responsabilidade.

40

Algumas desvantagens da propriedade individual da classe so: o Pode acontecer de um desenvolvedor necessitar fazer modificaes em classes que dependem de mudanas que esto sendo feitas nas classes que so de outro desenvolvedor. Isto poderia resultar em perda de tempo at que os dois desenvolvedores entrassem em sintonia. o Caso o proprietrio da classe saia do projeto por alguma razo, isso acarretar na necessidade de um entendimento do funcionamento desta por outro desenvolvedor, ocasionando em perda de tempo. Equipes de Caractersticas: A prtica da propriedade individual da classe atribui classes a desenvolvedores especficos. Contudo, sabe-se que o desenvolvimento deve ser por caracterstica, assim necessrio organizar equipes para as mesmas. So escolhidos desenvolvedores para serem lderes de equipes e atribudo a eles um conjunto de caractersticas. Abaixo esto algumas consideraes sobre as equipes de caractersticas: o Uma equipe de caracterstica deve ter de 3 a 6 membros. o Por definio, uma equipe de caractersticas compreende todos os proprietrios das classes relacionadas ao desenvolvimento de uma caracterstica em particular. o Cada membro de uma equipe de caracterstica executa uma caracterstica sob a orientao de um desenvolvedor experiente. o Eventualmente, um proprietrio da classe pode trabalhar para uma outra equipe da caracterstica. Os desenvolvedores podem pertencer a 2 ou 3 equipes de caractersticas simultaneamente por um curto perodo de tempo. o Os programadores principais devem trabalhar em conjunto para resolver conflitos e para evitar sobrecarregar qualquer desenvolvedor em particular. Inspees: O FDD confia em inspees, feitas durante e ao final de cada iterao para assegurar a qualidade do projeto e do cdigo. O objetivo preliminar das inspees a deteco de defeitos. Todos necessitam ver as inspees como uma ferramenta para eliminao de erros e como uma grande oportunidade de aprendizado.

41

Construes Regulares: Construes regulares possibilitam a deteco de erros de integrao prematuramente. Uma construo regular assegura tambm que haja sempre um sistema atual e executvel para ser apresentado ao cliente. Estas construes acontecem durante as iteraes, onde acontece o desenvolvimento de um conjunto de caractersticas.

Administrao de Configurao: O FDD sugere a utilizao de um sistema de controle de verses para datar e manter um histrico das alteraes feitas em cada classe. Bem como, no que se refere aos requisitos, anlise e o projeto de modo que facilite a visualizao das modificaes feitas. Todo artefato utilizado durante o desenvolvimento do sistema candidato ao controle de verso. sugerido solicitar uma autenticao dos clientes e gerentes de projeto para cada modificao, dando uma certa segurana ao contrato comercial entre o cliente e a empresa que est desenvolvendo o produto.

Relatrio dos resultados: O FDD sugere que todos os resultados ocorridos durante o projeto sejam disseminados para todos os membros da equipe e clientes. Podem ser disponibilizados atravs de pginas na internet, relatrios impressos etc.

2.3.2 As Fases do Processo do FDD

Segundo Coad (1999), o FDD possui definies claras em relao s etapas do processo (Figura 5), pois se acredita que elas contribuem para o sucesso do projeto, fazendo com que os envolvidos no mesmo o sigam, evitando que busquem alternativas prprias que poderiam dificultar o seu andamento. O FDD possui o foco no projeto e construo e composto por cinco etapas: trs delas (desenvolver um modelo, construir uma lista de caractersticas e planejar cada uma delas) so realizadas no incio do desenvolvimento do sistema e as duas ltimas (projeto e construo de cada caracterstica) so completadas dentro de cada iterao.

42

Desenvolver um modelo global

Construir uma lista de caractersticas

Planejar a construo por caractersticas

Projetar Projeto cada Atravs de Caracterstica

Caractersticas

Construir cada Caracterstica

Enquanto existir caractersticas

Figura 5. Fases do Processo FDD.

A seguir, sero descritas as etapas do FDD de acordo com Highsmith (2002a), De Luca (2002) e Abrahamsson (2002). 2.3.2.1 Desenvolver um modelo global. a primeira etapa do processo no FDD, onde so definidos o contexto e os requisitos do software. As principais pessoas envolvidas nesta etapa so o Especialista do Domnio e o Projetista. A tarefa requerida nesta etapa a modelagem do domnio da aplicao, onde so construdos o diagrama de classe UML, o(s) diagrama(s) de seqncia UML e uma lista informal das caractersticas. 2.3.2.2 Construir uma lista de caractersticas. O objetivo da segunda etapa do processo no FDD, conforme apresenta Highsmith (2002a), construir uma lista completa de todas as caractersticas do produto a ser desenvolvido. Na lista, a equipe de desenvolvimento apresenta cada funo esperada pelo cliente baseada na lista de caractersticas gerada na etapa anterior, podendo ser necessria a incluso de novas classes no modelo de domnio, que dever tambm ser refeito, apresentando agora os atributos e os mtodos de cada classe. Cada caracterstica da lista apresenta uma estimativa de tempo para o desenvolvimento e uma prioridade que determina a ordem/importncia no desenvolvimento. A lista principal dividida em listas menores que so agrupadas de acordo com as suas dependncias, sendo que a execuo de cada grupo de caractersticas no dever exceder a 2 semanas. 43

2.3.2.3 Planejar a construo por caractersticas. Nesta etapa, construdo um plano de execuo dos conjuntos de caractersticas. As classes so distribudas aos seus proprietrios. A equipe de planejamento formada pelo Gerente do Projeto, Programador Chefe e Gerente de Desenvolvimento, a responsvel pela elaborao do plano de quais caractersticas sero desenvolvidas. Conforme Highsmith (2002a), planejar no FDD implica tambm em verificar vrios fatores que podero auxiliar ou prejudicar no desenvolvimento de software como determinao dos riscos do projeto, complexidade, balanceamento dos trabalhos, etc. 2.3.2.4 Projetar cada caracterstica. Nesta etapa so executadas as seguintes tarefas pela equipe e o programador chefe: estudar a documentao existente; desenvolver o diagrama de seqncia para o conjunto de caractersticas; refinar o modelo do objeto; reescrever as classes e os mtodos; inspecionar o projeto.

So resultados desse processo: o diagrama de seqncia detalhado, o diagrama de classes atualizado, alm das caractersticas com toda documentao. 2.3.2.5 Construir cada caracterstica. a ltima etapa de cada iterao do processo no FDD. A seguir, algumas tarefas requeridas nessa etapa que so executadas pela equipe e o programador chefe: implementao das classes e mtodos; inspeo de cdigo; teste de unidade; integrao; testes de integrao; 44

entrega do incremento.

Todos os conjuntos de caractersticas devem passar pelas etapas de projeto e construo at que o sistema esteja concludo.

2.3.3 A Equipe do FDD

Segundo Palmer (2002), o FDD classifica os papis da equipe em trs categorias: Chave, Suporte e Adicional. Os seis papis chaves so: O Gerente de Projeto o responsvel financeiro e administrativo do projeto. Uma de suas responsabilidades gerenciar a viabilidade do projeto oferecendo todas as condies necessrias equipe para o desenvolvimento do trabalho. No FDD, a ltima palavra dada por ele. O Arquiteto Principal quem elabora o projeto geral do software a ser desenvolvido, tomando decises finais em relao ao projeto tcnico. Essa funo poder ser dividida entre o Projetista de Domnio e o Projetista Tcnico. O Gerente de Desenvolvimento responsvel por gerenciar as atividades dirias do projeto resolvendo problemas que podero ocorrer com a equipe. Pode combinar as atividades desenvolvidas pelo Arquiteto Principal e Gerente de Projeto. O Programador Chefe geralmente o programador com maior experincia dentro da equipe, participando na anlise dos requisitos e no projeto do software. considerado como um dos papis mais importantes no projeto FDD, atuando principalmente nas duas ltimas etapas do processo. O Proprietrio de Classe trabalha subordinado ao Programador Chefe, tendo como tarefas projetar, codificar, testar e documentar. o responsvel pelo desenvolvimento das classes atribudas a ele. O Especialista no Domnio pode ser um usurio, analista de negcios, cliente ou qualquer pessoa que conhea bem o domnio do problema. Sua tarefa informar as funcionalidades que devero ser atendidas pelo software e entender como os requisitos esto sendo desenvolvidos.

45

Os seis papis de suporte so: O Gerente de domnio conduz os peritos de domnio a resolver a diferenas de opinio relativa aos requisitos do sistema. O Gerente de Verso responsvel por controlar o progresso no desenvolvimento atravs de constantes revises em conjunto com o Programador Chefe. Ele informa suas atividades ao Gerente de Projeto. O Especialista na Linguagem o membro da equipe responsvel por possuir um conhecimento completo de uma linguagem de programao especfica ou tecnologia. Este papel particularmente importante quando a equipe do projeto resolve utilizar uma nova tecnologia. O Coordenador de Configurao a pessoa responsvel pelas tarefas de administrao do sistema de controle de verso e a publicao da documentao, durante a atividade de construo. O Toolsmith10 responsvel por construir ferramentas de suporte para o desenvolvimento, teste e converso de dados no projeto. Tambm pode trabalhar com modelagem e manuteno de bancos de dados e websites para propsitos especficos do projeto. O Administrador de Sistema possui a tarefa de configurar, administrar e diagnosticar os servidores, estaes de trabalho e desenvolvimento e testar os ambientes usados pela equipe do projeto. Por fim, os trs papis adicionais so: Os Testadores verificam se o sistema que est sendo produzido satisfar os requisitos do cliente. Pode ser uma equipe independente ou parte da equipe de projeto. Os Desenvolvedores so responsveis por converter dados existentes ao formato requerido pelo novo sistema e participar no desenvolvimento de novos lanamentos. Pode ser uma equipe independente ou parte da equipe de projeto. O Escritor tcnico responsvel pela documentao de usurio.

10

No foi encontrada uma traduo para o termo Toolsmith.

46

De acordo com Palmer (2002), o FDD indicado em projetos que envolvam entre 10 e 30 pessoas na equipe de desenvolvimento do projeto e satisfatrio tanto para projetos novos, quanto para projetos que j se encontram em desenvolvimento, ou projetos que tem como objetivo a entrega de uma segunda verso de um sistema j existente. Os autores tambm sugerem que as organizaes devem adotar o mtodo gradualmente, em pequenas partes at chegar em sua totalidade. Para Highsmith (2002a), este mtodo, juntamente com o XP, considerado um dos melhores mtodos geis existentes na atualidade no mercado.

2.4 Adaptive Software Development (ASD)

O Adaptive Software Development (Desenvolvimento Adaptvel de Software) foi desenvolvimento por James A. Highsmith III. Muitos dos princpios do ASD tiveram origem numa pesquisa feita anteriormente pelo autor sobre mtodos de desenvolvimento iterativo e incremental. O antecessor mais conhecido do ASD o "RADical Sofware Development11", desenvolvido por Highsmith e S. Bayer (ABRAHAMSSON, 2002). Conforme Highsmith (2002a), o ASD encoraja o Desenvolvimento Incremental e iterativo. Fundamentalmente, seu objetivo prover um processo para auxiliar no desenvolvimento gil de software. Este um processo dedicado aprendizagem contnua, dirigido a mudanas, reavaliaes e grande colaborao entre desenvolvedores e clientes.

2.4.1 As Prticas do ASD

De acordo com Highsmith (2002a), o ASD no possui um conjunto de prticas definidas e sim um conjunto de propriedades que caracterizam o processo de desenvolvimento adaptativo. A seguir so apresentadas as propriedades, conforme Abrahamsson (2002):

11

Para mais informaes a respeito do RAD, acessar: http://www.adaptivesd.com/articles/ RAD_article.htm

47

Dirigido a misses: As atividades para cada ciclo de desenvolvimento so justificadas atravs de uma misso, onde cada iterao possui a sua, e que pode mudar ao longo do projeto.

Baseado em caractersticas: As atividades de desenvolvimento devem ser orientadas caractersticas, ou seja, a construo de uma pequena parte do software de cada vez.

Iterativo: O processo de desenvolvimento dividido em pequenos ciclos (iteraes) com o objetivo final de entregar um grupo de requisitos implementados que satisfaa a misso definida para cada iterao.

Prazos pr-fixados: A ambigidade em projetos de software complexos pode ser reduzida fixando-se prazos finais tangveis em uma base regular, forando os participantes do projeto a tomarem decises que podem representar algum risco no comeo do projeto.

Tolerncia a mudanas: As mudanas so freqentes. Assim, sempre melhor estar pronto a adapt-las do que control-las, fazendo uma constante avaliao de quais componentes podem mudar.

Orientado a riscos: Caractersticas de alto risco so desenvolvidas primeiro.

2.4.2 As Fases do Processo do ASD

O processo do ASD focado em resultados, no em tarefas, e os resultados so as caractersticas desenvolvidas durante as iteraes (HIGHSMITH 2002a). O ASD possui ciclos de trs fases: Especulao, Colaborao e Aprendizado (Figura 6).

48

Especulao

Colaborao

Aprendizado

Figura 6. O Processo ASD (adaptado de Abrahamsson, 2002).

A seguir so descritas as fases do processo ASD (Figura 7) de acordo com Highsmith (2002a) e Abrahamsson (2002).

Loop do Aprendizado

Incio do Projeto

Planejamento do Ciclo Adaptativo

Desenvolvimento Simultneo dos Requisitos

Revises de Qualidade Aprendizado

Entrega Final

Especulao

Colaborao

Figura 7. As Fases do Processo ASD. (adaptado de Highsmith, 2002a). 2.4.2.1 Especulao A fase de Especulao consiste na definio dos prazos, objetivos e de um plano baseado em caractersticas, pois todo processo focado em partes do sistema. Esta fase possui duas sub-fases chamadas Inicio do Projeto e Planejamento do Ciclo Adaptvel.

49

Na sub-fase Inicio do Projeto, estabelecido o objetivo do projeto e feito um esboo das caractersticas, dando uma idia inicial do tamanho do sistema. A identificao dos riscos tambm contemplada nesta sub-fase. Para projetos pequenos ela no deve durar mais que 5 dias, mas este prazo aumenta para 2 ou 3 semanas para projetos maiores. Os prazos e custos so estabelecidos com base na complexidade das caractersticas. Vale salientar que os prazos e custos so vagos, uma vez que as mesmas podem sofrer alteraes. Na sub-fase Planejamento do Ciclo Adaptvel, so definidas a quantidade de iteraes bem como o tempo necessrio para cada uma delas. Sugere-se que cada ciclo dure de 4 a 8 semanas. O tamanho do projeto e o grau de incerteza em relao a possveis alteraes so dois fatores importantes na determinao do tempo de cada iterao. Aps estabelecido o nmero de iteraes e o tempo para cada uma delas, a equipe elabora uma misso para cada iterao. As caractersticas a serem desenvolvidas em cada iterao so decididas em conjunto pelos desenvolvedores e clientes, bem como a ordem em que sero implementadas. Estas definies so feitas em sesses de JAD12 (Joint Application Development). Uma sesso de JAD essencialmente um workshop onde os desenvolvedores e os representantes do cliente se encontram para discutir sobre as caractersticas do sistema. utilizada uma planilha eletrnica para documentar o planejamento das iteraes. 2.4.2.2 Colaborao A fase de Colaborao composta por vrias iteraes, onde acontece o desenvolvimento das caractersticas escolhidas para fazerem parte da mesma. Estas caractersticas podem ser desenvolvidas simultaneamente. importante salientar que o enfoque do ASD no resultado final e suas qualidades, ou seja, na qualidade do sistema desenvolvido em cada iterao. O mtodo no sugere tarefas ou processos a serem utilizados para produzirem estes resultados. 2.4.2.3 Aprendizado

12

Wood, J. and D. Silver, Joint Application Development, 2nd ed., New York : Wiley, 1995.

50

A fase de Aprendizado se divide em duas sub-fases, Revises de Qualidade e Entrega Final. As Revises de Qualidade acontecem no final de cada iterao, onde apresentado um software contemplando os requisitos escolhidos para serem desenvolvidos durante a mesma. Estas revises possuem o objetivo de verificar: A qualidade funcional do sistema atravs da definio de grupos de clientes para testar a aplicao. A qualidade tcnica, onde um par de programadores responsvel por revisar e avaliar o cdigo do sistema. O desempenho da equipe, atravs de revises das tarefas realizadas durante a iterao.

O progresso geral do projeto, onde so verificados se os objetivos da iterao foram alcanados.

A sub-fase de Entrega Final consiste na entrega final do sistema para o cliente.

2.4.3 Os Papis da Equipe

No foram encontradas descries detalhadas a respeito de como deve ser formada a equipe no mtodo ASD. Entretanto, Abrahamsson (2002) sugere a necessidade de um Patrocinador (Executive Sponsor), nomeado como a pessoa com responsabilidade global em relao ao produto que est sendo desenvolvido. Como o mtodo incorpora sesses de JAD no seu processo de desenvolvimento, pode-se citar os alm dos membros que participam destas sesses, o Patrocinador; O Facilitador que possui a responsabilidade de liderar e planejar as sesses; O Escriba responsvel por fazer as anotaes necessrias; E os Desenvolvedores como possveis membros da equipe do ASD, (ABRAHAMSSON 2002). Apesar de no apresentar papis bem definidos, Highsmith (2002a) enfatiza a importncia da existncia da colaborao entre os envolvidos no projeto.

51

Segundo Abrahamsson (2002), o ASD no possui limitaes para sua aplicao, ou seja, pode ser utilizado tanto em sistemas simples quanto complexos e tambm no estabelece nmero mximo de pessoas na sua equipe. Uma caracterstica interessante do ASD que ele no obriga que os membros da equipes estejam num mesmo local como outros mtodos geis. Porm, o desenvolvimento distribudo est relacionado principalmente com as habilidades da equipe, que devem ser as mais especializadas possveis. Para isso, o ASD oferece algumas tcnicas13 para aumentar a colaborao entre a mesma sugerindo estratgias para compartilhar a informao e utilizar ferramentas de comunicao para apoiar o desenvolvimento distribudo.

2.5 Agile Modeling (AM)

A Agile Modeling (Modelagem gil) foi introduzida por Scott W. Ambler em 2002 e tem como objetivos principais a gerao de modelos e documentao eficazes que dem suporte ao desenvolvimento de sistemas, sem que o processo perca a agilidade. Como a maioria dos mtodos geis, a AM adota um conjunto de prticas guiado por princpios e valores. No um processo prescritivo, ou seja, no define procedimentos detalhados sobre como criar um determinado tipo de modelo, invs disso, fornece conselhos sobre como utilizar a tarefa de modelagem de forma eficiente e gil (AMBLER 2004). Uma questo importante sobre a AM que ela no um mtodo completo. Embora mostre a importncia das atividades de programao, testes, gerncia, suporte ao sistema etc, ela no contempla as mesmas no seu escopo. Como o seu foco na modelagem e documentao, Ambler (2004) afirma que a AM deve ser utilizada em conjunto com outros mtodos de desenvolvimento.

13

De acordo com Abrahamsson (2002), estas tcnicas so sugeridas no livro Agile Software Development: A Collaborative Approach to Managing Complex Systems publicado em 2000 por Highsmith.

52

2.5.1 Os Valores da AM
De acordo com Ambler (2004), a AM adota uma perspectiva similar ao XP em relao aos valores utilizados como base para o mtodo. Alm da Comunicao, Simplicidade, Feedback e Coragem, a AM sentiu a necessidade de incorporar mais um valor: a Humildade. Como os quatro primeiros valores j foram descritos anteriormente no Captulo 3 sobre o XP, a seguir ser apresentado apenas o valor que ainda no foi abordado. A Humildade deve fazer parte da maneira como os envolvidos no projeto se relacionam. Os modeladores geis devem respeitar as pessoas com as quais trabalham, percebendo que elas talvez possuam outras prioridades e experincias e, portanto, tero pontos de vista diferentes, bem como saber admitir que no sabem tudo e haver um momento em que precisaro pedir ajuda para realizar bem o seu trabalho.

2.5.2 As Prticas da AM
O ponto forte da AM so as suas prticas. Elas esto divididas em prticas bsicas que devem ser adotadas em sua totalidade para garantir um bom resultado e em prticas suplementares que podem ser utilizadas de acordo com a necessidade. As prticas bsicas e suplementares da AM esto organizadas em categorias. A seguir elas sero apresentadas segundo Ambler (2004). Prticas Bsicas: o Prticas para modelagem iterativa e incremental: Aplicar o(s) artefato(s) correto(s): Existe uma grande quantidade de artefatos e diagramas para representar graficamente cada modelo e a escolha pelo correto extremamente importante. Por isso, a melhor maneira de no errar saber o mximo possvel sobre o artefato escolhido, bem como sobre outras alternativas existentes. Criar diversos modelos em paralelo: Pode ser que seja necessria a gerao de vrios modelos ao mesmo tempo. Por exemplo, quando se est desenvolvendo em Java, pode ser que seja necessria a criao de um diagrama de classes UML para definio da estrutura do sistema, um 53

diagrama de estados UML para explorar o funcionamento interno de uma classe, um outro diagrama de seqncia UML para mostrar a troca de mensagens entre dois objetos, enfim, o trabalho poder ser mais produtivo utilizando diversos modelos simultaneamente do que focando um nico por vez. Iterar em outro artefato: Dificuldades em trabalhar com um determinado artefato um sinal que se deve repetir o mesmo processo com um outro artefato. Por exemplo, se atravs de um caso de uso essencial no se consegue descrever a lgica do negcio, pode ser que seja mais indicado utilizar um fluxograma ou um modelo CRC. Modelagem incremental: Ao utilizar uma estratgia de desenvolvimento iterativa (premissa gil), tambm se utiliza uma estratgia de modelagem incremental. Assim, modela-se um pouco, codifica-se um pouco, testa-se um pouco e entrega-se uma parte do sistema. o Prticas para um trabalho de equipe eficaz: Modelagem em conjunto: No h problema algum em desenhar um esboo simples sozinho, mas depois de concludo importante discutir o resultado com outras pessoas. Esta prtica ajuda a melhorar a comunicao, a criar um vocabulrio comum entre a equipe e aumenta a chance da realizao de um bom trabalho. Participao ativa do cliente: Esta prtica est diretamente relacionada prtica anterior e descreve a necessidade de se ter o cliente ou qualquer pessoa com habilidade para fornecer informaes relativas aos requisitos do sistema em construo, presente no momento que for preciso. Posse coletiva: Todos podem trabalhar em qualquer modelo ou artefato no projeto, caso necessitem. Esta prtica permite o aumento do conhecimento intelectual, pois no existe apenas um especialista e sim vrios, alm de promover o entendimento do sistema entre os membros da equipe. Visualizao dos modelos: Prope a criao de um local fsico (uma parede) ou virtual (pgina web), onde todos os modelos gerados so expostos para a 54

equipe e o cliente. Desta forma o cliente acompanha o progresso do trabalho e a equipe tem os modelos a sua disposio para eventuais consultas. o Prticas que permitem a simplicidade: Criao de contedo simples: O contedo real dos modelos deve ser o mais simples possvel, desde que satisfaa as necessidades dos clientes e da equipe. Um modelo simples quando comunica tudo o que deve ser comunicado, no possui informao duplicada e tem a menor quantidade de elementos possvel. Apresentao de modo simples: Semelhante prtica anterior, sendo que esta enfatiza a forma como apresentado o modelo. Algumas tcnicas para simplificar os diagramas incluem evitar: cruzamento de linhas; linhas curvas; linhas diagonais; itens que significam a mesma coisa com tamanhos diferentes, itens demais e detalhes desnecessrios. Utilizao de ferramentas simples: Como a proposta agilidade e simplicidade, importante que os modeladores utilizem uma ferramenta que supra as necessidades do projeto, no importando se uma ferramenta CASE (Computer Aided Software Engineering) de ltima gerao ou um simples desenho feito a lpis em uma folha de papel. o Prticas para validar o trabalho: Considerar a testabilidade: As atividades de testes no cdigo no fazem parte da AM, pois o mtodo focado apenas na modelagem do sistema. Portanto, os modeladores geis devem ter em mente a seguinte questo: Como isto pode ser testado?. Comprovar com cdigo: A melhor maneira de validar um modelo escrever o cdigo correspondente a ele. A ordem das atividades modelar, codificar e testar. Prticas Suplementares: o Prticas para melhorar a produtividade:

55

Aplicar as convenes de modelagem: A idia que a equipe adote um conjunto comum de convenes de modelagem. O padro mais comum a UML, mas nem tudo possvel ser representado pela UML. Neste caso, os padres devem incluir descries de notao para qualquer modelo noUML. Vale salientar que a compreensibilidade mais importante que seguir convenes e padres. Utilizar padres de projeto14 com moderao: Se existir a suspeita que um padro de projeto seja aplicvel, modele-o de forma a implementar a mnima funcionalidade necessria no momento, mas que se torne fcil de refazer mais tarde, caso necessrio. Esta prtica est diretamente relacionada com a simplicidade. Reuso dos recursos j existentes: A reutilizao de modelos agiliza a tarefa de modelagem. Esta prtica refora a importncia da existncia dos modelos, bem como da documentao. o Prticas para a documentao gil: Descartar modelos temporrios: Devem ser guardados apenas os modelos que forem realmente teis. Modelos temporrios geralmente esto desatualizados e guardando-os, alm de contribuir para a desorganizao, corre-se o risco de algum desavisado tomar uma deciso baseada em um modelo incorreto. Formalizao dos modelos de contrato: Os modelos de contrato servem para formalizar o que solicitado pelo cliente e o que de responsabilidade da equipe desenvolvedora. Atualizaes somente quando necessrio: As atualizaes nos modelos devem acontecer somente quando necessrio, do contrrio perda de tempo. Esta prtica est diretamente relacionada a Descartar modelos temporrios, pois quanto menos modelos e documentao permanentes forem mantidos, mais fcil ser atualiz-los quando preciso.
14

Recomenda-se a leitura do livro Padres de Projeto Solues Reutilizveis de Software Orientado a Objetos. Gamma. E; Hekm, R; Johnson, R; Vlissides, J. Ed. Bookman. 2000, para mais informaes sobre padres de projeto.

56

Prticas relacionadas com a motivao: Modelar para entender: A modelagem serve para auxiliar na compreenso do problema a ser solucionado. Sempre buscando a melhor e mais simples soluo que satisfaa os requisitos do sistema. Modelar para comunicar: A modelagem serve tambm para comunicar aos outros, integrantes ou no da equipe, como o sistema foi desenvolvido, bem como seus propsitos. A Figura 8, mostra a relao entre as prticas descritas anteriormente,

organizando-as em sete categorias. As categorias Validao, Iterativa e Incremental, Trabalho em Equipe e Simplicidade consolidam as prticas bsicas. As prticas suplementares esto consolidadas nas categorias Documentao, Motivao e Produtividade. Segundo Ambler (2004), as prticas da AM complementam-se, apiam-se e habilitam umas as outras.

Validao
Considerar a testabilidade Comprovar com cdigo

Iterativa e Incremental
Aplicar o(s) artefato(s) correto(s) Criar diversos modelos em paralelo Iterar em outro artefato Modelagem incremental

Trabalho em Equipe
Modelagem em conjunto Participao ativa do cliente

Simplicidade
Criao de contedo simples Apresentao de modo simples Utilizao de ferramentas simples

Motivao
Modelar para entender Modelar para comunicar

Produtividade
Aplicar as convenes de modelagem Utilizar padres com moderao Reuso dos recursos j existentes

Documentao
Descartar modelos temporrios Formalizao dos modelos de contrato Atualizaes somente quando necessrio

Figura 8. A Relao entre as Prticas AM. (adaptado de Ambler, 2004).

57

2.5.3 Sesses e Documentao geis

Conforme descrito anteriormente, a AM no um mtodo completo de desenvolvimento, e sim um mtodo que complementa outros processos de desenvolvimento, conforme observado na Figura 9, AMBLER (2004). Sendo assim, a AM no possui um ciclo de vida de desenvolvimento prprio. Outros mtodos a incorporam em seu ciclo de vida.

Agile Modeling (AM) Mtodo de Desenvolvimento (XP, Scrum, FDD, ...)

Novo mtodo

Figura 9. A AM complementando outros mtodos. (adaptado de Ambler, 2004). Por este motivo nesta sesso no sero descritas As Fases do Processo AM, como nos outros captulos sobre os mtodos geis. Neste caso, mostrado como deve ser conduzida uma sesso de modelagem para a gerao de modelos e como estes modelos se transformam em documentao, conforme Ambler (2004). 2.5.3.1 Sesses de AM Uma sesso de modelagem uma atividade onde vrias pessoas tm como objetivo principal o desenvolvimento de um ou mais modelos, fornecendo uma oportunidade delas colaborarem entre si e atravs da comunicao de suas necessidades chegarem a um melhor entendimento e trabalharem na busca de uma soluo. So nas sesses de modelagem gil que sero aplicadas as prticas da AM. A durao das sesses pode variar de alguns minutos a no mximo 3 dias, sendo que a maioria leva entre 10 e 30 minutos. A justificativa para a grande variao de tempo que no incio do projeto talvez exista a necessidade de longas sesses, uma vez que durante esta fase, a preocupao em obter uma viso global do projeto, enquanto que depois, a modelagem acontecer em iteraes focadas em partes especficas do sistema.

58

Aps cada sesso de modelagem, devem ser feitas validaes em cima do(s) modelo(s) criado(s). Estas validaes podem acontecer atravs de revises com outra pessoa da equipe ou atravs da prtica Comprovar com cdigo. Quanto mais rpido for o retorno, mais chance de saber se o que est sendo modelado reflete ou no os requisitos e a arquitetura do software. Existem algumas sugestes que podem ser adotadas para forar uma sesso de modelagem curta. Em primeiro lugar, as sesses devem ser realizadas em p, ao redor de um quadro ou mesa, pois a maioria das pessoas s quer ficar de p por curtos perodos. Em segundo, fazer das sesses curtas um hbito, assim quando as sesses durarem mais tempo, as pessoas ficaro inquietas. Em terceiro, manter o foco das sesses em um nico tpico, ou seja, nos requisitos daquele momento. Em quarto lugar, as sesses devem ser finalizadas assim que o objetivo for alcanado. As sesses de modelagem devem focar a criao de modelos relacionados s fases mais importantes do desenvolvimento tradicional, como requisitos, anlise, arquitetura e projeto. Em cada uma dessas sesses de modelagem a equipe trabalha em diversos modelos de uma s vez (prtica Criar diversos modelos em paralelo), os que forem mais apropriados a cada fase. Em uma sesso de modelagem de requisitos, por exemplo, podem ser criados diagramas de casos de uso UML ou user stories. Em uma sesso de modelagem de projeto, poder ser gerados diagramas de classe UML ou diagramas de estado UML. O importante sempre levar em considerao que a ferramenta escolhida para gerar os modelos em cada uma das fases, deve suprir as reais necessidades do projeto (prtica Aplicar o(s) artefato(s) correto(s)). 2.5.3.2 Documentao gil Alguns modelos se tornaro documentos, ou parte destes, ou sero descartados aps cumprir suas finalidades. Alguns modelos sero usados para guiar a implementao ou apenas para guiar o desenvolvimento de outros. Sob o ponto de vista da AM, um documento qualquer artefato externo ao cdigo-fonte, cujo objetivo transmitir informaes de forma persistente. J o conceito 59

de modelo, uma abstrao que descreve um ou mais aspectos de um problema ou uma soluo possvel para este. O cdigo-fonte uma seqncia de instrues, incluindo os comentrios que as descrevem, para um sistema computacional. E o termo documentao inclui tanto os documentos quanto os comentrios do cdigo-fonte. Um fator importante a ser levado em considerao so os tipos de documentos a serem criados durante o desenvolvimento de um sistema. A seguir alguns dos documentos mais comuns que podero ser criados para serem entregues como parte da documentao do sistema:

Documento (s)
Modelos de contrato

Pblico
Outras equipes Desenvolvedores Desenvolvedores de manuteno Gerentes de projeto Gerncia snior Gerncia de usurios Gerncia de projeto

Descrio
Descreve a interface para um sistema ou uma parte do mesmo Um resumo de decises crticas relacionadas ao projeto e arquitetura que a equipe tomou durante o desenvolvimento Uma definio da viso de sistema e um resumo da estimativa atual de custos, benefcios previstos, riscos, estimativas de pessoal e marcos no cronograma. Inclui uma indicao das dependncias com as quais o sistema est envolvido; a natureza de sua interao com outros sistemas, banco de dados e arquivos; referncias e procedimentos de backup; um resumo dos requisitos de disponibilidade/confiabilidade para o sistema e diretrizes de resoluo de problemas. Um resumo de informaes cruciais, como a viso do sistema, principais contatos dos usurios, tecnologias e ferramentas usadas para construir o sistema e processos cruciais de operao. Define o que o sistema ir fazer, resumindo ou compondo os artefatos de requisitos, como definies de regras de negcio, casos de uso, user stories, ou prottipos de interface essencial, por exemplo. Inclui materiais de treinamento especficos para o pessoal de suporte; toda a documentao de usurio para usar como referncia na resoluo de problemas; um guia para a soluo de problemas; procedimentos para lidar com problemas difceis; e uma lista de pontos de contato dentro da equipe de manuteno.

Decises de projeto

Viso geral executiva

Documentao de operaes

Pessoal de operaes

Viso geral do projeto

Desenvolvedores Gerentes Desenvolvedores de manuteno Pessoal de operao Desenvolvedores Desevolvedores de manuteno Usurios Gerentes de usurios

Documentos de requisitos

Documentos de suporte

Pessoal de suporte

60

Documentao do sistema

Desenvolvedores de manuteno Desenvolvedores

Fornece uma viso geral do sistema e ajuda as pessoas a compreend-lo. Algumas informaes includas no documento so, uma viso geral da arquitetura tcnica, da arquitetura do negcio e dos requisitos de alto nvel do sistema. A arquitetura detalhada e os modelos de projeto, ou referncias a eles, tambm podem estar includos. Inclui, um manual de referncia, um guia de uso, um guia de suporte ou at mesmo materiais para treinamento.

Documentao de usurio

Usurios Gerentes de usurios

Tabela 2. Documentos possveis criados pela equipe de desenvolvimento. (adaptado de Ambler 2004) A equipe deve se focar na criao de documentao que fornea o mximo valor para os clientes e deve ser criada somente quando for a melhor opo, o objetivo uma documentao simples que cumpra a funo desejada. Abaixo, sero listados alguns aspectos importantes relativos documentao gil. O ponto chave a comunicao efetiva, no a documentao. A documentao deve ser pequena e econmica. A documentao s dever ser criada se realmente necessrio. A documentao deve ser boa apenas o suficiente. A documentao faz parte do sistema tanto quanto o cdigo-fonte. O objetivo principal da equipe desenvolver software. O benefcio de ter documentao deve ser maior do que o custo de cri-la e mant-la. Cada sistema tem suas necessidades de documentao prprias e nicas. No existe uma soluo nica. A pergunta : Por que a documentao necessria e por que se acredita que precisa dela? E no: Quem quer documentao? O investimento na documentao do sistema uma deciso de negcio, no tcnica. Atualizar a documentao apenas quando for necessrio.

61

2.5.4 A Equipe da AM
A AM sugere trs papis compondo a equipe de modelagem: o Facilitador, o Escrivo e o Observador. Muitas sesses de modelagem funcionam perfeitamente sem ningum nestes papis, principalmente as sesses pequenas onde os desenvolvedores esto modelando para compreender uma parte do sistema. Entretanto, as sesses maiores de modelagem, especialmente as no incio do projeto, geralmente tero pessoas nestes papis (AMBLER 2004). A seguir sero apresentadas as responsabilidades atribudas a cada um deles. O Facilitador o responsvel pelo planejamento, execuo e gerncia das sesses de modelagem. O Escrivo o responsvel pelo registro das informaes durante uma sesso de modelagem. O Observador no participa das sesses efetivamente, ele est l para assistir o que acontece de modo que possa aprender. Ao envolv-lo na sesso de modelagem, no s o nmero de pessoas agregando valor sesso cresce, como tambm melhora o aprendizado da mesma. No existem comprovaes a respeito do uso da AM no desenvolvimento de sistemas muito complexos, principalmente em sistemas crticos, como por exemplo, um sistema de controle de trfego areo, pois os mesmos necessitam de uma documentao mais detalhada. Em relao ao tamanho da equipe, a AM indicada para equipes mdias e pequenas e que estejam localizadas na mesma rea, pois o contrrio pode afetar de forma negativa a comunicao entre os membros da mesma (AMBLER 2004). Ambler (2004) sugere que a AM seja utilizada em conjunto com outros mtodos geis. A adoo do mtodo em projetos que utilizam processos prescritivos no impossvel, mas provvel que o sucesso do projeto seja comprometido. Portanto, em relao a sua aplicabilidade recomendado que a AM seja utilizada de acordo com o sugerido pelo mtodo que est sendo complementado por ela. Como pde ser observado, a AM no trata de nenhuma tcnica de modelagem. Existem centenas de tcnicas que podem ser aplicadas no projeto. A escolha de quais

62

adotar da equipe de desenvolvimento. O importante a aplicao das prticas da AM para a criao dos modelos e documentao, e no a tcnica utilizada AMBLER (2004).

63