Faltam 0 dias! Inscreva-se agora! O maior encontro de profissionais web da américa latina.

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.