Feature Driven Development Reid S. Carlberg SE470

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis References

Abstract Feature Driven Development focuses on regular delivery of client-valued features More structure than XP and fewer requirements than RUP—a middle ground Embraces software development as a human activity, subject to human limitations and benefiting from human strengths

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis References

The Players Jeff De Luca, principle, Nebulon Pty. Ltd. (Australia) Peter Coad, TogetherSoft Corporation (now Borland)

Genesis: Singapore, A large bank had a failed software project 2 years of work 3,500 pages of use cases complex object model no functioning code concluded it couldn’t be done

Genesis: Singapore, De Luca comes in, hires Coad delivered 2000 functioning features took 15 months with 50 programmers came in under budget all this an “un-doable project” !

How? De Luca brought a methodology used for 20 years Coad brought his ideas about features. FDD was born. First published in 1999, Java Modeling in Color with UML

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis References

Description: Primary Components Core values Six roles Five processes Project tracking methodology

Description: Primary Components Core values Six roles Five processes Project tracking methodology

“Process pride” focuses on the process rather than tangible results Core Values Process Pride

Core Values A system for building systems is necessary Simple is better Process steps should be obviously valuable to each team member Good processes move to the background

Description: Primary Components Core values Six roles Five processes Project tracking methodology

Six Roles Every publication on FDD emphasizes people People’s strengths and weaknesses have a huge impact on any project’s outcome Surprisingly: how to attract, recognize, motivate and keep good people

Six Roles Project Manager Chief Architect Development Manager Chief Programmers Class Owners (aka Developers) Domain Experts

Six Roles: Project Manager Administrative lead for the project budget, headcount, progress reports Operates project system e.g. TogetherSoft Control Center Shields participants from external distractions

Six Roles: Chief Architect Responsible for the overall design of the system Runs design workshops (more on that in process) Steers project through technical obstacles.

Six Roles: Development Manager Leads day to day development activities Resolves resource conflicts Often combined with either the PM or CA

Six Roles: Chief Programmers Experienced developers Leads smaller teams of individual developers Key role: needs to be respected by both developers and managers.

Six Roles: Class Owners Individual developers Design, code, test and document features

Six Roles: Domain Experts Users, clients, sponsors, etc. Knowledge base for developers

Six Roles: OK—More than six! Supporting Roles Domain manager Release manager Language guru Build engineer Toolsmith System administrator Sometimes Helpful Testers Deployers Technical writers

Description: Primary Components Core values Six roles Five processes Project tracking methodology

Five Processes Per projectPer feature

1. Develop an overall model Who? domain experts, chief architect, chief programmers

1. Develop an overall model Establishes the shape of the system Defines classes, how classes related to each other Creates the base object model Includes internal and external reviews, model notes

1. Develop an overall model

2. Build a features list Who? Feature List Team: domain experts, chief programmers, chief architect (inspired by surgical teams)

2. Build a features list Functional decomposition of model developed in step 1 Subject area to business activity to business activity step Feature is a business activity step, customer centric not technology centric Nomenclature: “Generate an account number for the new customer”

2. Build a features list

3. Plan By Feature Who? The Planning Team: the project manager, the development manager, and chief programmers.

3. Plan By Feature

Group features into feature sets (one or more business activities) Prioritize based on customer need Establish completion dates (MM/YYYY)

3. Plan By Feature

4. Design by feature Who? The Feature Team: chief programmer, class owners

4. Design by feature Work package level—now based on the technical architecture Two weeks or less of work Fleshes out class and object design, create sequence diagrams as necessary Feature teams are very fluid Updates object model created in process #1.

4. Design by feature

5. Develop by feature Who? Class owners, chief programmers

5. Develop by feature Implement Code inspection Unit test Promote to build

5. Develop by feature

Primary Components Core values Six roles Five processes Project tracking methodology

Project Tracking Methodology Process 1’s 10% is the most significant. Other numbers are fungible.

Project Tracking Methodology walkthrough + design = 41% complete

Project Tracking Methodology

Project Tracking Methodology

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis References

Usage Guidelines: Use When… developers Handy pool of talented workers (above average)

Usage Guidelines: Avoid When… Team under 10 Team is still climbing the learning curve No support system

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis References

Market Position Coad joined TogetherSoft in employees (1999) to 266 employees (2000), 400 (today) 1/15/03: Borland purchases for $82.5m + 9m shares of stock

Market Position RUPFDDXP Scales To ??? developers 50 developers Tools Rational TogetherSoft (Borland) ??? Process HeavyMediumAgile Roles ~30~6 (9 optional) ~7 Artifacts 25-30Flexible ~10-15 ~30 (Thanks JN)

Market Position: FDD v XP FDD More hierarchical Class owners Success with above average developers Client works on 1,2,4 Process 1 “Live the life”! XP Peer to peer Collective ownership Success with average developers Client on the team Constant refactoring 40 hour weeks

Market Position: Notes TogetherSoft/Borland now sells TogetherSoft as a process agnostic development tool. FDD’s list of artifacts, processes, etc., seems to be growing over time.

Feature Driven Development Abstract Historical background Description Usage guidelines Marketplace analysis References

( Palmer, Stephen and Fesling, John, A Practical Guide to Feature Driven Development, Prentice-Hall, 2002 Highsmith, Jim, Agile Software Development Ecosystems, Addison-Wesley, 2003 Coad, De Luca and Lefebvre, Eric, Java Modeling In Color with UML, Prentice-Hall, 1999