Before the Agile Manifesto came to life, some tools ruled the management world. And of them is the Feature-Driven Development, as known as FDD.
The FDD was first of all created by Jeff de Luca in 1997, based on the Coad method, created by Peter Coad in the 1980s, and on the interactive and lean processes already used by Jeff de Luca.
Seeing the progress of the methods that could work better in most of the companies, Feature-Driven Development incorporates many of the best development practices already recognized by the industry into a cohesive package.
These practices are all feature-oriented, which is a value concept from the customer’s point of view. FDD’s main objective is to deliver a tangible and functional piece of software to the customer in space’s regular time slots.
In this article, you will figure out what are Feature-Driven Development’s main features and goals and how you can use them in project management.
What is Feature Driven Development?
FDD seeks development for functionality, that is, for a functional requirement of the system. It’s handy for working with initial projects or projects with existing encodings.
Although having some differences between FDD and XP, for example, it is possible to use the best practices of each methodology. FDD works very well in conjunction with Scrum, as Scrum acts in the focus of project management and FDD acts in the development process.
One of the objectives of FDD is to present such functionalities to the customer
in a fixed period of time, usually two weeks or less.
FDD has a short lifecycle and is best suited for systems that can change requirements quickly; it incorporates many of the best development practices already recognized by the industry into a cohesive whole.
These practices are all feature-oriented, which is a value concept from the customer’s point of view. The main objective of FDD is to deliver a tangible and functional piece of software to the customer in regular time frames, typically two weeks or less.
FDD roles in Scrum
1. Project Manager / Product Owner
The project manager is the one who handles the administrative issues of the project, where he has the autonomy to decide what should be done, prioritizing any functionality that delivers value and manages to be performed during that pre-determined period of time.
He is also responsible for a small team, ensuring good working conditions to increase the performance of everyone involved, as well as for deciding what will be done during the defined sprint.
2. Development Manager / Scrum Master
The development manager is responsible for removing any impediments that the team may have, in addition to making the necessary meetings happen.
He must also evaluate if the code carried out by the development team is in the project standards, and if not, he must point out improvements or suggestions that collaborate in the team’s maturity, in question to the code and also to the team.
3. Design Team / UX Team
The design team, based on the analysis of the architecture and documentation of the project and/or product worked, will be responsible for all the visual issues to be carried out, including usability issues.
4. Class Owner / Developer
The class owner is a member of the development team, where he will be under the command of the development manager. He is responsible for issues related to architecture and testing, but his main activity is the implementation of features defined by the project manager.
5. Technical Writer / Requirements Analyst
The technical writer is responsible for understanding the product, having to know the area of operation of the project and/or product worked and must be involved in a large part of the product decisions, as it is he who ensures that the system follows the business rules of each functionality.
FDD’s Best Practices
To flow correctly, there are some good practices in FDD usage. However, FDD preaches adaptability in the development environment:
- Domain object-oriented modeling: Modeling should be basic, just something illustrative for those involved in the project.
- Feature development: feature-oriented implementation.
- Proprietary code: the code performs only by one developer. That is, it starts and ends with the same developer. However, it does not prevent the pair programming from performing with another developer on the team.
- Team: team designed to develop features necessary for the project. Code review performs to ensure the usage environment will not result in future bugs and problems.
- Regular integration: the finished features must integrate. They allow for error checking and also create a current version.
- Configuration management: Currently a development environment, one for approval and another that is the stable environment for customers to use.
- Report/Visibility of results: everyone involved must know the development status of the features, as this is a way of learning.
FDD’s Basic Processes
Some processes are for the basic functioning of the FDD are as follows:
- Comprehensive model development (Object-oriented analysis);
- Construction of feature list;
- Incremental planning for functionality;
- Projection by functionality;
- Build for functionality.
Team Progress
The team’s progress is through each item added to be carried out at the beginning of development planning. There is a level of effort and a priority level of the functionality in question that you must estimate and the meetings you will hold and monitor.
When the feature’s development status changes, they can symbolize colors of “in progress”, “delivered” and “delayed”. Or simply carry out the estimation in hours that still show the task you will deliver.
The most common these days is to split the feature into development days, for example, if you committed to developing the feature. You should split it into smaller features that will fit in 8 hours of development, so your monitoring will be easier. It is common to split the feature as follows:
- Application domain survey ;
- Functionality knowledge ;
- Project inspection ;
- Development ;
- Code inspection;
- Integration
Feature-Driven Development Documentation
The FDD documentation is not very different from the documentation that is common in agile methodologies. The main idea for the documentation is that the feature must deliver value to the customer, follow good practices and basic processes. Each process must describe in a maximum of two pages: Input, Tasks, Verification, and Outputs.
Documentation Review
The inspections on the documentation carry out to prevent future bugs in the development. It allows the transfer of correct knowledge and gives the developer the standards. Also, they allow extracting metrics for improvements in both the documentation processes and the development processes.
Feature-driven development is an extremely adaptable agile methodology. It couples with the Scrum agile methodology as well. It has its advantages for the events during the development sprint.
The main advantage of FDD is to consider the whole bigger than each part separately, as this encourages team spirit, and makes everyone understand what the product is, to carry out the development of the feature, avoiding future problems in the implementation.
GitScrum supports your team to better and understandable self-organization!
Set your workflow and board to guide your Agile team, assign Tasks, Subtasks and keep in charge of the whole process evolvements. Allow your Agile team to collaborate.