David J. Anderson PM Microsoft Solutions Framework Feature Driven Development

Singapore Story Peter Coad Jeff De Luca The Coad Method Frequent, Tangible, Working Results On-time, on-budget with agreed function De Luca’s 1 st Law 80% Psychology, 20% Technology

FDD in the Agile Community Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Jon Kern, Director of Consulting at 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 a Feature List 3.Plan By Feature 4.Design By Feature 5.Build By Feature Wide rather than deep Marketing participates MRD input Carefully Analyze MRD Prioritize and plan Code development Build code in small batches Deep rather than wide

Engineering process Develop an Overall Model Build Feature List Plan By Feature Design By Feature Build By Feature Marketing Requirements Finished Code Test By Feature Weekly Integration 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() averageSalesOverPerio d() assessAccuray() assessSpeed() isActive() isSuspended() totalValue() isComplete() isUrgent() _findByIdNumber() _findByName() isOfType() getValue() assessAcrossRoles() listRolesPlayedBy() totalUnitsAvailable() totalUnitsManufacture d() 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 – [of|to|from|for] –E.g. calculate the interest for the bank a/c

FDD – How it works Feature List Subject Area Feature Set Individual Features A stockpile of inventory Subject Area Subject Area

Relating Features to the Model Feature –A method on the domain model –1 UML Sequence Diagram per Feature Feature Set –Related to a > on the domain model –All features in a set touch the same pink Subject Area –Related to a chain of >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

Modeling UI Flow (Statecharts) Create 1 UI Feature for each state with stereotype >, >, > 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 pattrern Some 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 WIP Lead Time

Achieving Smooth Flow

Ragged Flow Productivity is conservatively only 1/5 th 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) Invoicing Sales (33) Dec 2001 CP-1 Setting up Product Agreements (13) Dec 2001 Selling Products (22) Nov 2001 CP-1 Shipping Products (19) Dec 2001 CP-1 10% Delivering Products (10) Dec 2001 CP-3 30% Making Product Assessments (14) Dec % 99% 3% Customer A/C Mgmt (CA) Evaluating Account Applications (23) Oct % Logging Account Transactions (30) Nov % Opening New Accounts (11) Oct % Inventory Mgmt (IM) Establishing Storage Units (26) Nov % Moving Content (19) Nov % CP-3 Accepting Movement Requests (18) Nov % CP-3 KEY:Work In Progress Attention Completed Progress Bar Not Started CP-2CP-1 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

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

Project Overview

Feature List

Subject Area

Feature Set

Chief Programmer Worksheet

Contact Details David J. Anderson