Client-centric, architecture-centric, and pragmatic, Feature Driven Development (FDD) is an agile framework that primarily focus on the feature set that the client values, and is known for short iterations and frequent releases.
FDD was first introduced in 1999 in the book Java Modeling In Color with UML while its first real-world application was on a 15 month, 50-person project for a large Singapore bank in 1997, which was then immediately followed by a second, 18-month long 250-person project.
The term, “feature” emphasized in the FDD context, doesn’t necessarily mean product features, rather, they are more akin to user stories in Scrum. Thus, “completing the login process” might be considered a feature in the FDD methodology.
Not many talk about FDD, though it is often mentioned in passing in agile software development books and forums.
Source: DevPro Journal
Feature Driven Development is a customer-centric software development methodology built largely around discrete “feature” projects.
With this concept, developers can plan and manage each stage of project development to keep prioritizing client requests, responding to requests in time and making clients satisfied.
This is done through mapping out what features developers are capable of creating, breaking complex requests into a series of smaller feature sets and then creating a plan for how to complete each goal over time.
The Feature Driven Development Methodology
Source: New Line Technologies
Suitable forprojects with large development teams, follow pre-defined standards and require quick releases, FDD focuses on short iterations with each of which serves to workout certain part of the system’s functionality.
The project through the FDD concept is divided into “features”, known to be small pieces of a complete project.
Feature Driven Development Roles
FDD has six (6) key roles:
- Project Manager (PM). The administrative head of the project. He does reporting progress, handling budgets, and managing equipment, space and resources, etc.
- Chief Architect (CA). The one responsible for the overall design of the system.
- Development Manager (DM). Leads day-to-day development activities.
- Chief Programmers. Are experienced programmers who’ve been through the entire software development lifecycle a few times before.
- Class Owners. Are developers working as members of small development teams under the guidance of the Chief Programmer.
- Domain Experts. They are users, sponsors, business analysts, or a combination of these, known to be the knowledge base that the developers rely on, enabling them to deliver the correct system.
Other supporting roles, include:
- Release Manager. Ensures that Chief Programmers report progress weekly. He then reports directly to the Project Manager.
- Language Guru. Responsible for knowing a programming language or a specific technology inside out.
- Build Engineer. The one who sets up, maintain, and run the regular build process.
- Toolsmith. The one responsible behind the creation of small development tools for the development team, test team, and data conversion team.
- System Administrator. A person responsible in configuring, managing, and troubleshooting any servers and network of workstations that are specific to the project team.
Additional roles are as follows:
- Tester. Independently verifies that the system’s functions meet the users’requirements and that the system performs those functions correctly.
- Deployer. Converts existing data to the new formats as required by the new system and work on thephysical deployment of new releases of the system.
- Technical Writer.The one who writes and prepares online and printed user documentation.
Feature Driven Development Processes
FDD has five (5) basic processes steps:
- Developing an overall model. Cross-functional, iterative and highly collaborative. FDD pushes team members to work together to build an object model of the domain area as guided by the Chief Architect. When detailed domain models are created, these models are progressively merged into an overall model after.
- Building the list of features. By using the model on the previous step, the team or the chief programmer builds a list of features that would be useful to users and could be completed along a set timeline for release.
- Planning by feature. It’s all about organizing. Here, plans are laid in which order the features will be implemented. Teams are then selected and assigned feature sets.
- Designing by feature. On this stage, the chief programmer chooses the features for development and assigns them to feature teams consisting of the project manager; the chief architect; the development manager; the domain expert; the class owner; and the chief programmer.
- Building by feature. Feature teams have complete coding, testing, and documentation of each feature, then advance the feature to the main build.
Feature Driven Development is built around overall software engineering best practices:
- Identify the domain object model, or the scope of the problem that needs to be solved.
- Break down complex features into smaller functions and subsets.
- Assign features to a single owner in order to ensure consistency and code integrity.
- Build dynamic and diverse feature teams to collect multiple design options.
- Perform routine code inspections of each feature before implementing into the main build.
- Enforce project visibility through frequent, accurate progress reports during all steps.
An iterative and incremental software development methodology, Feature Driven Development (FDD) aims to develop high-level features, scope and domain object model and then utilize that to plan, design, develop and test the specific requirements and tasks upon the overarching feature that they belong to.
This concept is ideal for projects that have large development teams, follow pre-defined standards and require quick releases.
If you enjoy reading about software development methodologies, let’s take a look at other blog posts.
By Tuan Nguyen