Feature‐Driven Development (FDD) - DavidMyrseth/BuketovPY GitHub Wiki
Introduction
Feature-Driven Development (FDD) is an Agile software development methodology focused on designing and building features that deliver tangible value to end users. Unlike other Agile approaches like Scrum or XP, FDD provides a well-structured process with an emphasis on architecture and code quality. The methodology was introduced by Jeff De Luca in collaboration with Peter Coad in 1997.
Abbreviation
FDD = Feature-Driven Development
Translation: Development driven by features
Key Principle: Every system enhancement should be represented as an independent, measurable feature delivering business value.
Core Principles of FDD
Feature orientation: Each feature represents a specific system behavior that is understandable to both business and developers.
Short iterations: Each feature is implemented within 2–10 days, allowing for frequent progress demonstrations.
Domain modeling: Strong emphasis on object-oriented design, resulting in a comprehensive object model of the system.
Team collaboration and role division: Every participant has a defined responsibility for specific components.
Continuous integration and quality control: Code is integrated and tested upon the completion of each feature.
Five Key Development Stages in FDD
- Develop Overall Model
Architects and domain experts work together to create a high-level representation of the system.
Class, interaction, and scenario diagrams are used.
This model serves as a foundation for detailed design.
- Build Feature List
The system is divided into areas (domain packages), each containing a set of features.
Features must be small, measurable, and represent real system behavior.
Example: "The user can view order history."
- Plan by Feature
A schedule is created for delivering features, with specific responsibilities assigned (class owners).
Dependencies between features are considered.
- Design by Feature
A small team designs the architecture for the selected feature.
Diagrams, schemas, and class templates are created.
The design is discussed in a design review session.
- Build by Feature
The functionality is implemented and unit tested.
Code is reviewed and integrated into the main repository.
Feature Example
Description:
"As a customer, I want to see the history of my orders so I can track what and when I purchased."
Feature Format:
Display a customer's list of orders sorted by date (including date, amount, status).
Implementation:
UI: Table with orders
Business logic: Fetching data from the database
Tests: Check sorting, display, and access control for the user’s own data
Roles in FDD
Chief Architect: Leads model design
Class Owner: Responsible for specific classes and their implementation
Project Manager: Plans tasks and tracks progress
Feature Designer: Designs the specific feature architecture
Feature Developer: Implements code based on the design
Advantages of FDD
Suitable for large, complex projects
Clear process and role structure
Good progress visualization
Compatible with object-oriented programming
Emphasis on code quality
Disadvantages of FDD
Requires initial architectural planning, which can be difficult with rapidly changing requirements
Less flexible than Scrum
Doesn't cover all aspects of Agile: lacks retrospectives and backlog grooming mechanisms
May be complex for small teams without architectural experience
When to Use FDD
For long-term, scalable systems
When predictability, structure, and standardization are essential
When the project requires detailed documentation and quality control
Useful Resources
Official website: https://featuredrivendevelopment.com/
Book: "Java Modeling in Color with UML" — Peter Coad, Jeff De Luca
Article: Feature-Driven Development: A Practical Guide — Stephen Palmer
FDD is a disciplined development approach where every step is measurable, and each feature is a step toward a complete product.