David J. Anderson PM Microsoft Solutions Framework Feature Driven Development

David J. AndersonPM Microsoft Solutions

Frameworkhttp://

www.agilemanagement.net

Feature DrivenFeature DrivenDevelopmentDevelopment

http://www.agilemanagement.net/

Singapore Story

Peter Coad

Jeff De Luca

The Coad MethodFrequent,Tangible,

Working ResultsOn-time, on-budget with agreed functionDe Luca’s 1st Law

80% Psychology, 20% Technology


FDD in the Agile Community

Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler

James GrenningJim HighsmithAndrew HuntRon JeffriesJon KernBrian Marick

Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas

Jon Kern,Director of Consultingat Togethersoft stands

in for Peter Coad at Snowbird, Feb 2001


FDD is Powerful

• Highly Effective• High Quality• Faster To Market• Team working• No Overtime• Productivity

– 2 to 10 fold improvement

• Quality improvement– 3:1 to 2:100

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

Feature Driven Development (FDD)But…

Scary!!!


FDD – an agile methodology

1.Develop an

Overall Model

2.Build aFeature

List

3.PlanBy

Feature

4.DesignBy

Feature

5.BuildBy

Feature

Wide rather than deep

MarketingparticipatesMRD input

CarefullyAnalyze

MRD

Prioritize and planCode development

Build code in small batches

Deep rather than wide


Engineering process

Develop an

Overall Model

BuildFeature

List

PlanBy

Feature

DesignBy

Feature

BuildBy

Feature

MarketingRequirements

FinishedCode

TestBy

Feature

WeeklyIntegration

Build

Bug Reports

Engineering Lead Time


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


“Java Modeling in Color : Enterprise Components and Process”,Coad, Lefebvre and De Luca, PTR-PH 1999

Domain Modeling Drives FDD


Behavior of Colors

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

assessPerformance()salesMadeInPeriod() averageSalesOverPeriod()assessAccuray()assessSpeed()isActive()isSuspended()

totalValue()isComplete()isUrgent()

_findByIdNumber()_findByName()

isOfType()getValue()assessAcrossRoles()listRolesPlayedBy()

totalUnitsAvailable()totalUnitsManufactured()assessRoleAllowed()

Courtesy Stephen R. Palmer


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– <action> <result> [of|to|from|for] <object>– E.g. calculate the interest for the bank a/c


FDD – How it works

FeatureList

SubjectArea

Feature Set

Feature Set

Feature Set

Feature Set

Feature Set

Feature Set

Feature Set

Feature Set

Feature Set

IndividualFeatures

A stockpile ofinventory

SubjectArea

SubjectArea


Relating Features to the Model

• Feature– A method on the domain model– 1 UML Sequence Diagram per Feature

• Feature Set– Related to a <<moment-interval>> on the

domain model– All features in a set touch the same pink

• Subject Area– Related to a chain of <<moment-

interval>>s


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


LoD Compliant Sequence Diagram


Wrong – not LoD Compliant


Postponed Component Definition


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

http://www.agilemanagement.net/http://www.agilemanagement.net/Articles/Weblog/ArchitectureControlBoard.html




Modeling UI Flow (Statecharts)Create 1 UI Feature for each

state with stereotype <<View>>, <<Dialog>>,

<<Wizard>> etc.Create 1 UI Feature for each distinct Event (not transition)

Maps directly to View and Controller from MVC Type II

pattern


Modeling UI Flow (Visual Vocabulary)

Jesse Garrett’s VV notation can be mapped to Statecharts and

MVC Type II pattrernSome Ux people prefer VV as it

was invented by a Ux person


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


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



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


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


Cumulative Flow Diagram

020406080

100120140160180200220

Time

Fea

ture

s

Inventory Started Designed

Coded Complete Linear (Coded)

WIP

Lead Time


Achieving Smooth FlowDevice Management Ike II Cumulative Flow

020406080

100120140160180200220240

10-F

eb

17-F

eb

24-F

eb

2-M

ar

9-M

ar

16-M

ar

23-M

ar

30-M

ar

Time

Fe

atu

res

Inventory Started Designed Coded Complete


Ragged FlowProject B Cumulative Flow

0

25

50

75

100

125

150

175

9-O

ct

23-O

ct

6-N

ov

20-N

ov

4-D

ec

18-D

ec

1-Ja

n

15-J

an

29-J

an

12-F

eb

26-F

eb

11-M

ar

Time

Fe

atu

res

Inventory Started Designed Coded Complete

Productivity is conservatively only1/5th of previous project


Scope Creep & Dark Matter


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


Product Sale Management (PS)

InvoicingSales

(33)

Dec 2001

CP-1

Setting upProduct

Agreements(13)

Dec 2001

SellingProducts

(22)

Nov 2001

CP-1

ShippingProducts

(19)

Dec 2001

CP-1

10%

DeliveringProducts

(10)

Dec 2001

CP-3

30%

MakingProduct

Assessments(14)

Dec 2001

75%99% 3%

Customer A/C Mgmt (CA)

EvaluatingAccount

Applications(23)

Oct 2001

95%

LoggingAccount

Transactions(30)

Nov 2001

82%

OpeningNew

Accounts(11)

Oct 2001

100%

Inventory Mgmt (IM)

EstablishingStorage Units

(26)

Nov 2001

100%

MovingContent

(19)

Nov 2001

82%

CP-3

AcceptingMovementRequests

(18)

Nov 2001

97%

CP-3

KEY: Work In Progress Attention Completed Progress Bar Not Started

CP-2 CP-1

CP-2 CP-2 CP-2 CP-3

Parking Lot Chart


Advanced Scheduling with Critical Chain

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

BusinessLogic 1

BusinessLogic 2

ApplicationUI 1

BusinessLogic 3

ApplicationUI 2

SystemInterface 1

ProductTest

Integration

Start End

Critical Chain with UI Design as the CCR

UI Designer

FeedingBuffer

UI Designer

ProjectBuffer


Multi-project Schedule

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

BusinessLogic 1

BusinessLogic 2

ApplicationUI 1

BusinessLogic 3

ApplicationUI 2

SystemInterface 1

ProductTest

Integration

Start Project 1 End Project 1

UI Designer

FeedingBuffer

UI Designer

ProjectBuffer

Start Project 2 End Project 2

CapBuf

BusinessLogic 1

BusinessLogic 2

ApplicationUI 1

BusinessLogic 3

ApplicationUI 2

SystemInterface 1

ProductTest

Integration

UI Designer

FeedingBuffer

UI Designer

ProjectBuffer


Project Overview


Feature List


Subject Area


Feature Set


Chief Programmer Worksheet


Contact Details

David J. [email protected]


Documents

David J. Anderson PM Microsoft Solutions Framework Feature Driven Development