1. Extreme Programming and Systems Engineering Similarities and Synergy (based on talk given to INCOSE New England Chapter) Joseph (Yossi) Weihs Sept 10 th, 2004

2. 2 Abstract XP is one of the popular ‘Agile’ software development disciplines Systems engineers may have to deal with software teams practicing XP What should you look out for, and what can you exploit when working with an XP oriented team?

3. 3 Contents Overview – what is XP Overview – what is XP Why use XP Why use XP Overlap with SE Overlap with SE Key differences Key differences Integrated methods Integrated methods Summary / Take Home Summary / Take Home

4. 4 Agile Methods Formality - from lightweight to ‘heavy’: ScrumXP Crystal Orange DSDM

5. 5 Overview Extreme Programming is a software development methodology that originated about seven years ago Extreme Programming is a software development methodology that originated about seven years ago XP is winning recognition in large organizations XP is winning recognition in large organizations XP is bunched together with Lean development and Agile processes XP is bunched together with Lean development and Agile processes

6. 6 Must have a flow chart

7. 7 History of XP Started out as a one man’s quest Kent Beck Started out as a one man’s quest Kent Beck Defined four values in 1996: Defined four values in 1996: –Communication Communication –Simplicity Simplicity –Feedback Feedback –Courage Courage

8. 8 History of XP (continued) Since 1999 it has been publicly evangelized. Numerous publications have sprung up Since 1999 it has been publicly evangelized. Numerous publications have sprung up 2004 – XP is in use in many organizations, large and small 2004 – XP is in use in many organizations, large and small

9. 9 Why XP? The approach works best when: Project has numerous requirement changes Project has numerous requirement changes Project has numerous requirement changes Project has numerous requirement changes High risk development High risk development Applied to small (30<) teams Applied to small (30<) teams Testability is a requirement (V&V!) Testability is a requirement (V&V!) Use XP only with whole software team buy-in!

10. 10 XP Cost of Change Steve Hayes (steve@khatovartech.com)

11. 11 XP and Risk

12. 12 Core XP Principles Incremental change Incremental change Assume simplicity Assume simplicity Rapid feedback Rapid feedback Embracing the change Embracing the change Quality work Quality work

13. 13 Core XP Practices Broken down to four domains: Planning Designing Coding Testing

14. 14 Planning –User stories –Release planning / release plan –Make frequent small releases –Project velocity –Iterative development –Iteration planning –Move people around –Daily stand up meeting –Fix XP when it breaks

15. 15 Designing –Simplicity is the key –Choose a system metaphor –CRC cards –Spike solution –Never add functionality early –Re-factor mercilessly –YAGNI = You Ain’t Gonna Need It

16. 16 Coding –On site customer –Coding standard –Code unit then test –Pair programming –Sequential integration –Integrate often –Collective code ownership –Optimize last –40 hours a week

17. 17 Testing –Unit tests –When a bug is found… –Acceptance tests

18. 18 XP Life Cycle Exploration phase Exploration phase Planning phase Planning phase Iterations to release Iterations to release Productionizing Productionizing Death phase Death phase

19. 19 XP Team Members Programmers Programmers Customers Customers Testers Testers Trackers Trackers Coach Coach Consultants Consultants Manager Manager

20. 20 XP roles an SE plays Customer – the SE is requirements advocate and validation tester Customer – the SE is requirements advocate and validation tester Tracker – SE may act as project manager, including risk mitigation Tracker – SE may act as project manager, including risk mitigation Tester – SE may facilitate some tests Tester – SE may facilitate some tests Coach – SE’s as discipline leader Coach – SE’s as discipline leader Manager – SE as boss in large project Manager – SE as boss in large project

21. 21 XP & SE – Overlap XP Systems Engineering Planning Development plan, risk management Testing Validation & verification Coach Systems engineer Collective ownership System integration

22. 22 XP Iterations and SE XP: Assume customer does not have clear definition of system at any point SE: Maximize planning, scenario building risk assessment before starting work Collision? Sometimes, but SE can still manage process: trickle feed XP’rs requirements disguised as customer stories, according to SE requirement rankings

23. 23 XP Customer and SE XP: Customer Rep available at all times for iterations: Requirements, risks, priorities, validation SE: Customer signs off on SOW, gets briefed on progress and accepts product at milestones Collision? Sometimes – when working with XP teams, use their power throughout project initiation, and transition more structured disciplines as project matures

24. 24 Additional XP & SE issues XP’s short iterations and local focus fit concept exploration phase XP’s short iterations and local focus fit concept exploration phase XP is the least formalistic of the Agile methods : On-Site Customer XP is the least formalistic of the Agile methods : On-Site CustomerAgile methods Agile methods Pair Programming can cause cultural problems Pair Programming can cause cultural problems

