sexta-feira, setembro 29, 2006

Apresentando...FDD!

A FDD(Feature-Driven Development) é uma metodologia de desenvolvimento de software que, seguindo os princípios propostos pelo Manifesto Ágil, fornece processos para a distribuição repetível de software com valor para o cliente.

Com surgiu a FDD?
Ela surgiu no ano de 1997 quando Peter Coad e Jeff De Luca foram contratados para salvar um projeto bancário em Singapura. Reunindo experiências anteriores, eles chegaram ao que hoje é a FDD, esse mesmo projeto deu ainda origem à técnica de modelagem da UML em cores. Após pouco mais de um ano, o projeto estava salvo, tendo mais de 2.000 features (funcionalidades) desenvolvidas por uma equipe de 50 pessoas.

Identificando a FDD
A FDD possui características marcantes, entre elas podemos citar a importância que é dada para a qualidade das funcionalidades entregues ao cliente, através de práticas como a inspeção de modelo e de código. Outra característica não menos importante é a de priorizar a entrega de resultados frequentes, tangíveis e funcionais para os clientes, através do trabalho dividido em iterações, o que aliás é uma prática muito usada no mundo do desenvolvimento ágil. Relatórios de estado e progresso das atividades (como o famoso Parking Lot), adaptabilidade para projetos e equipes maiores ou menores, e um desenvolvimento partindo de um modelo abrangente são outras fortes características da FDD.

FDD significa Desenvolvimento Dirigido à Funcionalidades, mas...o que é uma funcionalidade?
É alguma característica do sistema que ofereça valor para o cliente e que possa ser desenvolvida em, no máximo, duas semanas. Para os mais experientes, uma funcionalidade pode ser comparada a um requisito funcional.
O template de uma funcionalidade é: [ação] [resultado] [objeto]
Alguns exemplos de funcionalidades: Calcular o desconto de uma venda, Validar o CPF de um cliente, Ordenar por Cidade e UF o relatório de clientes,...

Boas práticas da FDD
As principais práticas da FDD são as seguintes:
- Modelagem de objetos do domínio (negócio);
- Desenvolvimento por funcionalidade;
- Posse individual de classe (código);
- Time de funcionalidades;
- Inspeções de modelo e de código;
- Builds regulares;
- Gerenciamento de configuração;
- Relatório/visibilidade de resultados;

Os papéis da FDD
Os principais papéis que são definidos na FDD são os seguintes:
- Gerente de Projeto
- Gerente de Desenvolvimento
- Arquiteto-chefe
- Programadores-chefe
- Proprietários de código/classe (Desenvolvedores)
- Especialistas do domínio(negócio)
Em projetos maiores e que possuam tal necessidade, outros papéis podem ser incluidos no projeto, tais como:
- Gerente de Versão
- Guru da Linguagem
- Criador de Ferramentas
- Testadores
- Implantadores
- Redator Técnico
É importante ressaltar que é permitida, e comumente realizada, a atribuição de mais de um papel no projeto para a mesma pessoa.

Conhecendo os processos da FDD
A FDD é dividade em 5 processos que descrevo a seguir.

Processo 1: Desenvolvendo um Modelo Abrangente
Neste processo realizaremos um estudo dirigido sobre o escopo do projeto(e integrações) e seu contexto. Então, são realizados estudos mais detalhados sobre o domínio do negócio para cada área do produto(e integrações) a ser modelada. As atividades são realizadas em reuniões de domínio, executadas sequencialmente com a participação dos especialistas de negócio, programadores-chefes e arquiteo-chefe; eventualmente a participação do gerente do projeto pode ser considerada. Essas reuniões devem ser realizadas em ambiente isolado e confortável de forma a não torná-las excessivamente cansativas.

Processo 2: Construindo uma Lista de Funcionalidades
Processo realizado geralmente pelos programadores-chefes do processo nº 1, com o intuito de decompor funcionalmente o domínio(negócio) em áreas de negócio, atividades de negócio e funcionalidades.

Processo 3: Planejando por Funcionalidade
Este processo tem como finalidade produzir o plano de desenvolvimento. Gerente de projeto e programadores-chefes planejam, ordenam e estimam as funcionalidades que serão implementadas, baseando-se em dependências, carga de trabalho da equipe e complexidade.

Processo 4: Detalhando por Funcionalidade
Este processo é realizado uma vez para cada funcionalidade. O programador-chefe identifica os proprietários das classes (desenvolvedores) que provavelmente serão envolvidos no desenvolvimento da funcionalidade que ele selecionou. Esta equipe produz o(s) diagrama(s) de sequência para a(s) funcionalidade(s) atribuída(s). O programador-chefe, então, refina o modelo de objetos, baseando-se no conteúdo do(s) digrama(s) de sequência. Os desenvolvedores escrevem os prefácios das classes e
métodos. Realiza-se uma inspeção no projeto.

Processo 5: Construindo por Funcionalidade
É uma atividade para cada funcionalidade, para produzir uma função com valor para o cliente (funcionalidade). Começando com o pacote de projeto (design), os proprietários de classes implementam os itens necessários para que suas classes suportem o projeto para esta funcionalidade. O código desenvolvido passa pelo teste de unidade e pela inspeção – a ordem aqui é determinada pelo programador-chefe. Após passar pela inspeção, o código é promovido à versão atual (build).

Então verificamos o seguinte, os processos de 1 a 3 serão realizados uma única vez por projeto, mas lembrando que não necessariamente UM projeto é UM produto, podemos dividir a construção de um produto em vários projetos ou termos um projeto para cada versão, por exemplo. Os processos 4 e 5 serão repetidos uma vez para cada funcionalidade, ou seja, se na fase 2 geramos uma lista com 50 funcionalidades, significa que passaremos 50 vezes pela fase 4 e 5.

O que está fora da FDD?
Vale lembrar que a FDD se propõe a ser uma metodologia para DESENVOLVIMENTO DE SOFTWARE, portanto ela prevê boas práticas apenas para esse fim, diferentemente de metodologias que sugerem padrões também para fora do processo de desenvolvimento. Necessidades tais como escolha de tecnologias e ferramentas, definição de interface de usuário, testes de sistema e de carga, obtenção de patrocínio para o projeto, gerenciamento de recursos, conversão de dados, etc. NÃO são cobertas pela FDD.

Nenhum comentário: