Feature Driven Development (FDD)

1. Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.br 11/10/2005

2. Agenda • Introdução • Motivação • Melhores Práticas • Modelagem de Objeto do Domínio • Desenvolvimento por Feature • Class (Code) Ownership • Equipes por Feature • Inspeções • Builds Regulares • Gerência de Configuração • Comunicação/Visibilidade dos Resultados • Processo • Conclusão

3. Introdução • Desenvolvimento Ágil Tabela 1 – Manifesto Desenvolvimento Ágil

4. Feature Driven Development Criado por Jeff De Luca em 1999, baseado em 30 anos experiência na área de TI com envolvimento de Peter Coad e Steve Palmer; Trata-se de uma compilação dos “patterns of success” percebidos; Possui características de Desenvolvimento Ágil; Iterações pequenas (no máximo 2 semanas) Centrada em Design. “We cannot predict where a chess game will go, but we can learn patterns of play that bring success." [Highsmith 2000]. “Good habits are a wonderful thing. They allow the team to carry out the basic steps, focusing on content and results , rather than process steps . This is best achieved when process steps are logical and their worth immediately obvious to each member.” Coad, LeFebvre, De Luca [Coad 99] Introdução

5. Motivação • Clientes têm resultados rápidos e relatório do status numa linguagem que eles entendem • Gerentes de projeto têm uma visão completa e exata do status do projeto • Desenvolvedores conseguem trabalhar em novas coisas em poucos dias e ficam mais envolvidos em análise, projeto e codificação

6. Melhores Práticas • Modelagem de Objeto do Domínio • Diagramas de classes dos objetos do domínio e seus relacionamentos são construídos; • O suporte aos aspectos comportamentais é dado por diagramas de seqüência em alto nível; • Ênfase não é em cima de se determinar todos os atributos; • Evita as inferências isoladas dos analistas, por se tratar de um modelo global onde todos os envolvidos participam.

7. Modelagem De Objeto Do Domínio “Extending that analogy a bit further, a domain object model is like the road map that guides the journey; with it, you can reach your destination relatively quickly and easily without too many detours or a lot of backtracking; without it, you can very quickly end up lost or driving around in circles, continually reworking and refactoring the same pieces of code.” Stephen Palmer Figura 1 – Modelo de Objetos Do Domínio numa Fase Inicial

8. Req 1.1 Módulo 1 Req 1.2 Módulo 2 Req 2.1 Statement of Purpose Módulo 3 Req 3.1 . . . Req 3.2 Módulo N Req 3.3 . . . Req N.1 Desenvolvimento Por Feature Figura 2 – Decomposição do Statement Of Purpose em Requisitos Funcionais

9. Features são os requisitos funcionais com valor para o usuário, isto é, estão numa linguagem que o cliente ou usuário podem entender; Os requisitos funcionais tendem a misturar funções de interface, persistência e comunicação em rede com funções de negócio; Facilitam o acompanhamento da evolução do projeto (o quanto já foi feito) junto ao cliente. Feature “Once we have identified the classes in our domain object model, we can design and implement each one in turn. Then, once we have completed a set of classes, we integrate them and hey, presto! We have part of our system. Easy!...Well, it’s a nice dream!” “We can produce the most elegant domain object model possible, but if it does not help us to provide the system’s clients with the functionality for which they have asked, we have failed. It would be like building a fantastic office skyscraper but either leaving each floor unfurnished, uncarpeted, and without staff, or furnishing it with ornamental but impractical furniture and untrained staff.” A Practical Guide to FDD, cap 3

10. Feature • O termo feature em FDD é muito específico. Uma feature é uma função pequena, com valor no cliente expressa na seguinte forma: • <action> <result> <object> Com as proposições apropriadas entre ação, resultado e objeto. • Ex.: - Calcular o total de uma venda; - Avaliar o desempenho de um vendedor. - Validar a senha de um usuário. • Features vs. Casos de Uso • Classes com funções pesadas constantemente acessando classes com dados pesados • Alto acoplamento • Baixa coesão • Encapsulamento pobre

11. Feature • Exemplo • Área de Features Principal (Subject Domain Area) • Gerenciamento de venda de produtos • Conjunto de Features (Business Activity) • Vender para um cliente • Features • Calcular o total de vendas • Calcular o total de compras de um cliente • Estimar o tempo de entrega de uma venda • Calcular a taxa de uma venda

12. Class (Code) Ownership • Class (code) ownership num processo de desenvolvimento denota quem é em última instância responsável pelo conteúdo de uma classe (parte de código); • Pode ser: • Individual – a classe é atribuída somente a um único dono; • Coletiva – O time possui coletivamente a classe (código).

