Kleber Silva - Feature Driven Development (FDD)

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Clique para editar o estilo do título mestre
Clique para editar o estilo do subtítulo mestre
*
*
*
Feature Driven Development (FDD)
Kleber Silva, khfts@cin.ufpe.br
11/10/2005
*
*
*
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
*
*
*
Introdução
Desenvolvimento Ágil
Tabela 1 – Manifesto Desenvolvimento Ágil
*
*
*
Introdução
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]
*
*
*
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
*
*
*
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.
*
*
*
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
*
*
*
Desenvolvimento Por Feature
Figura 2 – Decomposição do Statement Of Purpose em Requisitos Funcionais
*
*
*
Feature	
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.
“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
*
*
*
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
*
*
*
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
*
*
*
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).
*
*
*
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.
*
*
*
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”.
*
*
*
Equipes por Feature
Como se organiza os class owners para construir as features?
Figura 3 – Equipes por Feature
*
*
*
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.
*
*
*
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.
*
*
*
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 release notes, listando novas features adicionadas, defeitos corrigidos, etc...
*
*
*
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.
*
*
*
Comunicação/Visibilidade Dos Resultados
Progress Reporting
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
KEY:	Work In Progress	 Attention	 Completed Not Started
*
*
*
Comunicação/Visibilidade Dos Resultados
*
*
*
Comunicação/Visibilidade Dos Resultados
Dez 2001
Porcentagem completa:
Status Completo:
Completo
Mês de conclusão
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
Status Geral:
MY
Barra de progresso
Trabalhos em progresso
Atenção (ie, atrasado)
Completo
Fazendo
avaliação
de produtos
(14)
75%
Não iniciado
CP-1
*
*
*
Comunicação/Visibilidade Dos Resultados
Product Sale Management (PS)
Invoicing
Sales
(33)
Dec 2001
CP-1
Setting up
Product
Agreements
(13)
Dec 2001
Selling
Products
(22)
Nov 2001
CP-1
Shipping
Products
(19)
Dec 2001
CP-1
10%
Delivering
Products
(10)
Dec 2001
CP-3
30%
Making
Product 
Assessments
(14)
Dec 2001
75%
99%
3%
Customer A/C Mgmt (CA)
Evaluating
Account
Applications
(23)
Oct 2001
95%
Logging
Account
Transactions
(30)
Nov 2001
82%
Opening
New
Accounts
(11)
Oct 2001
100%
Inventory Mgmt (IM)
Establishing
Storage Units
(26)
Nov 2001
100%
Moving
Content
(19)
Nov 2001
82%
CP-3
Accepting
Movement
Requests
(18)
Nov 2001
97%
CP-3
CP-2
CP-1
CP-2
CP-2
CP-2
CP-3
*
*
*
Comunicação/Visibilidade Dos Resultados
*
*
*
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).
*
*
*
Processo
Papéis principais
Gerente de projeto
Arquiteto chefe
Especialistas no domínio
Gerentes de desenvolvimento
Programadores chefes
Proprietários de classes
*
*
*
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
*
*
*
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.
Desenvolver um Modelo Geral
*
*
*
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
*
*
*
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.
*
*
*
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.
*
*
*
Atividades
Formar a Equipe da Lista de Features
Construir a lista de Features
*
*
*
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).
*
*
*
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
*
*
*
Atividade
Formar a Equipe de Planejamento
Determinar a Seqüência 
de Desenvolvimento
Atribuir Conjuntos de Features 
para Programadores Chefes
Atribuir Classes para Desenvolvedores
*
*
*
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).
*
*
*
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
*
*
*
Atividades
Formar a Equipe Por Feature
Estudo do Domínio
Estudar Documentos de Referências
Desenvolver Diagramas de Seqüência
Refinar o Modelo
Descrever os prefácios de 
classes e métodos
*
*
*
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)
*
*
*
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
*
*
*
Atividades
Codificar
Testar Unidades
Inspecionar Código
Promover à versão
atual (Build)
*
*
*
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
*
*
*
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.
*
*
*
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.
*
*
*
Dúvidas
???
Frisar aqui que não se trata de que o lado (+) vai prevalecer absoluto, mas que na verdade, o foco do desenvolvimento ágil privilegia os pontos marcados com (+) sobre os pontos marcados com (-). Os princípios por trás das metologias ágeis seguem: “We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a reference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. 
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Os desenvolvedores muitas vezes se detem em detalhes como a interface e novas tecnologias em detrimento do negocio
do usuario. A ideia por tras das features é justamente prover uma fatoração dos requisitos funcionas num tamanho que caiba no time frame de 15 dias e que possa se apresentar num formato compreensivel para o cliente.
Mac: So if I use the template to name my use cases and keep them to the two-week implementation limit, I would have the benefits of features and use cases? Use cases usually have preconditions, postconditions, and a description of what needs to happen. I could leave these empty to start with and fill them as development proceeds. That would avoid the analysis paralysis you warn of. 
Steve: I suppose you could. I’m not sure what it buys you. One problem you might encounter by calling your features use cases is that you are going to confuse others who associate a different level of granularity, format, and application with the name use case. Another problem is that, although nearly every expert I have spoken to recently advocates writing use cases in parallel with building a domain object model, most people still try to write them before doing any modeling or prototyping. In fact, many people advocate using use cases or functional requirements to drive the building of a domain object model.
Mac: Yes, I know, and I have seen the results many times! Function-heavy classes constantly accessing data-heavy classes, high coupling, low cohesion, and poor encapsulation. Yuck! I definitely prefer building the object model with Domain Experts first or at
the same time as writing use cases. The functional decomposition and object-oriented decomposition are orthogonal approaches. Doing both helps to ensure that we deliver the function required within a structure that is robust and extensible.
Para a equipe de desenvolvimento
Para programadores chefes e gerentes de projetos
Para patrocinadores, alta gerência e clientes
Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Então, são realizados estudos mais detalhados sobre o domínio do negócio para cada área a ser modelada. Após cada estudo dirigido sobre o domínio, pequenos grupos são formados por membros do domínio do negócio sendo estudado e por desenvolvedores, que comporão seus próprios modelos que satisfaçam o domínio em questão. Os pequenos grupos apresentam seus modelos para serem revisados por parceiros e para discussão. Um dos modelos propostos, ou uma combinação dos modelos, é selecionada por consenso, tornando-se, assim, o modelo para aquela área do domínio do negócio. Realiza-se, então, uma combinação do modelo da área do domínio dentro de um modelo abrangente, ajustando a forma do modelo se for necessário.
A equipe de modelagem é composta de membros permanentes das áreas do domínio do negócio e de desenvolvimento, especificamente os especialistas no domínio e os programadores-chefes. É feito um rodízio com os outros integrantes do projeto através das sessões de modelagem, de modo que todo mundo tenha a chance de participar e ver o processo em ação. 
Formar a Equipe de Modelagem -> Gerente de Projeto
Walkthrough sobre o Domínio -> Equipe de Modelagem
Estudar Documentos -> Equipe de Modelagem
Desenvolver pequenos modelos de grupo -> Equipe de Modelagem em grupos pequenos
Desenvolver um Modelo da Equipe -> Equipe de Modelagem sob a orientação do Chief Architect
Refinar o Modelo Geral -> Equipe de Modelagem sob a orientação do Chief Architect 
Escrever Anotações do Modelo -> Chief Architects, Chief Programmers.
Uma equipe, geralmente composta apenas por programadores-chefes do processo nº 1, é formada para decompor funcionalmente o domínio em áreas, atividades de negócio dentro delas e passos dentro de cada atividade de negócio, formando assim a lista categorizada de funcionalidades. A categorização de mais alto nível para a lista de funcionalidades vem da divisão do domínio feita pelos especialistas do domínio no processo nº 1. 
A equipe é composta por programadores-chefes da equipe de modelagem do processo nº 1. 
Formar a Equipe da Lista de Features -> Gerente de Projeto, Gerente do Desenvolvimento.
Construir a lista de Features -> Equipe da Lista de Features (Chief Programmers)
O gerente de projeto, o gerente de desenvolvimento e os programadores-chefes planejam a ordem na qual as funcionalidades serão implementadas, baseada nas dependências entre elas, na carga de trabalho da equipe de desenvolvimento e também na complexidade das funcionalidades a serem implementadas. As principais atividades neste processo não são uma seqüência estrita. Como muitas atividades de planejamento, elas são consideradas em conjunto, com refinamentos feitos a partir de uma ou mais atividades e então considerando os outros novamente.
 
