Universidade Federal de Pernambuco Centro de Informtica

Graduao em Cincia da Computao

Compondo Mtodos geis de Desenvolvimento de Software

Tiago de Farias Silva TRABALHO DE GRADUAO

Recife 01 de Julho de 2009

Universidade Federal de Pernambuco Centro de Informtica

Tiago de Farias Silva

Compondo Mtodos geis de Desenvolvimento de Software

Trabalho apresentado ao Programa de Graduao em Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para obteno do grau de Bacharel em Cincia da Computao. Orientador: Prof. Hermano Perrelli de Moura

Recife 01 de Julho de 2009

ii

Quem refreia suas prprias declaraes possudo de conhecimento e o homem de discernimento de esprito frio. - Provrbios 17:27 1

RESUMO
Com o surgimento do Manifesto gil em 2001, o processo de gerenciamento de projetos de software sofreu intensas mutaes. Com princpios focados em resultados rpidos e entregas constantes, diversas metodologias se consolidaram. Essas metodologias, utilizadas amplamente no indstria mundial de softwares, mostram-se muito teis em projetos que apresentam mudanas bruscas e ambientes pouco previsveis. Dessas metodologias, as mais conhecidas atualmente so: Scrum, XP e Feature Driven Development. Por sua vez, essas metodologias podem trazer consigo catalisadores, ou seja, tcnicas orientadas ao desenvolvimento de Software propriamente dito, que aumentam o desempenho das metodologias geis e provem mais qualidade ao produto final. Esse trabalho tem por objetivo mostrar como essas tcnicas de desenvolvimento de Software e metodologias geis so mais poderosas combinadas do que individualmente. Palavras-chave: Agilidade, Scrum, XP, Feature Driven Development, Domain Driven Design, Test Driven Development, Tcnicas geis, Gerenciamento de Projetos, Desenvolvimento de Software, Composio de Mtodos geis.

ABSTRACT
With the emergence of the Agile Manifesto in 2001, the process of projectmanagement software has undergone intense mutations. With new principles, this time focused on quick results and constant deliverables, several methodologies have arisen. These methods, widely used in the world market for software, are very useful in projects that have sudden changes and hardly predictable environments. These methodologies, the best known today are: Scrum, XP and Feature Driven Development. In turn, these methodologies can bring their own catalysts, that is, oriented techniques to software development itself, which increase the performance of agile methodologies and provide more quality to the final product. This work has as its prime objective to show how the techniques of software development and agile methodologies are more powerful together than individually. Keywords: Agile, Scrum, XP, Feature Driven Development, Domain Driven Design, Test Driven Development, Agile Techniques, Project Management, Software Development, Composition of Agile Practices.

AGRADECIMENTOS

Relutei um pouco pra fazer essa parte porque eu sabia desde o comeo que muita gente que eu tenho de agradecer. Desde colegas do curso, do colgio, do trabalho, do extrabalho, so muitas pessoas e possvel que eu no consiga citar todos por nome. De qualquer forma, esses que no foram citados diretamente saibam que toda vez que eu vir vocs, sempre lembrarei o apoio (por menor que tenha sido) dado. Primeiramente agradeo a meus pais pelo apoio incondicional em meus empreendimentos, tanto em sentido emocional, quanto financeiro, jamais ser esquecido por mim (talvez quando eu estiver com Alzheimer daqui h 83 anos). Agradeo profundamente ao meu orientador, Professor Hermano Perrelli, que foi muito paciente e extremamente prestativo comigo durante a elaborao deste trabalho. Apesar de muito atarefado, mostrou-se pronto pra ajudar a qualquer momento com seu conhecimento da rea e raciocnio. Agradeo aos meus colegas de curso (por ordem alfabtica): Apebo, Arara, Alysson, Borba, Braga, Caio, Felipe Fifo, Jera, Joo Doido, Joo Paulo, Leila, Mrio, Rafael Formiga, Reaf, Riffa e Sos. Ao pessoal da Educandus, primeiramente ao Professor Ricardo Lessa pela grande oportunidade concedida a mim desde o comeo do curso, assim como tambm por ser uma fonte de inspirao pela grande pessoa que . Mas tambm a outros que passaram por l e me ensinaram muitas lies: Mestre Tairone, Tia Las, Bruna, Lo, Joo Augusto, Ricardo Teixeira, Teoria, enfim, muito obrigado a todos pelo aprendizado do dia a dia! A Provider Sistemas e os caras de l, pois foi nesse ambiente de trabalho que pude ver na prtica os benefcios de se usar mtodos geis. Marcos Pereira e Igor Macabas eram os pioneiros nisso, mas agradeo a todos por esclarecer coisas sobre o assunto e a abrir minha mente para novas tecnologias. Obviamente no podia esquecer da galerinha do CPI. Foi onde a instiga comeou. A todo o grupo de estudiosos: Bruno BB, Jefferson Fefa, Humberto Panz, Paulo Bolado, Renata, Ana Rita, Zoby e todos os demais que de alguma forma me inspiraram a conseguir essa conquista. Enfim, muito obrigado a todos! 4

SUMRIO

RESUMO ............................................................................................................................... 2 ABSTRACT ........................................................................................................................... 3 AGRADECIMENTOS ........................................................................................................... 4 SUMRIO .............................................................................................................................. 5 LISTA DE FIGURAS ............................................................................................................ 7 LISTA DE TABELAS ........................................................................................................... 8 1. INTRODUO .............................................................................................................. 9 1.1 Contexto do Trabalho ................................................................................................... 9 1.2 Motivao ..................................................................................................................... 9 1.3 Objetivos..................................................................................................................... 11 1.4 Estrutura do Trabalho ................................................................................................. 11 2. METODOLOGIAS GEIS .......................................................................................... 12 2.1 Uma breve histria de agilidade Manifesto gil ..................................................... 13 2.2 Scrum .......................................................................................................................... 15 2.2.1 Definies ............................................................................................................ 15 2.2.2 Fases .................................................................................................................... 19 2.2.3 Vantagens e desvantagens ................................................................................... 20 2.3 Extreme Programming................................................................................................ 22 2.3.1 Princpios e diferenas para outras metodologias................................................ 23 2.3.2 Boas Prticas ....................................................................................................... 24 2.3.3 Elementos ............................................................................................................ 26 2.3.4 Fases .................................................................................................................... 27 2.4 Feature Driven Development...................................................................................... 29 2.4.1 Elementos ............................................................................................................ 29 2.4.2 Boas prticas ........................................................................................................ 31 2.4.3 Fases .................................................................................................................... 32 2.4.4 Vantagens e desvantagens ................................................................................... 35 2.5 Anlise Comparativa .................................................................................................. 37 3. TCNICAS E ABORDAGENS GEIS .......................................................................... 44 3.1 Test Driven Development........................................................................................... 44 3.1.1 Como funciona .................................................................................................... 44 3.1.2 Benefcios ............................................................................................................ 46 3.1.3 Limitaes ........................................................................................................... 47 3.2 Outras tcnicas ............................................................................................................ 48 3.2.1 Design Patterns .................................................................................................... 49 3.2.2 Controle de verso ............................................................................................... 51 3.3 Domain Driven Design Uma abordagem gil ......................................................... 53 3.3.1 Conhecimento do domnio................................................................................... 54 3.3.2 Uma linguagem ubqua ........................................................................................ 55 3.3.3 Model Driven Design .......................................................................................... 56 3.3.4 Elementos do Model Driven Design ................................................................... 57 3.3.5 Benefcios ............................................................................................................ 61 4. COMPONDO MTODOS GEIS .............................................................................. 63 5

4.1 Scrum + XP + TDD .................................................................................................... 63 4.1.1 Praticando Scrum + XP + TDD ........................................................................... 65 4.1.2 Vantagens da composio ................................................................................... 68 4.1.3 Concluso ............................................................................................................ 70 4.2 FDD + DDD + Design Patterns .................................................................................. 70 4.2.1 FDD + DDD + Design Patterns na prtica .......................................................... 71 4.2.2 Vantagens da composio ................................................................................... 74 5. CONCLUSES E TRABALHOS FUTUROS ............................................................ 76 4.1 Trabalhos futuros ........................................................................................................ 77 REFERNCIAS BIBLIOGRFICAS ................................................................................. 78

LISTA DE FIGURAS

Figura 1. Esquema de um dashboard no meio de uma sprint, mostrando tarefas a fazer, em processo, a verificar e finalizada .......................................................................................... 19 Figura 2. Funcionamento de uma Sprint recebendo Sprint Backlog como entrada e aps vrios Daily Scrums (durao mdia da Sprint de 2 a 4 semanas), a entrega do incremento de software funcionando ....................................................................................................... 20 Figura 3. Os 5 processos do FDD ......................................................................................... 35 Figura 4. Grafo mostrando as etapas do Test Driven Development ..................................... 46 Figura 5. Relaes entre os elementos que compem o Domain Driven Design. ............... 61 Figura 6. XP sendo executado dentro das iteraes do Scrum ............................................. 67

LISTA DE TABELAS

Tabela 1. Anlise comparativa entre Scrum, XP e FDD. ..................................................... 38

1. INTRODUO

1.1 Contexto do Trabalho Com o crescente aumento da competitividade dos mercados internacionais, a exigncia sobre o produto tornou-se um diferencial determinante. E visto que o software tornou-se essencial para a manuteno do controle e da produtividade nos mais diversos setores organizacionais, j era previsvel o surgimento de novas metodologias e tcnicas que buscassem garantir agilidade e ao mesmo tempo robustez no processo de desenvolvimento de software. Assim surgiu o Manifesto gil, com o objetivo de promover prticas geis de desenvolvimento de software e gerenciamento de projetos. Essas prticas tm como conceito base o incentivo ao trabalho em equipe, equipes auto-organizadas e responsveis, um conjunto de tcnicas de engenharia que permitem rpidas entregas de produtos com alto nvel de qualidade, alm de uma nova abordagem ao alinhar os interesses dos clientes com os objetivos dos desenvolvedores. Como os conceitos advindos do Manifesto gil mostraram-se de intenso valor para as boas prticas organizacionais, uma grande quantidade de engenheiros de software e gerentes de projeto comearam a adaptar tais conceitos para o seu prprio contexto. Dessa forma surgiram novas metodologias e diferentes tcnicas focadas em dinamizar o processo de desenvolvimento. Entretanto, essas tcnicas e metodologias podem se mostrar tambm deficientes em alguns aspectos. Porm, ao analisar as fraquezas e os pontos fortes de cada uma delas, possvel encontrar os pontos onde estas se complementam. 1.2 Motivao

Com o crescimento do mercado mundial de Software, novas empresas com novas estratgias de marketing e idias inovadoras tm surgido. Nos ltimos 8 anos, por exemplo,

muito tm-se falado sobre Agilidade. No de admirar, pois a comunidade gil tem-se mostrado bastante eficaz, trazendo maneiras novas de resolver problemas antigos na rea de Gerenciamento de Projetos e Desenvolvimento de Software. Dentro dessa comunidade, existe um verdadeiro ecossistema composto por metodologias, tcnicas e abordagens que, se executadas em conjunto de forma equilibrada, so extremamente robustas do ponto de vista organizacional, garantindo qualidade, objetividade e agilidade ao projeto. importante definir o conceito de metodologia, tcnica, abordagem e mtodo no contexto desse trabalho: Uma metodologia um conjunto estruturado de prticas (por exemplo: Material de Treinamento, Programas de educao formais, Planilhas, e Diagramas) que pode ser repetvel durante o processo de produo de software. Na verdade, metodologias de Engenharia de Software abrangem muitas disciplinas, incluindo Gerenciamento de Projetos, e as suas fases como: anlise, projeto, codificao, teste, e mesmo a Garantia da Qualidade. Uma tcnica uma prtica de desenvolvimento de software aplicada a uma determinada fase. Por exemplo, uma tcnica pode existir tanto na fase de codificao quanto na fase de testes. Uma abordagem uma forma de visualizar o projeto de software em questo. Com uma srie de boas prticas e princpios, prope uma forma diferente de encarar o projeto numa determinada fase. No completamente especificada com regras. Mas, deixa o desenvolvedor do projeto livre para aplicar regras que se adquem aos conceitos propostos pela abordagem. Mtodo, no contexto desse trabalho, um termo geral utilizado para se referir a metodologias, tcnicas e abordagens.

10

1.3 Objetivos

O objetivo deste Trabalho de Graduao mostrar como as metodologias, abordagens e tcnicas de desenvolvimento de software existentes atualmente na comunidade gil podem ser mais bem aproveitadas do ponto de vista organizacional se aplicadas em conjunto, ao invs de individualmente. Tornando-se assim mais robustas e eficientes sem perder o foco na agilidade. 1.4 Estrutura do Trabalho

No Captulo 2 temos a definio do que so Metodologias geis. Ser abordado como tudo comeou com o surgimento do Manifesto gil em 2001 e o que este prope, ou seja, quais seus princpios bsicos. Neste mesmo captulo sero apresentadas as metodologias mais conhecidas de toda comunidade gil: Scrum, Extreme Programming (tambm conhecida pela sua abreviao XP) e Feature Driven Development. Ao final deste captulo ser realizada uma anlise comparativa sobre estas metodologias. O Captulo 3 descreve as tcnicas de engenharia utilizadas como catalisadores para os processos geis. So apresentadas as suas respectivas definies, funcionamento e aplicaes no contexto de anlise e desenvolvimento de software. apresentada a tcnica Test Driven Development (TDD) e a abordagem Domain Driven Design (DDD), assim como outras tcnicas de programao como Design Patterns e ferramentas de controle de verso. O Captulo 4 o corao deste Trabalho de Graduao, analisando como as metodologias geis podem ser aliadas as tcnicas ou prticas de engenharia de modo a conceber agilidade e qualidade em todas as camadas de um projeto de software. Primeiramente, analisamos a composio das metodologias Scrum, XP e TDD. Depois, a metodologia FDD, a abordagem DDD e a tcnica de Design Patterns. O Captulo 5 apresenta as concluses do trabalho, trabalhos relacionados e propostas futuras.

11

2. METODOLOGIAS GEIS

A filosofia aceita e pregada para o desenvolvimento de sistemas de que o processo de desenvolvimento perfeitamente previsvel, podendo ser planejado, estimado e completado com sucesso [3]. No entanto, isso tem se mostrado incorreto na prtica. O ambiente de desenvolvimento catico e sofre constantes mudanas, muitas vezes bruscas, o que causa grande impacto no produto final. O processo de desenvolvimento gil prope uma nova abordagem. Essa abordagem um conjunto de novas idias, velhas idias e velhas idias modificadas, e enfatiza [2]: Uma maior colaborao entre programadores e especialistas do domnio; Comunicao cara-a-cara (como sendo mais eficiente do que comunicao documentada); Entregas constantes de novas funcionalidades com valor de negcio; Equipes auto-organizadas; Maneiras de adaptar o cdigo e a equipe a novos requisitos que poderiam causar grande confuso; De forma geral, metodologias geis priorizam software funcionando como principal mtrica de progresso. Tendo em vista a preferncia por comunicao cara-acara, os mtodos geis normalmente produzem menos documentao do que os outros mtodos. notvel tambm a grande adaptabilidade dos projetos em relao a mudanas, o que no consagrado modelo Waterfall ou Cascata permanece uma grande dificuldade [4]. Neste captulo ser apresentado o ideal por trs do Manifesto gil, seus princpios e objetivos. Sero apresentadas tambm algumas das metodologias mais praticadas atualmente no mercado de software, como: Scrum, Extreme Programming (XP) e Feature

12

Driven Development (FDD). Analisaremos o funcionamento de cada uma delas, assim como tambm suas principais caractersticas, pontos fortes e pontos fracos, com o objetivo de comparar cada uma dessas metodologias. 2.1 Uma breve histria de agilidade Manifesto gil

O Manifesto gil uma declarao sobre os princpios que servem como base para o desenvolvimento gil de software. [5] Foi elaborado de 11 a 13 de Fevereiro de 2001, em Utah, onde representantes de vrias novas metodologias, tais como Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature Driven Development, Pragmatic Programming, se reuniram para discutir a necessidade de alternativas mais leves em contraposio as tradicionais metodologias existentes [1]. Simplificadamente, o Manifesto gil prega os seguintes valores [5]: Indivduos e interaes acima de processos e ferramentas; Software funcional acima de documentao compreensiva; Colaborao do cliente acima de negociao do contrato; Responder a mudanas acima de seguir um plano fixo; Nomeando a si mesmos como Agile Alliance, esse grupo de inovadores em desenvolvimento de software concordaram em chamar esses novos valores de Manifesto para o Desenvolvimento gil de Software (em ingls: Manifesto for Agile Software Development). A frase final do Manifesto expressa de forma sucinta esse ideal [5]: Sendo assim, enquanto existe valor agregado aos itens da direita, ns valorizamos mais os itens da esquerda. Atravs desses valores, os fundadores do Manifesto gil chegaram a concluso de doze princpios que deveriam reger as metodologias geis [6]: 1. Nossa maior prioridade satisfazer o cliente, mediante a rpida e contnua entrega de software funcional. 13

