Speed skating

Feature Driven Development, criado por Peter Coad, Jeff De Luca e Stephen Palmer, conforme visto em [111], é uma metodologia ágil para gerenciamento e desenvolvimento de software que combina as principais vantagens das metodologias ágeis com técnicas baseadas em modelos, em uma única abordagem completa para a Engenharia de Software. Ela é totalmente orientada a objetos, o que a torna bem eclética, e por isto conquista os três principais públicos envolvidos na construção do software, conforme de Luca et al. [37]: clientes, gerentes e desenvolvedores.

Em 2002, Stephen Palmer, gerente de desenvolvimento do projeto em Singapura, e John Mac Felsing, arquiteto senior na TogetherSoft, publicaram o livro “A Practical Guide to Feature Driven Development” [111], com a versão completa, atualizada e comentada da metodologia. Em 2003, David Anderson, que foi o especialista em interface com o usuário no projeto de Cingapura, publicou um marco na literatura ágil, “Agile Management for Software Engineering: Using the Theory of Constraints for Business Results” [5], onde oferece uma análise profunda sobre a FDD, entre outras metodologias, além de material inédito.

A FDD chama a atenção pelas seguintes características, que a torna bem peculiar: • Modelagem em objetos de domínio;

• Desenvolvimento orientado por características das funcionalidades;

• Integração regular (build);

• Resultados úteis a cada duas semanas ou menos;

• Blocos bem pequenos de funcionalidades valorizadas pelo cliente, chamadas de “Features”;

• Planejamento detalhado e guia para medição;

• Rastreabilidade e relatórios com incrível precisão;

• Fornece uma forma de saber, dentro dos primeiros 10% de um projeto, se o plano e a estimativa são sólidos;

• Reportar a visibilidade do projeto (todos sabem sobre a evolução do sistema).

Com relação às outras metodologias de desenvolvimento de software, situa-se numa posição intermediária entre as abordagens mais prescritivas, como o Processo Unificado, e as abordagens Ágeis (XP, Scrum, Crystal, etc.).

A.2.5.1 A Técnica

Conforme vemos no site oficial do FDD [92], para que seja possível gerenciar de forma correta um projeto usando FDD, existe a definição de alguns papéis centrais responsáveis por assumir a gerência, algo bem simples: O gerente, o arquiteto-chefe, o dono das classes e o programador-chefe. Esse último é também um desenvolvedor que cuida da implementação das regras de negócio e deve ser conhecedor profundo delas. Ele é o criador do time de métodos ágeis e que conduzirá o desenvolvimento através da verificação de quais são as classes que serão usadas, recrutando seus respectivos “donos”. Com isso, podem existir, dependendo do tamanho da equipe, diversos times de desenvolvimento, o que pode fazer com que os desenvolvedores trabalhem em mais de um time, com recomendação de, no máximo, três, para cada iteração. O programador-chefe pode também acumular a função de “dono” de algumas classes. O papel do “dono” das classes é o de manter a documentação em dia e em ordem.

A.2.5.2 O Processo

A modelagem é feita para cada funcionalidade associada com a troca de informações entre o usuário da ponta da linha e o sistema. Assim, poder-se-á ter uma visão mais clara e específica do comportamento de cada requisito, suas pormenoridades, e checando sempre com o cliente, se é aquilo mesmo que ele solicitou — o lema é cliente satisfeito. A modelagem, nesse caso, quase sempre é feita pelo programador-chefe e a elaboração do código massivo, dita “pesada”, pelos demais programadores do time.

Abaixo, as etapas desse processo: 1. Desenvolver um modelo abrangente; 2. Construir a lista de funcionalidades; 3. Planejar por funcionalidades;

5. Construir por funcionalidades.

Dessas etapas, as três primeiras pertencem à parte de planejamento do processo e as duas últimas, ao desenvolvimento, que são consideradas a parte iterativa. Os trabalhos de modelagem de negócios estão contidos dentro da parte iterativa, conforme podemos observar na Figura A.11.

A.2.5.2.1 (1) Desenvolver um modelo abrangente:

A primeira etapa do processo consiste na criação do modelo de domínio, com a concepção das classes de domínio, representando as entidades abstraídas das regras de negócios, com todas as relações apuradas e com um nível de detalhamento apenas suficiente para dar forma ao sistema de um modo geral. A finalidade desta etapa, segundo Palmer e Felsing [111], é diminuir um possível ou provável refatoramento no futuro, uma vez que gera um arcabouço para a construção do sistema nas etapas subsequentes, mantendo assim uma integridade conceitual. Essa integridade conceitual tem de ser cuidadosamente estudada para evitar problemas futuros.

Figura A.11: Etapas de um processo usando a metodologia FDD, adaptado de Palmer e Felsing [111], Fonte: http://heptagon.com.br/fdd-estrutura.

A.2.5.2.2 (2) Construir a lista de funcionalidades:

Na segunda etapa constrói-se a lista de funcionalidades previstas para todo o sistema (as features), agrupando-as e priorizando-as com a atribuição de pesos em cada uma delas.

no modelo de domínio, removendo ou adicionando detalhes abstraídos de requisitos. Ela deverá corresponder adequadamente as expectativas do cliente. Um ponto importante é que essas funcionalidades devem ser breves, havendo sempre a preocupação com o prazo estipulado para a entrega, não podendo ultrapassar, em geral, duas semanas – o que pode obrigar a decomposição de uma funcionalidade, caso ela seja muito extensa.

A.2.5.2.3 (3) Planejar por funcionalidades:

Com a lista das funcionalidades em mãos, a terceira etapa se caracteriza pelo intenso planejamento — como transformar as ideias abstraídas em funcionalidades reais, com a elaboração de um plano voltado especificamente aos desenvolvedores. Esse plano deve considerar as relações entre as características de cada funcionalidade, a carga de trabalho que a equipe pode suportar e a complexidade delas, bem como a avaliação da tecnologia a ser utilizada para a implementação, em especial a camada de apresentação [92].

A.2.5.2.4 (4) Detalhar cada funcionalidade:

Após a terceira etapa, é iniciada a fase de construção do software propriamente dita, abrangendo mais duas etapas. Na etapa de detalhamento, são desenvolvidos os diagramas de sequência, procurando detalhar o máximo a implementação, desta vez levando-se em conta a linguagem de programação que é importante. Agindo assim, o programador-chefe tem condições de refinar bem o modelo a ser codificado. É nesta etapa que o “dono” das classes inicia a escrita da documentação da funcionalidade que está sendo implementada. O cliente junto poderá participar dessa atividade.

A.2.5.2.5 (5) Construir por funcionalidades:

Nesta etapa, tem-se início a construção do software, os programadores devem implementar o que foi discutido na etapa anterior (métodos, classes, etc) e criar e executar os testes de unidade.