25. 25 Integrated Approaches Small XP teams within larger projects Small XP teams within larger projects Software – part heavyweight, part XP Software – part heavyweight, part XP Extreme / Agile Project Management Extreme / Agile Project Management Extreme applied to other engineering disciplines Extreme applied to other engineering disciplines

26. 26 Summary / Take Home Works well for smaller software projects / proof of concept Works well for smaller software projects / proof of concept Works with CMMI / UML (to a point) Works with CMMI / UML (to a point) No fixed cookbook – tailor it to your project No fixed cookbook – tailor it to your project Spill over to project management and general engineering management Spill over to project management and general engineering management

27. 27 References Extreme Programming Explained, Kent Beck, Addison Wesley 1999 Extreme Programming Explained, Kent Beck, Addison Wesley 1999 Re-factoring: Improving the Design of Existing Code, Martin Fowler, Addison Wesley 1999 Re-factoring: Improving the Design of Existing Code, Martin Fowler, Addison Wesley 1999 Many web sites Many web sites

28. 28 Links http://www.extremeprogramming.org http://www.extremeprogramming.org http://www.extremeprogramming.org http://www.xp2001.org http://www.xp2001.org http://www.xp2001.org http://www.iturls.com/English/SoftwareEngineering /xpm_apm.asp http://www.iturls.com/English/SoftwareEngineering /xpm_apm.asp http://www.iturls.com/English/SoftwareEngineering /xpm_apm.asp http://www.iturls.com/English/SoftwareEngineering /xpm_apm.asp http://www.balagan.org.uk/work/ http://www.balagan.org.uk/work/ http://www.balagan.org.uk/work/ http://collaboration.csc.ncsu.edu/laurie/Papers/XPS ardinia.PDF http://collaboration.csc.ncsu.edu/laurie/Papers/XPS ardinia.PDF http://collaboration.csc.ncsu.edu/laurie/Papers/XPS ardinia.PDF http://collaboration.csc.ncsu.edu/laurie/Papers/XPS ardinia.PDF http://www.xprogramming.com/ http://www.xprogramming.com/ http://www.xprogramming.com/ http://www.dsmweb.org/ http://www.dsmweb.org/ http://www.dsmweb.org/ http://www.martinfowler.com/articles/newMethodol ogy.html http://www.martinfowler.com/articles/newMethodol ogy.html http://www.martinfowler.com/articles/newMethodol ogy.html http://www.martinfowler.com/articles/newMethodol ogy.html

29. 29 Extra Slides

30. 30 XP - The Four Core Values Communication. Communication. Simplicity. Simplicity. Feedback. Feedback. Courage. Courage.

31. 31 Communication Often problem that arise in SW project can be tracked back to lack of communication. Often problem that arise in SW project can be tracked back to lack of communication. XP enforces the Communication Value by employing many practice that could not be carried without communicating (e.g. pair programming, unit testing etc.). XP enforces the Communication Value by employing many practice that could not be carried without communicating (e.g. pair programming, unit testing etc.). XP employs a Coach whose job is that of noticing when people are not communicating and reintroduce them. XP employs a Coach whose job is that of noticing when people are not communicating and reintroduce them.

32. 32 Simplicity XP embrace the principle of “Make it Simple” XP embrace the principle of “Make it Simple” XP is betting that it is better to do a simple thing today and pay a little more tomorrow to change it, if it needs to be changed, than building a more complicate system that has feature that will never be used. XP is betting that it is better to do a simple thing today and pay a little more tomorrow to change it, if it needs to be changed, than building a more complicate system that has feature that will never be used. Simplicity and Communication support each other mutually. Simplicity and Communication support each other mutually.

33. 33 Feedback Feedback works in XP at different time scales. Feedback works in XP at different time scales. Programmers have feedback on a minutes time scale on the status of the system thanks to unit tests. Programmers have feedback on a minutes time scale on the status of the system thanks to unit tests. When customers write new stories the programmers estimate those immediately to give prompt feedback to the customer about the quality of the stories. When customers write new stories the programmers estimate those immediately to give prompt feedback to the customer about the quality of the stories. The customer review the scheduler every 2- 3 weeks and provide prompt feedback to the developer. The customer review the scheduler every 2- 3 weeks and provide prompt feedback to the developer.

34. 34 Courage XP team should have the courage of throwing code away. XP team should have the courage of throwing code away. XP team should have the courage of mainly refactor the architecture of the system, if architectural flaw are detected. XP team should have the courage of mainly refactor the architecture of the system, if architectural flaw are detected. Courage has in XP the same role that mutation has in genetic algorithms. Takes you out of local maximum/minimum. Courage has in XP the same role that mutation has in genetic algorithms. Takes you out of local maximum/minimum.