2. Permitir mudanas nos requisitos, mesmo que tardiamente no projeto. Processos geis aproveitam mudanas para o benefcio do cliente. 3. Entregar software funcional frequentemente, podendo variar entre semanas ou meses, com uma preferncia por escalas de tempo menores. 4. Especialistas do domnio e desenvolvedores devem trabalhar juntos diariamente durante o projeto. 5. Desenvolver projetos em torno de indivduos motivados. Dar a eles o ambiente e apoio de que precisam, e confiar neles para a realizao do trabalho. 6. O mtodo mais prtico e eficiente de se comunicar com a equipe de desenvolvimento conversar cara-a-cara com os integrantes. 7. Software funcional a medida primria de progresso. 8. Processos geis promovem desenvolvimento sustentvel. Os patrocinadores, desenvolvedores e usurios devem ser capazes de manter um ritmo constante. 9. Ateno contnua a excelncia tcnica e bom design aumenta a agilidade. 10. Simplicidade - a arte de maximizar a quantidade de trabalho no terminado - essencial. 11. As melhores arquiteturas, requisitos e modelos surgem de equipes autoorganizadas. 12. Em intervalos regulares de tempo, a equipe reflete em como se tornar mais eficiente, ento se prepara e se ajusta de acordo. Esses princpios, ao contrrio do que muitos dizem, no formam a base para uma anti-metodologia. De fato, as metodologias geis no so uma forma de contrariar completamente as metodologias tradicionais. Na verdade, o Manifesto gil props uma nova abordagem na forma de desenvolver projetos. Por exemplo, modelagem uma prtica utilizada, mas no a ponto de se tornar primordial. Documentao outra prtica adotada

14

nos projetos, mas jamais levantar uma srie de relatrios que jamais sero completamente lidos ou que levaro muito tempo para serem revisados. Logo, os princpios e valores propostos pelo Manifesto gil so uma nova forma de pensar desenvolvimento e gerenciamento de software, tendo em mente um conjunto de valores compatveis, baseados na confiana e respeito pelos companheiros de equipe e promovendo modelos organizacionais simplificados e centrados em pessoas e em colaborao. Dessa maneira, construindo comunidades organizacionais nas quais seria prazeroso trabalhar. 2.2 Scrum

Scrum um processo leve que visa gerenciar e controlar o desenvolvimento de software: uma metodologia de gerncia de projetos. No entanto, ao invs de promover a tradicional abordagem do modelo cascata ou waterfall, anlise modelagem codificao teste instalao do sistema, Scrum adota as prticas iterativa e incremental. Assim, Scrum no dirigido a artefato (ou artifact-driven), onde so criados grandes documentos de requisitos, especificaes, documentos de modelagem e diagramas. Pelo contrrio, Scrum exige pouqussimos artefatos. Ele se concentra no que de fato importante: Gerenciar um projeto ou codificar um software que produza valor de negcio [4]. 2.2.1 Definies

Sprint: Uma Sprint uma iterao que segue o ciclo PDCA (Plan Do Check Act) e entrega incremento de software funcional. Essas iteraes duram normalmente de 2 a 4 semanas e comeam e terminam com uma reunio da equipe. Scrum Master: o responsvel por proteger os membros da equipe de desenvolvimento de qualquer presso ou ameaa externa, seja isto clientes esbravejantes, diretores da empresa insatisfeitos ou qualquer outra coisa que seja considerado perigoso para a produtividade da equipe. Tenta garantir que todas as prticas do Scrum sejam utilizadas com perfeio pela equipe. Assim como tambm tem um papel de facilitador nas reunies da Sprint. Normalmente assumem esse papel os gerentes de projeto ou lder 15

tcnico, mas na prtica pode ser assumido por qualquer um com experincia o suficiente na metodologia. Product Owner: o responsvel por priorizar o Product Backlog. Este um papel importante pois a equipe de desenvolvimento observar o Product Backlog priorizado e construir o Sprint Backlog, comprometendo-se a entregar os itens postados. O Product Owner garante que durante a Sprint no haver mudanas nos requisitos solicitados, porm, nos intervalos entre Sprints ele possui total liberdade para modific-los. Essa funo realizada por uma pessoa que simular o papel de cliente em relao ao produto (da o nome Owner). O papel normalmente exercido por algum da rea de marketing ou por algum usurio muito importante no contexto do desenvolvimento do produto. Scrum Team: a prpria equipe de desenvolvimento. No entanto, isso no significa que uma equipe tradicional de desenvolvimento de software com programadores, especialistas em BD, testadores e etc. . Na verdade, as equipes de desenvolvimento em Scrum so incentivadas a serem multidisciplinares, ou seja, todos trabalham cooperativamente para entregar as funcionalidades que a equipe se comprometeu a entregar no comeo do Sprint. O tamanho tpico de uma equipe varia entre 6 e 10 pessoas, mas nada impede que as equipes possuam mais colaboradores. Dashboard: Visto que o Scrum prega a transparncia dentro de uma equipe de desenvolvimento, um quadro onde todas as histrias (requisitos) existentes para um produto estejam expostas extremamente til. Este quadro conhecido como Dashboard. Nele esto registradas, preferencialmente atravs de post-its, as issues a serem entregues para o desenvolvimento de um produto. O dashboard possui o status das issues a serem entregues pela equipe. As issues vo se movendo no Dashboard com o passar do tempo de acordo com seu status, por exemplo: issue no Product Backlog (no est contida na Sprint atual), issue no Sprint Backlog (est contida na Sprint atual), issue no Work in Progress (trabalho sendo feito no momento exato), issue na reviso e issue finalizada. As divises existentes podem ser modificadas de acordo com a necessidade de cada equipe. A figura 1 mostra como deve ser a organizao de um dashboard;

16

Product Backlog: a lista principal de funcionalidades para o desenvolvimento de um dado produto. O Product Backlog pode e deve mudar no decorrer das sprints tornandose maior, melhor especificado e mudando as prioridades das issues. um elemento essencial na reunio de Planning, pois com o Product Backlog (priorizado) que o Product Owner ir se comunicar com a equipe de desenvolvimento com o objetivo de expressar suas maiores necessidades para aquela sprint. Sprint Backlog: Na reunio de planejamento da Sprint (Planning) o Product Owner dever mostrar o Product Backlog priorizado e a equipe ir escolher quais issues daquela lista sero realizadas durante aquela sprint. As issues escolhidas sero colocadas na sesso de Sprint Backlog, ou seja, lista de funcionalidades a serem implementadas na sprint corrente. Issue ou Estria: Cada elemento da lista conhecido como Issue e deve ser identificado com um nome e/ou id com objetivos de identificao e rastreamento. Essas issues devem possuir tambm uma breve descrio das funcionalidades requeridas pelo Product Owner para um dado produto. O time pode dividir uma issue em tarefas, de preferncia pequenas, para que, com a concluso de todas as tarefas, a prpria issue esteja concluda. uma forma de usar a abordagem dividir para conquistar em gerenciamento de projetos. Sprint Planning: a reunio principal do Scrum. Nela so planejadas as atividades para a sprint corrente. Nesta reunio, o Product Owner apresenta o Product Backlog priorizado, para da ento, os membros da equipe decidirem quais issues do Product Backlog sero includas no Sprint Backlog. De forma coletiva, o Product Owner e a equipe de desenvolvimento definem um objetivo para o Sprint, que na verdade uma breve descrio sobre o que se deseja entregar na Sprint. Sprint Review: No final de cada sprint, a equipe de desenvolvimento, o Scrum Master e o Product Owner se renem para verificar o que foi feito durante a sprint. A equipe apresenta as funcionalidades prontas e o Product Owner aprova ou desaprova o produto. Essa reunio aberta para qualquer outra equipe presente na empresa que queira observar a apresentao das issues completadas durante o sprint. A reunio possui a forma

17

de uma demo de produto, onde so apresentadas novas funcionalidades, bugs consertados entre outras coisas. Sprint Retrospective: realizada logo aps o Sprint Review e tem como objetivo extrair para todos da equipe a essncia do que houve de melhor e do que pode melhorar na sprint analisada. Essa reunio fechada para apenas a equipe e o Scrum Master. Durante essa reunio sero colhidas, atravs de comunicao cara-a-cara entre os integrantes da equipe, informaes sobre o andamento do projeto. Os membros da equipe so incentivados a falar sobre o que esto achando do projeto (em todos os sentidos) e realizada pelos prprios membros uma retrospectiva em formato de timeline especificando as datas chave para o sprint. Essa reunio considerada muito importante para o crescimento da equipe, pois nela onde sero mostrados os erros e consequentemente as lies aprendidas durante a sprint. Daily Scrum: uma reunio realizada diariamente entre os membros da equipe, Scrum Master e opcionalmente com a presena do Product Owner com o objetivo de analisar o que cada membro da equipe fez no dia anterior, o que pretende fazer durante o dia presente e quais os impedimentos ou obstculos que tem para cumprir com as tarefas. Normalmente feita em formato de Stand-up-meeting e de durao bem curta. uma forma eficiente de manter a comunicao aberta entre os membros da equipe de desenvolvimento e o Scrum Master.

18

Figura 1. Esquema de um dashboard no meio de uma sprint, mostrando tarefas a fazer, em processo, a verificar e finalizada. [13]

2.2.2 Fases

Planejamento: Essa fase marca o incio de uma nova Sprint. O Sprint Planning a cerimnia na qual a equipe se rene com o Product Owner para analisar as issues priorizadas por este e decidir quais destas a equipe se compromete em entregar. Essas reunies costumam durar de 1 a 3 horas com a participao ativa de todos da equipe. Geralmente o Product Owner explica brevemente o objetivo de cada issue e, caso surja alguma dvida, explica mais detalhadamente para todos.

Desenvolvimento: Essa fase a maior do Sprint, pois representa todos os dias em que a equipe est trabalhando concentradamente na entrega do software. Em cada um desses dias realizado o Daily Scrum com os membros da equipe. Neste so discutidas questes relativas entrega do software, como o que foi feito e o que pretendo fazer at o prximo Daily Scrum.

19

Concluso: A concluso de uma sprint marcada por duas cerimnias: Sprint Review e Sprint Retrospective. A Sprint Review uma cerimnia aberta para toda a empresa com o objetivo de mostrar as novas funcionalidades implementadas pela equipe de desenvolvimento durante a Sprint. A equipe faz uma breve demonstrao para o Product Owner, que aprova ou no a nova funcionalidade. Normalmente a Sprint Retrospective acontece logo aps a Sprint Review. A Sprint Retrospective de fato a ltima reunio da Sprint. Nesta reunio moderada pelo Scrum Master, a equipe discute seus melhores e piores momentos no decorrer da Sprint. comum acontecer que, ao final desta reunio, surjam feedbacks de coisas a melhorar, seja na equipe ou na prpria organizao. vlido salientar que esta reunio no aberta nem mesmo ao Product Owner, mas somente a equipe e ao Scrum Master, pois tem como objetivo realmente extrair o que cada membro est sentindo com relao ao andamento do projeto. Por este motivo, desaconselhada a presena de pessoas externas ao grupo na sala de reunio da equipe.

Figura 2. Funcionamento de uma Sprint recebendo Sprint Backlog como entrada e aps vrios Daily Scrums (durao mdia da Sprint de 2 a 4 semanas), a entrega do incremento de software funcionando. [13]

2.2.3 Vantagens e desvantagens

As metodologias tradicionais so projetadas para reagir a mudanas imprevisveis apenas no comeo de um ciclo de desenvolvimento. Mesmo as metodologias que no

20

seguem o modelo cascata (seguem o modelo espiral por exemplo), mostram-se limitadas para reagir a mudanas uma vez que o projeto tenha comeado. Scrum, por outro lado, lightweight, ou seja, leve. Foi modelado para ser adaptvel a mudanas durante todas as fases do projeto. Ele prov mecanismos de controle para planejar uma entrega de produto e, enquanto o projeto avana, prov variveis de gerenciamento. essa abordagem que permite a mudana do projeto e de entregas a qualquer momento, entregando assim, a parte mais apropriada do software desenvolvido. Scrum incentiva a criatividade dos membros da equipe de desenvolvimento na resoluo de problemas. Isso acontece quando os problemas surgem no projeto e/ou o ambiente de desenvolvimento sofre mudanas. Neste caso, os membros da equipe podem vir com as solues mais diferentes possveis de modo a resolver o problema e trazer a equipe novamente ao rumo correto. A deciso nesses casos sempre da equipe. Equipes pequenas, colaborativas e multidisciplinares compartilham conhecimento sobre todas as fases do processo de desenvolvimento. A conseqncia imediata disto a baixa concentrao de informao em apenas um membro da equipe. Caso algum membro precise sair da equipe por qualquer que seja o motivo, o impacto sobre o restante do grupo no ser muito grande. Alm do mais, essa caracterstica prov um treinamento excelente para todos os membros da equipe em todas as reas do processo de desenvolvimento. A tecnologia Orientada a Objetos (OO) prov a base para o Scrum. Por ser bastante prtica e limpa, a viso OO garante que os processos de Scrum sero simples de entender e de usar [7]. O curto intervalo de tempo entre os releases uma vantagem. Dessa forma, o cliente pode acompanhar de perto a evoluo do projeto e fornecer feedbacks a cada sprint, tornando-se assim tambm uma vantagem para a equipe desenvolvedora. Desenvolve-se desde cedo uma relao de confiana com o cliente, o que um grande fator de sucesso organizacional atualmente. [7] Scrum no se mostra vantajoso no caso de grandes projetos com durao muito longa, prazo muito curto, muitas pessoas trabalhando em muitas camadas e oramento

21

muito alto. Ken Schwaber, um dos fundadores de Scrum diz que quando se investe muito alto num projeto com um prazo muito apertado, os lderes da organizao no esto apoiando a independncia das equipes de desenvolvimento. O que costuma acontecer que, aps apenas uma Sprint, os gerentes de projeto analisam o Release Burndown e constatam que impossvel entregar o produto no prazo determinado. Normalmente os investidores recuam e o projeto cancelado. Nesses casos mais vantajoso usar o modelo cascata, pois s se constata que o projeto vai atrasar de fato aps alguns meses de trabalho e j tarde demais para cancelar o projeto [7]. Scrum um mtodo que exige uma gesto constante e muito prxima. Isso significa que o gestor deve estar sempre removendo barreiras e monitorando as equipes de desenvolvimento, se certificando de que as prticas da metodologia esto sendo postas em prtica como deveriam. Monitoramento constante exigido do gestor. Como Scrum prov um alto nvel de independncia s equipes, o gestor deve permitir que as equipes tomem suas prprias decises, permitindo at que estas falhem ao faz-lo. Assim, possvel haver prejuzos em curto prazo, tanto em sentido financeiro quanto em tempo. vlido lembrar que Scrum uma metodologia relativamente nova e que as pessoas so resistentes a mudanas. Na fase inicial de implantao da metodologia numa organizao, desconforto pode existir. H tambm a possibilidade de alguns elementos dentro da organizao no conseguirem se adaptar ao novo ritmo e nova filosofia do Scrum. [6] 2.3 Extreme Programming

Extreme Programming (XP) na verdade uma abordagem para o desenvolvimento de Software. Esta metodologia foi criada com o objetivo de entregar o software que o cliente precisa quando ele precisa. XP encoraja os desenvolvedores a se adaptarem a mudanas no escopo do projeto, mesmo que tardiamente no ciclo de produo do software.

22

Assim como a metodologia Scrum, XP enfatiza o trabalho em equipe como chave para um processo de produo de Software mais gil e com melhor qualidade. [13] 2.3.1 Princpios e diferenas para outras metodologias

Os princpios vistos no Manifesto gil so a base dos princpios do XP [14]. So eles: Codificar a atividade chave; Cultura de Software pronto no tempo do cliente; Ciclos freqentes de lanamento (Release); Comunicao feita a partir do cdigo; Melhorar cdigo com Refactoring.

