Feature Driven Development

Feature Driven Development Reid S. Carlberg SE470 http://www.fivesticks.com/info/fdd

Feature Driven Development • Abstract • Historical background • Description • Usage guidelines • Marketplace analysis • References

Abstract • Feature Driven Development focuses on regular delivery of client-valued features • More structure than XP and fewer requirements than RUP—a middle ground • Embraces software development as a human activity, subject to human limitations and benefiting from human strengths

The Players • Jeff De Luca, principle, Nebulon Pty. Ltd. (Australia) • Peter Coad, TogetherSoft Corporation (now Borland)

Genesis: Singapore, 1997-98 • A large bank had a failed software project • 2 years of work • 3,500 pages of use cases • complex object model • no functioning code • concluded it couldn’t be done

Genesis: Singapore, 1997-98 • De Luca comes in, hires Coad • delivered 2000 functioning features • took 15 months with 50 programmers • came in under budget • all this an “un-doable project” !

How? • De Luca brought a methodology used for 20 years • Coad brought his ideas about features. • FDD was born. • First published in 1999, Java Modeling in Color with UML

Description: Primary Components • Core values • Six roles • Five processes • Project tracking methodology

Process Pride Core Values • “Process pride” focuses on the process rather than tangible results

Core Values • A system for building systems is necessary • Simple is better • Process steps should be obviously valuable to each team member • Good processes move to the background

Six Roles • Every publication on FDD emphasizes people • People’s strengths and weaknesses have a huge impact on any project’s outcome • Surprisingly: how to attract, recognize, motivate and keep good people

Six Roles • Project Manager • Chief Architect • Development Manager • Chief Programmers • Class Owners (aka Developers) • Domain Experts

Six Roles: Project Manager • Administrative lead for the project • budget, headcount, progress reports • Operates project system • e.g. TogetherSoft Control Center • Shields participants from external distractions

Six Roles: Chief Architect • Responsible for the overall design of the system • Runs design workshops (more on that in process) • Steers project through technical obstacles.

Six Roles: Development Manager • Leads day to day development activities • Resolves resource conflicts • Often combined with either the PM or CA

Six Roles: Chief Programmers • Experienced developers • Leads smaller teams of individual developers • Key role: needs to be respected by both developers and managers.

Six Roles: Class Owners • Individual developers • Design, code, test and document features

Six Roles: Domain Experts • Users, clients, sponsors, etc. • Knowledge base for developers

Supporting Roles Domain manager Release manager Language guru Build engineer Toolsmith System administrator Sometimes Helpful Testers Deployers Technical writers Six Roles: OK—More than six!

Five Processes Per project Per feature

1. Develop an overall model Who? domain experts, chief architect, chief programmers

1. Develop an overall model • Establishes the shape of the system • Defines classes, how classes related to each other • Creates the base object model • Includes internal and external reviews, model notes

1. Develop an overall model

2. Build a features list Who? Feature List Team: domain experts, chief programmers, chief architect (inspired by surgical teams)

2. Build a features list • Functional decomposition of model developed in step 1 • Subject area to business activity to business activity step • Feature is a business activity step, customer centric not technology centric • Nomenclature: <action> <result> <object> • “Generate an account number for the new customer”

2. Build a features list

2. Build a features list http://www.nebulon.com/articles/fdd/DevView.html

3. Plan By Feature Who? The Planning Team: the project manager, the development manager, and chief programmers.

3. Plan By Feature

3. Plan By Feature • Group features into feature sets (one or more business activities) • Prioritize based on customer need • Establish completion dates (MM/YYYY)

3. Plan By Feature http://www.nebulon.com/articles/fdd/planview.html

4. Design by feature Who? The Feature Team: chief programmer, class owners

4. Design by feature • Work package level—now based on the technical architecture • Two weeks or less of work • Fleshes out class and object design, create sequence diagrams as necessary • Feature teams are very fluid • Updates object model created in process #1.

4. Design by feature

5. Develop by feature Who? Class owners, chief programmers

5. Develop by feature • Implement • Code inspection • Unit test • Promote to build

5. Develop by feature

Primary Components • Core values • Six roles • Five processes • Project tracking methodology

Project Tracking Methodology Process 1’s 10% is the most significant. Other numbers are fungible.

Project Tracking Methodology walkthrough + design = 41% complete

Project Tracking Methodology http://www.nebulon.com/articles/fdd/SummaryTables.html

Project Tracking Methodology http://www.nebulon.com/articles/fdd/linereport.html

Usage Guidelines: Use When… • 10-250 developers • Handy pool of talented workers (above average)

Feature Driven Development