Transcript 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
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


Core Values

Process
Pride
“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
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

Operates project system

Shields participants from external
distractions
• budget, headcount, progress reports
• e.g. TogetherSoft Control Center
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 overall
model
Build a features
list
Per project
Plan by feature
Design by feature
Build by feature
Per feature
1. Develop an overall model
Develop an overall
model
Build a features
list
Plan by feature
Design by feature
Who?
domain experts, chief architect, chief
programmers
Build by feature
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
Study documents
Form the modeling
team
Deelop a team
model
Conduct a domain walk through
Develop small
group models
Refine the overall
object model
Write model notes
Model Name: NewModel
Package Name: NewModel
Diagram Name: ClassDiagram1
Diagram Type: Class
1. Develop an overall model
1
+CompositeClass
+StandardComponent1
1
1
1
1
+CollectionComponent1
1
0..*
+CollectionMember
1
+StandardComponent2
2. Build a features list
Develop an overall
model
Build a features
list
Plan by feature
Design 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 features
list team
Build features list
2. Build a features list
http://www.nebulon.com/articles/fdd/DevView.html
3. Plan By Feature
Develop an overall
model
Build a features
list
Plan by feature
Design by feature
Build by feature
Who?
The Planning Team: the project manager, the
development manager, and chief
programmers.
3. Plan By Feature
Determine the
development
sequence
Form the planning
team
Assign features to
chief programmers
Assign classes to
developers
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
Develop an overall
model
Build a features
list
Plan by feature
Design by feature
Build 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
Conduct a domain
walk through
Develop the
sequence
diagrams
Form a feature
team
Study the
referenced docs
Refine the object
model
Write class and
method prologue
Design inspection
5. Develop by feature
Develop an overall
model
Build a features
list
Plan by feature
Design by feature
Who?
Class owners, chief programmers
Build by feature
5. Develop by feature




Implement
Code inspection
Unit test
Promote to build
5. Develop by feature
Unit Testing
Code
Promote to build
Code inspections
Primary Components

Core values
Six roles
Five processes

Project tracking methodology


Project Tracking Methodology
Develop an overall
model
Build a features
list
Plan by feature
10% initial,
4% ongoing
4% initial,
1% ongoing
2% initial,
2% ongoing
Design by feature
Process 1’s 10% is the most significant.
Other numbers are fungible.
Build by feature
77%
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
???
Process
Heavy
Medium
Agile
Roles
~30
~6 (9 optional)
~7
Artifacts
25-30
Flexible
~10-15
~30
(Borland)
(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