Esses princpios no indicam que o desenvolvedor, quando estiver trabalhando, apenas comece a escrever cdigo rpida e desesperadamente. Pelo contrrio, preciso ser disciplinado nesse sentido ou o efeito ser contrrio ao desejado. A aplicao desses princpios num projeto de desenvolvimento de software a base para o estabelecimento da metodologia XP. Logo, diferentes caractersticas surgiro desta nova metodologia em relao a outras existentes no mercado. Podemos citar algumas dessas diferenas [17]: 1. Feedback rpido e contnuo advindo de um ciclo de vida mais curto do projeto; 2. Planejamento incremental, no esttico. Neste o plano de projeto pode evoluir; 3. Implementao de forma flexvel, de modo a se adequar s necessidades do cliente;

23

4. Baseia-se em comunicao oral, testes, e escrever cdigo como uma forma de descrever a estrutura e propsito do sistema; 5. Alto nvel de colaborao entre programadores com menos habilidades; 2.3.2 Boas Prticas

Pair-Programming: Programao em par ou Pair-Programming uma tcnica para o desenvolvimento de software na qual um programador no trabalha sozinho, mas sim com um companheiro de equipe. Assim, compartilham experincias, pensam juntos antes de escrever cdigo, tiram dvidas um do outro, enfim, trabalham conjuntamente num mesmo computador. Nesta tcnica, temos um piloto, que o usurio que est escrevendo cdigo, e temos o navegador, que o usurio responsvel por revisar cada linha de cdigo escrita. Isso costuma aliviar a presso em cima do piloto, pois o navegador possui tambm a responsabilidade de procurar eventuais falhas tanto na escrita quanto no design do cdigo [15]. Para que nenhuma das duas partes se limite a apenas um tipo de atividade (s codificar ou s revisar), os usurios devem trocar de lugar frequentemente. A grande vantagem da programao em par que, dessa forma, o cdigo final apresenta maior legibilidade, melhor design e menor susceptibilidade a erros. Por outro lado, a

programao em par pode causar intimidao em alguns programadores mais retrados ou menos habilidosos, diminuindo a produtividade da dupla. Planning Game: O processo de planejamento na metodologia Extreme Programming chamado de Planning Game ou Jogo do Planejamento. Esse jogo acontece uma vez por iterao e dividida em duas fases [15]: Planejamento do Release: O foco desta reunio planejar quais requisitos sero escolhidos para a prxima iterao e quando ser realizada a entrega dessas funcionalidades. Primeiramente, o cliente prover uma lista de requisitos que deseja para a sua aplicao. Estes requisitos sero mapeados em estrias e escritos em cartes. Da a equipe desenvolvedora ir escolher algumas dessas estrias para ser

24

implementadas e se comprometero com a entrega dessas. Finalmente, com as estrias em mos, a equipe e o cliente podero se reunir e decidir se algo mais ser acrescentado quela estria, removido da estria ou replanejado. Planejamento de Iterao: Neste planejamento, o cliente no participa. Apenas a equipe de desenvolvedores se rene para dividir as estrias escolhidas em tarefas menores. Primeiramente, as estrias so repartidas em tarefas e atividades e escritas em cartes. Da, os desenvolvedores decidem quem ficar com qual tarefa e estimam quanto tempo gastaro para termin-las. Aps as tarefas serem concludas, feita uma comparao entre o que foi planejado e o que de fato foi feito. Testes: Um fator que chama ateno na metodologia XP que num projeto, a equipe inteira tem responsabilidade pela qualidade do produto. Dessa maneira, todos os participantes da equipe, tanto programadores quanto testadores, so responsveis por criar testes (incluindo todos os tipos) para a aplicao. Testar uma atividade integrada num projeto XP. Os testadores devem fazer o mximo para transferir suas habilidades relativas atividade para todos os membros da equipe. Abaixo, citamos algumas atividades dos testadores numa equipe XP [16]: Negociar qualidade com o cliente (o cliente que decide o quo padronizado ele quer o cdigo); Esclarecer estrias e retirar dvidas que surgem durante a

implementao; Certificar-se de que os testes de aceitao verificam a qualidade especificada pelo cliente; Ajudar a equipe a automatizar testes; Testar a qualquer momento, sem qualquer restrio para isso. Qualquer integrante pode testar na hora em que quiser;

25

Definio e redefinio da arquitetura a todo o momento: Visto que em XP, a equipe de desenvolvimento est sempre analisando cdigo, testando funcionalidades e alterando o design da aplicao, a arquitetura est sempre sendo atualizada. Isso no implica dizer que a aplicao no possui uma padronizao na arquitetura. Pelo contrrio, a equipe est frequentemente alterando a estrutura da aplicao para ter maior flexibilidade escalabilidade e legibilidade, atributos que envolvem diretamente padronizao no cdigo. No h confuso quanto s redefinies de arquitetura porque a equipe est se comunicando a toda hora (um dos princpios do Manifesto gil). Stand-up Meeting: Reunio de curta durao (entre 5 e 10 minutos) entre os membros de uma equipe XP para discutir assuntos relacionados ao projeto. Esse tipo de reunio realizada normalmente todos os dias (podendo ser convocada a qualquer hora) com os membros todos de p (da o nome stand-up). O objetivo conseguir maior concentrao dos membros durante a reunio assim como evitar distraes, como conversas paralelas, assistir a vdeos no computador, chats e coisas do tipo. Por estarem todos de p, os membros no iro tirar o foco do assunto em pauta e no demoraro muito para terminar a reunio, que deve ser curta. 2.3.3 Elementos Gerente de Equipe: o responsvel por assuntos administrativos do projeto. Deve possuir grande habilidade ao lidar com pessoas, visto que ir tratar de assuntos ligados ao projeto com a equipe e com os clientes. um tipo de mediador entre os interesses da equipe e do cliente. Outro papel do gerente de equipe manter as ameaas externas longe da equipe sob sua superviso. Tambm responsvel por tentar manter o cliente informado do projeto em questo e, ainda mais importante para a empresa, participando do desenvolvimento de forma direta. Obviamente, um bom gerente de equipe deve acreditar em todos os valores de XP para que possa cobrar isto da sua equipe. Coach: Responsvel pelas questes tcnicas do projeto de software. O coach deve possuir grande conhecimento em todas as fases do XP e conhecer bem os membros da equipe. o responsvel por estimular a equipe a dar o melhor sempre que possvel. Ao

26

conhecer e aplicar os conceitos de XP, deve estar apto para sinalizar a sua equipe os erros cometidos ao longo do projeto e dar os passos necessrios para consert-los. Analista de teste: Responsvel por garantir a qualidade do sistema desenvolvido atravs da atividade de testes do sistema. Normalmente o analista de testes ajuda o cliente a escrever os casos de testes necessrios para garantir que os requisitos ordenados sero devidamente satisfeitos. No final duma iterao, deve realizar os testes no software a ser entregue com o objetivo de verificar se existem bugs e requisitos no-cumpridos. perigoso usar um desenvolvedor do software para test-lo e construir casos de teste junto ao cliente. O que pode acontecer que, pelo fato de o desenvolvedor conhecer o cdigo, ele ter uma viso tendenciosa, evitando tocar nos pontos que ele sabe serem sensveis no sistema. Por outro lado, o analista de testes deve ter uma viso muito parecida com a do cliente. Redator tcnico: Pessoa responsvel por cuidar da documentao do projeto. Dessa forma, a equipe de desenvolvedores pode se concentrar exclusivamente em codificar. Para que a documentao esteja de acordo com o cdigo escrito e as necessidades do cliente, o redator deve estar sempre em comunicao com os desenvolvedores, sabendo o que esto desenvolvendo e como. Desenvolvedor: o papel principal no XP. O desenvolvedor responsvel por analisar, projetar e escrever cdigo para o sistema em desenvolvimento. Numa equipe de desenvolvedores utilizando XP, os desenvolvedores esto todos no mesmo nvel. Por exemplo, no existe diferena entre analista e programador uma vez que eventualmente todos executaro uma dessas atividades. 2.3.4 Fases Explorao: Esta a primeira fase de um projeto utilizando XP e realizada anteriormente construo do sistema. So estudadas vrias solues para resolver o problema do cliente e verificadas as viabilidades de cada uma destas solues. Nesta fase so pensadas as possveis arquiteturas e ambientes, levando

27

em conta as condies necessrias para a implementao do sistema, como plataforma, sistema operacional, configuraes da rede, hardware e linguagem utilizada. O objetivo desta fase fazer os programadores e os prprios clientes ganharem confiana no planejamento do projeto para que, logo mais, comecem a escrever estrias e comear a construo do sistema. Planejamento inicial: utilizada para que os clientes e a empresa desenvolvedora do sistema possam acordar em uma data para o primeiro release. O planejamento tem incio com os programadores estimando as estrias escritas na fase de explorao e as escrevendo com seu valor estimado em cartes. Aps a estimativa de cada uma das estrias, a equipe informa quantas estrias podem ser entregues levando em considerao a mdia de estrias entregues em iteraes passadas. Por sua vez, o cliente prioriza as estrias em seu ponto de vista. O planejamento inicial obtm como sada uma srie de cartes com as estrias priorizadas e estimadas pela equipe, prontas para guiar os desenvolvedores na prxima fase. Normalmente a fase de planejamento inicial dura de uma a trs semanas e cada release dura de dois a quatro meses. Iteraes do release: Nessa fase comea a construo do sistema propriamente dita. Os desenvolvedores comeam a codificar, testar, refatorar, analisar cdigo, depurar bugs e projetar, sempre seguindo os princpios e valores da metodologia XP. Frequentemente durante uma iterao, a equipe realiza reunies de stand-up meeting, onde sero discutidas questes relativas a implementao do sistema. O resultado da primeira iterao de um produto essencial para o cliente ter uma idia de como o produto est sendo construdo (se est cumprindo os requisitos acordados anteriormente) e se haver atraso na entrega da release. Produo: Aps um release, o sistema est pronto para ser simulado em um ambiente de produo. Nesta fase, o sistema ser testado observando atributos como confiabilidade e performance. Testes de aceitao podem ser realizados de acordo com a necessidade do cliente. Manuteno: Aps um release o sistema estar funcionando bem o suficiente para poderem ser feitas manutenes. Isso pode envolver vrias atividades como por exemplo: refatoramento de cdigo existente, introduo de uma nova

28

arquitetura, instalao de um novo servidor no ambiente de desenvolvimento ou introduo de uma nova tecnologia. vlido ressaltar que uma vez que o sistema estiver em produo, fazer manutenes se torna perigoso. Por isso, a equipe deve tomar muito cuidado ao modificar o sistema, visto que uma alterao errada ou mal planejada pode causar danos gigantescos ao sistema, causando prejuzo ao cliente. Morte: Essa fase constitui o fim de um projeto XP. Normalmente ocorre quando o cliente j est plenamente satisfeito com o sistema obtido e no consegue visualizar nenhuma funcionalidade essencial para ser implementada

futuramente. Porm, podem ocorrer casos de um projeto XP morrer antes de completar o produto final. Por exemplo, se aps a primeira iterao o cliente observar que o tempo e oramento necessrios para a finalizao do projeto esto fora do alcance. Nestes casos, os clientes podem cancelar o projeto, causando seu fim. 2.4 Feature Driven Development

Feature Driven Development (FDD) uma metodologia gil para desenvolvimento de software, voltada para o cliente e orientada a modelagem. Consiste de cinco atividades ou fases bsicas e possui mtricas para marcar o progresso dessas atividades [22]. Nessa metodologia, as entregas, assim como nas outras apresentadas nesse trabalho, so incrementais. Atualmente, crescente o nmero de empresas de software que a utilizam por esta oferecer um esquema orientado a modelagem e agilidade ao processo de desenvolvimento [23]. 2.4.1 Elementos

Gerente de Projeto: o personagem central deste mtodo. Est frente do projeto. Possui como tarefas, delegar responsabilidades aos arquitetos-chefe e ao gerente de configurao (podendo tambm acumular esse papel), assim como tambm resolver problemas administrativos ligados ao projeto.

29

Arquitetos-chefe: Responsveis pela modelagem do sistema em todas as fases. Como o FDD d bastante nfase modelagem, os arquitetos-chefe so bastante cobrados e so diretamente responsveis pelo sucesso do projeto.

Programadores-chefe: Os programadores-chefe so os desenvolvedores mais experientes. A eles so atribudas funcionalidades a serem construdas. Entretanto, eles no as constroem sozinhos. Ao invs disso, o programadorchefe identifica quais classes esto envolvidas para se desenvolver a funcionalidade e rene seus proprietrios de classes, criando uma equipe para implementar aquela funcionalidade. O programador-chefe age como um coordenador, designer lder e mentor, enquanto os proprietrios de classes fazem a maior parte da programao das funcionalidades.

Proprietrios de cdigo/classes: So os desenvolvedores da equipe. Codificam, projetam e fazem anlise de cdigo a qualquer nvel. Possuem propriedade sobre o cdigo, de forma que ficam responsveis pela parte de cdigo que lhes foi designada. Assim, so diretamente responsveis pela legibilidade, bom design e clareza do cdigo.

Especialistas do domnio: Podem ser membros externos ou internos do projeto. Interno seria algum membro designado para entender completamente as necessidades do cliente de modo que pudesse represent-lo nas reunies da equipe. Externo no caso de o prprio cliente participar das reunies no projeto. So as pessoas que mais conhecem sobre o assunto abordado. O objetivo deles passar para a equipe o mximo de conhecimento sobre o domnio, de modo que os membros da equipe possam tambm se tornar experts no domnio.

Gerente de configurao: Membro responsvel por controlar o cdigo fonte de todo o sistema, mantendo sempre atualizadas as alteraes realizadas ao trmino ou incio de cada funcionalidade. Normalmente o gerente de configurao assume outros papis relativos configurao dos sistemas da equipe de desenvolvimento, aliviando a quantidade de trabalho desperdiada pelos desenvolvedores com problemas relativos a falhas tcnicas das mquinas (formatao do sistema, backups, troca de mouses ou teclados e etc.) entre outras coisas.

30

Testador: Membro responsvel por testar as funcionalidades implementadas pelos desenvolvedores do projeto. Escrever testes, casos de teste e testar funcionalidades manualmente so as principais tarefas do testador.

Redator tcnico: Responsvel pela documentao gerada nas reunies de planejamento da equipe. Dessa maneira, alivia os membros da equipe de trabalhos relativos escrita de documentos, focando exclusivamente na modelagem e construo das funcionalidades.

2.4.2 Boas prticas

Feature Driven Development possui um conjunto de boas prticas baseadas nas prticas de engenharia de software. Essas prticas so baseadas na viso de valor do cliente, e no da equipe de desenvolvimento [23]. justamente essa fuso de prticas e tcnicas que torna o FDD to til. Algumas prticas que tm sido amplamente aproveitadas no mercado de desenvolvimento de software so listadas. Modelagem do domnio: Explora e explica o domnio do problema a ser resolvido tendo como perspectiva a orientao a objetos. Esta considerada uma boa prtica, pois ajuda a descrever o domnio da aplicao, provendo uma modelagem genrica de alto nvel no qual podem ser adicionadas vrias funcionalidades. Desenvolvimento por funcionalidade: Qualquer atividade a ser desenvolvida deve ser analisada para verificar se esta pode ser quebrada em atividades menores, ou funcionalidades atmicas (indivisveis). Essa prtica torna o cdigo inteiro mais seguro contra erros. Alm do mais, garante flexibilidade e escalabilidade ao cdigo [24]. Posse sobre o cdigo: Em FDD, os desenvolvedores possuem individualmente posse de cdigo. Por exemplo, a classe A, B e C pertencem ao programador 1, enquanto as classes X, Y e Z pertencem ao programador 2. O proprietrio do cdigo torna-se automaticamente responsvel pela performance, consistncia, corretude e integrao da classe. O proprietrio aconselhado a utilizar os melhores padres da engenharia de software. No entanto, est livre para criar seus prprios padres. Equipes de funcionalidades: So equipes pequenas responsveis por desenvolver uma pequena atividade. Dessa forma, a equipe decide de forma conjunta como ser feito o

31

