Agile and Feature Driven Development (FDD)

Feature Driven Development (FDD) definitions

• Feature Driven Development (FDD) uses a prescriptive model where the software development process is planned, managed, and tracked from the perspective of individual software features.
  • Feature Driven Development (FDD) uses short iterations of two weeks or less to develop a set amount of features.
• A project team following the FDD method will first develop an overall model for the product, build a feature list and plan the work.
  • The team then moves through the design and build iterations to develop the specifications.

Feature driven development (FDD) steps

• The five step Feature Driven Development (FDD) process is :
  • Develop overall model;
  • Create the features list;
  • Plan by feature;
  • Design by feature;
  • Build by feature.
  • [Agile Software Development: The Cooperative Game – 2nd Edition. Alistair Cockburn.]

Develop Overall Model

• The FDD project starts with a high-level walkthrough of the scope of the system and its context.
  • Next, detailed domain models are created for each modelling area by small groups and presented for peer review.
  • One or more of the proposed models are selected to become the model for each domain area.
  • Domain area models are progressively merged into an overall model.

FDD practices

• DOMAIN OBJECT MODELING
  • the team explores & explains the business environment of the problem to be solved
• DEVELOPING BY FEATURE
  • breaking functions down into two-weeks or shorter chunks and calling them features
• INDIVIDUAL CLASS OWNERSHIP
  • areas of code have a single owner to warrant consistency, performance and conceptual integrity.
• FEATURE TEAMS
  • dynamic teams evaluating multiple design options and risk associated to those options
• INSPECTIONS
  • reviews to help ensure good-quality design & code
• CONFIGURATION MANAGEMENT
  • labeling code, tracking changes as managing the source code (ITIL)
• REGULAR BUILDS
  • through regular builds, the team makes sure the new code integrates with existing code
• VISIBILITY OF PROGRESS AND RESULT
  • process tracks progress based on completed work

Build feature list

• Knowledge gathered during the initial modeling is used to identify a list of features by functionally decomposing the domain into subject areas.
  • Subject areas each contain business activities, and the steps within each business activity form the basis for a categorized feature list.
  • Features in this respect are small pieces of client-valued functions expressed in the form ”

Plan by feature

• After the feature list is completed, the next step is to produce the development plan and assign ownership of features (or feature sets) as classes to programmers.

Design by feature

• Design package is produced for each feature.
  • A chief programmer selects a small group of features that are to be developed within two weeks.
  • Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model.
  • Next, the class and method prologues are written and finally a design inspection is held.

Build by feature

• After a successful design inspection for each activity to produce a feature is planned, the class owners develop code for their classes.
  • After Unit Testing (UT) and successful code inspection, the completed feature is promoted to the main build.

FDD Best Practices

• Feature-driven development is built on a core set of software engineering best practices aimed at a client-valued feature perspective.
  • Domain Object modelling.
    • Domain Object modeling consists of exploring and explaining the domain of the problem to be solved.
    • The resulting domain object model provides an overall framework in which to add features.
  • Developing by Feature.
    • Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature.
    • This makes it easier to deliver correct functions and to extend or modify the system.
  • Individual Class (Code) Ownership.
    • Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner.
    • The owner is responsible for the consistency, performance, and conceptual integrity of the class.
  • Feature Teams.
    • A feature team is a small, dynamically formed team that develops a small activity.
    • Multiple minds are always applied to each design decision, and multiple design options are evaluated before one is chosen.
  • Inspections.
    • Inspections are carried out to ensure good quality design and code primarily by the detection of defects.
  • Configuration Management.
    • Configuration management helps with identifying the source code for all features that have been completed to date and maintaining a history of changes to classes as feature teams enhance them.
  • Regular Builds.
    • Regular builds ensure there is always an up-to-date system that can be demonstrated to the client and helps highlight integration errors of source code for the features early.
  • Visibility of progress and results.
    • Managers steer a project using frequent, appropriate, and accurate progress reporting from all levels inside and outside the project based on completed work.

More informations at PMI-ACP exam

Updated : 24/10/2021