Feature Driven Development Reid S. Carlberg SE470 http://www.fivesticks.com/info/fdd
Dec 22, 2015
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
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: OK—More than six!
Supporting Roles Domain manager Release manager Language guru Build engineer Toolsmith System administrator
Sometimes Helpful Testers Deployers Technical writers
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”
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)
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
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
Feature Driven Development Abstract Historical background Description
Usage guidelines Marketplace analysis References
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