design de determinada funcionalidade. Com mais de uma pessoa pensando no mesmo problema, solues diferentes podem surgir. O que se torna muito eficiente, visto que no final essas solues podem ser fundidas em uma soluo final da equipe. Inspees: Inspeo de cdigo uma tima prtica de engenharia, pois alm de fazer verificaes contra erros, incentiva uma melhor modelagem do sistema, junto com atributos como legibilidade e alta coeso. Gerncia de configurao: Essa prtica tem como objetivo manter um controle sobre o cdigo fonte das funcionalidades implementadas, mapeando as funcionalidades aos seus respectivos cdigos-fontes e aos seus proprietrios. Alm disso, mantm as datas de modificao do cdigo, guardando um histrico de alteraes. Build constante: Deve existir sempre uma verso do sistema rodando numa mquina. Isso garante que a equipe possui pelo menos uma verso do sistema que funciona. Dessa forma, sempre que for necessrio apresentar alguma funcionalidade para o cliente, existir uma verso do sistema que pode ser utilizada para isso. Visibilidade do progresso: Como sempre mantido um relatrio de progresso das atividades do projeto, todos na equipe e fora dela sabem exatamente como esto em termos de produtividade. No entanto, essa atividade deve ser feita com muita preciso e frequncia. Caso contrrio, os dados extrados do relatrio sero enganosos e podero levar a decises desastrosas para o cliente. 2.4.3 Fases

O Feature Driven Development dividido em 5 atividades, cada uma destas possuindo sub-atividades que compem o processo como um todo. Essas 5 atividades so (em ordem) [23]: Desenvolver um modelo geral, gerar uma lista de funcionalidades, planejar por funcionalidade, modelar por funcionalidade e construir por funcionalidade. As trs primeiras so realizadas uma vez antes da realizao do projeto e as 2 restantes so realizadas a cada iterao. Todas essas atividades sero explicadas e suas sub-atividades sero listadas nesse tpico.

32

Desenvolver um modelo geral: O projeto comea com uma anlise superficial do escopo do sistema e seu contexto. Assim, so estudados os domnios de negcio do sistema e criado um modelo geral baseado nestes. Depois criada uma modelagem superficial para cada rea de domnio existente. Cada um desses modelos revisado por um grupo aleatrio de membros do projeto e melhorias so discutidas. escolhido o modelo de domnio melhor projetado, ou seno escolhido um modelo que a juno de mais de um domnio projetado. Finalmente, os modelos escolhidos para cada rea de domnio so fundidos para gerar um modelo do domnio como um todo (ou domnio principal) do sistema.

Sub-atividades: Formar equipe de modelagem; Estudar o domnio de negcio; Estudar os documentos; Formar vrias equipes pequenas para sugerir uma soluo de modelo; Desenvolver o modelo escolhido; Refinar o modelo geral gerado; Escrever notas explicativas sobre o modelo final;

Gerar uma lista de funcionalidades: O conhecimento obtido na fase de desenvolvimento do modelo geral essencial para esta fase. Nesta, ser elaborada uma lista de funcionalidades do sistema decompondo as reas de domnio obtidas. Cada funcionalidade uma pequena tarefa a ser implementada que gere valor para o cliente. Devem seguir o formato <ao> <resultado> <objeto>, por exemplo: Gerar relatrio de vendas ou Validar a senha do usurio. Essas funcionalidades so muito importantes para o processo como um todo. A no identificao delas causa um impacto enorme sobre o projeto, pois significa que a primeira fase no foi feita com sucesso e consequentemente os efeitos aparecem em cascata nas prximas fases [22].

Sub-atividades: Escolher uma equipe para gerar uma lista de funcionalidades; Gerar a lista de funcionalidades.

33

Planejar por funcionalidade: realizado o planejamento de desenvolvimento de cada funcionalidade da lista obtida da fase anterior. So designadas classes ou cdigo especfico para os programadores-chefe tomarem conta. Da em diante, os programadoreschefe sero responsveis pelo cdigo produzido nessas classes.

Sub-atividades: Formar uma equipe de planejamento Determinar a sequncia de desenvolvimento das funcionalidades; Designar atividades de negcio para os programadores-chefe; Designar classes para os desenvolvedores.

Modelar por funcionalidade: Os programadores-chefe escolhem algumas funcionalidades para que, junto com os proprietrios de cdigo, sejam feitos os diagramas de sequncia e a modelagem completa das funcionalidades. A diferena desta modelagem para a modelagem feita na primeira fase que esta especfica para a funcionalidade em questo. Ou seja, nesta etapa pensa-se nas classes, mtodos e atributos que iro existir. Ao final da modelagem, realizada uma inspeo do modelo pela equipe que a fez ou por outra equipe designada.

Sub-atividades: Formar uma equipe para a funcionalidade em questo; Estudar a funcionalidade como parte inserida no modelo de domnio; Estudar documentos relacionados funcionalidade; Desenvolver diagrama de sequncia; Refinar objeto modelo; Escrever as classes e as assinaturas dos mtodos (tipo de retorno, parmetros e excees lanadas); Realizar inspeo da modelagem.

34

Construir por funcionalidade: Aps a modelagem, o cdigo finalmente implementado e os testes finalmente escritos. Assim, o cdigo fonte produzido e as funcionalidades ganham vida. O programador-chefe designa um programador para implementar uma certa funcionalidade. Logo, este ltimo ser o proprietrio do cdigo escrito. Aps uma inspeo no cdigo escrito, a funcionalidade terminada.

Sub-atividades: Implementar as regras de negcio das classes; Inspecionar cdigo; Conduzir testes unitrios; Release da funcionalidade.

Figura 3. Os 5 processos do FDD.[24]

2.4.4 Vantagens e desvantagens

Por ser orientado a modelo e utilizar logo cedo no projeto (na fase de Desenvolvimento de um modelo geral) transferncia de conhecimento ao utilizar vrias equipes para projetar vrias solues para o domnio pedido, FDD agrega valor aos membros das equipes [24]. E ainda por cima, o conhecimento do domnio estar crescendo de forma similar atravs de todos os membros de todas as equipes. Isso possvel pelo fato

35

de a modelagem realizada inicialmente ser feita de maneira superficial e no especfica, habilitando todos os membros das equipes a aprenderem sobre o domnio. Para um gerente de projeto, ter um modelo preciso para poder se basear essencial para o andamento do projeto. Para se ter esse modelo preciso, deve haver algum tipo de atividade de anlise que gere informao. exatamente o que faz a primeira fase do FDD [24]. FDD torna o trabalho do gerente de projeto mais fcil ao medir o progresso de cada funcionalidade em termos de valor para o cliente. Se todo o projeto feito utilizando a noo de valor do cliente, ser mais fcil discutir assuntos como mudanas e escopo do projeto. Ou seja, unifica a linguagem utilizada por todos no projeto, incentivando a comunicao de todos os pontos. FDD enfatiza bastante a modelagem do sistema. Apesar de a ltima fase ser implementao do cdigo, a fase mais crtica dessa metodologia a fase de modelagem das funcionalidades. A arquitetura do sistema analisada em quase todas as fases. Por estar sempre sendo testada, a modelagem do sistema tende a ser mais flexvel e reutilizvel. Apesar de possuir um ciclo completo de documentao, a especificao original da aplicao no comenta sobre sua aplicabilidade a manuteno de sistemas. Este um ponto em aberto para a metodologia FDD [22]. Por ser extremamente focado em documentao de modelagem do sistema, FDD foge um pouco de um dos princpios do Manifesto gil: Software funcional sobre documentao abrangente.. Muita documentao produzida durante as 4 primeiras fases e o cdigo s realmente experimentado na ltima fase, perdendo prioridade diante de outras atividades de modelagem. Por possuir vrios papis, fica evidente que uma equipe FDD no pode ser muito menor que o nmero de papis existentes na metodologia. Caso isto ocorra, uma mesma pessoa passar a assumir vrias responsabilidades distintas dentro de uma mesma equipe. Assim, o foco deste membro no ser to consistente, poder ocorrer sobrecarga de trabalho e conflitos de interesses, causando impacto sobre o projeto.

36

2.5 Anlise Comparativa

As 3 metodologias analisadas possuem um objetivo comum: conferir agilidade ao processo de desenvolvimento de software ganhando eficincia. Porm, as trs possuem caractersticas diferentes. So essas caractersticas que sero comparadas neste tpico. No quadro abaixo so mostrados alguns atributos e como as metodologias se adaptam a estes. Observe a legenda: * - 1 asterisco (Acontece com freqncia razovel) ** - 2 asteriscos (Acontece com freqncia alta) - 0 asterisco (Ausncia desse atributo)

Caractersticas/Metodologia Equipes pequenas nfase no modelo nfase gerencial Interao Cliente/Desenvolvedor Gerenciamento de risco Projetos grandes/complexos Stand-up meetings Especialista em

FDD ** * *

XP * **

SCRUM ** ** **

* **

** *

* ** -

37

documentao Cdigo coletivo ** *

Tabela 1. Anlise comparativa entre Scrum, XP e FDD.

Analisemos agora, essas caractersticas uma por uma. Equipes pequenas:

Scrum: Em Scrum existem poucos papis (Scrum Master, Product Owner e membro da equipe) que no podem ser acumulados por um mesmo membro. Alm disso, as tcnicas gerenciais do Scrum so muito flexveis, podendo ser usadas em projetos no ligados a rea de software, inclusive com pouqussimas pessoas numa equipe. XP: Prega-se a comunicao pessoal como um dos princpios da metodologia. Comunicao que deve ser feita a todo momento entre os membros de uma equipe. Obviamente, esse princpio melhor colocado em prtica no caso de equipes pequenas.

FDD: Como envolve muitos papis entre os membros e esses papis no podem ser exercidos pela mesma pessoa por questes de conflitos de interesses, FDD no d margem para equipes muito pequenas. Normalmente, quando bem distribudos entre os membros, os papis so de vital importncia para o sucesso do projeto. XP e Scrum no possuem este problema.

nfase no modelo:

Scrum: Em Scrum no h essa preocupao com a arquitetura do sistema, pois a metodologia no foi projetada com o intuito exclusivo de ser utilizada no desenvolvimento de software [7]. Assim, a nfase nas interaes entre os indivduos.

XP: Em XP, a nfase na codificao/manuteno do cdigo.

38

FDD: a nica destas trs metodologias que possui um foco na arquitetura ou modelagem do sistema. Nesta metodologia, a arquitetura pensada desde a primeira fase do ciclo iterativo e passa por inspees durante todas as outras fases [23].

nfase gerencial:

Scrum: uma metodologia focada em processos gerenciais [7]. No existe uma lista de tcnicas agregadas aos processos de Scrum assim como existe em XP, por exemplo. Por outro lado, existe uma carga maior de prticas gerenciais que incentivam agilidade em equipe quando comparado a outras metodologias geis.

XP: uma metodologia orientada a processos de desenvolvimento. Assim, no possui nfase gerencial.

FDD: Possui certa nfase gerencial. Existem membros dentro de uma equipe FDD responsveis por outros setores. Por exemplo, programador-chefe um papel gerencial, no sentido de que coordena os desenvolvedores nas atividades destes. Por sua vez, respondem a superiores (gerentes de equipe), afirmando um carter gerencial a metodologia.

Interao cliente/desenvolvedor:

Scrum: Por ser uma das principais caractersticas das metodologias geis, todas as trs metodologias mencionadas aplicam-na de alguma forma. Scrum aplica intensivamente, visto que o Product Owner faz o papel do cliente durante a Sprint e suas cerimnias. Assim, participa das reunies de planejamento junto aos desenvolvedores e explica os requisitos pessoalmente, priorizando os de maior necessidade. O ideal que o Product Owner seja o prprio cliente ou algum representante do cliente. No entanto, caso isso no seja possvel, a equipe do projeto designar um membro experiente para estudar as necessidades do cliente e executar o papel deste. Dessa maneira, em Scrum, sempre h um alto nvel de interao entre os desenvolvedores e o cliente.

39

XP: Este na verdade um dos poucos requisitos do XP. O cliente deve estar presente todo momento. No apenas para ajudar o time de desenvolvimento, mas tambm para ser parte dele. Todas as fases de um projeto XP dependem de comunicao com o cliente, de preferncia cara a cara [14]. O cliente escrever estrias junto com os desenvolvedores, avaliar funcionalidades implementadas e daro feedback o mais rpido possvel para a equipe de desenvolvimento.

FDD: Existe interao com o prprio cliente. O cliente deve estar sempre presente nas reunies de planejamento e principalmente durante a primeira fase de modelagem do ciclo. O cliente normalmente tambm o especialista no domnio, explicando as regras de negcio para os arquitetos e os programadores-chefe. Entretanto, como os programadores-chefe no so propriamente desenvolvedores, o contato entre o cliente e os desenvolvedores ser realizado indiretamente, diminuindo a intensidade da interao Cliente/Desenvolvedor. Alm disso, os desenvolvedores comeam a trabalhar baseados na modelagem existente do sistema, a qual tarefa dos arquitetos e programadores-chefe junto ao cliente.

Projetos grandes e complexos:

Scrum: Scrum foi primeiramente pensado para controlar grupos pequenos. No entanto, pode ser escalvel para trabalhar com grupos de 50 ou 60 pessoas [7]. Mas, nesse caso necessrio dividir o grupo em grupos menores e executar um Scrum de Scrums, onde cada grupo utiliza Scrum internamente e um Scrum Master controla as interaes entre os grupos existentes. Alm disso, por haver uma quantidade grande de pessoas trabalhando num mesmo projeto, torna-se mais difcil a comunicao cara-a-cara entre elas, prejudicando a obedincia ao princpio da comunicao no Scrum.

XP: Segue o mesmo princpio de pequenas equipes auto-organizadas que existe no Scrum. Semelhantemente, pode ser escalvel para grandes equipes em grandes projetos, mas originalmente foi idealizado para equipes pequenas com poder de deciso prprio.

40

FDD: O primeiro projeto utilizando FDD foi realizado para um banco em Cingapura no ano de 1997. Neste projeto, participavam 50 pessoas e o prazo era de 15 meses [22]. Assim, a prpria origem da metodologia indica que FDD pode ser utilizado em projetos grandes sem necessitar repartir os membros em pequenos grupos de FDD. Isto se d pelo perfil hierrquico ao qual a metodologia se apega. Diferentemente de XP e Scrum, FDD possui uma hierarquia especfica, podendo assim delegar grupos de pessoas sob a responsabilidade de um membro, por exemplo, um gerente. o que acontece entre os papis de desenvolvedor e programador-chefe - vrios desenvolvedores esto subordinados a um ou mais programadores-chefe.

Gerenciamento de riscos:

Scrum: A cada Daily Scrum, a equipe se rene e conversa sobre o que foi feito desde a ltima reunio at ento. So discutidos tambm possveis impedimentos e riscos que podem atrapalhar o trabalho de desenvolvimento da equipe. Os membros da equipe devem se sentir absolutamente livres para expressar algo que est ameaando a equipe: influncias externas, falta de recursos, desmotivao, falta de clareza nos requisitos, entre outros. Esse impedimento escrito em um carto e colado no Dashboard da equipe, indicando para o Scrum Master que existe um obstculo a ser retirado. uma forma rpida e descomplicada de levantar riscos e elimin-los (sempre que possvel) [8]. Por outro lado, no h um plano explcito para (1) identificar riscos, (2) estabelecer estratgias de gerenciamento de riscos e (3) mitigar riscos.

XP: Como a nfase no processo de desenvolvimento e no no processo de gerncia, no h uma base para tratar riscos em XP.

FDD: Cabe ao gerente de projeto identificar e eliminar riscos durante o projeto. No existe um documento de Gerenciamento de Riscos assim como tambm no h impedimentos levantados pela equipe. Os riscos so vigiados pelo gerente de

41

projeto e tratados de acordo com sua estratgia. O objetivo dessa abordagem diante de riscos justamente evitar se concentrar em problemas gerenciais, de modo a se concentrar principalmente no design e conseqente implementao do sistema.

Stand-up meetings:

Scrum: Esse estilo de reunio proposto inicialmente na metodologia XP utilizado tambm por Scrum. Em Scrum, essas reunies so chamadas de Daily Scrum e as equipes programam um horrio especfico para realiz-la todos os dias.

XP: No h um horrio especfico para realizar essas reunies. desejvel que seja realizada todos os dias, mas no uma cerimnia formal e qualquer membro da equipe pode convocar um stand-up meeting a qualquer momento [13].

FDD: Apesar de a comunicao interna ser estimulada, no existem traos especficos deste estilo de reunio entre os membros de uma equipe.

Especialista em documentao:

Scrum: No h um redator tcnico. O prprio Scrum Master ou Product Owner se responsabilizam pela documentao produzida.

XP: Em XP, existe um especialista em documentao assim como no FDD, se responsabilizando sobre documentos de requisitos, casos de uso, mudanas de requisitos, entre outros. No entanto, como esses documentos s so produzidos quando promovem algum valor para o cliente, a importncia do redator tcnico no to grande.

