Feature Driven Development

1. Feature Driven Development For the agile agent of change Justin-Josef Angel www.JustinAngel.Net blogs.Microsoft.co.il/blogs/JustinAngel

2. Stress Your Comfort Zone Change Change Stress

3. Feature Driven Development For the agile agent of change Justin-Josef Angel www.JustinAngel.Net blogs.Microsoft.co.il/blogs/JustinAngel

4. Who here has caused change? • Deployed an application? • Upgraded technology? • Switched IDEs? • Told someone you loved them? • People resist to change. • People don’t want change. • Change = Bad.

5. Agile = Change = Bad • Agile methodologies require us to work differently. • What about other people? • PROBLEM • But first, What are you going to get from this presentation? • and what is “Agile”?

6. What Is Agile? Analysis - Requirements Design Implement - Code Test Deploy • Agile is the solution to a problem. • The traditional Waterfall model:

7. Waterfall has a problem • “building model” • jumping from the side of a building. • If you fall from the top – it’s really going to hart when you reach the bottom. • Projects FAIL! Analysis Design Implement Test Deploy

8. Example of the problem • “Transfer X amount of money from one account to the other and take 10% commission”. • Who are we taking the commission from? • Israeli Banks – From the sender. • Paypal – from the receiver.

9. Simplest Solution – Short Iterations Analysis - Requirements Design Implement - Code Test Deploy • Take the waterfall model – and add one arrow.

10. What is Agile and is it the solution? • Agile is adding that arrow. • Short Iterations – Process • (Contentious integration – Practice) • Agile is a family of Software development process methodologies. Big words  • Agile Manifesto.

11. So, Who’s in the family? • Feature Driven development • eXtreme Programming (XP) (which is the most common) • Scrum • DSDM • Crystal Clear • Agile RUP – AUP • ASD • …

12. When do we use XP? Critical Amount ofpeople Very Low Novice 100 Senior 10 500+ Often QualityOf people Rarely Requirements Change

13. When do we use XP? • Senior & experienced developers • Small number of developers • Low critically • High Requirements change

14. XP Critics say… • requires too much cultural change to adopt • insufficient structure and necessary documentation • only works with senior-level developers • can lead to more difficult contractual negotiations - wikipedia, “Agile software development”

15. XP Is not enough for some • Team size < 10 • Very experienced developers • Low critically • Very big changes • Process Buy-in is a must • There is no golden hammer

16. Common Agile problems & Solutions • Non-experienced developers  More process • High critically  More upfront design • Big teams  More role definitions • Change is not an option Less Change, More adapting • MORE

17. Feature Driven Development • Feature Driven Development (FDD) can be implemented with: • up to 500 developers • More critical projects • Bigger projects • More novice developers • Environments that demand Waterfall • Every methodology has: • Process • Best Practices

18. The Three Faces of FDD • Waterfall • Extremely Agile • myFDD • The boss doesn’t have to know we’re Agile. • The developers don’t need to know they’re Agile. • No change = Good.

19. The FDD Process Analysis Design Implement Design Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy

20. Develop Model • Roles we need to assign: • Chief Architect • Chief Developers • Domain Experts (Billy-bob-joe) • Create Modeling Team: Roles mentioned above & rotating developers. • Domain Walkthrough: Domain Experts tell us everything they know. • Study Documents

21. COWS!!! • Billy-bob-joe is a southern cattle-rancher and he needs a system to manage his farm. • The system should manage: • Existing cattle • Breeding • Slaughtering & selling meat • Selling cattle • This is our problem domain.

22. Develop Model - example 4. Create Model in groups of three people. How about this one?

23. Develop Model – Straw man • What did you think of that Model? • This was intentionally a “weak” Model the chief architect created. • “Straw-man” Model • The groups of three people “captured” my Model and while doing so improved it and exposed it’s weak points.

24. Develop Model – Three Faces • Alternative Models as notes. • Model Driven Architecture. • Develop Model as Waterfall – 98%-100% complete Model. • Develop Model as extremely Agile – 60%. • myFDD should be about 70%-80%.

25. The FDD Process Analysis Design Implement Design Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy

26. Build Feature List • Do one thing – Build a Feature List. • A FDD “Feature” is a small client valued feature. • Small • Client • Valued • Feature • Feature - <action> <result> <object> • Feature Set – <action>ing <object> • Major Feature Set – <object> Management

27. Build Feature List - Example • Feature - <action> <result> <object> • Feature Set – <action>ing <object> • Major Feature Set – <object> Management Herd Management Birthing cattle • Add a new baby Cattle To Herd • Mark Mom not pregnant for Cattle Slaughter Management Slaughtering Cattle • Calculate Price For Cattle • Add meat to Meat Storage • Remove Dead cow from herd.

