Feature Driven Development

Reid S. Carlberg

SE470http://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

Feature Driven Development Abstract

Historical background Description Usage guidelines Marketplace analysis References

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

Feature Driven Development Abstract Historical background

Description Usage guidelines Marketplace analysis References

Description: Primary Components

Core values Six roles Five processes Project tracking methodology

Description: Primary Components

Core values Six roles Five processes Project tracking methodology

“Process pride” focuses on the process rather than tangible results

Core Values

Process Pride

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

Description: Primary Components Core values

Six roles Five processes Project tracking methodology

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

Six Roles: OK—More than six!

Supporting Roles Domain manager Release manager Language guru Build engineer Toolsmith System administrator

Sometimes Helpful Testers Deployers Technical writers

Description: Primary Components Core values Six roles

Five processes Project tracking methodology

Five Processes

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

Per project Per feature

1. Develop an overall model

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

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

Form the modelingteam

Conduct a domain walk through

Study documents

Develop smallgroup models

Deelop a teammodel

Refine the overallobject model

Write model notes

1. Develop an overall model

Model Name: NewModelPackage Name: NewModelDiagram Name: ClassDiagram1Diagram Type: Class

+CompositeClass

+StandardComponent1

+CollectionComponent1

+CollectionMember

+StandardComponent2

1

1

1

1

1

0..*

1

1

Class Diagram: ClassDiagram1

Date: Jun 1, 2003 Page: 1 of 1 Time: 2:13:36 PM

2. Build a features list

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

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

Form the featureslist team

Build 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.

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

3. Plan By Feature

Form the planningteam

Determine thedevelopment

sequence

Assign features tochief programmers

Assign classes todevelopers

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

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

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

Form a featureteam

Conduct a domainwalk through

Study thereferenced docs

Develop thesequencediagrams

Refine the objectmodel

Write class andmethod prologue

Design inspection

5. Develop by feature

Who?

Class owners, chief programmers

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

5. Develop by feature

Implement Code inspection Unit test Promote to build

5. Develop by feature

Code

Unit Testing

Code inspections

Promote to build

Primary Components Core values Six roles Five processes

Project tracking methodology

Project Tracking Methodology

Develop an overallmodel

Build a featureslist

Plan by featureDesign by feature Build by feature

10% initial,4% ongoing

4% initial,1% ongoing

2% initial,2% ongoing

77%

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

Project Tracking Methodology

Design by feature Build by feature

77%

Walk through: 1%Design: 40%

Inspection: 3%

Code/test: 45%Inspection: 10%

Promote: 1%

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

Feature Driven Development Abstract Historical background Description

Usage guidelines Marketplace analysis References

Usage Guidelines: Use When…

10-250 developers Handy pool of talented workers (above

average)

Usage Guidelines: Avoid When…

Team under 10 Team is still climbing the learning curve No support system

Feature Driven Development Abstract Historical background Description Usage guidelines

Marketplace analysis References

Market Position

Coad joined TogetherSoft in 1999 35 employees (1999) to 266 employees

(2000), 400 (today) 1/15/03: Borland purchases for $82.5m +

9m shares of stock

Market Position

RUP FDD XP

Scales To ??? 10-250 developers

50 developers

Tools Rational TogetherSoft (Borland)

???

Process Heavy Medium Agile

Roles ~30 ~6 (9 optional) ~7

Artifacts 25-30 Flexible

~10-15

~30(Thanks JN)

Market Position: FDD v XP

FDD More hierarchical Class owners Success with above

average developers Client works on 1,2,4 Process 1 “Live the life”!

XP Peer to peer Collective ownership Success with

average developers Client on the team Constant refactoring 40 hour weeks

Market Position: Notes

TogetherSoft/Borland now sells TogetherSoft as a process agnostic development tool.

FDD’s list of artifacts, processes, etc., seems to be growing over time.

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis

References

References http://www.fivesticks.com/info/fdd http://www.featuredrivendevelopment.com http://www.nebulon.com http://www.togethersoft.com (http://borland.com) Palmer, Stephen and Fesling, John, A Practical Guide to

Feature Driven Development, Prentice-Hall, 2002 Highsmith, Jim, Agile Software Development Ecosystems,

Addison-Wesley, 2003 Coad, De Luca and Lefebvre, Eric, Java Modeling In Color with

UML, Prentice-Hall, 1999