FDD: Como FDD d muita ateno documentao produzida durante a modelagem, uma pessoa responsvel por estes documentos: o redator tcnico. Este responsvel por aliviar a carga sobre os desenvolvedores e gerentes, tomando conta da documentao produzida durante as fases de desenvolvimento.

42

Cdigo coletivo:

Scrum: Quando utilizado em projetos de software, no prega abertamente a coletividade do cdigo. No entanto, seus princpios se adquam a esta caracterstica advinda do XP [18]. Quando uma estria est sendo implementada, a equipe inteira j se comprometeu com aquela estria. Logo, toda equipe deve ter acesso ao cdigo fonte e liberdade para modific-lo.

XP: Possui a coletividade do cdigo como um princpio [13]. O cdigo pertence equipe e todos devem estar cientes disso. Esse princpio estimulado por outra tcnica de XP - Pair-Programming. Ferramentas de desenvolvimento como CVS e SVN so utilizadas como forma de repositrio para o cdigo implementado.

FDD: Designa alguns membros especficos como proprietrios de classe. Isso bate de frente com a idia de cdigo coletivo pregada por XP. Na verdade, FDD foi pensado realmente desta forma. Seu criador, Jeff De Luca, escreveu que cdigo coletivo no uma estrutura em que ele realmente acredita [22].

43

3. TCNICAS E ABORDAGENS GEIS

Neste captulo sero apresentadas algumas tcnicas geis de desenvolvimento bastante utilizadas na indstria de software. As explicaes sobre essas tcnicas de engenharia so breves e enfatizam trs pontos: funcionamento; benefcios de aplicar a tcnica; e limitaes desta. 3.1 Test Driven Development

Test Driven Development uma tcnica de desenvolvimento de Software que utiliza pequenas iteraes de desenvolvimento atravs de testes unitrios escritos antes de ser escrito o cdigo pertencente funcionalidade em questo. Cada iterao produz cdigo necessrio exclusivamente para passar pelos testes daquela iterao. Quando essa fase de iteraes termina, o programador faz um refactor no cdigo gerado. 3.1.1 Como funciona

1. Criando um teste: Antes de uma funcionalidade ser criada, o programador escreve um teste para ela. Obviamente, nesta primeira tentativa o teste ir falhar. Mas ele deve falhar, porque no h como testar uma funcionalidade sem antes constru-la. A grande vantagem de escrever um teste antes de implementar uma funcionalidade que o desenvolvedor ir pensar nos requisitos antes de codificar, ao contrrio do que se faz normalmente. essencial que o programador entenda bem a regra de negcio em questo antes de escrever o teste, pois dessa forma, evita escrever um teste errado do ponto de vista da lgica de negcio, anulando o teste [8]. 2. Teste o teste: O prximo passo rodar todos os testes e verificar se o teste em questo passa. Se ele passar, significa que intil, pois est aprovando cdigo que na verdade no deveria passar (a funcionalidade correspondente daquele teste ainda no existe). Esse passo realizado com o propsito de assegurar para 44

o programador que esse teste realmente est funcionando de forma correta, falhando quando deve falhar [8]. 3. Escreva cdigo: O programador deve escrever cdigo correspondente a funcionalidade testada. Ou seja, implementar a funcionalidade exclusivamente para o respectivo teste passar. Caso o teste passe mas de alguma forma o programador no tenha ficado satisfeito com a forma como isso aconteceu, no se deve ajustar o cdigo imediatamente. Esse passo est mais adiante. 4. Faa todos os testes passarem: O prximo passo rodar todos os testes e verificar se passaram com a incluso do novo teste em questo. Caso acontea algum erro em qualquer dos testes, o programador repete o passo anterior at que o teste passe. 5. Faa o refactor: Finalmente, aps o novo teste passar junto com todos os testes existentes anteriormente, o programador deve limpar o cdigo. Isso pode envolver vrias coisas, como por exemplo, remover cdigo duplicado ou melhorar desempenho [11]. Nesse passo que sero feitas as adaptaes necessrias de acordo com a vontade do programador, por exemplo, remover algum artifcio tcnico (um if a mais ou algum nmero mgico colocado no cdigo para fazer o teste passar). Caso acontea algum erro em qualquer dos testes, o programador deve voltar aos passos 3 e 4, at que o teste passe e o cdigo esteja refatorado de maneira satisfatria. 6. Loop: Com o cdigo pronto e todos os testes passando, o programador deve passar para a prxima iterao, repetindo o ciclo desde o comeo. importante que o tamanho das alteraes seja pequeno, forando o programador a pensar em cada pequena etapa individualmente. uma forma de usar a abordagem Dividir para Conquistar para assegurar que, se as pequenas partes do cdigo esto funcionando e seus respectivos testes esto sendo aprovados, a aplicao como um todo ir funcionar e estar completamente testada [9].

45

Figura 4. Grafo mostrando as etapas do Test Driven Development. [12]

3.1.2 Benefcios

Um estudo realizado em 2005 mostrou que os programadores que utilizavam TDD escreviam mais testes e, por sua vez, programadores que escreviam mais testes tinham a tendncia de ser mais produtivos [10]. Logo, Test Driven Development indicado para equipes de desenvolvimento que desejam construir software de forma mais rpida sem perder qualidade. Essa tcnica oferece mais do que apenas corretude, mas pode tambm melhorar a arquitetura do software. Um grande benefcio obtido por utilizar TDD a capacidade de uma aplicao inteira em pequenos passos. Isso significa que o programador ir se concentrar na tarefa atual - fazer o teste passar sem interferir nos outros testes j aprovados. Cada pequena parte do cdigo ser analisada cuidadosamente e ter a ateno do programador, cada uma por

46

vez. Casos excepcionais e erros complexos no so considerados inicialmente. Para esses casos especiais, devem ser criados separadamente testes para verific-los [9]. Outra vantagem de se utilizar TDD num projeto de desenvolvimento de software a grande cobertura de testes provida pela tcnica. Se as pequenas partes do cdigo esto funcionando e testadas, o cdigo como um todo estar seguro. Alm disso, a futura manuteno do cdigo ser mais fcil e uma grande margem de segurana quanto a erros ser dada aos clientes. Normalmente um programador que utiliza TDD escreve mais testes (e consequentemente mais cdigo) do que um programador que no utiliza TDD [10]. No entanto, o tempo total de implementao menor utilizando TDD [8]. Uma grande quantidade de testes limita a quantidade de erros num projeto de software. Se esses testes forem aprovados junto com o trmino das funcionalidades, ou seja, no incio do projeto, haver uma base concreta de preveno contra erros endmicos, poupando o desenvolvedor do trabalho de lenta e custosa depurao de cdigo. TDD tende a deixar o cdigo mais flexvel, modularizado e extensvel. Esse efeito obtido pela caracterstica do prprio TDD de analisar cada parte do cdigo individualmente quanto corretude e design. Dessa forma, as classes tendem a ser menores, centradas num s objetivo e com baixo acoplamento. Ao incentivar os desenvolvedores a programarem o suficiente apenas para o teste correspondente passar, TDD torna o cdigo mais simples e fcil de entender. 3.1.3 Limitaes

Assim como toda tcnica de engenharia, TDD tambm tem seus pontos fracos, por assim dizer. Na verdade, so situaes onde se torna difcil aplicar seus conceitos e obter bons resultados.

47

Ao desenvolver partes do cdigo concernente a interfaces grficas o TDD no proveitoso porque nesse caso so necessrios testes completamente funcionais. Qualquer outra situao que exigir testes completamente funcionais no se aplica a TDD [9]. Em casos onde a organizao/empresa inteira no est totalmente convencida de que TDD aumenta a agilidade e a produtividade, TDD no costuma obter sucesso. Isso acontece pelo fato de, mais cedo ou mais tarde, a gerncia comea a achar que o tempo gasto escrevendo testes tempo desperdiado [9]. Visto que nesta tcnica o desenvolvedor escreve os testes para o cdigo que ele mesmo implementou, pode haver algum ponto cego, ou seja, um pedao de cdigo implementado com potencial de erro, mas nenhum teste escrito para este pedao. Pair Programming pode ser a soluo nesses casos. Se o desenvolvedor no entendeu completamente o fundamento do TDD, ao criar os testes para seu prprio cdigo, ele pode cair no erro de simplesmente querer fazer os testes passarem para livrar seus cdigos de erros, sem realmente analisar se os testes so efetivos. Isso gera um falso senso de segurana na equipe desenvolvedora e, uma vez que encontrados os erros, o prejuzo ser muito maior. 3.2 Outras tcnicas

Existem inmeras outras tcnicas de engenharia que podem tornar o desenvolvimento de software mais rpida e de melhor qualidade. Essas tcnicas apresentadas aqui no so consideradas tcnicas geis propriamente ditas, mas, so tcnicas que aceleram o desenvolvimento de software dentro de uma empresa. No entanto, abordamos aqui duas tcnicas que se mostram muito populares atualmente na indstria de desenvolvimento de software. A primeira delas Design Patterns, que uma tcnica de modelagem/desenvolvimento de software. E a segunda delas Controle de Verso, que uma tcnica de suporte ao desenvolvimento de software.

48

3.2.1 Design Patterns

Design Patterns, termo conhecido em portugus como padres de projeto ou padres de desenho de software, descrevem solues para problemas decorrentes no desenvolvimento de sistemas de software orientados a objetos. Por padro, um design pattern descreve [26]:

Um problema recorrente; Uma soluo; Quando aplicar a soluo; Conseqncias.

Os objetivos dos design patterns so: permitir o reuso do cdigo, facilitar o design das classes orientadas a objetos e melhorar a documentao e o aprendizado de um projeto de software. Para isso, o padro precisa definir uma soluo para um problema especfico, ser independente e mostrar claramente onde se aplica. Os design patterns GoF (Gang of Four) totalizam 23 design patterns documentados e catalogados, que so, ao mesmo tempo, os mais populares e mais utilizados entre desenvolvedores de software na indstria [26]. Esses design patterns so divididos em 3 categorias ou tipos de padro: Criacional: Esse padro lida com a melhor forma de se criar instncias de classes. A idia que um programa no dependa da forma como os objetos e classes so criados e inicializados dentro dele. Os padres criacionais so: o Abstract Factory; o Builder; o Factory Method; o Prototype; o Singleton.

49

Estrutural: Este padro lida com a implementao das classes e dos objetos. Tem por objetivo suavizar o design do sistema por identificar formas de realizar relacionamentos entre entidades existentes no modelo de uma maneira simples. Os padres estruturais so: o Adapter; o Bridge; o Composite; o Decorator; o Faade ou Fachada; o Flyweight; o Proxy.

Comportamental: Tem por objetivo encontrar dinamicamente padres de comunicao entre objetos e identificar esses padres. Dessa forma, os padres comportamentais aumentam a flexibilidade na forma como a comunicao exercida. Os padres comportamentais so: o Chain of Responsability; o Command; o Iterator; o Mediator; o Memento; o Observer; o State; o Strategy; o Template Method; o Visitor.

O uso de design patterns durante a etapa de desenvolvimento de software possui diversas vantagens. Para os desenvolvedores de uma equipe extremamente produtivo, pois incentiva uma forma clara e otimizada de comunicao. Projetistas de software podem discutir a soluo para um problema de forma transparente, visto que todos na equipe de

50

desenvolvimento entendem os padres de projeto. O tempo de aprendizado da equipe de desenvolvimento reduzido drasticamente [27]. Tambm, prov uma melhor forma de documentar solues e resolver problemas de maneira prtica. Alm disso, por ter sido utilizada em diversos projetos que apresentaram o mesmo problema, essas solues mostram-se comprovadamente eficazes. Padres de projeto tornam o cdigo mais coeso e com acoplamento mnimo, atributos desejveis de engenharia de software [27]. A complexidade do cdigo reduzida por causa da forma como so tratadas as abstraes de classes e instncias. Por apresentar atributos como rapidez no processo de aprendizagem dos desenvolvedores, transparncia das solues apresentadas, alto nvel de reuso de cdigo no sistema, baixo nvel de complexidade, praticidade ao resolver problemas recorrentes e melhoria na capacidade de expresso da equipe, os padres de projeto mostram ser uma tcnica de engenharia bastante eficaz para ser utilizada durante a fase de codificao/modelagem de software.

3.2.2 Controle de verso

Um sistema de controle de verso um software que tem por finalidade gerenciar as verses geradas de um software durante todo o processo de fabricao deste [28]. Na verdade, estes softwares so utilizados para salvar histrico de modificaes de qualquer documento. Entretanto, na indstria de softwares eles so extremamente necessrios por guardar diferentes verses de cdigo-fonte e documentao do projeto. Sistemas de controle de verso so muito populares atualmente e podem ser encontrados em forma de softwares livres, como CVS e SVN, ou softwares comerciais, como o ClearCase da IBM. Uma diferena entre as solues comerciais e livres, que as verses livres no oferecem garantia contra erros, por exemplo, perda de dados. Por outro lado, as verses livres possuem melhor performance e maior segurana contra ataques externos [28].

51

O funcionamento bsico de um sistema de controle de verso bastante simples e pode ser explicado brevemente por meio dos elementos que compem este sistema [28]: Servidor: Uma mquina que possui espao para armazenamento de arquivos. Deve possuir um endereo lgico, que pode ser uma URL ou um conjunto IP/porta. Esse endereo necessrio para o cliente poder se conectar ao servidor. Repositrio: o sistema de arquivos responsvel por armazenar os dados gravados dos documentos. Esses dados devem ser guardados de forma persistente (como num banco de dados) e facilmente resgatveis. Um servidor pode possuir mais de um repositrio. Por exemplo, o repositrio A conter os arquivos produzidos pelo projeto X. Enquanto o repositrio B armazenar os arquivos produzidos pelo projeto Y. Cpia local: Todo desenvolvedor possui em sua mquina uma cpia dos seus documentos. Esses documentos so sempre a verso mais atual existente no sistema. Quando um desenvolvedor resolve salvar (fazer um commit) um documento no sistema de controle de verso pela primeira vez, este documento fica salvo no repositrio especificado pelo desenvolvedor. Caso outro desenvolvedor do mesmo projeto que possui acesso ao documento salvo faa uma alterao na sua cpia local e deseje salv-la no respositrio, o sistema no permitir. De fato, o sistema indicar para este usurio que ele possui uma verso desatualizada daquele documento. Uma vez que o desenvolvedor atualiza a verso mais nova do documento, ele capaz de alterar este documento e salv-lo no sistema novamente. Num projeto de software, extremamente til manter um histrico das verses do produto em desenvolvimento. exatamente esse o objetivo dos sistemas de controle de verso. Esses sistemas oferecem facilidade ao fazer/desfazer modificaes nos documentos do projeto, possibilitando uma anlise do histrico de desenvolvimento. Alguns sistemas, como CVS e SVN, por exemplo, exibem at mesmo comparaes entre verses produzidas

52

[29]. Assim, todos os elementos da equipe podem compartilhar cdigo-fonte do sistema em desenvolvimento sem medo de fazer alteraes irreversveis. Alm disso, o cdigo se torna acessvel e compreensvel por todos da equipe, promovendo a integrao entre os membros. Ao mesmo tempo, evita conflitos de verses, que pode ocorrer sempre que dois usurios esto modificando um mesmo arquivo ao mesmo tempo. Muitos sistemas permitem que os usurios salvem uma verso estvel do projeto inteiro ou tag. A idia que, caso o lanamento de uma nova verso acontea com erros, fazendo surgir uma verso instvel, possvel pedir ao sistema para voltar ltima verso estvel do projeto [28]. Assim, uma equipe de desenvolvimento pode sempre possuir uma verso relativamente estvel do produto em desenvolvimento, facilitando inclusive a manuteno do software. Sistemas de controle de verso mostram-se tambm ser uma ferramenta de suporte que confere agilidade ao projeto. Ao utilizar esse sistema, uma equipe de desenvolvimento pode desenvolver funcionalidades em paralelo, sem que uma interfira na outra.

3.3 Domain Driven Design Uma abordagem gil

Modelagem de software como uma arte e no pode ser ensinada como uma cincia exata por meio de frmulas e teoremas. Podem ser utilizados princpios e mtodos para melhorar a construo de um software, no entanto, jamais existir um caminho exato a ser seguido para prover as necessidades de um sistema no mundo real com um software. Assim como na construo de um prdio, a construo de um software ir refletir caractersticas das pessoas que o modelaram e o implementaram. Existem vrias formas de abordar o modelo de um sistema. Nos ltimos 20 anos, a indstria de software tem utilizado vrios mtodos de modelagem para criar seus produtos, cada um deles com suas vantagens e desvantagens [26]. O objetivo deste tpico abordar uma abordagem de modelagem que tem sido aprimorada por mais de duas dcadas,

