What Is Feature-Driven Development?
Feature-Driven Development, also known as FDD, is an Agile model for software development that involves short iterations. It refers to a lightweight, incremental process in which development work (and progress) revolves around features.
FDD in Agile aims at delivering features efficiently and regularly. You build features incrementally until you have complete, working software. The framework is customer-centric and blends in a number of industry best practices. It promotes excellent status reporting, making it easy to keep tabs on progress and results.
You may notice that this model sounds somewhat similar to Scrum. A major difference, however, is that while FDD concentrates on features, the other deals with user stories. Even then, these features are similar to user stories and should not be viewed simply as product features. An example feature could be “integrate a payment platform.”
The FDD model was developed by Jeff de Luca and Peter Coad and was first used during a project for a Singaporean bank. It was discussed at length in the book, “Java Modeling in Color with UML,” published by Eric Lefebvre in 1999. The framework is now a popular choice for simplifying large, complex projects.
How FDD Works
This model involves five key activities or stages of activity. These are essentially the best practices you have to observe when using the framework. They are:
1. Develop an overall model – You start by deciding the overall scope by drawing up an outline. It is not critical to have all the details at this point. The overall model focuses on the vision, audience, and context. To be effective at this stage, it is important that you first collect data that enables you to grasp well a project’s content and context.
2. Build a features list – Working with the information you’ve gathered and your overall model, list out required features. Think of all you’d need to do to have a complete product or software. Remember that features are more like user stories.
3. Plan by feature – Assess features and determine realistic estimates for them. Consider difficulty when deciding on the order in which to execute each feature. Identify class owners and allocate features to team members.
4. Design by feature – At this stage, a decision is made on what features to design and build. FDD in Agile encourages teams to design in tandem. A review takes place at the end, with everyone in the team taking part, before proceeding to the next stage.
5. Build by feature – Following the inspection and finalization of feature details in the previous stage, the team now executes all the items needed to support the design. A prototype may be created for testing and approval before being added to the main build for shipping.
The first two stages cover all features. The remaining ones are repeated separately for each feature.
Is It Right for You?
The fact that this framework is loved and used by many development teams doesn’t mean it is ideal in all cases. It is important to note that it works best for companies working on large-scale projects. If you’re working on small projects, you might not find it helpful enough.
A lot depends on lead programmers or developers in FDD. This makes it more suitable for environments where decisions are made at the top and less so where decisions are made collectively.
