Feature Driven Development

FDD was first applied on a software development project for a large Singapore bank in 1997. FDD was first introduced to the world in 1999 via the book Java Modeling In Color with UML. A more substantial description is published in the book A Practical Guide to Feature-Driven Development as well as the Feature Driven Development web site.

Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic software process. The term "client" in FDD is used to represent what Agile Modeling (AM) refers to as project stakeholders or eXtreme Programming (XP) calls customers.

FDD was around before the Agile Manifesto was published. But FDD seemed to be aligned with the values expressed in the Manifesto, and thus was placed under the same Agile umbrella term. 

After a relatively short ramp-up period, where an initial model and feature list is developed, development begins. The development cycle of FDD focuses on feature sets, so that features are delivered complete and working at least every 2 weeks. This ensures the steady and continuous delivery of new functionality.

 

As the name implies, features are an important aspect of FDD. Features are to FDD as user stories are to Scrum - they're a primary source of requirements and the primary input into your planning efforts.

Five steps of the Feature Driven Development process:

  1. Develop an Overall Model

    • Output: High-Level Object Model and Notes

  2. Build a Features List

    • Output: List of Features grouped into sets and subject areas

  3. Plan By Feature

    • Output: Development Plan; Class and Feature Set Owners

  4. Design By Feature

    • Output: Design Package

  5. Build The Feature

    • Output: Programming, Testing, Packaging

 

The majority of the effort on an FDD project, roughly 75%, is comprised of the fourth and fifth steps: Design By Feature and Build By Feature. These two activities are exactly what you'd expect, they include tasks such as detailed modeling, programming, testing, and packaging of the system.​

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

FDD also defines a collection of supporting roles, including:

  • Domain Manager

  • Release Manager

  • Language Guru

  • Build Engineer

  • Toolsmith

  • System Administrator

  • Tester

  • Deployer

  • Technical Writer

Developing by feature and including individual class ownership are good practices, as is having developers work together in feature teams. Inspections are an important aspect of FDD. FDD also insists on regular builds, similar to XP, and configuration management. Finally, FDD promotes a best practice called reporting/visibility of results, similar to XP's and Agile's philosophy of open and honest communication.

Advantages of FDD:

  • Often used to move small to large projects, and obtain repeatable success

  • Practicing the five processes helps to bring new staff in with a shorter ramp-up time

  • Built around a core set of industry-recognized best practices

  • Regular builds ensure there is always an up-to-date system that can be demonstrated to the client, and helps highlighting feature integration errors in the source code earlier, rather than later

  • Enhanced visibility of progress and results through frequent and accurate progress reporting

  • Reduced risk via iteration of design & build in small chunks

  • Clarity of requirements and better understanding of system to be built gained through the Develop Overall Model process

  • Costing by feature leads to greater project budgeting accuracy

Disadvantages of FDD:

  • Not as powerful on smaller projects (i.e., one developer, only one person modeling)

  • High reliance on chief programmer. They act as coordinator, lead designer, and mentor.

  • Minimal written documentation