Extreme Programming and Systems Engineering Similarities and Synergy

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

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. Contents • Overview – what is XP • Why use XP • Overlap with SE • Key differences • Integrated methods • Summary / Take Home

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

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

6. Must have a flow chart

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

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

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

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

11. XP and Risk

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

13. Core XP Practices Broken down to four domains:

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. 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. 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. Testing • Unit tests • When a bug is found… • Acceptance tests

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

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

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

21. XP & SE – Overlap

22. XP Iterations and SE Collision? Sometimes, but SE can still manage process: trickle feed XP’rs requirements disguised as customer stories, according to SE requirement rankings

23. XP Customer and SE Collision? Sometimes – when working with XP teams, use their power throughout project initiation, and transition more structured disciplines as project matures

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

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

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

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

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

29. Extra Slides

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

31. 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 employs a Coach whose job is that of noticing when people are not communicating and reintroduce them.

32. Simplicity • 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. • Simplicity and Communication support each other mutually.

33. Feedback • 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. • 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.

34. Courage • 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. • Courage has in XP the same role that mutation has in genetic algorithms. Takes you out of local maximum/minimum.