FDD (Feature-Driven Development)
FDD
Feature-Driven Development
1. Overview of FDD, an Agile Methodology for Large-Scale Projects Built Around Iterative Development by Feature List
flowchart LR
A["Large-scale projects are<br/>hard to plan holistically<br/>(uncertain scope & schedule)"] --"Feature-list-based<br/>staged approach"--> B["Iterative development<br/>by Feature, within 2 weeks"] --"Progress visibility<br/>& quality management"--> C["Predictable<br/>large-scale software development"]
style A fill:#FFEBEE,stroke:#D32F2F,color:#000
style B fill:#E3F2FD,stroke:#1976D2,color:#000
style C fill:#E8F5E9,stroke:#388E3C,color:#000
Definition: An Agile-based software development methodology proposed by Jeff De Luca that systematically manages large-scale projects through a five-phase process — developing an overall model, building a feature list, planning, designing, and building — centered on a list of Features that customers value.
Characteristics: (Feature) A small unit of functionality expressed in the form “verb + result + object” (e.g., “Look up a customer’s account balance”). (Progress visibility) Iterative development in small Feature units completable within two weeks maximizes progress visibility. (Role structure) A collaborative structure between the Chief Programmer and the Domain Expert.
2. Core Structure of FDD
A. The Five-Phase Development Process
flowchart LR
S1["1. Develop Overall Model"]
S2["2. Build Feature List"]
S3["3. Plan by Feature"]
S4["4. Design by Feature"]
S5["5. Build by Feature"]
S1 --> S2 --> S3
S3 --> S4 --> S5
S5 -->|"Repeat"| S4
style S1 fill:#E3F2FD,stroke:#1976D2,color:#000
style S2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
style S3 fill:#FFF3E0,stroke:#F57C00,color:#000
style S4 fill:#FFEBEE,stroke:#D32F2F,color:#000
style S5 fill:#E8F5E9,stroke:#388E3C,color:#000
| Phase | Owner | Key Activities | Deliverables |
|---|---|---|---|
| 1. Develop Overall Model | Development team + Domain Expert | Roughly establish the domain model (class diagram) for the entire system | Domain model, class list |
| 2. Build Feature List | Chief Programmer | Hierarchically derive a list of Features by business activity | Feature list |
| 3. Plan by Feature | Development Manager | Establish priority, dependencies, and schedule per feature | Development plan, progress tracking sheet |
| 4. Design by Feature | Chief Programmer | Detailed design for a selected set of Features | Sequence diagrams, design packages |
| 5. Build by Feature | Class Owner (developer) | Coding, unit testing, code inspection, build, integration | Completed Features, integration build |
B. Feature-Centric Iterative Development Mechanism
flowchart TD
subgraph R1[" "]
direction LR
F1["Feature hierarchy<br/>Subject Area<br/>→ Business Activity<br/>→ Feature Set<br/>→ Feature"]
F2["Feature expression format<br/>verb + result + object<br/>e.g., Look up a customer's<br/>order history"]
end
subgraph R2[" "]
direction LR
F3["Iteration cycle<br/>Design by Feature<br/>Build by Feature<br/>repeats in units of up to 2 weeks"]
F4["Progress measurement<br/>based on number of<br/>completed Features<br/>tracked weekly, burndown chart"]
end
style F1 fill:#E3F2FD,stroke:#1976D2,color:#000
style F2 fill:#F3E5F5,stroke:#7B1FA2,color:#000
style F3 fill:#FFF3E0,stroke:#F57C00,color:#000
style F4 fill:#E8F5E9,stroke:#388E3C,color:#000
style R1 fill:none,stroke:none
style R2 fill:none,stroke:none
Core FDD Roles
| Role | Responsibility |
|---|---|
| Chief Architect | Designs the overall domain model and determines technical direction |
| Development Manager | Manages schedule, resources, and progress |
| Chief Programmer | Leads design of a Feature set, conducts code review |
| Class Owner | Responsible for coding and maintenance of a specific class |
| Domain Expert | Clarifies business requirements and validates the model |
Comparison with Scrum and XP
| Comparison Item | FDD | Scrum | XP |
|---|---|---|---|
| Iteration unit | Feature (within 2 weeks) | Sprint (1–4 weeks) | Iteration (1–2 weeks) |
| Planning basis | Feature list | Product Backlog | User Story |
| Strength | Large-scale projects, progress visibility | Flexible priority adjustment | Technical quality (TDD, pair programming) |
| Suitable scale | Medium–large (dozens of people or more) | Small–medium (around 10 people) | Small (5–10 people) |
3. Expected Benefits and Application of FDD
| Category | Key Expected Benefits | Application and Practical Approach |
|---|---|---|
| Visibility | Quantitatively tracks progress by number of completed Features | Operate weekly Feature burndown charts for stakeholder reporting |
| Large-scale application | Applies Agile practices even in large teams of dozens or more | Maintain design consistency across distributed teams through the Chief Programmer system |
| Quality management | Performs code inspection and unit testing at the Feature level | Include code review in the Definition of Done for feature completion |
| Domain alignment | Ensures traceability between requirements and code through business-feature-centered development | Combine with DDD Bounded Contexts to separate Features by domain |