Feature Driven Development l l l Outline Historical

Feature Driven Development l l l Outline Historical background Description Usage guidelines Marketplace analysis References

Abstract l l l 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 l Abstract l Historical background l l Description Usage guidelines Marketplace analysis References

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

Genesis: Singapore, 1997 -98 l l l 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, 1997 -98 l l l 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? l l 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 l Abstract Historical background l Description l l Usage guidelines Marketplace analysis References

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

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

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

Core Values l l 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 l Core values l Six roles l l Five processes Project tracking methodology

Six Roles l l l 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 l l l Project Manager Chief Architect Development Manager Chief Programmers Class Owners (aka Developers) Domain Experts

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

Six Roles: l l l 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: l l l Development Manager Leads day to day development activities Resolves resource conflicts Often combined with either the PM or CA

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

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

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

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

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

Five Processes Per project Per feature

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

1. Develop an overall model l l 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

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 l l l Functional decomposition of model developed in step 1 Subject area to business activity step Feature is a business activity step, customer centric not technology centric Nomenclature: <action> <result> <object> “Generate an account number for the new customer”

2. Build a features list

2. Build a features list http: //www. nebulon. com/articles/fdd/Dev. View. html

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

3. Plan By Feature

3. Plan By Feature l l l Group features into feature sets (one or more business activities) Prioritize based on customer need Establish completion dates (MM/YYYY)

3. Plan By Feature http: //www. nebulon. com/articles/fdd/planview. html

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

4. Design by feature l l l 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 l l Implement Code inspection Unit test Promote to build

5. Develop by feature

Primary Components l Core values Six roles Five processes l Project tracking methodology l l

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 http: //www. nebulon. com/articles/fdd/Summary. Tables. html

Project Tracking Methodology http: //www. nebulon. com/articles/fdd/linereport. html

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

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

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

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

Market Position l l l Coad joined Together. Soft in 1999 35 employees (1999) to 266 employees (2000), 400 (today) 1/15/03: Borland purchases for $82. 5 m + 9 m shares of stock

Market Position RUP FDD XP Scales To ? ? ? 10 -250 developers Tools Rational Together. Soft ? ? ? Process Heavy Medium Agile Roles ~30 ~6 (9 optional) ~7 Artifacts 25 -30 Flexible ~10 -15 ~30 (Borland) (Thanks JN)

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

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

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

References l l l l http: //www. fivesticks. com/info/fdd http: //www. featuredrivendevelopment. com http: //www. nebulon. com http: //www. togethersoft. com (http: //borland. com) 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