Um cenário típico é levar em conta a seqüência de desenvolvimento, depois levar em conta a atribuição das atividades de negócio aos programadores-chefes e, ao fazê-lo, considerar quais das classes principais (apenas) são atribuídas a quais desenvolvedores (lembrar que o programador-chefe também é um desenvolvedor).
 
Quando esse equilíbrio for alcançado, e a seqüência de desenvolvimento e a atribuição das atividades de negócio aos programadores-chefes estiver essencialmente completada, então a posse das classes estará completada (além das classes principais que já foram consideradas para posse).
A equipe de planejamento é composta pelo gerente de desenvolvimento e pelos programadores-chefes. 
Formar a Equipe de Planejamento -> Gerente de Projeto
Determinar a Sequencia de Desenvolvimento -> Equipe de Planejamento (Gerente de Desenvolvimento e pelos Chief Programmers)
Atribuir Conjunto de Features para Chief Programmers -> Equipe de Planejamento
Atribuir Classes para Desenvolvedores -> Equipe de Planejamento.
É uma atividade para cada funcionalidade, para produzir o pacote de projeto (design) para a funcionalidade.
 
Certo número de funcionalidades são agendadas para desenvolvimento ao atribuí-las a um programador-chefe. Ele seleciona as funcionalidades para desenvolvimento a partir de sua “caixa de entrada” de funcionalidades atribuídas. Ele pode escolher diversas funcionalidades que utilizem as mesmas classes (e portanto, desenvolvedores). Operacionalmente, com freqüência acontece o caso de “conjuntos” de funcionalidades serem agendados para desenvolvimento de uma vez pelo programador-chefe. Tal conjunto é chamado de Pacote de Trabalho do programador-chefe.
 