13. Individual Class Ownership • Vantagens • Um guardião de integridade conceitual; • Um expert para explicar uma parte do código; • Um desenvolvedor mais rápido para implementar essa parte de código; • “É minha classe, dela me orgulho!!!” • Desvantagens • Mudanças que dependem de outras classes; • Perda do conhecimento por ocasião da falta do class owner.

14. Collective Class Ownership • Vantagens • Resolve o problema da espera por outro para solução de um problema; • Desvantagens • Facilmente degenera em não tem dono ou classes governadas por uma “elite”.

15. Equipes por Feature • Como se organiza os class owners para construir as features? Figura 3 – Equipes por Feature

16. Equipes por Feature • Normalmente pequena: de três a seis integrantes; • Possui todo o código que necessita para mudar sua feature; • Cada membro de uma feature contribui para o design e implementação de uma feature sob a orientação de um desenvolvedor mais experiente.

17. Inspeções • Usadas para: • Detecção de Defeitos; • Transferência de Conhecimento; • Aderência à Padrões de Codificação; • Extrair Métricas para Melhoria do Processo. • Cuidado: Não devem ser tomadas como uma avaliação pessoal de performance.

18. Builds Regulares • Em intervalos regulares, o sistema completo é montado; • Identifica os erros de integração; • Garante um sistema “up-to-date” para demonstração ao cliente • Um processo de geração de builds pode ser melhorado para: • Gerar documentação; • Rodar script de métricas e de auditoria; • Base para testes de regressão; • Construir novo build e releasenotes, listando novas features adicionadas, defeitos corrigidos, etc...

19. Gerência de Configuração • Identificação do código para todas as features completadas; • Manutenção de um histórico de mudanças das classes.

20. ProgressReporting Facilita o acompanhamento gerencial, através da coleta de informações confiáveis e precisas sobre o status do projeto; Sugere um número de formatos de relatórios intuitivos e diretos para ilustrar o progresso. Closely related to project control is the concept of “visibility,” which refers to the ability to determine a project’s true status....If the project team can’t answer such questions, it doesn’t have enough visibility to control its project. The working software is a more accurate status report than any paper report could ever be. Steve McConnell [McConnell 98] Comunicação/Visibilidade Dos Resultados

21. Comunicação/Visibilidade Dos Resultados KEY: Work In Progress Attention Completed Not Started

22. Comunicação/Visibilidade Dos Resultados

23. Comunicação/Visibilidade Dos Resultados CP-1 Status Geral: Fazendo avaliação de produtos (14) Trabalhos em progresso Exemplo: Conjunto de Features: Fazendo avaliação de produtos – Trabalho em progresso CP-1 é o programador chefe inicial (14) esse conjunto de Features possui 14 características Conjunto de Features/ está 75% completado A conclusão é para dezembro de 2001 Atenção (ie, atrasado) Completo Não iniciado 75% Porcentagem completa: Barra de progresso Dez 2001 Status Completo: Completo Mês de conclusão MY

24. KEY: Work In Progress Attention Completed Progress Bar Not Started Comunicação/Visibilidade Dos Resultados Product Sale Management (PS) CP-1 CP-1 CP-3 CP-1 CP-2 CP-1 Invoicing Sales (33) Making Product Assessments (14) Setting up Product Agreements (13) Delivering Products (10) Selling Products (22) Shipping Products (19) 99% 75% 30% 3% 10% Dec 2001 Dec 2001 Dec 2001 Dec 2001 Nov 2001 Dec 2001 Customer A/C Mgmt (CA) Inventory Mgmt (IM) CP-2 CP-2 CP-2 CP-3 CP-3 CP-3 Opening New Accounts (11) Logging Account Transactions (30) Accepting Movement Requests (18) Moving Content (19) Evaluating Account Applications (23) Establishing Storage Units (26) 100% 97% 82% 82% 95% 100% Oct 2001 Nov 2001 Nov 2001 Nov 2001 Oct 2001 Nov 2001

25. Comunicação/Visibilidade Dos Resultados

26. Processo • Descrição • Cada processo é descrito em não mais do que duas páginas de papel tamanho carta, frente-e-verso; • Cada descrição do processo apresenta-se de acordo com a estrutura: Entrada, Tarefas, Verificação e Saídas (ETVX).

27. Processo • Papéis principais • Gerente de projeto • Arquiteto chefe • Especialistas no domínio • Gerentes de desenvolvimento • Programadores chefes • Proprietários de classes

28. Modelo de Objeto (mais formas do que conteúdo) Uma lista de Features categorizada Um plano de desenvolvimento (mais conteúdo do que forma) Um pacote de projeto (seqüências) Uma função do cliente completada Processo 1.Desenvolver um Modelo Geral 2. Construir uma Lista de Features 3. Planejar Por Feature 4. Projetar Por Feature 5. Construir Por Feature Figura 4 – Os 5 Processos FDD

