Feature Driven Development: Evolution vs Revolution

Feature Driven Development (FDD) is not as well-known as many other agile frameworks.

But when you’re dealing with a large, long-running project, especially in an organization where agile is still mostly confined to software development, FDD may be your friend.

Feature Driven Development bridges the gap between traditional controlled waterfall approaches and the emergent processes found in agile approaches like behavior driven development, extreme programming, and scrum.

Brief Overview

FDD is a methodology broadly regarded as based on the four agile values and the twelve agile principles as set out in the Agile Manifesto. It was one of 6 methodologies represented at the meeting that created the Agile Manifesto. Work starts with building a domain object model and identifying all the features and feature sets (groups of features). After prioritizing the features, work proceeds iteratively and incrementally. The combination of more traditional planning with agile build practices helps FDD fit in with traditional enterprise structures. It works well for large teams and long, complex projects.

Brief History

The founders of Feature Driven Development were Jeff De Luca and expert modeler Peter Coad, helped by their co-workers. FDD was first applied in 1997 working on a product for a Singapore bank. The product took 15 months to complete with 50 people. After its success, it was used on a second, 18-month long, 250-person product. It grew from there.

How Does It Work

Feature-driven development defines five steps in two phases: planning and construction.

Planning Phase

The planning phase is about getting to a shared understanding of the scope of the product (a new software system) between the customer and their users, and the development organization. It’s how FDD helps you start an evolution instead of a revolution towards agile development.

Step 1: Develop an Initial Model

The first step in FDD is to outline an initial domain object model. Teams of developers and domain experts (e.g., future users in the customer’s company) each define a model that reflects their shared understanding of the important objects in the new system. The chief architect supports and guides them in this work. When these are done, all models are reviewed to come up with the initial model for the next steps. This can be one of the models or one that is a composite of one or more of the individual team’s models.

Step 2: Develop a Feature List

Next up is the feature list — all the functionality the product needs to offer. To do this, you split the domain model into subdomains that each represent a business function. For each subdomain, you then list all the features you require for the product to support your customer in that business function. Features that are closely related are often grouped into feature sets. A feature set can also be a feature broken down into smaller ones because it would otherwise take more than two weeks to complete.

The third step is where you plan the order in which to develop features and feature sets.

Factors to consider, are:

Which features your customer’s users need most urgently.

Which features will deliver the most value soonest.

Development time estimates — you don’t want to leave the biggest features for last.

Technical dependencies between features.

Risks involved with features — for example compliance testing, using new technology, learning new frameworks and libraries.

Available people, their skills and expertise.

Workload.

The result is a prioritized list of everything you need to implement. It’s like starting a Scrum project with a fully filled (but not refined) product backlog.

Construction Phase

In the design and build phase of FDD, you work through the feature list on a feature-by-feature basis. Work proceeds in two-week cycles, or iterations and is thus inherently iterative and incremental. The strict two-week cycle is why FDD wants you to break up features to fit that. In FDD, it’s okay to form and reform teams with the requirements of the features you’ll build next in mind. Generally, selecting people for a specific feature team is the realm of the chief programmer (see Key Roles and Responsibilities).

Step 4: Design by Feature

Each feature team works on the detailed design of the features assigned to them for the current iteration. Developers and domain experts, helped by the chief architect and chief programmer as needed, use UML modeling techniques such as class diagrams, sequence diagrams, and state transition diagrams to specify what the feature will do and how it’ll do it. Working on these specific designs, knowledge about the product increases and informs any changes needed to the initial domain object model. Each iteration, at the end of the design phase, a review by the entire team ensures that overlaps are identified and all the teams are aware of the overall model and design and stay within the original product concept.

Step 5: Build by Feature

Each feature team then works to turn their design into working software, test it, and gather feedback from domain experts to verify that the feature works as intended. When all’s okay, they’ll integrate their work with everything that’s been built in this and previous iterations.

Similarities and Differences

Feature Driven Development is a blend of up front design — the initial domain model — and planning, and iterative and incremental implementation. As such it’s both architecture-centric and agile.

It’s agile in its emphasis on meeting the needs of the end-users, collaboration with customer’s domain experts, and breaking down requirements into small features designed to deliver business value.