O programador-chefe, então, forma uma equipe de funcionalidades, identificando os proprietários das classes (desenvolvedores) que provavelmente serão envolvidos no desenvolvimento das funcionalidades que ele selecionou. Esta equipe produz o(s) diagrama(s) de seqüência para a(s) funcionalidade(s) atribuída(s). O programador-chefe, então, refina o modelo de objetos, baseado no conteúdo do(s) diagrama(s) de seqüência. Os desenvolvedores escrevem os prefácios das classes e métodos. Realiza-se uma inspeção no projeto (design).
O programador-chefe identifica as classes que provavelmente serão envolvidas no projeto deste conjunto de funcionalidades e, consequentemente, atualiza o banco de dados de funcionalidades. Da lista de proprietários de classes, o programador-chefe identifica os desenvolvedores necessários para formar a equipe de funcionalidades. 
Formar a Equipe Por Feature -> CP
Estudo de Domínio -> Domain Expert
Estudar Documentos de Referência -> Equipe de Features
Desenvolver Diagramas de Sequencia -> Equipe de Planejamento
Refinar o Modelo -> 	CP
Descrever prefácios de classes e métodos -> Equipe de Feature
É 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).
Codificar -> Equipe de
Feature
Testar Unidades -> Equipe de Feature
Inspecionar Código -> Equipe de Feature
Promover à versão atual -> CP e a equipe de Feature