53

contudo, tem se afirmado mais claramente como um mtodo h poucos anos: Domain Driven Design (DDD). DDD uma abordagem da modelagem que visa tornar a idealizao e consequentemente a construo de software mais gil, fazendo isso de uma forma transparente a todos envolvidos no processo. DDD combina prticas de modelagem e desenvolvimento, e mostra como bom design e desenvolvimento podem trabalhar juntos para criar uma soluo tima. Um bom design ir acelerar o desenvolvimento, enquanto feedback constante provido por parte do desenvolvimento aumentar a qualidade do design.[25] 3.3.1 Conhecimento do domnio

Como o prprio nome da tcnica diz, o foco desta tcnica o domnio de negcio. Por onde comear a idealizao de um software? Entendendo o domnio. A melhor forma de compreender bem um determinado domnio conversar com as pessoas que melhor o entendem. Isso significa que no caso de um software para uma central de teletxi, por exemplo, o mais recomendado seria conversar com as pessoas que trabalham na central atendendo os telefonemas. No caso de um software para controle de trfego areo, seriam os controladores de vo. E assim por diante. O objetivo encontrar o expert do domnio, a pessoa que tem em sua mente o modelo de como o sistema no mundo real funciona para, desta forma, transferir o modelo para o papel. O arquiteto, analista ou desenvolvedor do software deve conversar com o expert do domnio, trocar conhecimento, fazer perguntas e escutar bem as respostas. Dessa forma, o idealizador do software estar como que escavando o problema, captando conceitos essenciais do domnio em questo. Esses conceitos podem parecer confusos e desorganizados de incio. Mas, de qualquer forma so essenciais para o entendimento do domnio. O objetivo ao fazer perguntas extrair o modelo dentro da mente dos experts de domnio. O ideal que o idealizador do software junto com o expert do domnio consigam chegar a um consenso sobre a viso do domnio e produzam um modelo. Essa viso no

54

ser completa nem correta inicialmente. Contudo, algo necessrio para comear a pensar nos conceitos essenciais do domnio [25]. Em algum momento durante o processo de modelagem do sistema, os especialistas em software talvez queiram fazer um prottipo do modelo para testar se este funciona. Essa uma atitude produtiva, pois ao encontrar erros, os idealizadores do software podem querer fazer modificaes no modelo. interessante que a comunicao no unilateral, sempre vinda do especialista do domnio at os desenvolvedores, arquitetos e analistas. Pelo contrrio, os especialistas do software devem, sempre que possvel, prover feedbacks. Isso aumenta a clareza e a qualidade do modelo produzido [25]. De forma geral, especialistas do domnio conhecem bem sobre suas reas de trabalho, entretanto, organizam as idias de um modo particular. Cabe ao especialista do software sintetizar esse conhecimento de forma til para montar o design do software. Essa atividade pode parecer custosa no comeo, e realmente deve ser, pois no final dessa atividade o sistema em forma de software deve refletir perfeitamente o funcionamento do sistema no mundo real [25]. 3.3.2 Uma linguagem ubqua

Os especialistas de software ao falar com especialistas do domnio esto sempre com a mente cheia de assuntos ligados a rea de desenvolvimento. Enquanto o especialista do domnio explica os conceitos, os especialistas de software esto pensando em termos de Orientao a Objetos, herana, poliformismo, atributos e coisas do tipo. Mas os especialistas do domnio no fazem idia do que seja um framework, uma classe ou padres de projetos. Logo, no h como conversar sobre o domnio usando uma linguagem que apenas um lado dos especialistas entender. Da mesma forma, especialistas do domnio possuem uma viso bem particular da sua rea de trabalho. Usam jarges que normalmente no so compreendidos por pessoas que no trabalham na rea. Essa linguagem tambm no seria compartilhada por ambos os lados. E quando ambos os lados no conseguem se comunicar efetivamente significa que o projeto tem problemas. Deste problema surgiu a idia para uma linguagem ubqua. Esse um dos princpios centrais do DDD e tem como objetivo unificar a linguagem de ambos os especialistas. A

55

idia criar uma linguagem baseada no modelo e no na rea de domnio de nenhum dos lados. O modelo o fator comum entre as duas equipes. onde a rea de domnio se funde com o software. O modelo serve de esqueleto para a comunicao entre as partes. DDD prega que a linguagem ubqua deve ser utilizada consistentemente por todas as fases do projeto, inclusive na implementao [25]. Criar uma linguagem ubqua no um trabalho fcil. Pelo contrrio, a linguagem deve ser criada junto com o modelo. Quando o modelo sofre modificaes, a linguagem sofre modificaes. necessrio encontrar os termos-chave que definiro o modelo e o domnio. Alguns termos so fceis de encontrar, outros so difceis. Mas uma vez decidido qual termo utilizar para um conceito do domnio, este termo deve ser utilizado em todo documento, diagrama, classe ou mtodo que se refira ao mesmo conceito. s vezes necessrio esclarecer um termo entre as equipes de especialistas para que no haja confuso sobre conceitos importantes do sistema futuramente. Caso os especialistas de domnio achem que determinado termo muito obscuro para ser entendido facilmente, significa que este termo no deve ser utilizado. Deve ser discutido um termo alternativo para substitu-lo. Da mesma forma, especialistas de software devem estar atentos a ambigidades ou inconsistncias de termos que iro aparecer durante a modelagem.

3.3.3 Model Driven Design

Na viso do DDD, construir um modelo a parte mais importante de todo o processo de desenvolvimento de software [25]. a partir da que o software vai tomar forma e se tornar extensvel, flexvel e de fcil manuteno. Um problema comum que ocorre no desenvolvimento de um modelo quando o modelo feito separadamente pelos especialistas do domnio e arquitetos de software. Estes tendem a enxergar o modelo descartando caractersticas intrnsecas da tecnologia usada, pois no so desenvolvedores. Por exemplo, talvez o modelo produzido independentemente no seja compatvel com o conceito de objetos persistentes. Talvez o framework utilizado trate os objetos do modelo de uma forma no transparente aos desenvolvedores. Na fase de

56

implementao, o modelo codificado pelos desenvolvedores no ser equivalente ao modelo produzido inicialmente, produzindo software de qualidade questionvel [26]. A soluo que DDD prope incluir os desenvolvedores nas reunies de definio do modelo. O modelo do domnio deve ser construdo com um olho aberto ao software e a caractersticas da arquitetura.[25] Ou seja, desenvolvedores devem ser includos na produo do modelo. Isso prov feedback de ambas as partes, o que produtivo para o produto final. importante lembrar que a comunicao nessas reunies deve utilizar a linguagem ubqua criada para o modelo [25]. Dessa forma, todos envolvidos na elaborao do modelo (desenvolvedores, analistas, arquitetos de software e especialistas do domnio) sero capazes de compreender os problemas e solues apresentados. 3.3.4 Elementos do Model Driven Design

Neste tpico sero apresentados de forma breve os elementos ou padres mais importantes do Model Driven Design. O objetivo mostrar alguns conceitos principais usados na modelagem de objetos ou design de softwares do ponto de vista do DDD. A Figura 5 representa alguns desses elementos e indica como eles se relacionam. 1. Arquitetura em camadas: Model Driven Design divide o software basicamente em 4 camadas: Interface Grfica (apresentao das informaes na tela), Aplicao (coordena atividades da prpria aplicao aplicao), Domnio (regras de negcio) e Infra-estrutura (classes de suporte ao sistema). DDD incentiva que cada uma dessas camadas deve ser dependente apenas das camadas mais abaixo. Ou seja, os desenvolvedores devem isolar todo o cdigo relativo ao domnio e manter esse cdigo em apenas uma camada. Isso promove baixo acoplamento e quebra a complexidade do sistema em partes menores. Se o cdigo no estiver separado corretamente em camadas, a manuteno se tornar muito difcil [26]. 2. Entidades: Nem todo objeto uma entidade. Mas todo objeto que possua uma identidade prpria deve ser uma entidade. DDD incentiva a utilizao de

57

entidades dentro do sistema. Ou o objeto possui um atributo que serve como identificao nica dele ou o objeto ser identificado por uma juno de vrios atributos dele. Os desenvolvedores devem saber quando utilizar objetos como entidades e quando no. Entretanto, invariavelmente um sistema deve ter suas prprias entidades, isto , objetos que possuem uma identificao prpria para se diferenciar de outros objetos idnticos. 3. Objetos-Valor: So objetos utilizados para descrever certo aspecto do domnio e no possuem uma identificao nica [25]. Obviamente, nem todo objeto dentro de um sistema ser uma entidade. Isso degradaria a performance do sistema e criaria atributos inexpressivos para os objetos. Logo, no seria uma boa prtica de modelagem do domnio. Objetos-valor so caractersticos de objetos que no possuem uma necessidade de continuidade durante a vida do sistema, ou seja, podem ser criados e descartados a qualquer momento sem conflitos de identidade. DDD d muita nfase no fato de que os idealizadores do modelo devem saber quando um objeto uma entidade ou um objeto-valor. 4. Servios: Caracteriza um objeto do domnio que prov algum tipo de servio. Mas, no funciona como uma entidade nem como um objeto-valor. Na verdade, uma operao realizada pelo sistema que no se encaixa como um comportamento de um objeto. So classes que provem determinados tipos de servios e servem como ponto de conexo entre vrios objetos do domnio. As operaes realizadas pelos servios so conceitos do domnio que no pertencem a um objeto-valor ou a uma entidade. No entanto, as operaes normalmente se comunicam com outros objetos e no guardam um estado prprio (stateless). 5. Mdulos: Modelos muito grandes so difceis de se analisar como um todo. Por isso, DDD incentiva a criao de mdulos, que so utilizados como uma forma de organizar conceitos relacionados dentro do modelo com o objetivo de quebrar a complexidade. Essa prtica incentiva a alta coeso, um atributo muito importante da engenharia de software. Ao organizar mdulos, os especialistas de software devem agrupar classes com o mesmo propsito e isolar classes com 58

propsitos diferentes. Para haver boa integrao entre os mdulos, devem existir interfaces bem definidas e acessveis de dentro de outros mdulos. 6. Aggregates: Esse um padro de projeto bastante til para eliminar relacionamentos complexos no domnio. Muitos relacionamentos entre objetos so complicados de administrar e muitas vezes podem tornar o software performtico. Modelos com relacionamentos complexos sofrem com a manuteno destes, principalmente se os relacionamentos forem bidirecionais. DDD prega que este tipo de modelagem no eficiente [25]. Portanto, um modelo do domnio deve possuir o mnimo de relacionamentos possvel. Um dos principais problemas encontrados com os relacionamentos complexos e multidirecionais a dependncia criada entre os objetos. Caso um objeto precise ser deletado do sistema, todas as referncias que apontam para ele devem ser notificadas. O mesmo ocorre no caso de uma atualizao no estado do objeto. O padro aggregates resolve isso de forma simples. Como o prprio nome sugere, so criados objetos agregados dentro de outro objeto. Porm, a nica parte acessvel externamente a raiz do Aggregates, que normalmente uma entidade. uma forma simples de substituir a idia de relacionamentos por objetos dependentes. Assim, evitam-se relacionamentos de outros objetos externos com os internos ao Aggregates. Assim, caso a raiz precise ser deletada do sistema, suas dependncias sero deletadas conjuntamente sem

processamentos demorados. 7. Factories: comum aparecerem objetos complexos na modelagem do domnio. Objetos complexos seriam, por exemplo, objetos que encapsulam outros objetos ou objetos com construtores extensos. No momento de instanciar os objetos, os construtores desses objetos tornam-se muito grandes, complicando a legibilidade do cdigo e separando o modelo do domnio do domnio no mundo real. Como DDD prega que os sistemas devem espelhar o domnio real, construtores extensos no devem ser utilizados [25]. Alm disso, objetos no deveriam criar a si prprios. Mas, deveriam existir objetos que criassem outros objetos de forma descomplicada. Esses objetos criadores so chamados de Factories. As

59

Factories no fazem parte do domnio real, mas fazem parte da modelagem da aplicao. Elas provem uma interface que abstrai a criao de objetos complexos, por exemplo, Aggregates. Alm disso, Factories no exigem que o cliente referencie classes concretas ao instanciar objetos. Toda informao para a obteno do novo objeto escondida dentro da Factory deste objeto. Existem diversos padres de projetos que implementam o modelo de Factories [26]. De qualquer forma, uma instncia do tipo Carro seria obtida atravs de uma Factory de Carros, por exemplo. 8. Repositrios: O propsito de um repositrio encapsular toda lgica necessria para obter referncias de objetos. Os objetos do domnio no tero de lidar com a camada de infra-estrutura do sistema para obter referncias de outros objetos do domnio. Eles simplesmente pegam as referncias para esses objetos no repositrio. Dessa forma, o modelo fica mais claro e coeso. Objetos podem ser guardados no repositrio para uso posterior. Alm disso, caso o repositrio receba uma requisio por uma referncia que ele no possua, ele sempre pode obter esta referncia da camada de infra-estrutura. De qualquer forma, o repositrio age como um local de persistncia dos objetos acessveis globalmente. Dessa maneira, a camada de infra-estrutura ser invocada bem menos do que anteriormente (num modelo sem repositrio). Essa tcnica confere agilidade e simplicidade ao sistema [26].

60

Figura 5. Relaes entre os elementos que compem o Domain Driven Design. [25]

3.3.5 Benefcios

Domain Driven Design no uma metodologia de desenvolvimento de software. Na verdade, uma nova abordagem que prov um conjunto de boas prticas para modelagem de um sistema. Essas boas prticas incentivam o trabalho em equipe, com todos os membros participando da troca de conhecimento e do desenvolvimento do modelo do domnio. DDD tem como principal alvo a compreenso do domnio do sistema. A modelagem de um sistema de software deve se espelhar o mximo possvel na rea de domnio a qual o sistema pertence. Dessa forma, so evitados objetos complexos e esquemas complicados demais para a compreenso de pessoas que no so especialistas em software. Ao utilizar tcnicas como Diviso por Camadas, DDD maximiza a escalabilidade do sistema e confere maior facilidade na manuteno do software. Ao utilizar tcnicas de modelagem como Aggregates e Objetos-valor, reduz a necessidade por relacionamentos 61

complexos no modelo. Logo, o sistema projetado tende a ter melhor desempenho e maior coeso. A comunicao e o feedback existente entre todos envolvidos no projeto, desde especialistas do domnio at desenvolvedores, prov grande agilidade ao desenvolvimento do modelo e consequentemente do sistema. Possveis erros de modelagem so evitados cedo durante o design do sistema. Problemas de integrao so logo detectados e discutidos atravs de uma linguagem comum entre todos os envolvidos. Ms decises de implementao so refatoradas para uma melhor construo do cdigo. Enfim, DDD evita erros na modelagem do software, confere agilidade ao processo de produo e ao mesmo tempo agrega valor ao produto final.

62

4. COMPONDO MTODOS GEIS

Neste captulo, sero mostradas composies dos mtodos geis apresentados neste trabalho. Ser explicado como podemos combinar Scrum, XP e TDD, de forma a agilizar todas as atividades da equipe de desenvolvimento. Da mesma forma, supriremos FDD com tcnicas de modelagem existentes no DDD e com Design Patterns na parte de desenvolvimento. Muitas outras composies poderiam ser explicadas neste captulo. No entanto, a escolha das composies mostradas neste captulo fruto de uma anlise realizada pelo autor. Os critrios utilizados para escolher os mtodos que fariam parte das composies foram: 1. Princpios convergentes e no conflitantes entre si; 2. Abordagens semelhantes entre si; 3. nfase do mtodo (gerencial, testes, modelagem e etc.). 4.1 Scrum + XP + TDD

Scrum e XP so duas metodologias com abordagens diferentes, mas com um objetivo comum. Ambas propem aumentar a produtividade do desenvolvimento de uma equipe. O motivo disto que, na realidade, ambas foram idealizadas sobre o mesmo conjunto de princpios. Princpios estes que se encontram hoje fundamentados no Manifesto gil [5]. Enquanto isso, TDD ser aplicado dentro das tcnicas do XP como um mtodo que agiliza ainda mais os processos deste.

63

