Feature Driven Development David J Anderson PM Microsoft

Feature Driven Development David J. Anderson PM Microsoft Solutions Framework http: //www. agilemanagement. net

Singapore Story Peter Coad The Coad Method Frequent, Tangible, Working. On-time, Results on-budget with agreed stfunction De Luca’s 1 Law 80% Psychology, 20% Technology Jeff De Luca http: //www. agilemanagement. net/

FDD in the Agile Community Jon Kern, Director of Consulting at Togethersoft stands in for Peter Coad at Snowbird, Feb 2001 Kent Beck James Grenning Mike Beedle Jim Highsmith Arie van Bennekum Andrew Hunt Alistair Cockburn Ron Jeffries Ward Cunningham Jon Kern Martin Fowler Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas http: //www. agilemanagement. net/

FDD is Powerful Feature Driven Development (FDD) • • • Highly Effective High Quality Faster To Market Team working No Overtime Productivity – 2 to 10 fold improvement • Quality improvement But… • • No Time Tracking No Gantt Charts No Task Tracking No Time on Task Estimates Scary!!! – 3: 1 to 2: 100 http: //www. agilemanagement. net/

FDD – an agile methodology Marketing participates MRD input Carefully Analyze MRD Prioritize and plan Code development Build code in small batches 1. Develop an Overall Model 2. Build a Feature List 3. Plan By Feature 4. Design By Feature Wide rather than deep 5. Build By Feature Deep rather than wide http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

Domain Modeling Drives FDD “Java Modeling in Color : Enterprise Components and Process”, Coad, Lefebvre and De Luca, PTR-PH 1999 http: //www. agilemanagement. net/

Behavior of Colors total. Value() is. Complete() is. Urgent() assess. Performance()_find. By. Id. Number() sales. Made. In. Period()_find. By. Name() average. Sales. Over. Perio is. Of. Type() d() get. Value() assess. Accuray() assess. Across. Roles() assess. Speed() list. Roles. Played. By() is. Active() is. Suspended() Courtesy Stephen R. Palmer total. Units. Available() total. Units. Manufactured () assess. Role. Allowed() • Instances of Archetypes share similar attributes • Instances of Archetypes share similar methods http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

FDD – How it works Feature Set Subject Area Feature List Feature Set Individual Features Feature Set Subject Area Feature Set A stockpile of inventory http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

Lo. D Compliant Sequence Diagram http: //www. agilemanagement. net/

Wrong – not Lo. D Compliant http: //www. agilemanagement. net/

Postponed Component Definition http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/ of pinks

http: //www. agilemanagement. net/Articles/Weblog/Architecture. Control. Board. html http: //www. agilemanagement. net/

http: //www. agilemanagement. net/Articles/Weblog/Architecture. Control. Board. html http: //www. agilemanagement. net/

http: //www. agilemanagement. net/Articles/Weblog/Architecture. Control. Board. html http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

Cumulative Flow Diagram Lead Time WIP http: //www. agilemanagement. net/

Achieving Smooth Flow http: //www. agilemanagement. net/

Ragged Flow Productivity is conservatively only 1/5 th of previous project http: //www. agilemanagement. net/

Scope Creep & Dark Matter http: //www. agilemanagement. net/

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 http: //www. agilemanagement. net/

Parking Lot Chart Product Sale Management (PS) CP-1 CP-3 CP-1 Selling Products Shipping Products Delivering Products Invoicing Sales (22) (19) (10) (33) 99% 10% 3% Nov 2001 Dec 2001 CP-2 Setting up Product Agreements (13) CP-2 Dec 2001 Inventory Mgmt (IM) CP-2 CP-3 Opening New Accounts (11) Logging Account Transactions (30) Establishing Storage Units (26) Accepting Movement Requests (18) 95% 100% 82% 100% 97% Oct 2001 Nov 2001 Work In Progress Nov 2001 Attention Completed CP-3 Evaluating Account Applications (23) KEY: Making Product Assessments (14) 75% Customer A/C Mgmt (CA) CP-2 CP-1 Progress Bar Moving Content (19) 82% Nov 2001 Not Started http: //www. agilemanagement. net/

Advanced Scheduling with Critical Chain • Schedule Tasks based on Feature Set groupings • Buffers aggregated across many Features • UI Designer as system constraint http: //www. agilemanagement. net/

Multi-project Schedule • Multi-project scheduling works equally well • UI Designer as synchronizing constraint http: //www. agilemanagement. net/

Project Overview http: //www. agilemanagement. net/

Feature List http: //www. agilemanagement. net/

Subject Area http: //www. agilemanagement. net/

Feature Set http: //www. agilemanagement. net/

Chief Programmer Worksheet http: //www. agilemanagement. net/

Contact Details David J. Anderson dja@agilemanagement. net http: //www. agilemanagement. net/