Metodologia Ágil:
Feature Driven Development
António Barbosa1, Bruno Azevedo2, Bruno Pereira3,
Pedro Campos4, Pedro Santos5 1Estudante da LEIC – ei03023@fe.up.pt 2Estudante da LEIC – ei01058@fe.up.pt 3Estudante da LEIC – ei03026@fe.up.pt 4 Estudante da LEIC – ei03082@fe.up.pt 5Estudante da LEIC – ei03005@fe.up.pt Resumo.
Feature Driven Development(FDD) é uma metodologia ágil de desenvolvimento de software. Esta metodologia permite desenvolver um sistema de forma rápida e permite facilmente introduzir novas features (funcionalidades) a este. Uma nova feature demora entre duas horas a duas semanas a ser concluída. O facto de no FDD usar-se processos simples proporciona uma rápida exposição do projecto a novos elementos que venham a fazer parte da equipa, assim como torna o trabalho menos monótono, uma vez que se esta sempre a iniciar/acabar um processo.
1.Metodologias Ágeis
1.1. O aparecimento das metodologias ágeis
As metodologias ágeis surgiram em resposta ao problema dos atrasos do desenvolvimentos software, e aos cancelamentos por obsolescência, ou seja um programa que demore muito tempo a ser desenvolvido, tem tendência a ficar desactualizado se seguir os objectivos propostos no seu planeamento.
Houve outros avanços que se esperavam resolver os problemas anteriores, como os métodos estruturados em 1980 ou as metodologias orientadas a objectos, mas os problemas mantinham-se.
Também se achou que a solução passaria pelo melhorar o processamento do software, mas só a introdução das metodologias de desenvolvimento ágil trouxeram solução aos problemas, visto a chave era a adaptabilidade e não apenas o aperfeiçoamento dos métodos existentes.
Assim, esta metodologia veio a reduzir a taxa de abandono dos projectos a meio e proporcionou um rápido desenvolvimento e um cumprir sistemático dos objectivos.
1.2. Introdução às metodologias ágeis.
A definição de metodologias ágeis de desenvolvimento de software foi criada durante os anos 90 como reacção contra os métodos de desenvolvimento "pesados", tipificados pelo modelo em cascata. Estes métodos eram então vistos como burocráticos e lentos e criavam uma contradição em relação à ideia que o trabalho dos engenheiros de software é eficaz.
Inicialmente, as metodologias ágeis eram denominadas como métodos de desenvolvimento "leves", mas em 2001 alguns elementos da comunidade encontraram-se na estância de sky de Snowbird e criaram o "The Agile Manifesto" no qual adoptaram o nome Métodologias Ágeis. Este Manifesto foi criado com o intuito de fazer a união entre as diferentes metodologias ágeis, e é apresentado como sendo a definição canónica do desenvolvimento ágil. O Manifesto é apresentado a seguir na sua forma original:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, the above authors
this declaration may be freely copied in any form, but only in its entirety through this notice.
1.3.Comparação com outros tipos de metodologias
É comum afirmar-se que os métodos ágeis de desenvolvimento de software são o oposto de metodologias disciplinadas e planeadas; no entanto tal afirmação é uma má interpretação da adaptabilidade pedida. Uma distinção mais precisa pode ser feita através da disposição dos métodos seguindo uma linha desde "Adaptáveis" a "Preditivas"
<--Ágil--> <--Iterativa--> <--Cascata--> <---|---|---|---> Adaptável Preditiva
Métodos adaptáveis focam-se na adaptação a constantes mudanças. Uma equipa sabe o trabalho que lhe cabe na fase actual do projecto mas desconhece o passo seguinte, que vai sendo decidido durante o decorrer de cada fase.
Métodos preditivos fazem o planeamento detalhado do futuro. Uma equipa preditiva define exactamente que tarefas irão ser desempenhadas e que características irão ser desenvolvidas durante toda a duração do processo de desenvolvimento e a sequência de fases a passar. Uma equipa preditiva tem dificuldades em lidar com mudanças, pois normalmente o plano foi optimizado tendo em conta o destino original, sendo que qualquer alteração pode fazer com que determinado trabalho terá que ser feito de maneira completamente distinta. As equipas preditivas geralmente instituem uma comissão de controlo de mudanças, constituída por elementos com responsabilidades altas para o projecto, tais como clientes, gestores ou líderes de equipas, que asseguram que apenas as mudanças mais importantes serão feitas.
Desenvolvimento iterativo
Os métodos ágeis partilham o objectivo dos métodos iterativos de criar partes do software que possam ser lançadas em curtos períodos tempo. Diferem na duração dos períodos de tempo, sendo que nos métodos ágeis o tempo é medido em semanas e nos métodos iterativos é medido em meses. A maioria dos métodos ágeis diferem também pois têm em conta estritamente o tempo, ao invés de um objectivo planeado.
Modelo em cascata
O modelo em cascata é o mais preditivo de todos, consiste em seguir a sequência rígida e planeada de recolher requisitos, analisar, desenhar, codificar e testar. O progresso é medido no cumprimento dos requisitos, planos de testes e revisões de código. O modelo em cascata pode resultar num esforço substancial de integração no fim do ciclo, que se estende por um período de tempo que pode ir de vários meses a vários anos. O tamanho e a dificuldade deste esforço é uma das causas do falhanço do projecto em cascata. Contrariamente, os métodos ágeis produzem aplicações completamente funcionais (mas a uma pequena percentagem do total) a cada semana. A ideia é obter uma aplicação inacabada mas funcional antes da final, que vai sendo continuamente desenvolvida.
Algumas equipas ágeis usam uma das ideias do modelo em cascata: o repetir de um ciclo em cada iteração.
Análise do risco de utilização de Métodos Ágeis e Preditivos
Para diminuir o risco na utilização de métodos ágeis e preditivos pode-se verificar onde os diferentes métodos se enquadram melhor:
Métodos ágeis
- Pouca crítica à implementação
- Equipa de desenvolvimento constituída por elementos experientes - Grandes mudanças nos requisitos
- Equipa de desenvolvimento constituída por poucos elementos - Cultura que prospera na falta de organização.
Métodos preditivos
- Muita crítica à implementação
- Equipa de desenvolvimento constituída por elementos inexperientes - Poucas mudanças nos requisitos
- Equipa de desenvolvimento constituída por muitos elementos - Cultura que exige ordem e organização.
Ao analisar o projecto tendo em conta estes enquadramentos pode-se avaliar o risco de utilização de métodos ágeis ou preditivos.
2.Feature Driven Development
2.1. Agentes/Actores desta metodologia.
No FDD existem vários papéis que os membros da equipa podem assumir. O mesmo papel pode ser assumido por vários membros e cada membro pode assumir vários papais simultaneamente.
Existem três tipos de papéis: papéis principais, papéis secundários e papéis adicionais.
Os papéis principais são: Gestor de Projecto, Chefe de Design, Gestor de Desenvolvimento, Programador Chefe, Dono de Classe, Especialista da Área.
Gestor do Projecto
O gestor do projecto é quem trata das questões financeiras e administrativas do projecto. É ele que tem a última palavra sobre os objectivos, o pessoal e a calendarização do projecto. Cabe-lhe também assegurar as condições de trabalho óptimas, para aumentar o rendimento e evitar as distracções.
Chefe de Design
O chefe de design é responsável por toda a arquitectura do projecto e dá as sessões de design, onde expõe as suas decisões às equipas.
Gestor de Desenvolvimento
O gestor de desenvolvimento lidera as actividades de desenvolvimento do código do dia-a-dia. É responsável por resolver os problemas de recursos ou conflitos entre a equipa que venham surgindo. É um papel bastante ligado aos de gestor do projecto e pode ser executado pelo mesmo membro.
Programador Chefe
O programador chefe é o responsável por uma equipa pequena e pela divisão e atribuição de trabalho entre os membros dela. Deve ser um programador experiente pois cabe-lhe a escolha das features a implementar em cada iteração e as respectivas classes e métodos necessários. Para este efeito deve colaborar com o chefe de design. Vai ser ele também que faz o relatório da actividade da equipa semanalmente e trata dos problemas técnicos e de recursos com os outros programadores chefe.
Dono de Classe
O dono de classe é um membro de uma equipa sob o comando de um programador chefe e está responsável pela arquitectura, implementação, teste e documentação de uma determinada classe. Em cada iteração fará parte das equipas cujas features envolvam a sua classe.
Especialista da Área
O especialista da área é alguém que conhece o assunto sobre o qual a aplicação actua. Está envolvido na decisão do preço do programa e é ele que assegura que o sistema seja competente dentro da área, passando a quem desenvolve o programa os conhecimentos necessários. O especialista da área pode ser um cliente, um analista de negócio, um patrocinador ou um utilizador.
Os papéis secundários são: Gestor de Actividade, Guru da Linguagem, Engenheiro de Builds e Administrador de Sistema.
Gestor de Actividade
O gestor de actividade recebe os relatórios de actividade os vários programadores chefe e vai mantendo o gestor do projecto informado.
Guru da Linguagem
O guru da linguagem é um papel importante quando se trabalho com linguagens ou tecnologias novas. Ele é responsável por dominá-las.
Engenheiro de Builds
O engenheiro de builds é o responsável por criar e manter o processo de build para as várias versões incluindo a documentação respectiva.
Administrador do Sistema
O administrador do sistema configura, gere e resolve problemas nos servidores e redes usadas.
Os papéis adicionais são: Tester, Suporte, Documentador Tester
O Tester deve experimentar todos os casos de utilização exaustivamente e verificar se o sistema é sólido, resistente a erros e se preenche os requisitos do cliente.
Suporte
O trabalho de suporte consiste em converter a informação para o formato necessário a um novo sistema e a novas releases do programa.
Documentador
O documentador cria os manuais técnicos e de utilização.
2.2Descrição dos processos
Esta metodologia FDD consiste em cinco processos sequenciais. O uso de processos tem várias vantagens:
- O facto de nos FDD’s usarem processos simples e bem definidos faz com que o mover novas utilidades (features) para projectos grandes seja fácil. Pois é como fazer algo simples várias vezes. No desenvolvimento de processos complexos, deve-se dividir em N processos simples, o permite que o progresso do projecto seja mais rápido.
- A integração de novos elementos nas equipas é rápida, pois o facto de os processos serem simples faz com que seja fácil a compreensão destes por parte dos novos membros.
- O facto de os processos serem simples, faz com que a equipa esteja sempre concentrada no trabalho uma vez que estão constantemente a acabar/iniciar um novo processo. Não causa uma monotonia do trabalho.
Como tinha sido referido acima esta metodologia consiste em cinco processos sequenciais sendo estes:
1. Develop an Overall Model (Trata-se de utilizar os requisitos e funcionalidades pedidas pelo cliente e fazer o estudo destas de forma a fazer a estrutura do sistema. Baseia-se no desenho do sistema);
2. Build by Features list (Constrói uma lista de features detalhada e ordenada por ordem hierárquica);
3. Plan By Feature (Trata-se de planear como devem ser desenvolvidas as features);
4. Design by Feature (Analisa uma feature em particular e estuda-a de forma a criar-se um detalhado diagrama sequencial, que será os passos a seguir para construir uma feature);
5. Build By Feature (Faz todas as alterações necessárias para ser possível construir uma feature).
Em baixo esta uma descrição detalhada destes processos.
2.2.1.Develop an Overall Model
Este processo inicia-se quando o cliente está pronto para dar início ao projecto. Este tem de alguma forma uma lista de requerimentos, que poderão estar ou não anotados. O cliente indica quais os requisitos que quer ver compridos pelo sistema. Cabe às equipas de desenvolvimento analisar o sistema anterior e verificar se todos os requisitos foram especificados pelo cliente, sugerir novos requisitos e colocar todas as questões que possam ainda não ter sido respondidas, ou que tenham sido esquecidas.
O cliente chega com os seus requisitos e apresenta-os ao desenvolvedores. Estes em conjunto com os especialistas da área e sobre a liderança de um modelador de componentes e/ou de objectos experiente (chefe de design), trabalham em conjunto neste processo.
Os especialistas da área apresentam um guia inicial e preçário do sistema e do seu contexto. Que em conjunto com os desenvolvedores criam a estrutura inicial do sistema, que deve ser seguido desde o início.
Depois de desenvolvido este esqueleto os especialistas da área voltam a fazer o guia inicial, sendo desta vez mais detalhado.
Entretanto sempre que os membros deste processo trabalham em conjunto em pequenas equipas, ou seja, quando trabalham em áreas mais especificas a determinado grupo, e que a participação de outros membros seria desnecessária, os resultados desse trabalho são adicionados ao modelo comum, que sofre os respectivos ajustes para se manter sempre viável ao longo de todo o processo.
Neste processo é necessário de compreender perfeitamente o que o cliente deseja, e de o explicar a todo o grupo de trabalho. Para que todos saibam o que tenham de o fazer e como o devem fazer. Este plano é descrito mais detalhadamente nos processos seguintes.
Para melhor compreender o sistema e para mais facilmente o explicar ao grupo de trabalho, constrói-se um relatório de requisitos, assim como um diagrama de classes, preferencialmente ordenado por ordem descendente de importância, classes, ligações, métodos e os atributos.
As classes e as ligações são o conteúdo da estrutura do sistema. Os métodos expressam as funcionalidades e são o material para construir a lista de features a desenvolver.
Também são tomadas notas acerca de diferentes modelos que poderiam ser tomados como alternativas.
2.2.2.Build a Feature List
A equipa de desenvolvimento identifica todas as features, e agrupa-as por ordem hierárquica. Nesta ordem é tomada em conta a prioridade de cada feature, sendo
prioritária uma feature que o cliente pediu ou que se ache que lhe agradará ver feita e uma feature de que outras dependam. As features definidas com baixa prioridade são muitas vezes features extra, mas que certamente iriam valorizar o projecto. Estas poderão ser desenvolvidas no futuro.
Ainda neste processo também se dividem pequenas equipas especialidades em cada uma das áreas de cada conjunto de features. Os especialistas da área poderão participar em algumas das sessões referentes a este processo. A divisão das features é feita com base em certos critérios: divide-se as features por áreas em que estas se enquadrem, e de acordo com as classes envolvidas.
Se estes conjuntos de features demorarem mais de duas semanas a serem desenvolvidos este conjunto de features ou uma feature individual, são divididos em pequenos passos. Isto para de duas em duas semanas se poder analisar o projecto e ver os progressos.
Chama-se de feature (funcionalidade) uma acção com o seguinte formato: <action> the <result><by|for|of|to> a(n)<objecto>
Conjunto de features: - <action><-ing>a(n)<object> Um maior conjunto de features: <object> management
Nota: Quando um objecto é uma pessoa, lugar, ou coisa, inclui-se papeis, datas, ou intervalos de tempo, ou catalogo entrada/descrição.
Em resumo:
Neste processo, entra a provisória lista de features desenvolvidas no processo anterior e sai uma detalhada lista de features agrupada em maiores conjuntos de features e conjuntos de features. Lista esta que terá de ser revista e aprovada pelo desenvolvedor assim como pelo arquitecto chefe.
2.2.3.Plan by feature
Usando a lista detalhada e ordenada por prioridade das features, criada no processo anterior, o chefe do projecto, o chefe de design e o chefe dos programadores estabelecem a estrutura para o método “Desenho por Funcionalidade, Construção por Funcionalidade”/Design by Feature, Build by Feature.
Isto é, este grupo de planeamento, determinam a sequência, e o conjunto inicial de datas para dar como terminada cada conjunto de features e do mais importante conjunto de features.
Este planeamento é repartido, atribuindo de acordo com o desenvolvimento sequencial e o peso de cada feature como guia e associa as classes do sistema aos responsáveis pelas classes.
A cada chefe de programação é fornecida a lista de features a desenvolver. Como temos vindo a observar esta abordagem à construção de sistemas é um planeamento top-down, em que os desenvolvedores têm a oportunidade de aceder aos planos.
Há que ter em conta que cada feature a desenvolver não devera demorar mais de duas semanas. E que nesta atribuição de trabalhos certos desenvolvedores poderão estar de desacordo com este método, pois certamente prefeririam ter uma data para entregar todo o trabalho, mas esta é uma metodologia ágil e não se baseia nesse
método. À que portanto convence-los a apresentar os resultados assim como eles estão planeados.
Em contraste, outros desenvolvedores poderão aceitar muito bem isto, pois estão desejosos de apresentar trabalho, mas não avaliam de uma forma cuidada o trabalho que terão pela frente. Ou seja poderão atrasar-se com o desenvolvimento de determinada feature. À que ter em atenção de no processo anterior ter sido dividido todas as features que darão mais complexas em features mais simples. Isto para de duas em duas semanas ser possível ter sempre conteúdo novo, de forma a mostrar o nosso trabalho.
No final deste processo deveremos ter um plano já revisto e aprovado pelo desenvolvedor chefe e pelo chefe de design. Deveremos ter também já uma previsão de quando o projecto estará terminado. Assim como uma data em que os conjuntos de features deverão estar completas. O mesmo para cada classe.
Existe um truque que se pensa que acelera o desenvolvimento das features. Este truque consiste em criar um grupo denominado “Future Feature Boar”(FFB). Este truque faz com que os desenvolvedores sejam como que os “bons da fita”, enquanto que os FFB são os maus da fita.
O truque consiste em incentivar os bons da fita, de maneira a que a sua motivação esteja alta e desta maneira desenvolvam o seu trabalho de uma maneira mais rápida.
2.2.4.Design by Feature (DBF)
Este processo ira ser repetido tantas vezes quantas o número de features a desenvolver. Isto porque é necessário fazer o desenho da estrutura para cada feature.
Iremos analisar este processo com algum cuidado, isto porque apesar de o que ele faz ser fácil de entender, este tem de analisar vários documentos construídos noutros processos, assim como trocar informação com outros AGENTES.
Comecemos então a analisar este processo, o programador chefe começa por identificar as classes que estão envolvidas nestas features. E contacta os respectivos responsáveis dessas classes, estes escrevem/actualizam a classe e os protótipos dos métodos que esta contém, actualizando o diagrama sequencial. Estes responsáveis incluem tipo de parâmetros, tipo de valores retornados, excepções e mensagens enviadas.
Dependendo da complexidade da feature o programador chefe poderá consultar os especialistas da área para que estes lhe dêem uma visão acerca da área de domínio que esta feature engloba, esta informação será incluída na construção do diagrama, mas não fará necessariamente parte da implementação. A equipa de programadores poderá também consultar documentos da lista de features ou de outro documento, de forma a extrair informação detalhada acerca desta feature.
Depois de consultar todos os documentos que se ache necessário para a compreensão da feature, o programador consulta o diagrama sequencial construído num processo anterior, e com base em toda a informação recolhida este constrói um diagrama de sequência detalhado e formal para esta feature. Este diagrama é adicionado ao projecto modelo.
A equipa de programadores toma nota de todas as alternativas, decisões e notas que achem relevantes.
Antes de dar por terminado este processo é necessário garantir que o programador chefe assim como arquitecto chefe revejam e aprovem:
- O diagrama sequencial e o de classes actualizado; - As classes e os métodos actualizados;
- As notas de consideração da equipa de programadores;
- Os documentos de referências de features, caso haja necessidade.
Caso todos estes documentos sejam aprovados passamos ao último processo Build By Feature.
2.2.5.Build by Feature (BBF)
Tal como no processo anterior, este processo ira ser repetido para cada feature, pois todas as features terão de ser construídas.
Este processo começa por estudar a informação proveniente do processo anterior e seguidamente começa a construção da feature. Nomeadamente começam os responsáveis pelas classes associadas a esta feature a construir os métodos que esta feature ira necessitar. Estes responsáveis irão também estender os testes de uso desta classe assim como os testes unitários da mesma.
A equipa de desenvolvimento desta feature inspecciona o código, antes ou depois de estruturados os testes unitários.
Quando o código é implementado com sucesso e inspeccionado, o responsável da classe verifica a classe assim como as configurações de manutenção do sistema. Quando todas as classes referentes a esta feature forem verificadas, o programador chefe indica que o código para desenvolver esta feature esta disponivel. Esta alteração é registada na lista de features.
Para dar este processo como terminado o programador chefe devera rever e aprovar:
- A implementação, inspecção e teste dos métodos; - Os testes unitários para cada método;
- A verificação das classes por parte dos seus responsáveis; - A promoção das features;
- A actualização da lista de features realizada por si próprio.
2.3.Ferramentas de aplicações
A utilização do FDD num projecto, torna recomendável o uso de uma ferramenta que permita organizar todas as implementações que se deseja criar sendo possível a inclusão e discriminação de todas as componentes necessárias para as novas funcionalidades.
Uma ferramenta deste tipo deve ter alguns requisitos necessários para facilitar a utilização de FDD.
Como já foi referido, é necessário que este apresente uma discriminação de todas as “features” a ser implementadas como também das suas respectivas componentes, encontrando-se estas devidamente documentadas, no sentido de facilitar a equipa do projecto, como também por equipas futuras, após estas “features” se encontrem concluídas.
Como tal, proporciona uma visão da arquitectura geral do programa, o que permite a tomada de consciência da estrutura do futuro programa, permitindo a não ocorrência da repetição de “features” semelhantes, ou mesmo a criação de componentes em duplicado. A visão da arquitectura do programa também permite que as novas implementações se possam inserir em “packages” já existentes, ou mesmo em novos “packages”.
Estas ferramentas também devem incorporar a indicação do tempo necessário para a sua implementação, como também da equipa ou as pessoas responsáveis pela sua implementação.
Esta visão geral, permite que cada grupo possa opinar sobre a implementação das novas “features” sugerindo outras soluções, ou mesmo o refinamento das mesmas. Nesta fase, torna-se possível a apresentação ao cliente do futuro programa que permita concordar, ou discordar da sua implementação, como também do seu tempo necessário e obviamente dos custos a si associados.
A utilização destas ferramentas permite maximizar as vantagens do FDD, essencialmente, no sentido de evitar custos extra, como também de tempo gasto em criação de componentes desnecessárias.
Este tipo de ferramentas é normalmente utilizado nas primeiras três fases da utilização do FDD, permitindo a sua planificação.
Outras funcionalidades que se podem incluir neste tipo de ferramentas é a descrição de todos os testes necessários para testar cada “feature”, como também a sua duração e o seu resultado. Isto permite, que quando se interligar as implementações, se possa obter os mesmos resultados que se obtinham quando as “features” se encontravam “desligadas” entre si. A implementação de um sistema de prioridades, que permite maximizar o tempo num projecto, deixando para trás as implementações menos importantes.
Outra funcionalidade, possível é um gráfico de decorrência de tempo, entre a percentagem de trabalho previsto com a percentagem de trabalho realizado, permitindo a verificação do trabalho, se encontrar dentro dos prazos previstos, ou se por outro lado é necessário a reverificação do tempo necessário para o desenvolvimento da nova implementação.
Uma funcionalidade pouco usual, mas também útil, é a possibilidade de, a dado momento, ser possível obter o número de “features” já criadas, permitindo a obtenção de indicadores de performance no sentido de avaliar os grupos ou as pessoas, da equipa do projecto, permitindo a sua futura reorganização para futuros projectos, maximizando os recursos humanos.
Este tipo de ferramentas apresenta um senão. A sua máxima utilização, na planificação de novos projectos, torna-se eficaz, quando todas as implementações, desde o início do projecto, se encontram descritas, não fazendo parte do actual desenvolvimento.
O nome de algumas ferramentas que podem ser utilizadas é o FDD Manager, MagicDraw, OptimalJ, Poseidon, Rose, Simply Objects, Together, Enterprise
Architect, entre outras. Algumas destas ferramentas são bastantes simples, outras mais complicadas, sendo também open source, ou mesmo de utilização paga.
2.4.Comparação entre FDD e XP
Após um breve estudo das metodologias ágeis mais conhecidas, verificamos que a que se assemelhava a FDD era eXtreme Programming (XP), sendo esta a mais interessante de comparar. Vamos então apresentar as semelhanças entre FDD e XP.
Tanto FDD como XP, foram desenhadas de modo a que as equipas possam mostrar resultados mais rapidamente sem comprometer a qualidade. São processos altamente iterativos e orientados a resultados. São ainda metodologias que acabam com a separação entre os analistas, os desenhadores e implementadores. Estes novos processos em conjunto com novas ferramentas, vão permitir que a analise, concepção, código, teste e desenvolvimento sejam feitos em simultâneo. Quais são então as diferenças entre FDD e XP?
Tamanho das Equipas
O XP foi desenhado para projectos com equipas de dois a dez programadores. FDD foi inicialmente usado com equipas de 16 a 20 colaboradores com diferentes habilitações, ambientes culturais e experiência. A FDD foi desenhada para ser aplicável a equipas bastante maiores, sendo esse tamanho limitado pelo número de Programadores Chefe existentes.
Modelo
Em FDD, quando os developers tomam conhecimento dos requisitos, começam a formar uma imagem mental do sistema, assumindo e estimando partindo dessa base. Desenvolvendo um objecto modelo domínio global, força essas assumpções a serem expostas, de modo a que os erros sejam corrigidos e uma melhor compreensão comum seja formada
XP usa a analogia de conduzir um carro. Conduzir requer uma continuidade de pequenos ajustes de percurso. Não se pode simplesmente orientar o carro na direcção correcta e carregar no acelerador. Um objecto modelo de domínio é o mapa que nos guia no percurso. Pode prevenir-nos de andarmos em círculos. O objecto modelo domínio dá-nos uma forma sobre a qual se vão adicionar funções, funcionalidade por funcionalidade.
Código colectivo, ou classe colectiva.
XP promove que o código seja colectivo. Cada developer pode adicionar ou alterar qualquer parte do código à medida que ai sendo necessário. Mas geralmente este colectivismo degenera num código sem proprietários. Para projectos pequenos resulta bastantes vezes, mas para projectos de maior dimensão raramente funciona. XP garante 3 benefícios derivados do colectivismo do código.
1. Não é necessário esperar por alguém para fazer a alteração necessária ao código.
2. Código demasiado complexo é eliminado, pois se alguém que o encontre, vai tentar simplifica-lo. Posto isto, os programadores deixam de criar código cuja complexidade não consigam justificar.
3. Código colectivo espalha o conhecimento do sistema por toda a equipa, reduzindo o risco caso um membro critico da equipa saia.
Em FDD, também se resolveu estes problemas, enquanto se manteve as vantagens do código individual.
1. Por definição, todos os donos de classes que necessitam de updates para o desenvolvimento de uma determinada feature, são membros da equipa de features. Por outras palavras, a equipa de features controla todo o código que necessita ser mudado para uma determinada feature, o que minimiza o tempo de espera para que alguém altere esse código.
2. Em FDD todo o desenho de baixo nível é feito dentro das equipas de features. O problema do desenvolvimento por surpresa, quando um developer entrega código do que foi acordado, é detectado nas inspecção de código pela equipa de features. Código demasiado complexo é também detectado da mesma maneira, antes de entrar no sistema.
3. Apesar dos donos de classes trabalharem apenas nas classes que lhes pertencem, donos de classes próximas, trabalham geralmente na mesma equipa de features. Todos têm conhecimento das classes que lhes estão próximas. O conhecimento é separado em blocos bem definidos e estruturados, e não espalhado ao calhas.
Inspecção e Programação em pares
Inspecções ao desenho e ao código, quando bem feitas são mais eficazes do que a fase de teste. Outras vantagens são:
1. Os developers aprendem técnicas uns com os outros, e o código tem tendência a seguir um standard.
2. XP usa programação em pares, para garantir um nível contínuo de desenho e inspecção de código.
Todo o desenho de baixo nível, assim como o código é feito em pares. Isto revela-se bastante mais eficaz do que um único developer criar código sem nenhum tipo de inspecção.
Em FDD promove-se as inspecções pela equipa de features. O nível de formalidade é deixado ao cargo do chefe de programação. Este processo é mais demorado, mas tem algumas vantagens em relação à programação em pares.
1. O código é inspeccionado por outra pessoa, que detecta falsos pressupostos feitos pelo programador.
2. Um programador chefe está presente para garantir que as técnicas usadas são boas técnicas.
3. Dá um certo tempo de descanso ao developer, enquanto o código está as ser inspeccionado.
Não há razão para os elementos de uma equipa de features não se organizarem em pares. É comum ver-se dois elementos a trabalhar juntos, quando tal é vantajoso. Uma vantagem das equipas de features é que uma feature só está completa quando a equipa acaba o trabalho. É do interesse dos seus elemento ajudarem-se mutuamente.
Testes
Em FDD o teste das unidades é garantido como uma parte da fase Build by Feature. Não estão definidos os mecanismos ou os níveis de formalidade para o teste das unidades. Deixa-se ao cargo do programador chefe definir o que é apropriado.
É aceitável usar técnicas de teste de unidades de XP em FDD. Quando novas builds são criadas regularmente ou até continuamente, faz sentido haver um maior número de testes que possam ser usados. Em FDD, não se especificou isto, visto que a tecnologia e os recursos diferem muito de projecto para projecto. Em muitos casos é muito difícil criar um grupo isolado de testes independentes que possam ser corridos num intervalo de tempo razoável.
Referências
Artigos sobre metodologias ágeis e outros mais específicos sobre FDD’s, nomeadamente: http://www.pcoad.com/download/bookpdfs/jmcuch06.pdf
http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf http://www.vtt.fi/ele/uutta/electra/agile.pdf
http://www.nebulon.com/articles/fdd/download/fddoverview.pdf E ainda a consulta a página respectiva a esta metodologia:
