Feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.
FDD organizes software development around making progress on features. Features in the FDD context, though, are not necessarily product features in the commonly understood sense. They are, rather, more akin to user stories in Scrum. In other words, “complete the login process” might be considered a feature in the Feature Driven Development (FDD) methodology.
Feature-Driven Development (FDD) was invented by Jeff De Luca. Jeff designed FDD from the ground up to work for a larger team. Larger teams present different challenges.
FDD was designed to follow a five-step development process, built largely around discrete “feature” projects. That project lifecycle looks like this:
- Develop an overall model
- Build a features list
- Plan by feature
- Design by feature
- Build by feature
This methodology relies heavily on chief developers and has a top-down decision-making approach, as opposed to some of the other agile frameworks (such as XP) that are based more on collective project ownership.
Why it’s useful
FDD is useful because it demonstrates that you can focus on domain modeling on an iterative and incremental project, and because it demonstrates agile-like methodologies, it can also easily scale. FDD shows that teams can spend a short amount of time at the beginning of the project to establish a clear understanding of the domain in which they are working and use that understanding to formulate a rough plan without getting stuck in analysis and design paralysis.
Benefits and Disadvantages
One of the questions that is often asked about feature driven development is how it compares with Scrum development. When assessing feature driven development vs Scrum, it is clear there are a number of common points: both are collaborative; both offer improved communication; the emphasis is on quality components; while features are developed in short iterations with progress constantly tracked.
Where they are different however, is that Scrum does not specify any particular engineering practice. Instead, it focuses on vertical slices of functionality with short feedback loops. By contrast, FDD places the focus on specific engineering practices with longer feedback loops and with a feature team that takes clearly recognisable roles.
It could be argued that FDD was formed by taking into account the natural strengths and weaknesses of humans. It has proven to be a highly effective way to rescue complex projects because it addresses so many of the problems that so commonly afflict developers. The entire feature list is built to the priorities of business users and its fast approach – using two-week increments – even gives businesses the chance to use the application before it has been finished.
Advantages of FDD
- Practicing the five processes helps to bring new staff in with a shorter ramp-up time.
- Allows larger teams to move products forward with continuous success
- Leverages pre-defined development standards, so teams are able to move quickly
- Feature-Driven Development is built around a core set of industry-recognized best practices as
- Regular Builds – Regular builds ensure there is always an up to date system that can be demonstrated to the client and helps highlighting integration errors of source code for the features early.
- Visbility of progress and results – By frequent, appropriate, and accurate progress reporting at all levels inside and outside the project, based on completed work, managers are helped at steering a project correctly.
- Risk Reduction via iteration of design & build in small chunks. FDD helps in reducing risks using shorter iterations of designing, understanding of the requirements and the system- in a clear and distinct way, thereby leading to a state where there are no ambiguities, as the needs and expectations are already understood very well.
- Clarity of requirements and better understanding of system to be built is gained through the Develop Overall Model process. This process includes high-level walkthrough of the scope of the system and its context. Next, detailed domain walkthroughs are held for each modeling area.
- Costing the project by feature leads to greater accuracy.
Disadvantages of FDD
- Not as powerful on smaller projects (ie, one developer, only one person modeling)
- High reliance on chief programmer. He act as coordinator, lead designer, and mentor.
- No written documentation. Less written documentation, which can lead to confusion
- Does not work efficiently for smaller projects
How to use it
- Develop an Overall Model.
- Build a Features List.
- Plan by Feature.
- Design by Feature and Build by Feature.
- Repeat step 4 until no more features exist.
Processes of feature-driven development
FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high-level overview of the activities. In the figure on the right, the meta-process model for these activities is displayed. During the first two sequential activities, an overall model shape is established. The final three activities are iterated for each feature.
- Develop overall model
- Build feature list
- Plan by feature
- Design by feature
- Build by feature
Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project, it is important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially.
Best Practices
At the heart of FDD are a number of best practices designed for software engineering: all of which are formed from a client’s perspective. Some of the best practices that should be followed by developers include:
- Domain Object modeling.
- Developing by Feature.
- Individual Class (Code) Ownership.
- Feature Teams.
- Inspections are carried out to ensure good quality design and code primarily by detection of defects.
- Configuration Management.
- Regular Builds.
- Visibility of progress and results.
