7 Things You Need to Know About Feature Driven Development

The main goal of the Feature Driven Development methodology is to develop real, working software systematically and meet deadlines. The list of developer tasks is a list of features to be included in the product.

This methodology is an attempt to combine methods that are widely recognized in the software development industry and take the functionality (properties) of the developed software important for the customer as a basis.

You can find more than enough detailed theoretical info on this topic. So, let us dwell on the most important things you should know about FDD.

FDD Is Part of Agile

This methodology appeared before the Agile manifesto but declares similar principles. The difference between FDD and other Agile development methodologies is in more attention to preliminary modeling, reports, and charts, though functions are developed separately and in short stages.

The key principles of Feature Driven Development methodology:

• Each major project should be developed systematically
• The processes should be simple and well-elaborated
• The process value and consistency should be clear to every team member
• Short iterative development cycles have preferences. This approach allows you to avoid errors and increase functionality quickly.

Feature Driven Development Approach Is Based on Short Iterations

Like all other Agile methodologies, it focuses on short iterations, each of which serves to work out a certain part of the system functionality. A single iteration lasts no more than two weeks.

Although FDD also resorts to an iterative development model, it differs in some features from Agile:

• more attention is paid to preliminary modeling
• reports and charts are more important
• it is focused on corporate development.

FDD Process Implies Five Steps

The first three steps are related to the project start:

1. Developing an overall model (project vision based on preliminary data).
2. Building the feature list (like the product backlog in the Scrum methodology).
3. Planning by feature (each member of the team makes a properties complexity assessment).
4. Designing by feature.
5. Building by feature.

The last two steps are the final stage, after which the property becomes part of the product and the cycle starts over.

Team Features

For each function, a special functional group of team members, who qualify best for the desired roles, can be brought together. Such a team can be cross-functional and multi-component.

Project success depends on the leading developer’s experience and knowledge. In FDD, he plays all the main roles: a leader, a mentor, an analyst, etc.

FDD Suits Large and Long-Term Projects

This methodology was created for large and long-term projects, so it is unreasonable to apply it for small tasks in most cases. The possibility to scale even for large teams makes this framework well-suited for enterprise development.

As a result, FDD is considered to be an efficient solution designed to support the management of relatively complex Agile projects.

Efficiency Is in the Spotlight

When you apply Feature Driven Development, you get the following benefits:

• system properties documentation
• detailed design
• easier to assess small tasks
• tests are focused on business tasks
• a well-elaborated product development process
• short iterative development cycles allow you to quickly increase functionality and reduce errors.

Continuous progress reports at all levels help you track the development and results. This feature allows you to regularly update the project, find errors, and provide the customer with necessary data at any time.

FDD Has Nothing in Excess

Developers need simple and practical methods, which they could easily implement to get a proper result. Complex processes are good but hard to make them work in a real case scenario. Therefore, lightweight processes are the natural request of the industry.

This methodology is good because even though it is meant to be used by large teams, it has nothing in excess. This peculiarity makes the FDD approach easy to implement and support. However, if you would like to make it “heavier” a bit, you could always do it with no trouble.

When choosing a methodology for product development, you should make a decision based on the customer’s and team’s specific requirements, capabilities, and limitations. We hope the information presented in our article will help you make the right decision!

If you are looking for a reliable technology partner, please contact us, and we will gladly answer all your questions.