28. Build Feature List – Feature & Model • Feature  Model • Add a new baby Cattle To Herd  Herd.AddNewBabyCattle(Cattle) • Mark Mom not pregnant for Cattle  Cattle.MarkMomAsNotPregnant • Calculate Price For Cattle  Cattle.CalculatePrice • Add meat to Meat Storage  MeatStorage.AddMeat(Meat)

29. Build Feature List - Reports • Features are reportable! • Client is always informed. • Management also has access  Herd Management 100% (14) Yaniv Roy John 33%(3) 0%(19) Birthing Cattle Adding Cattle Removing Cattle

30. Build Feature List – Summery • Features are small & client valued. • Feature list is very short. • Reportable. • Testable. • Feature sets are Assignable. • Feature sets  iterations. • Iterations can be planned.

31. Build Feature List – Three faces • Features as waterfall – write up 95%-100% of the features and sign as contract. • Features as Extremely agile – 70-80%. • myFDD – 80%-90%

32. The FDD Process Analysis Design Implement Design Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy

33. Feature Sets into iterations • Determine Development Sequence • Check Dependencies (cow before cows) • Consider High-risk feature • Consider High complexity features • Either by Date or by Sequence. • Assign Project Manager • Assign Chief developers to feature sets • Assign developers as Class Owners

34. Plan By Feature - Example Justin  “Meat Storage” Class Owner Miki  “Cow” Class Owner Oren  “Herd” Class Owner Roy  “Slaughtering Cattle” Chief Developer Yaniv  “Birthing Cattle” Chief Developer Feature Sets into Iterations: • Adding Cattle, Removing Cattle • Birthing Cattle, Killing Cattle • Storing Meat, Selling Cattle • Slaughtering Cattle, Selling Meat

35. Plan by feature • Planning like waterfall – Set dates for the completion & start date, hours to work and for each feature set. • Planning extremely Agile – determine the order of Feature sets. • Planning myFDD – determine completion months for feature sets. • Anyway – group Feature Sets into Iterations.

36. The FDD Process Analysis Design Implement Design Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy

37. Design By Feature • This is the first part of short iteration. • We know which feature sets we need to build. • Now it’s time to design the software we will build.

38. Design By Feature • Determine which Class Owners are needed for this Feature Set. They are our “Feature Team”. • Have the domain expert tell us everything he knows about this Feature Set and review any additional data sources. • Use UML (if you feel it’s needed).

39. Design By Feature • Make changes to the project Model. • Design Inspection.

40. Design By Feature – Feature Teams • In the “Plan by feature” phase we assigned Classes to Developers. • Now, We need to get all Class owners relating to our feature set. Slaughter Management Slaughtering Cattle • Calculate Price For Cattle  Cattle • Add meat to Meat Storage  MeatStorage • Remove Dead cow from herd.  Herd

41. Design By Feature – Feature Teams Slaughtering Cattle Feature Team Slaughtering Cattle Class Owners MeatStorage Herd Cow Chief Developer

42. Design By Feature – Feature Teams Herd Management Birthing cattle • Add a new baby Cattle To Herd  Herd • Mark Mom not pregnant for Cattle  Cow

43. Design By Feature – Feature Teams Slaughtering Cattle Feature Team Slaughtering Cattle Class Owners MeatStorage Herd Cow Chief Developer I’m a domain Expert Birthing cattle Chief Developer Birthing cattle Feature Team

44. Design By Feature – Feature Teams

45. Design By Feature – Three Faces • Waterfall – Design Everything upfront. • extremely Agile – Change only the interface we expose, the rest will come together when we code. • myFDD – Do everything besides UI.

46. The FDD Process Analysis Design Implement Design Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy

47. Build By Feature • Create a Branch in the Source Control for the Feature team to work on. • Code Feature Set. • Test Feature Set. • Code Inspection. • Promote to build (Integration). • Deploy

48. The FDD Process Analysis Design Implement Design Develop Model Build Feature List Plan By Feature Design by Feature Build By Feature Deploy

49. FDD Best practices • Countenious Integration. • Domain Object Modeling. • Developing By Feature. • Individual Class ownership. • Feature Teams. • Source Control. • Reporting/Visibility of results.

50. More about the topic… • Jeff De-Luca’s offical site: www.nebulon.com Read the FDD process description. • FDD Community & Articles www.featuredrivendevelopment.com • “Practical Guide to Feature Driven Development”