29. Desenvolver um Modelo Geral • Adquirir conhecimento do domínio e construir o modelo geral • Estabelecimento do “propósito de negócio” do novo sistema; • Construção de um “modelo conceitual” do sistema.

30. Atividades Formar a Equipe de Modelagem Walkthrough sobre o Domínio Estudar Documentos Desenvolver pequenos Modelos de Grupo Desenvolver um Modelo da Equipe Refinar o Modelo Geral Escrever Anotações do Modelo

31. Entradas e Saídas • Entrada • Especialistas no domínio, programadores e arquitetos chefes são selecionados. • Saídas • Modelo geral do domínio; • Diagrama das classes principais com alguns métodos e atributos identificados; • Diagramas de seqüência de algumas funcionalidades mais complexas (se houver); • Comentário sobre o modelo.

32. Construir lista de Features • O domínio é decomposto até chegar nas Features; • Features são agrupadas e categorizadas; • Features são granuladas até ser necessário menos de 2 semanas pro seu desenvolvimento.

33. Atividades Formar a Equipe da Lista de Features Construir a lista de Features

34. Entradas e Saídas • Entrada • O processo de desenvolvimento do modelo geral ter sido concluído com sucesso. • Saídas • Uma lista das áreas do domínio identificadas; • Para cada área, uma lista de atividades de negócio (conjunto de Features); • Para cada atividade, os passos a serem realizados (Features).

35. Planejar Por Features • Uma data de lançamento é estabelecida para o release inicial; • A lista de Features priorizadas é refinada; • Dependência entre funcionalidades • Carga de Trabalho • Complexidade ou Risco • Milestones • O trabalho técnico é planejado e atribuído – plano de desenvolvimento

36. Atividade Formar a Equipe de Planejamento Determinar a Seqüência de Desenvolvimento Atribuir Conjuntos de Features para Programadores Chefes Atribuir Classes para Desenvolvedores

37. Entradas e Saídas • Entrada • O processo de construir a lista de Features ter sido concluído com sucesso. • Saídas • Áreas de Domínio com datas de término; • Atividades de negócio com datas de término; • Programadores-chefes atribuídos a atividades de negócio; • A lista de classes e seus donos (desenvolvedores).

38. Projetar Por Features • Regras e transações são identificadas • O modelo da interface do usuário é esboçado • Diagramas de seqüência mais detalhados são produzidos • Especialistas são consultados para descobrir qualquer necessidade específica adicional

39. Atividades Formar a Equipe Por Feature Estudo do Domínio Estudar Documentos de Referências Desenvolver Diagramas de Seqüência Descrever os prefácios de classes e métodos Refinar o Modelo

40. Entradas e Saídas • Entrada • O processo de planejamento ter sido concluído com sucesso • Saídas • Diagramas de seqüência • Designs alternativos (caso exista) • O modelo de objeto com classes, métodos e atributos novos ou atualizados • A documentação da API do sistema • Lista de tarefas (calendário/ To-Do)

41. Construir Por Feature • Features são construídas implementando todas as classes e métodos necessários • Testes de unidades • Features são inseridas no build quando o teste resulta em sucesso

42. Ponto de integração para a funcionalidade inteira Atividades Codificar Testar Unidades Inspecionar Código Promover à versão atual (Build)

43. Entradas e Saídas • Entrada • O processo de construção por Feature ter sido concluído com sucesso • Saídas • Classe(s) e/ou método(s) que passaram na inspeção de código com sucesso • Classes inseridas no build • A conclusão da funcionalidade do cliente

44. Conclusão • Requer alguma arte na alocação de recursos; • Permite um bom acompanhamento gerencial do status das atividades; • Mais leve e simples de implementar; • Favorece um bom Design do sistema.

45. Referências • http://agilemanifesto.org/principles.html, Principles Behind The Agile Manifest. • Highsmith, James A. III, 2000, "Adaptive Software Development: A Collaborative Approach to Managing Complex Systems." Dorset House Publishing • R Palmer, S. Felsing, John M. A Practical Guide to Feature-Driven Development. The Coad Series. • Coad P., Lefebyre E., De Luca, J. Java Modeling In Color With UML: Enterprise Components And Processes. Prentice Hall. • http://www.cin.ufpe.br/~processos/TAES3/slides-2004.2/FDD.ppt, Feature Driven Development. Apresentação por Manuela Xavier, 05/11/2004. • http://www.nebulon.com/fdd/, Feature Driven Development. • http://www.faturedrivendevelopment.com/, The Portal For All Things FDD. • http://www.fddmanager.com/, FDD Manager – Overview. • http://fddtools.sourceforge.net/, FDD Tools Project.

46. Dúvidas ???