In other respects it’s much less agile.

All in all, I’d dare to posit that FDD is a good step away from the waterfall approach, but it falls short of many accepted agile practices that are better at encouraging everyone to take responsibility and activating and engaging everyone’s creativity, and deferring decisions to the last responsible moment.

Documentation

FDD insists on putting the (design) documentation into a knowledge system and extending it with construction information, meeting minutes, and decisions and issues that have arisen. It also insists on keeping that documentation up-to-date and spot on. As such, it’s a lot more documentation-heavy than most agile methodologies.

Dealing with change

As FDD plans, designs and builds “by feature”, it’s possible to pause the construction phase and consider how to respond to changes in the new system’s environment, for example a new competitor in your market. This means FDD is more amenable to change than the waterfall approach, but there’s more waste than in other agile approaches, as you’d essentially be re-doing the planning phase to decide which built features to scrap, which not-yet-finished features to drop, and which new features to add. And that is including all the changes needed to keep the documentation up-to-date.

We’ll cover the cycles themselves in more detail later. Now, let’s focus on the characteristics of great teams.

Code ownership

FDD is unique in its insistence on ‘individual class ownership’. Jeff de Luca says:

“Collective ownership is code for ‘no ownership’. It’s not a structure I believe in.”

In this, FDD goes against common practices advocated in the agile community. Individual class ownership lowers your bus factor to 1 — it’s somewhat compensated for by FDD’s reliance on good documentation.

Key Roles and Responsibilities

The project manager oversees the entire project, and uses traditional rather than agile management techniques. The development manager deals with the day-to-day activities. S/he is often the developers’ line manager and also functions as a mentor for less experienced team members. The chief architect is in charge of the overall design of the system and guides the domain experts and developers in their work during the initial and iterative design steps. The chief programmer is an experienced developer who assists teams with analysis and design during the design and build steps. S/he helps the class owners and other developers to keep the code base consistent in its application of software design principles. S/he may also manage small development teams. A class owner is any developer responsible for designing, coding, testing, and documenting a class that implements part of the domain object model in code. A domain expert understands the customer’s business in general and the part that the new product (system) will support in particular. S/he helps the development teams understand how the business operates and what it needs. S/he usually comes from the customer’s organization.

Key Meetings, Cycles, Delivery Cadences

The Planning Phase is a two-week period to produce the initial domain object model and the feature list. During the Design and Build phase, the delivery of work for testing is weekly. Delivery of features to the customer is every two weeks. Teams participate in reviews of progress and performance. For example, there are regular round-table meetings for code reviews during the construction phase.

Methods and Techniques

Broken down into its five steps, FDD is more structured than other methodologies. This is reflected in the methods and techniques it uses and advocates. Object-Oriented Design: With Peter Coad — a renowned object-orientation proponent and UML pioneer, as a founder, it’ll be no surprise that object-oriented design features prominently in feature driven development. Features and feature sets: Features are small, client-valued pieces of a product’s functionality. They are expressed through action, result, and object — e.g., ‘Calculate the total of a sale’. Feature Sets are simply grouping of features. Individual class (code) ownership: Each class or related set of functions in code has a single owner who is responsible for the performance and quality of that code. Feature teams: feature teams in FDD are dynamic — they are formed and disbanded from class owners as needed by the features that are to be built next. Inspections: FDD uses design inspections and code inspections to prevent errors — or rather to detect them before they escape into the wild. Highly visible progress reports: FDD specifies a comprehensive and easily understood set of progress reports. It uses a number of milestones to report feature progress consistently and color codes statuses for an easy big-picture view of project progress. Two progress reports specific to FDD are Parking Lot charts and Feature Complete charts.

Getting Started

All the normal advice to getting started with a new methodology applies just as much to getting started with FDD. That means: get buy-in from and collaborate with top management; train everybody in the methodology — including people that won’t work according to it but are affected by the way it works; use coaches and mentors who’ve walked the path before at all levels; etc.

Original Source Link

Article source: https://article-realm.com/article/Computers/Software/41958-Feature-Driven-Development-Evolution-vs-Revolution.html