Enquanto Scrum confere agilidade focando essencialmente no processo gerencial, XP prov uma srie de tcnicas de engenharia que comprovadamente aumentam a produtividade das equipes de desenvolvimento de software. Pode-se dizer ento que XP preenche o espao deixado em Scrum com relao a tcnicas de desenvolvimento de software, assim como Scrum envolve XP com uma camada a mais de agilidade, estabelecendo passos bem definidos para gerenciar as fases de desenvolvimento. Como essas duas metodologias se complementam, podemos utilizar Scrum e XP num mesmo projeto, de modo que Scrum seja executado na parte de gerncia de pessoas e atividades, enquanto XP, sobre o desenvolvimento das tarefas que geram valor de negcio para o cliente. Dessa forma, teramos agilidade em todas as partes do projeto, desde a gerncia at o desenvolvimento. Scrum funcionaria ento, como uma embalagem para as tcnicas providas por XP. Dessa maneira, como Scrum no possui regras especficas sobre a forma como os desenvolvedores devem programar ou testar um software, XP pode ser usado durante toda uma sprint, controlando a forma como o desenvolvimento realizado, por exemplo, usando Pair-Programming. Ao mesmo tempo, TDD pode ser utilizado como mtodo de desenvolvimento e testes durante toda uma sprint. Visto que ambas as metodologias, XP e Scrum possuem os mesmos princpios e objetivos, mas no possuem princpios contraditrios entre si, no h razo para concluir que a unio entre elas seja improdutiva. Pelo contrrio, muitas empresas de renome no mercado de Software tm optado continuamente pela unio entre Scrum e XP na execuo dos seus projetos [19]. Suponhamos um projeto de desenvolvimento de software X para uma dada empresa. O cliente que encomendou este projeto quer receber o produto o mais rpido possvel. Mais tarde a empresa notificada que os requisitos podem mudar bruscamente durante o projeto. A empresa decide utilizar mtodos geis: Scrum e XP. Como seria possvel executar as duas metodologias de forma a cumprir com o objetivo final entregar software funcionando rpido e cumprir com os requisitos do cliente? Vamos analisar, passo a passo, uma soluo para essa questo.

64

4.1.1 Praticando Scrum + XP + TDD

Pr-Sprint ou Sprint Zero: No comeo do projeto, o Scrum Master decide se ir fazer uma Sprint Zero, a qual normalmente opcional, na qual seria organizada a arquitetura inicial da aplicao, escolhidos os membros da equipe de desenvolvimento e explicado o propsito do projeto. papel do Scrum Master, no apenas assegurar que a equipe cumpra com os princpios e valores do Scrum, mas agora, que tambm as tcnicas do XP sejam seguidas. Deve incentivar a equipe a ser o mais comunicativa possvel. E claro, assegur-los de que estar trabalhando para retirar impedimentos que possam atrapalhar o andamento do projeto. Sprint Planning : Sero definidas as issues para o projeto. O Product Owner priorizar as issues definidas de acordo com a vontade do cliente. Antes de se comprometer sobre quais issues sero entregues, a equipe deve estar a par de quais tcnicas de XP sero utilizadas no desenvolvimento das tarefas. S ento, levando esse fator em considerao, a equipe estima as issues e as divide em tarefas de acordo com a vontade dos desenvolvedores. O Planning dever gerar como resultado um Sprint Backlog. Cada issue do Sprint Backlog deve conter uma lista de tcnicas de XP que devem ser utilizadas para aquela issue. Dependendo do cumprimento das tcnicas, a issue no poder ser finalizada. Por exemplo, caso o Pair-Programming no tenha sido feito durante uma atividade, o Scrum Master deve repor essa tcnica por outra que tenha a mesma finalidade, que aumentar a margem contra erros e melhorar a qualidade do cdigo. Daily Scrum : Essas reunies por si s j aplicam originalmente o conceito de Stand-up Meeting presente no XP. Durante essas curtas reunies entre a equipe, explicado e discutido o que foi feito desde a ltima reunio de Daily Scrum e o que ser feito at a prxima. Normalmente, se alguma atividade em progresso estiver sendo realizada em par, apenas uma pessoa explica o que est sendo feito. No entanto, no prximo Daily Scrum, a outra pessoa, que no falou na reunio passada, deve explicar. A inteno dessa estratgia sempre garantir que nenhum dos dois elementos da dupla esteja por fora da implementao em algum momento durante a Sprint.

65

Dias de trabalho da Sprint : Durante os dias de trabalho da Sprint, a equipe deve sempre procurar pr em prtica tanto os conceitos de Scrum quanto os de XP. nessa fase que as tcnicas de XP sero realmente teis. Como XP possui uma srie de tcnicas de engenharia para agilizar o desenvolvimento de software, a equipe deve aplic-las durante os dias de trabalho para otimizar a produtividade. Uma dessas tcnicas a programao em par ou Pair-Programming. Em Scrum, a responsabilidade por uma funcionalidade da equipe. Assim, todos os membros devem estar a par do cdigo escrito. Por esta razo, o cdigo considerado coletivo e normalmente as equipes utilizam ferramentas de suporte como CVS e SVN. Entretanto, XP no contraria este princpio. Nesta metodologia o cdigo tambm considerado coletivo. A diferena que os programadores que utilizam PairProgramming tm contato direto com o cdigo um do outro. Assim, se algum da dupla repentinamente sair do projeto, por exemplo, o programador que ficou j conhece o cdigo bem o suficiente, de modo que o trabalho no pra. Consequentemente este problema ser reduzido a um problema menor: substituir o membro que saiu. Tcnicas de padronizao de cdigo podem ser utilizadas para facilitar ainda mais o entendimento do cdigo por parte de outros programadores da equipe [21]. Durante os dias de trabalho da Sprint, os membros devem estar sempre atentos a qualidade do cdigo escrito. Uma das atividades de XP que ajuda a melhorar a qualidade do cdigo o Refactoring ou Refatorao do Cdigo. Normalmente esta tcnica feita conjuntamente com o Pair-Programming: enquanto o piloto escreve o cdigo, o navegador pensa, entre outras coisas, em como refatorar o cdigo para simplific-lo. Os programadores tambm devem ter em mente um dos princpios do XP: Design Simples. Isso significa que, para resolver um problema, a soluo mais simples sempre deve ser escolhida ao invs de solues mais complexas, mesmo que as ltimas sejam mais robustas. A idia visar agilidade em primeiro lugar. Obviamente, no se pode esquecer da confiabilidade do produto entregue. Por isso, os desenvolvedores devem sempre testar o que foi implementado. Normalmente, uma equipe s considera uma issue como finalizada aps a mesma ter sido testada. O teste pode acontecer aps o fim da codificao ou pode acontecer durante o desenvolvimento, utilizando TDD sempre que possvel. Dessa forma, os testes sero escritos antes das respectivas funcionalidades, aumentando a capacidade do programador de prever possveis falhas e conseqentemente evitando mais bugs. Como TDD possui refatorao como uma de suas atividades, a equipe

66

estaria assim testando, refatorando e codificando ao mesmo tempo, priorizando mais uma vez a agilidade sem perder o foco em qualidade. Concluso da Sprint: Essa fase composta pelas reunies de Sprint Review e Sprint Retrospective. O Sprint Review realizado da forma tradicional seguindo os padres do Scrum. J na Sprint Retrospective, a equipe se reunir numa sala segura e livre de pessoas externas a equipe para discutir sobre o que aconteceu naquela Sprint. Sero levantadas questes sobre o que houve de bom e o que h ainda para melhorar. Assim como tambm lembradas as lies aprendidas durante aquela Sprint. Portanto, a equipe tem uma grande oportunidade para conversar sobre o que est funcionando e o que no est. Entre essas, devem ser levadas em considerao os mtodos utilizados, como: Pair-Programming, Design Simples, Refactoring, TDD e padres de codificao. Por exemplo, se no Projeto X os programadores no esto satisfeitos na forma como os pares so distribudos, devem levantar isso na reunio e comunicar ao Scrum Master. Dessa forma, a comunicao efetiva entre os membros da equipe levar a equipe ao auge de sua capacidade. Ao fim da Sprint Retrospective, uma Sprint ter sido finalizada e o cliente j estar com um software funcionando e devidamente testado, cumprindo a exigncia de entrega rpida.

Figura 6. XP sendo executado dentro das iteraes do Scrum. [19]

67

4.1.2 Vantagens da composio

O uso das tcnicas de XP e TDD dentro de um projeto de software causam uma grande melhoria na qualidade do cdigo. Apesar de cada uma das prticas influenciar diferentes aspectos do cdigo, em conjunto elas tm um efeito profundo na melhoria da qualidade do produto final. Entretanto, esse efeito na qualidade do produto s notado aps um perodo de tempo, quando o cdigo existente j passou por diversos refatoramentos e a aplicao j foi testada de diversas maneiras. Esse acontecimento explicado pela forma incremental como o Scrum funciona, ou seja, a cada Sprint o produto vai ficando cada vez mais funcional e mais valorizado pelo cliente. Scrum aplicado junto com XP num projeto de software melhora ainda a produtividade da equipe. O motivo principal disto a unio de idias, princpios e valores semelhantes unidos com um nico objetivo: Permitir aos desenvolvedores focar-se em funcionalidades teis para o cliente ao invs de entregar artefatos de valor questionvel. Isso no significa que essas duas metodologias desprezem documentao. Na realidade, atividades de anlise e modelagem so realizados quando necessrio para o projeto, ou seja, quando sentido que elas agregam valor ao produto. Entretanto, quando constatado que essas atividades no geram valor para o cliente, a equipe responsvel pelo projeto deve ignor-las [19]. Executar Scrum junto com XP torna o projeto transparente para o cliente. O motivo disto que ambas pregam que o cliente (ou um representante do cliente) deve estar sempre presente durante o planejamento das atividades e sempre disponvel para sanar dvidas dos desenvolvedores. Tambm as funcionalidades criadas de forma incremental so entregues diretamente ao cliente, o que aumenta a capacidade deste de fornecer feedbacks para a equipe de desenvolvimento. Quando o Product Owner prioriza as issues durante a reunio de Planning, est na verdade comunicando aos desenvolvedores quais so suas principais necessidades naquele momento. Consequentemente, quando as respectivas funcionalidades

68

estiverem prontas, o cliente ficar mais do que satisfeito. Por sua vez, a excitao do cliente contaminar a equipe do projeto, aumentando a confiana deste. E assim sucessivamente. A necessidade de Scrum por uma tcnica ou uma srie de tcnicas geis de desenvolvimento suprida de forma bastante oportuna com a metodologia XP. Da mesma forma, h a necessidade por parte do XP de uma metodologia com nfase em processos gerenciais para controlar a execuo iterativa e incremental de um projeto. Logo, h uma relao de dependncia entre as duas metodologias. Quanto mais XP for incorporado dentro de um projeto Scrum, mais a equipe de desenvolvimento sair ganhando, pois estar eliminando os pontos fracos das duas metodologias paralelamente [20]. Ao utilizar TDD em unio com as tcnicas de XP, a equipe ser ainda mais gil com relao ao desenvolvimento [21]. Escrever testes para qualquer mtodo antes mesmo deste existir, pode parecer uma perda de tempo. Mas o que acontece na prtica o contrrio. O tempo perdido com testes no comeo do desenvolvimento agilizar muito mais o andamento do projeto no futuro, pois poupar o programador de depurar linha por linha de cdigos imensos. TDD tende a melhorar a qualidade do cdigo e a robustez dos softwares produzidos[10]. Assim, escrever testes para toda e qualquer funcionalidade de uma aplicao antes mesmo de implement-la significa garantir uma maior confiabilidade do cdigo como um todo. A quantidade de bugs encontrados no software ser menor e consequentemente o custo com manuteno de software ser menor. Utilizar Pair-Programming com TDD numa equipe que j utiliza Scrum extremamente indicado para equipes que possuem programadores de diferentes nveis tcnicos [19]. Como no caso das duas metodologias o cdigo coletivo, os desenvolvedores com menos experincia e qualidade tcnica podem formar par com desenvolvedores mais experientes e de nvel tcnico mais alto. Isso far com que a evoluo do programador menos experiente se torne visvel a todos os membros da equipe. Dessa forma, a confiana de uns para com os outros ser fortificada. Com os membros compartilhando experincias entre si e se ensinando mutuamente, a equipe ser cada vez

69

mais auto-organizada e multi-disciplinar, exaltando os valores de uma equipe que segue Scrum. 4.1.3 Concluso Scrum e XP integram facilmente uma a outra para construir projetos de software de forma gil, e tambm podem ser usados independentemente. A principal fora destas duas tecnologias o compartilhamento de valores e princpios convergentes [20]. De fato, elas possuem mais semelhanas do que diferenas e, sendo assim, podem ser acopladas de modo a produzir software de qualidade incrementalmente. Enquanto Scrum se refere a prticas de gerenciamento, XP focada em prticas de engenharia. Consequentemente, Scrum pode ser utilizado como uma embalagem para projetos XP, tornando tais projetos mais escalveis [21]. Na prtica, XP executado principalmente dentro dos dias de trabalho da Sprint, onde os desenvolvedores aplicaro suas tcnicas de desenvolvimento de software. 4.2 FDD + DDD + Design Patterns

Ao contrrio da composio entre Scrum e XP, que so duas metodologias com focos diferentes, Feature Driven Development e Domain Driven Design possuem o mesmo foco: modelagem do sistema. Ambos visam projetar o sistema num documento antes que em uma mquina. Aps toda a modelagem pronta, design patterns podem ser usadas como uma tcnica de programao eficaz para expressar os conceitos orientado a objeto do modelo. FDD prov uma sequncia de fases para fabricar um modelo inicial, que ser modificado de acordo com as mudanas encontradas nas iteraes do projeto. DDD uma forma de abordar a modelagem do sistema com uma srie de tcnicas aplicveis no prprio design. Tanto FDD quanto DDD incentivam boas prticas para gerar um modelo para o sistema. Ambos pregam que o modelo a base para um bom projeto de software. Assim, DDD supre os processos do FDD com alguns mtodos que incentivam a excelncia no desenvolvimento do modelo.

70

Como o prprio DDD possui alguns elementos de design como Factories e Aggregates por exemplo, design patterns, que possui esses padres por definio, pode ser muito bem aproveitado na implementao das funcionalidades do modelo do sistema. Alm de prover suporte as abstraes do modelo, design patterns pode oferecer outras tcnicas para melhorar as boas prticas de reuso de software num dado projeto. Por possurem o mesmo foco e no possurem princpios contraditrios, FDD e DDD podem trazer muitos benefcios quando aplicados conjuntamente num mesmo projeto de desenvolvimento de software. FDD funciona como uma base para gerenciar os passos do desenvolvimento, j que possui uma sequncia de fases do desenvolvimento de software. Enquanto DDD pode ser usado como um provedor de boas prticas dentro de cada uma dessas fases do FDD. Podemos dizer que existiria um mdulo DDD dentro de cada um dos processos de FDD. Por outro lado, FDD possui uma tcnica onde so escolhidos proprietrios de cdigo. Logo, o cdigo no compartilhado por toda equipe, mas uma responsabilidade restrita ao proprietrio. Dessa forma, ao chegar fase de construo do software, os especialistas no domnio no tem acesso ao que est acontecendo no sistema que eles encomendaram. DDD corrige essa falha, como ser mostrado mais a frente. Suponhamos um projeto de software X numa dada empresa. Esse software a ser construdo possui um domnio especfico, digamos, um software para gerenciar ligaes dentro de um call-center. O cliente precisa do produto com certa urgncia. E informa que os requisitos podem mudar bruscamente e devem ser esquematizados perfeitamente, pois qualquer falha na modelagem do sistema causar prejuzo para a empresa. A empresa fabricante do software decide utilizar FDD com DDD. Mostraremos no prximo tpico como seria o passo a passo do projeto X ao aplicar esses mtodos geis.

4.2.1 FDD + DDD + Design Patterns na prtica

Desenvolver um modelo geral: Nessa primeira fase, os especialistas do sistema precisam aprender sobre o domnio do negcio. DDD pode ser aplicado cedo no projeto,

71

