What is Feature-Driven Development?
Feature-driven development (FDD) is an Agile framework that organizes the software development process around delivering features often and efficiently. As other Agile methodologies, it is iterative, incremental, and customer-centric: first, a domain object model is built, and all the necessary features are identified; afterwards the features are priorities and the work towards progress on features proceeds in iterations.
Unlike most Agile practices, FDD is hierarchical in nature and uses traditional project management and the roles of the chief architect and chief programmer, especially during the planning and design. Besides, a team is not seen as a stale autonomous entity, but members can join the team only to build a specific feature and then leave. In this sense, FDD combines traditional planning with Agile build practices, which provides clients with regular updates and lets the team get feedback and identify errors promptly.
FDD Advantages
- FDD allows for rapid development due to a simple five-step process.
- It helps teams break a large problem into small issues and allocate specific resources to cope with it within a short period.
- It is suitable for large-scale long-term projects since it is easily scalable and can grow as the project grows.
FDD Disadvantages
- FDD doesn’t work efficiently for smaller projects since it does not give the team the necessary autonomy and power to make decisions.
- It is highly dependent on the experienced people, such as the chief architect and the chief programmer who act as designers, leads, and coordinators for the team.
- FDD pays less attention to written documentation, which can lead to confusion.
- It relies on individual, rather than on shared team code ownership, which reduces the quality and consistency and impedes collaboration and knowledge sharing between team members.
FDD Process
Feature-Driven Development process spans across five steps that can be divided into two phases: planning and construction.
Planning
This phase is focused on achieving shared understanding of the scope of the product between the customer, and the organization responsible for the development.
Step 1: Build an Initial Model. The team of developers and domain experts define an initial domain object model that covers important aspects of the future system.
Step 2: Develop a Feature List. The team splits the domain model into subdomains, each representing a business function and lists all features required for each subdomain.
Step 3: Prioritize features and plan their implementation. The team plans the order in which features and feature sets will be developed depending on several factors:
- which features will be needed by the users most urgently;
- which features provide the most value in the shortest time;
- dependencies between features;
- size of the feature;
- risks involved with features;
- available resources and workload.
As a result, prioritized features form the Product Backlog.
Construction Phase
In the construction phase, the team addresses features listed in the Product Backlog one-by-one proceeding in strict two-week iterations.
Step 4: Design by Feature. Developers, domain experts, the chief architect, and the chief programmer collaborate on the detailed design of the features assigned for the current iteration. For this, they can use various UML modeling techniques that specify the role of the feature and its place within the system.
Step 5: Build by Feature. The team works on implementing their design to create a working software, test it, collect feedback from domain experts, and integrate into the overall solution.
Overall, the FDD framework is a good option for projects that have grown too large or that are too old and have gone through multiple changes so that small Scrum teams cannot handle them. FDD ensures that the team is guided by experienced specialists and gives the team a good understanding of the scope and the context of the project.
