Introduction to Feature Driven Development (FDD) - Type of Agile Software Development

Feature Driven Development (FDD)was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using the following eight practices:

1. Domain Object Modeling
2. Developing by Feature
3. Component/Class Ownership
4. Feature Teams
5. Inspections
6. Configuration Management
7. Regular Builds
8. Visibility of progress and results

Feature Driven Development asserts that:
- A system for building systems is necessary in order to scale to larger projects.
- A simple, but well-define process will work best.
- Process steps should be logical and their worth immediately obvious to each team member.
- "Process pride" can keep the real work from happening.
- Good processes move to the background so team members can focus on results.
- Short, iterative, feature-driven life cycles are best.

FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other Agile approaches, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.