com os especialistas em software entrevistando os especialistas do domnio (gerentes, supervisores, atendentes e diretores de call-center) sobre as peculiaridades da rea. Entender questes estruturais, por exemplo, saber como so feitas as chamadas telefnicas, qual o principal objetivo da empresa, qual a hierarquia de comando existente e como acontece o controle de acesso dos agentes, vital para essa primeira fase do processo. DDD prope que, para haver um melhor entendimento entre as partes, os membros da equipe de software junto com os especialistas na rea de call-centers devem encontrar uma linguagem em comum. Porque linguagem orientada a objetos e jarges da rea de programao no familiar a especialistas na rea de telefonia. Da mesma forma que as expresses utilizadas no dia a dia dos especialistas do domnio no so conhecidas pelos especialistas em software. Essa linguagem proposta pelo DDD chamada "linguagem ubqua" e um meio termo entre o conhecimento entre as duas reas. Na verdade, a linguagem deve ser encontrada durante o entendimento do domnio e os termos combinados devem ser respeitados por ambas as equipes at o fim do projeto. Nessa fase ser criado um modelo geral, com o propsito de entender o domnio e retratar suas entidades mais importantes. FDD prega que devem ser divididas vrias equipes de desenvolvimento do projeto e cada uma fazer uma modelagem baseada no seu entendimento do domnio. O melhor modelo, com design mais completo e correto escolhido como modelo inicial ou base. DDD incentiva esta prtica, pois prega que no apenas os arquitetos devem participar na modelagem, mas todos da equipe de desenvolvimento devem estar envolvidos nesta atividade. Inclusive, o prprio cliente, no caso o especialista do domnio, deve validar os modelos gerados, mostrando falhas no entendimento da regra de negcio e as expondo para todas as equipes, como num ambiente de sala de aula. Ao concretizar o modelo inicial, a equipe de arquitetos deve escrever ou documentar notas explicativas sobre as entidades e elementos do modelo escolhido. Gerar uma lista de funcionalidades: Esta fase utilizar o conhecimento obtido na fase anterior para criar tarefas no projeto. Uma equipe selecionada para criar uma lista de funcionalidades baseadas no modelo. Assim, elaborada uma lista de funcionalidades do sistema decompondo as reas de domnio no modelo. Essas funcionalidades so pequenas tarefas que geram valor para o cliente. Ao seguir o formato <ao><resultado><objeto>, conceitos de DDD se sobressaem, como Servios (Services), Entidades (Entities) e 72

Objetos-valor. A ao pode ser representada por um elemento Servio no modelo. E um objeto pode ser representado por uma entidade, um objeto-valor ou at mesmo um elemento Aggregate no caso de composio de objetos. No projeto em questo, teramos por exemplo a funcionalidade "Validar senha do atendente" no contexto de login do sistema. Assim, o modelo teria um servio "Validar" e uma entidade (pois um atendente deve possuir um identificador nico) "Agente". importante que o cliente ou especialista do domnio esteja sempre pronto para dar feedbacks sobre o projeto. Pois apesar de DDD ser um mtodo gil para produzir modelos abstratos, feedbacks conferem qualidade ao produto final ao validar os modelos gerados. Planejar por funcionalidade: planejado o desenvolvimento das funcionalidades extradas do modelo inicial. So designados proprietrios de cdigo. No h muitos princpios do DDD explicitamente aplicveis nessa fase. Mas um deles seria a continuidade da linguagem ubqua durante essa fase. a linguagem ubqua que possibilitar os especialistas no domnio a entenderem se as funcionalidades descobertas pelos especialistas em software fazem sentido no contexto ou no. Modelar por funcionalidade: nessa fase que os programadores-chefe iro escolher funcionalidades para fazer seus diagramas de sequncia e sua modelagem completa. Essa modelagem diferente da modelagem realizada na primeira fase, visto que no to abrangente. Na verdade, essa fase tem por objetivo criar modelos para as funcionalidades obtidas do passo anterior. So idealizadas classes, atributos e mtodos. Model Driven Design utilizado diretamente nessa fase. De fato, as classes so criadas como Entidades, Objetos-valor ou Aggregates. Ainda so criados os repositrios, que servem como estrutura de coleo para a persistncia de objetos na memria. Ao final dessa fase, uma inspeo realizada e um refatoramento no modelo do sistema j possvel de ser feito atravs da mquina dos desenvolvedores. Assim, desenvolvedores podem encontrar desde j, inconsistncias do modelo com alguma parte tcnica do projeto. Essas inconsistncias devem voltar como feedback para os programadores-chefe e os especialistas no domnio. Caso haja alguma correo, a soluo repassada para os programadores para que possam terminar suas tarefas. Tambm importante que os desenvolvedores vejam o quanto antes onde ser necessrio inserir padres de projeto.

73

Construir por funcionalidade: Com o modelo preparado, no h mais o que fazer no modelo encontrado para o sistema. Essa fase diz respeito a implementao ou codificao das funcionalidades. Design Patterns prov boas solues para problemas recorrentes. Dessa forma, problemas no precisam ser pensados por muito tempo. Pois existe um Design Pattern correspondente aquele problema. Entretanto, os desenvolvedores podem decidir utilizar padres de projeto para uma certa peculiaridade da funcionalidade que seria transparente ao modelo. Ao final da implementao, os testes unitrios so escritos e aplicados, gerando mais feedbacks. 4.2.2 Vantagens da composio

Essa composio traz benefcios durante todo o processo de produo do software, desde a modelagem at a implementao do cdigo. Isso acontece pelo fato de DDD ser parte integrante de cada uma das fases do FDD. Como o objetivo desses dois mtodos fundamentalmente o mesmo, ou seja, prezar por uma estrutura slida e flexvel antes de comear a construir, a composio deles reafirma suas caractersticas. Por no possurem princpios conflitantes entre si, DDD e FDD apiam-se mutuamente durante todo o projeto. A linguagem ubqua uma tcnica bastante eficiente do DDD e pode ser til antes mesmo de a modelagem do sistema comear. Na fase de coleta de requisitos e estudo do domnio, a construo de uma linguagem no-ambgua que esclarea termos obscuros entre as partes essencial para a compreenso do desejo do cliente. A linguagem construda durante a fase inicial do projeto, de modo que durante as iteraes, a maioria dos termos j esto estabelecidos como padro da linguagem. As pessoas envolvidas falam esse novo idioma sempre que estiverem se comunicando sobre o projeto. A linguagem utilizada tanto na comunicao falada, quanto na comunicao escrita, por meio de diagramas e modelos preliminares. A equipe de desenvolvimento deve expressar os conceitos dessa linguagem durante todo o projeto, at a codificao do sistema. Dessa forma, os especialistas no domnio sempre iro entender o que est acontecendo no desenvolvimento do software, podendo observar falhas no desenho do modelo e esclarecendo dvidas dos especialistas do sistema relativas ao domnio em qualquer fase do projeto.

74

Existe um alto nvel de acoplamento entre os elementos do Model Driven Design e Design Patterns. Elementos do DDD como Aggregates, Servios e Repositrios possuem um padro equivalente em Design Patterns. Portanto, padres de projeto podem ser utilizados para expressar ou traduzir os elementos do modelo do domnio em cdigo do sistema. Por exemplo, um Aggregate pode ser representado por um padro Composite. Um Servio pode ser representado por um padro Command ou Chain of Responsibility. Ainda um elemento Factory pode ser expresso atravs de um objeto Factory. Ou seja, Design Patterns so teis para expressar elementos do modelo do domnio por meio de objetos do sistema. No entanto, padres de projeto s aparecem nas duas ltimas fases do FDD, onde a implementao das classes e mtodos do sistema passam a existir. A arquitetura em camadas, uma caracterstica de boas modelagens orientadas a objetos, incentivada tanto por FDD quanto por DDD. Quando FDD utiliza a diviso em camadas sugerida pelo DDD, a complexidade do sistema diminui e o aprendizado dos desenvolvedores aumenta. Alm disso, a manuteno do software, uma vez que este estiver pronto, ser pouco custosa. Design Patterns possui alguns padres estruturais que funcionam melhor em arquiteturas em camadas. Da a vantagem de unir os 3 mtodos com o mesmo objetivo. DDD uma abordagem na forma de encarar a modelagem do sistema na qual a preocupao entender o domnio acima de qualquer coisa. Com o aprendizado de toda equipe de desenvolvimento sobre o domnio de negcio completo, o resto do projeto ser simplificado. uma forma de tornar gil a forma de produzir um modelo. De fato, FDD uma metodologia gil por natureza que prioriza a modelagem do sistema, enquanto DDD uma abordagem que, quando levada em considerao pelos membros do projeto, tende a aumentar a qualidade do modelo final, fazendo isso de forma simples e prtica. Juntas, a metodologia e a abordagem reforam uma a outra.

75

5. CONCLUSES E TRABALHOS FUTUROS

Neste trabalho, abordamos algumas das metodologias de gerenciamento de software mais usadas na indstria de software: Scrum, Extreme Programming e Feature Driven Design. Cada uma dessas metodologias possui uma maior nfase em um determinado aspecto. Por exemplo, Scrum possui um foco totalmente centrado na rea gerencial. J Extreme Programming contm uma srie de tcnicas para agilizar o desenvolvimento propriamente dito. Enquanto Feature Driven Design enfatiza bastante a modelagem do sistema, ou seja, se um projeto possui uma modelagem de alta qualidade, todas as outras fases produziro, por conseqncia, alta qualidade. Foram analisadas vantagens e desvantagens de se utilizar cada uma dessas metodologias individualmente e foi apresentada uma anlise comparativa das metodologias em questo. Apresentamos tambm algumas tcnicas de engenharia e abordagens que so, com certa freqncia, utilizadas em muitos projetos de desenvolvimento de software. Foi apresentada a tcnica conhecida como Test Driven Design, onde primeiramente escrito um teste unitrio para cada nova funcionalidade do sistema e s ento escrito o pedao de cdigo correspondente. Foi explicada a abordagem do Domain Driven Design sobre a modelagem de um sistema, apresentando seus conceitos sobre linguagem ubqua e elementos padres de modelo de sistemas. Finalmente, foram abordadas tcnicas mais utilizadas na codificao do software propriamente dito, como o uso de Design Patterns e sistemas de controle de verso. Como parte principal deste trabalho de graduao, foram combinadas algumas metodologias e tcnicas geis. Esses mtodos foram escolhidos de acordo com uma anlise realizada pelo autor. Primeiramente, foi combinado Scrum com XP e TDD, ou seja, duas metodologias geis com uma tcnica de engenharia gil. A anlise mostrou-se positiva, pois as metodologias no possuem princpios conflitantes. Pelo contrrio, foi aproveitado o melhor de cada uma delas. Enquanto Scrum guia a parte gerencial do projeto, criando sprints com planejamento, desenvolvimento e retrospectiva, as tcnicas de desenvolvimento de Extreme Programming so utilizadas dentro dessas sprints, como que preenchendo as 76

lacunas deixadas por Scrum. Ao mesmo tempo, a tcnica voltada para a rea de testes de software, TDD, utilizada como se fosse uma das tcnicas de XP. Depois, analisamos a combinao entre FDD, DDD e Design Patterns. Neste caso, temos uma metodologia, uma abordagem e uma tcnica de programao. O interessante nessa composio que tanto a metodologia (FDD), quanto a abordagem (DDD) e a tcnica (Design Patterns) so focadas na modelagem do sistema de software. Por esta razo, essa combinao tambm mostrou-se positiva, com FDD agregando pontos fortes de DDD nas suas iteraes e, sempre que possvel, expressando isso no cdigo por meio de Design Patterns. 4.1 Trabalhos futuros

Na finalizao deste trabalho, podem-se identificar alguns encaminhamentos futuros no sentido de elaborar uma nova metodologia. Essa nova metodologia criada seria o aperfeioamento de uma das duas composies analisadas neste trabalho. No final, seria produzida uma nova metodologia gil X com duas possibilidades: 1. Herdar caractersticas gerenciais de Scrum, prticas de XP e uma tendncia a testar todo e qualquer pedao de cdigo antes do desenvolvimento, de TDD; 2. Possuir nfase em modelagem e design de sistemas. Caracterstica herdada de FDD e de DDD. Design Patterns seria considerada uma boa prtica da nova metodologia. De qualquer forma, o intuito nas duas possibilidades o mesmo: Combinar boas prticas das metodologias geis com as tcnicas geis de desenvolvimento, baseando-se sempre nos princpios do Manifesto gil, para que no haja conflitos de interesses entre os mtodos. Mas para que, por outro lado, a composio funcione como um complemento das boas caractersticas existentes entre os mtodos.

77

REFERNCIAS BIBLIOGRFICAS
[1] Agile Alliance. Acesso em: 01 de Maro de 2009. Disponvel em: http://www.agilealliance.org/. [2] COHEN, D., LINDVALL, M., & COSTA, P. An introduction to agile methods. In Advances in Computers (pp. 1-66). New York: Elsevier Science, 2004. [3] PRESSMAN, R. Software Engineering (A practitioner's approach). 5th edition, 2000. Mc Graw-Hill Education. [4] AMBLER, S. (April 2008). Scaling Scrum - Meeting Real World Development Needs. Acessado em: 07 de Abril de 2009. Disponvel em: http://www.ddj.com/architect/207100381. [5] Agile Manifesto: Acesso em: 07 de Abril de 2009. Disponvel em: http://agilemanifesto.org/ . [6] Agile Manifesto History: Acesso em: 07 de Abril de 2009. Disponvel em: http://agilemanifesto.org/history. [7] SCHWABER, K. SCRUM Development Process. In Advanced Development Methods. [8] NEWKIRK, J.,VORONTSOV, A. Test-Driven Development in Microsoft .NET, Microsoft Press, 2004. [9] BECK, K. Test-Driven Development by Example. Addison Wesley, 2003. [10] ERDOGMUS, H., MORISIO, T. "On the Effectiveness of Test-first Approach to Programming". Proceedings of the IEEE Transactions on Software Engineering, 31(1). Janeiro de 2005. Acesso em: 08 de Maio de 2009. Disponvel em: http://iit-iti.nrccnrc.gc.ca/publications/nrc-47445_e.html.

78

[11] FOWLER, M. Refactoring - Improving the design of existing code. Boston: Addison Wesley Longman, 1999. [12] UML.ORG: Acesso em: 06 de Maio de 2009. Disponvel em: http://www.uml.org.cn/softwareprocess/200904012.asp. [13] Mountain Goat Software: Acesso em: 08 de Maio de 2009. Disponvel em: www.mountaingoatsoftware.com/. [14] "Extreme Programming" (lecture paper), USFCA.edu. Acesso em: 26 de Abril de 2009. Disponvel em: http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html. [15] STEPHENS, M. & ROSENBERG, D. Extreme Programming Refactored. Berkeley: APress, 2003. [16] Wikipedia: Acesso em 02 de Maio de 2009. Disponvel em: http://en.wikipedia.org/wiki/Extreme_Programming. [17] Agile Alliance: Acesso em: 03 de Maio de 2009. Disponvel em: http://www.agilealliance.org/system/article/file/1376/file.pdf. [18] SCHWABER, K. & BEEDLE, M. Agile Software Development with Scrum. Prentice Hall, 2001. [19] LASCANO, J. Extreme Programming embedded inside Scrum. Acesso em: 25 de Maio de 2009. Disponvel em: http://www.sstc-online.org/Speaker/Papers/2276.pdf. [20] WELLS, D. Extreme Programming: A gentle introduction, CRC Cards. Acesso em: 25 de Maio de 2009. Disponvel em: http://www.extremeprogramming.org/rules/crccards.html. [21] Control Chaos. Scrum Its About Common Sense. XP @ Scrum. Acesso em: 25 de Maio de 2009. Disponvel em: http://www.controlchaos.com/about/xp.php.

79

[22] IT-Agile Magazine Entrevista com Jeff DeLuca. Acesso em: 26 de Maio de 2009. Disponvel em: http://www.it-agile.com/56.html. [23] HARTMANN, D. Feature Driven Development: Still relevant? Acesso em: 26 de Maio de 2009. Disponvel em: http://www.infoq.com/news/Another_look_at_FDD. [24] AMBLER, S. Feature Driven Development and Agile Modeling. Acesso em: 27 de Maio de 2009. Disponvel em: http://www.agilemodeling.com/essays/fdd.htm. [25] AVRAM, A., MARINESCU, F. Domain-Driven Design Quickly. InfoQ Enterprise Software Development Series. 2006 C4Media Inc. Acesso em: 03 de Maro de 2009. Disponvel em: http://www.infoq.com/books/domain-driven-design-quickly. [26] GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994. [27] FREEMAN, E. et al. Head First Design Patterns. O'Reilly Media, 2004. [28] MOLINARI, L. Gerncia de Configurao - Tcnicas e Prticas no Desenvolvimento do Software. Florianpolis: Visual Books, 2007. [29] CRISTIANO, C. CVS: Controle de Verses e Desenvolvimento Colaborativo de Software. Novatec, 2004.

80

Orientador ____________________________________________ Prof. Dr. Hermano Perrelli de Moura

Aluno _____________________________________________ Tiago de Farias Silva

81