Metodologia Ágil:
Feature Driven Development
António Barbosa1, Bruno Azevedo2, Bruno Pereira3,
Pedro Campos4, Pedro Santos5
1
Estudante da LEIC –
[email protected]
2 Estudante da LEIC –
[email protected]
3 Estudante da LEIC –
[email protected]
4 Estudante da LEIC –
[email protected]
5 Estudante da LEIC –
[email protected]
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:
http://www.featuredrivendevelopment.com/