Hoje vou falar de FDD, que além de ser um método
ágil tem uma grande eficiência e aderência a requisitos. Vou dar uma
visão geral de como o método funciona e como podemos mixar o método com
outro método ágil chamado de Scrum.

Se você quiser saber mais sobre Scrum, pode ler outros posts que tenho sobre o assunto abaixo:

• Scrum e a gestão de pessoas
• Gerenciamento de Níveis com Scrum e RUP – Parte 01
• Gerenciamento de Níveis com Scrum e RUP – Parte 02

Voltando ao FDD,
o método é iterativo incremental e funciona muito bem com iterações
curtas de duas semanas, você pode usar um timebox maior, mas eu
recomendo muito o uso desse timebox, para mim o foi o que melhor
funcionou.

O FDD foi criado por Jeff De Lucca
em 1997. FDD é um método que prega a visibilidade do estado projeto de
forma consistente e honesta. Você consegue saber quantas
funcionalidades já foram desenvolvidas e quantas faltam ser
desenvolvidas porque tudo é orientado às funcionalidades.

O FDD
ajuda muito você a organizar as suas entregas, e funciona muito bem
porque ajuda usando as boas práticas de gerência de configuração como
plano de release, plano de deploy e outras práticas ágeis, como build
contínuo e foco em testes.

Visão geral

Visão Geral do FDD

O
FDD tem, basicamente, duas fases: a de Concepção e Planejamento e a
de Construção. Por ser simples e objetivo, o FDD pode ser uma
excelente solução para projetos de manutenção.

Na fase concepção
acontece a triagem de requisitos. Você ainda pode usar as técnicas
tradicionais da Engenharia de Requisitos, mas focando em
funcionalidades, é perfeitamente viável essa abordagem. De início você
tem que desenvolver um modelo abrangente. Isso é legal porque nesse
ponto começa a se mixar o FDD com as práticas de OOAD e UML em Cores.

No
modelo abrangente, o foco está mais na forma do que no conteúdo, isso é
bom por vários motivos. Primeiro que é um incentivo para que você não
faça um big design up to front e também não comece a querer fazer toda
a arquitetura de uma vez só, esse é um bom ponto de interação do design
com a arquitetura também.

Com isso, você tem insumos para a
geração da lista de features, que pode ser o seu backlog que você usa
Scrum, logo você pode manter isso em uma boa planilha excel. Esse
trabalho permite que você faça um planejamento por features que pode
ocorrer em uma reunião de planejamento do Scrum, com as práticas do
Scrum, logo você consegue saber quantas funcionalidades por sprint você
é capaz de desenvolver.

Na fase de construção existe um
detalhamento por funcionalidade, nesse ponto que você vai especificar
mais o que deve ser feito, acho plausível se você sentir necessidade,
usar histórias do usuário do XP.

Neste ponto você constrói por
funcionalidade, e o progresso é medido por funcionalidade. A cada
funcionalidade feia, se você quiser, pode colocá-la em produção. Eu
recomendo o Flckr, por exemplo, tem deploys em produção diariamente, deploy mais freqüentes são melhores para o negócio – quanto mais, melhor.

Nota:
Quando falo de deploy freqüente ou diário em produção, me refiro a
quando isso é possível, não estou dizendo para você pular testes nem bypassar seu SQA. Mas se você puder fazer um deploy todo o dia, melhor, isso será bom para todo mundo.

Medindo progresso com o FDD

Essa
medição se dá através de um cartão que representa a funcionalidade. Você pode fazer isso com um post-it semelhante ao da figura abaixo. Essa não é uma funcionalidade pura e já fiz uma mix com o Scrum:

Tracking de Funcionalidades com o FDD

Na
figura acima existem as funcionalidades tradicionais do FDD, mas
existe um mix que fiz com o Scrum também. Vamos por partes: primeiro o
FDD e as modificações que fiz. A cor amarela significa que a Feature
está em andamento, em verde significa que já foi concluída, e rosa
significa que a funcionalidade está atrasada. Usei essas cores porque
são as cores básicas dos post-its, se você quiser fazer tudo isso com
post-its.

Outro mix válido é mixar o FDD com o Kanban, assim as
atividades de planejamento, revisão, design, revisão, construção,
revisão e deploy do FDD podem ser colocadas em um pipeline. Para
facilitar a sua vida com post-it, você pode deixar só para desenhar a
barra de progresso ou então considere que a funcionalidade é o item do
scrum e continuar quebrando a feature em tarefas, mas vá movendo o
progresso só da feature e use o Tasks/W.I.P/Done do Scrum Tradicional.

Os
números dos cartões de funcionalidades são os seguintes – vou explicar da
esquerda para a direita, de cima para baixo. O primeiro número é o
identificador único da funcionalidade, esse pode ser o mesmo número que
você tem no backlog do Scrum ou até mesmo o número de um ticket da sua
ferramenta de tracking.

O número do meio é a pontuação do Scrum,
onde está pontuada a complexidade de desenvolver essa funcionalidade. E
o terceiro número, bem à direita, é a prioridade da feature que é dada
pelo dono do produto. Você pode jogar o post-it fora para mudar a cor
ou pode pintá-lo. Outra abordagem para quem não usa um dashboard seria
fazer isso em uma planilha excel. É uma boa, mas eu prefiro as coisas
feitas à mão porque elas favorecem a colaboração.

Quando atualizar o progresso?

Para
mim o momento ideal é quando estamos fazendo as reuniões de pé. Todo dia você pode atualizar o progresso de todas as funcionalidades em
desenvolvimento no dashboard ou em sua planilha, assim todos vão saber
do andamento das funcionalidades. Esse mix com o Scrum é muito benéfico,
pois o scrum dá um framework geral e com o FDD colocamos algumas coisas
especificas.

As revisões

O
FDD enfatiza a prática de revisão tanto de código como de projeto, isso
é muito bom e contribui para a evolução da qualidade do produto. Aqui o
FDD pode se juntar com diversas práticas da Garantia da Qualidade de
Software.

O FDD é um método que provê muitas coisas legais em
torno de funcionalidades, mas isso não elimina outras necessidades. Em
um projeto é muito saudável misturar FDD com outros métodos como Scrum,
XP, RUP e OpenUP. Misturas com Kanban também são bem-vindas e podem
melhorar mais ainda a visibilidade e facilitar a visualização do status
do projeto.

Se vocês quiserem mais informações sobre o FDD, confiram neste site aqui, aqui e aqui.

Abraços e até a próxima.