What is Feature Driven Development?

Feature Driven Development arose in the late 1990s from collaboration between Jeff DeLuca and Peter Coad. Their flagship project, like XP’s C3 Project, was the Singapore Project. DeLuca was contracted to save a failing, highly complicated lending system. The previous contractor had spent two years producing over 3,500 pages of documentation, but no code. DeLuca started from the beginning and hired Coad to assist with the object modeling. Combining their previous experiences, they developed the feature-oriented development approach that came to be known as FDD.

Highsmith explains FDD’s core values:

·        A system for building systems is necessary in order to scale to larger projects

·        A simple, well-defined process works 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 the team members can focus on results

·        Short, iterative, feature-driven life cycles are best

Develop an overall model: As depicted in Figure, the FDD process begins with developing a model. Team members and experts work together to create a “walkthrough” version of the system.

Build a features list: Next, the team identifies a collection of features representing the system. Features are small items useful in the eyes of the client. They are similar to XP story cards written in a language understandable by all parties. Features should take up to 10 days to develop. Features requiring more time than 10 days are broken down into sub features.

Plan by feature: The collected feature list is then prioritized into subsections called “design packages.” The design packages are assigned to a chief programmer, who in turn assigns class ownership and responsibility to the other developers.

Design by feature & build by feature: After design packages are assigned, the iterative portion of the process begins. The chief programmer chooses a subset of features that will take 1 to 2 weeks to implement. These features are then planned in more detail, built, tested, and integrated.

Team size: Team size varies depending on the complexity of the feature at hand. DeLuca stresses the importance of premium people, especially modeling experts.

Iteration length: Up to two weeks.

Support for distributed teams: FDD is designed for multiple teams and, while it does not have built-in support for distributed environments, it should be adaptable.

Criticality: The FDD prescription does not specifically address project criticality.