David J. Anderson

1
Feature Driven Development

• David J. Anderson
• PM Microsoft Solutions Framework
• http//www.agilemanagement.net

2
Singapore Story
Peter Coad
Jeff De Luca
3
FDD in the Agile Community
Jon Kern, Director of Consulting at Togethersoft
stands in for Peter Coad at Snowbird, Feb 2001
Kent BeckMike BeedleArie van BennekumAlistair
CockburnWard CunninghamMartin Fowler
James GrenningJim HighsmithAndrew HuntRon
JeffriesJon KernBrian Marick
Robert C. MartinSteve MellorKen SchwaberJeff
SutherlandDave Thomas
4
FDD is Powerful
Feature Driven Development (FDD)
But

• Highly Effective
• High Quality
• Faster To Market
• Team working
• No Overtime
• Productivity
• 2 to 10 fold improvement
• Quality improvement
• 31 to 2100

• No Time Tracking
• No Gantt Charts
• No Task Tracking
• No Time on Task Estimates

Scary!!!
5
FDD an agile methodology
Marketing participates MRD input
Carefully Analyze MRD
Prioritize and plan Code development
Build code in small batches
Wide rather than deep
Deep rather than wide
6
Engineering process
Engineering Lead Time
Marketing Requirements
Develop an Overall Model
Build Feature List
Plan By Feature
Design By Feature
Build By Feature
Test By Feature
Finished Code
Weekly Integration Build
Bug Reports
7
Practices in FDD

• Frequent, Tangible, Working Results
• A context for best practices
• Domain object modeling
• UI Flow Modeling
• (Statecharts or Visual Vocabulary)
• Feature teams
• Chief Programmer Work Packages
• Regular design and code review (by Feature Team)
• Class (code) ownership
• Regular builds
• Configuration management (Promotion groups and
  Labeling)
• Visibility of results

8
Domain Modeling Drives FDD
9
Behavior of Colors
Courtesy Stephen R. Palmer

• Instances of Archetypes share similar attributes
• Instances of Archetypes share similar methods

10
Definition of a Feature

• Tiny piece of client-valued functionality which
  can be delivered in less than 2 man weeks,
  typically 2 days
• 4 types of Features
• UI User Interface
• PD (Problem Domain / Business Logic)
• SI (System Interface)
• DM (Data Management / Persistence)
• PD or SI Feature
• ltactiongt ltresultgt oftofromfor ltobjectgt
• E.g. calculate the interest for the bank a/c

11
FDD How it works
Individual Features
Feature Set
Subject Area
Feature Set
Feature Set
Feature Set
Feature List
Subject Area
Feature Set
Feature Set
Feature Set
Subject Area
Feature Set
Feature Set
A stockpile of inventory
12
Relating Features to the Model

• Feature
• A method on the domain model
• 1 UML Sequence Diagram per Feature
• Feature Set
• Related to a ltltmoment-intervalgtgt on the domain
  model
• All features in a set touch the same pink
• Subject Area
• Related to a chain of ltltmoment-intervalgtgts

13
Law of Demeter
A different view of the DNC showing the dynamic
dependencies between classes. Classes only hold
dependencies to their immediate neighbors The DNC
is very loosely coupled
14
LoD Compliant Sequence Diagram
15
Wrong not LoD Compliant
16
Postponed Component Definition
17
Re-usable Enterprise Components
Pinks and yellows are re-usable across multiple
greens the core Enterprise Components
Greens and blues are re-usable across discrete
Enterprise Applications modeled as sequences of
pinks
18
http//www.agilemanagement.net/Articles/Weblog/Arc
hitectureControlBoard.html
19
http//www.agilemanagement.net/Articles/Weblog/Arc
hitectureControlBoard.html
20
http//www.agilemanagement.net/Articles/Weblog/Arc
hitectureControlBoard.html
21
Modeling UI Flow (Statecharts)
Create 1 UI Feature for each state with
stereotype ltltViewgtgt, ltltDialoggtgt, ltltWizardgtgt
etc. Create 1 UI Feature for each distinct Event
(not transition) Maps directly to View and
Controller from MVC Type II pattern
22
Modeling UI Flow (Visual Vocabulary)
Jesse Garretts VV notation can be mapped to
Statecharts and MVC Type II pattrern Some Ux
people prefer VV as it was invented by a Ux person
23
Class (code) ownership

• Conceptual integrity of a class
• Consistent, concise class API
• Sense of satisfaction in ownership
• Scales better than collective ownership
• Combine with feature teams for best of both worlds

24
Feature teams

• Dynamically formed per feature
• Only practical way to develop by feature and have
  class ownership
• Under guidance of a Chief Programmer
• Multiple minds on design
• Compare multiple options and chose the best
• All owners of relevant code in team
• Benefits of collective ownership
• Emphasizes teamwork
• Nobody finished until the feature team is
  finished

25
(No Transcript)
26
Definition of a CPWP

• Chief Programmer Work Package
• A collection (or batch) of Features which can
  logically be grouped for development
  simultaneously, and can be delivered within 2
  weeks or less
• i.e. each Feature must be less than 2 weeks and
  each CPW must be less than 2 weeks

27
Reporting Progress

• FDD uses automated reporting
• Eliminates needs for annoying PMing
• Each Feature has 6 stages
• Requirement walkthrough, design, review, code
  unit test, review, promote to build
• Each stage tracked through artifacts in version
  control system
• Progress is reported on a website

28
Cumulative Flow Diagram
Lead Time
WIP
29
Achieving Smooth Flow
30
Ragged Flow
Productivity is conservatively only 1/5th of
previous project
31
Scope Creep Dark Matter
32
Configuration Management

• Version Control uses Promotion Groups
• Head of build labeled Dev
• Class owner work in progress
• Feature Team Area
• Shared client, exclusive lock checkout
• Class Ownership insures integrity
• Integration Build labeled Build
• From the promote to build step in DBF-BBF
• Chief Programmer or Dev manager relabels approved
  revision of each class to Build
• Integration Build (Nightly/Weekly) runs against
  the Build Label
• Promotion Groups and Class Ownership mean there
  is no need to branch merge for each Feature
  Team / Chief Programmer Work Package

33
Parking Lot Chart
Product Sale Management (PS)
CP-1
CP-1
CP-1
CP-3
CP-2
CP-1
Invoicing Sales (33)
Making Product Assessments (14)
Setting up Product Agreements (13)
Selling Products (22)
Shipping Products (19)
Delivering Products (10)
99
30
75
10
3
Dec 2001
Dec 2001
Dec 2001
Dec 2001
Nov 2001
Dec 2001
Customer A/C Mgmt (CA)
Inventory Mgmt (IM)
CP-2
CP-2
CP-2
CP-3
CP-3
CP-3
Logging Account Transactions (30)
Opening New Accounts (11)
Moving Content (19)
Accepting Movement Requests (18)
Evaluating Account Applications (23)
Establishing Storage Units (26)
95
82
100
100
82
97
Nov 2001
Oct 2001
Nov 2001
Nov 2001
Oct 2001
Nov 2001
34
Advanced Scheduling with Critical Chain

• Schedule Tasks based on Feature Set groupings
• Buffers aggregated across many Features
• UI Designer as system constraint

35
Multi-project Schedule

• Multi-project scheduling works equally well
• UI Designer as synchronizing constraint

36
Project Overview
37
Feature List
38
Subject Area
39
Feature Set
40
Chief Programmer Worksheet
41
Contact Details
David J. Anderson dja_at_agilemanagement.net http//w
ww.agilemanagement.net/