1. Feature Driven Development Reid S. Carlberg SE470 http://www.fivesticks.com/info/fdd

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

3. 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

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

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

6. Genesis: Singapore, 1997-98 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

7. Genesis: Singapore, 1997-98 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” !

8. 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

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

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

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

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

13. 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

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

15. 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

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

17. 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

18. 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.

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

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

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

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

23. 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

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

25. Five Processes Per projectPer feature

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

27. 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

28. 1. Develop an overall model

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

31. 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”

32. 2. Build a features list

33. http://www.nebulon.com/articles/fdd/DevView.html

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

35. 3. Plan By Feature

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

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

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

39. 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.

40. 4. Design by feature

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

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

43. 5. Develop by feature

44. Primary Components Core values Six roles Five processes Project tracking methodology

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

46. Project Tracking Methodology walkthrough + design = 41% complete

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

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

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

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

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

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

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

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

55. 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

56. 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.

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

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