Feature driven development is a process that provides businesses with feature-rich systems that should help them control their ever-evolving nature.
As the name suggests, features are an important aspect of the entire Feature Driven Development (FDD) process. FDD blends a number of best industry-recognized practices which contribute to the business by complementing and reinforcing each other. While these practices are not new, their particular blend is new.
The chosen practices are all client-based. This means that the developers focus on the features that their clients value and find important for their business. On top of that, these features help the developers handle each step of the planning stage of the project development.
The birth of Feature Driven Development
Back in 1997, when Jeff De Luca was the Project Manager of a large software development project for a bank in Singapore, he encountered the complex problem. He realized that even by using all the available resources, his knowledge and traditional strategy of software development he could not solve the problem.
He consulted Peter Coad and they came up with the concept of feature driven development together. The concept consisted of five processes that were designed to cover the model’s development, its listing, design, planning and the feature building. In print, this was first published in the book called “Java Modeling in Color with UML” written by Peter Coad (Peter, et al., 1999).
Although FDD was Initially aimed at for smaller teams, De Luca and Coad designed the feature driven development from the ground-up to work for larger teams. This was of huge benefit to not only small businesses which are just learning the ropes of project management, but also huge corporations who often have to fight challenges of working with large teams and organizations.
The 5 processes of FDD
Jeff Luca proposed a solution: a mix of five processes that would cover the development of the model.
Developing an overall model
Domain and the development team members work together to create an object model of the domain problem. Their goal is to propose the model for the domain area. They are always under the watchful eye of a Chief Architect who also gives them guidance. After the teams have proposed their own models, one of the proposed models or a merge of models is selected and it becomes the model for that domain area. This helps the team have a clear overview of the entire project.
Building a feature list
Once your team has developed an object model, the next step is to identify the features that are valuable to the client. The features are the building blocks of the project and help the team navigate the processes.
Planning by feature
The third stage revolves around organizing the features and the way your team will implement them. Naturally, it’s important to take team workload, risks, and other aspects into consideration so you can prevent any complex issues from arising.
Designing by feature
By using the knowledge gained in the first modeling process, the chief programmer selects the group of features the team should develop next and determines the domain classes. Once the team starts working on the project, the domain expert starts analyzing and designing a solution to each feature.
Building by feature
The next step is to implement all the necessary items to be able to support the design. In other words, after your team has developed, tested and inspected the code, they are ready to start building the software.
Why do we need FDD
As the software system grows, the software development becomes more complex. In such a scenario, your team will have to find the most efficient way to tackle the pains they come across. FDD is the method that allows your team to successfully runs the project by:
- Improving the communication - most processes require constant communication flow, especially in large teams. FDD allows team members to communicate more easily while encouraging team creativity and innovation
- Minimising the complexity of the system - the bigger the size of the software system, the more complex the system gets. Complexity is one of the most frequent obstacles every software developer needs to overcome because it quickly outstrips the capacity of the human brain. FDD gives your team the ability to break the entire problem into many smaller problems which they can deal with in a smaller period of time. On top of that, smaller problems minimize the communication needs within the team and improve the communication flow.
- Maximising the quality - each member of the development team perceives quality in a different way. An average user associates quality with the interface, reliability and the response time. On the other hand, a developer talking about the quality discusses the ease of maintenance and enhancement of the software. However, the ever-increasing demands of the market prevent us from predicting the challenges we will have to struggle with and the changes we will have to make to produce positive results.
That’s why when working on a software development, it’s always best to view quality as a spectrum rather than a separate unchangeable parameter. In FDD, the concept of quality does not only include the testing of the code - it also includes coding standards, measuring audits and metrics in the code.
Feature driven development vs Scrum
When comparing Scrum methodology to FDD, it is obvious that they have many common points. Both of them:
- Improve communication
- Emphasize quality components
- Enhance collaboration
On the other hand, unlike FDD which focuses on specific engineering practices, Scrum does not specify any particular engineering practice. Also, while FDD has longer feedback loops Scrum has short feedback loops and focuses on a vertical slice.
Benefits of FDD
There are a number of reasons why Feature Driven DEvelopment is gaining popularity in IT world:
- FDD is an excellent solution for big and complex projects especially when dealing with critical situations
- 5 processes help the new team members become familiar with the system in short period of time
- Frequent progress reporting that takes place at almost any level of the project development, allows your team to keep track of the progress and track results
- It allows you to keep your project up-to-date regularly, identify any errors, and provide your client with valuable information at any time
- The deeper understanding of the software system allows you to build small parts one by one. This reduces the risk and keeps you safe from any unpleasant surprises.