Houston 2015 COMFORTABLE SOFTWARE DEVELOPMENT FOR TEAMS FEATURE-DRIVEN DEVELOPMENT TM
Dec 25, 2015
Houston 2015
COMFORTABLESOFTWARE DEVELOPMENT
FOR TEAMSFEATURE-DRIVEN DEVELOPMENT TM
Three reasons why FDD may not be for you…
Do you dothat voodoo that you do,
so well?
Copyright 1974 by Warner Brothers, Inc.
Hi, I’m Larry.This is my brother, Darryl.
And this is my other brother, Darryl.
And, our nephew, Steve Jobs.
•
•
•
•
•
…nothing more difficult……nor more doubtful of success…
…nor more dangerous to handle……has enemies in…the old order…
…lukewarm defenders…
i amcurtisschlak
how i present
ComfortThe premises and conclusions by which I entrust myself to FDD
Axiom
software is about people
1
Axiom
all methodologies provide anillusion of control
2
Corollary
participants’ belief in a process enable the success of a process
1
Corollary
participants’ belief in a process enables accurate reporting
2
believabilityfamiliaritysimplicity
FDD: Who/HowHigh-Level Review of Feature-Driven Development
project managerchief architect
development managerchief programmers
class owners*domain experts
Develop an Overall Model
Build a Feature
List
Plan by Feature
21 3
BUFD!
Design by Feature
Build by Feature
54
entry criteriatasks
verificationexit criteria
• People join the club to become members and get invoiced monthly a flat fee and participation fees for classes• Participation fees for classes consist of a prorated
amount of the instructor’s hourly rate and a percentage of the cost of the equipment used by participants in the class• Record member purchases of food and beverages
from the club for rewards• For every ten dollars spent on food and beverages
from the club, the member receives a one dollar credit on their next invoice• Members RSVP for classes and their arrival is recorded• Instructors schedule rooms and equipment for classes
Develop an Overall ModelPhase I
taskslearn the domain
develop the model
verification by team
outputdiagrams and notes
problem domainsystems integrationdata management
user interface
problem domainmodeling in color
systems integrationdata managementtraditional design
enterprise patternsblah blah blah
user interfacehand waving and unicorns
domain-neutral componentmoment-interval
moment-interval detailsrole
thingdescription
Build a Features ListPhase II
tasksbuild a features list
verification by domain experts
outputa categorized list of features by
business activity and feature type
feature: «action» «result» «object»
«calculate» the«total amount» of a «sale»
«determine» the «total quantity sold by a retail outlet» for an «item
description»
business activity:«action» «object»
«completing» a «sale»
«forecasting» «inventory»
subject area:«object» management
«sales» management
«inventory» management
Member Management
Rewarding a Member
«create» a «$1 credit» for a «member purchase»«create» an «invoice line item» for «every credit»
Plan by FeaturePhase III
tasksdetermine development sequenceassign business activities owners
assign class owners
Outputdevelopment ordercompletion dates
owners
intermezzofixed-cost estimates
Design by FeaturePhase IV
tasksform the team
review features and domainin-depth design
verification through inspection
outputthe “design package”
walkthrough 1%design 40%
inspection 3%
Build by FeaturePhase V
taskscode
verification through code inspections and unit tests
outputpromote to main
code 45%inspection 10%
promote 1%
Tracking and Reporting
walkthrough 1%design 40%
design inspection 3%code 45%
code inspection 10%promote 1%
Tracking by Feature
Oct Nov Dec Jan 06 Feb Mar Apr May0
200
400
600
800
1000
1200
# of Features Completed Total # of Features
Report Board
Member ManagementBilling a Member
(18)77%
March 2016
Rewarding a Member
(4)
April 2016
Invoicing a Member
(7)50%
January 2016
Houston 2015