Extreme Programming Modified : Embrace Requirements Engineering Practices

1. IEEE Joint International Conference on Requirements Engineering 9-13 September 2002, Essen, Germany Extreme Programming Modified:Embrace Requirements Engineering Practices J. Nawrocki, M. Jasinski, B. Walter, A.Wojciechowski Poznan University of Technology, Poznan, Poland

2. Extreme Programming (XP) = a lightweight (agile) software development methodology Tom DeMarco Introduction "XP is the most important movement in our field today."

3. Introduction • Interesting practices of XP: • strong customer orientation • increments & short releases • test-first coding • planning game etc.

4. Introduction • Weaknesses of XP: • lack of documentation • one (on-site) customer • too short planning perspective How to solve those problems and preserve agility?

5. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

6. I’ve changed my mind. Let’s go that way. Documen -tation Documen -tation Developer Customer Reconciling XP with documentation Travel light.

7. I’ve changed my mind. No problem. code + tests Customer Reconciling XP with documentation Travel light. What you need is just code and test cases. IEEE Standard 830 UML

8. Error Reconciling XP with documentation Travel light. What you need is just code and test cases. Oral communication is preferred as „the written and e-mail communications (..) are error-prone”. But people sometimes forget! Why did I decide to ..

9. I’ve changed my mind. No problem. Documen -tation Customer Reconciling XP with documentation To be agile does not mean that you have to throw away the (requirements) documentation.

10. I’ve changed my mind. No problem. Documen -tation Developer Customer Reconciling XP with documentation To be agile does not mean that you have to throw away the (requirements) documentation.

11. Reconciling XP with documentation To be agile does not mean that you have to throw away the requirements documentation. In XP tester „is responsible for helping the customer choose and write functional tests”. -- Kent Beck • XP roles: • Customer • Developer • Coach • Tracker • Tester Tester-analyst (product manager) is responsible for writing and managing usage scenarios, requirements, and acceptance tests. Tools: Rational RequisitePro, Rational Robot, xUnit

12. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

13. Weaknesses of XP One on-site customer If there are many it is assumed they speak one voice. Sometimes they don’t. We need a new car. No! We need a new furniture.

14. Original Planning Game Development Customer Customer 6 h More colors 9 h More func. 9 hours More colors More colors Writes user stories Chooses scope Effort, risk, velocity Multiple customer representatives

15. Modified Planning Game Development Customers Customers 6 h 9 h More colors More func. More colors 9 hours More colors More colors They write user stories Effort, risk, velocity How to choose the scope? Multiple customer representatives

16. Modified Planning Game Big boss Customers Multiple customer representatives 20 hours for you .. Customers 6 h 9 h More func. More colors How to choose the scope?

17. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

18. Technical risk Utility A spike solution Modifying the XP Lifecycle Design for today, not for tomorrow. Short planning perspective (one release) One release is sometimes not enough.

19. Modifying the XP Lifecycle Design for today, not for tomorrow. Short planning perspective (one release) One release is sometimes not enough. Technical risk Utility

20. Modifying the XP Lifecycle 0. Initial Project Statement (subject, stakeholders etc.) 1. Usage scenarios (problems + visions) 2. Requirements specification 3. Project presentation & selection of developers 4. Project planning (and risk exploration) 5. Release 1 (2 iterations, each takes 3 weeks) 6. Release 2 (2 iterations)

21. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

22. Quality Manager and Facilitator 5th year Project Manager and Analyst 4th year Designing, coding, testing, writing documentation 3rd year Software Development Studio – A team structure

23. Experiment at PUT Software Development Studio 2000/01 CMM Level 2 eXtremme Programming

24. Experiment at PUT Software Development Studio 2001/02 Modified eXtremme Programming

25. Score: 3 – obligatory 2 – frequently used 1 – sometimes 0 – never Initial < 55 Basic Sommerville-Sawyer Model RE Practices • Interm. • ... • ... • Advanced • ... • ... • Basic • ... • ... Defined > 85 Basic & > 40 Interm.+Adv. Repeatable > 55 Basic

26. Score: 3 – obligatory 2 – frequently used 1 – sometimes 0 – never Initial < 55 Basic Sommerville-Sawyer Model Defined > 85 Basic & > 40 Interm.+Adv. Repeatable > 55 Basic

27. Summary At last! • Tester-analyst is responsible for documenting and managing requirements. • Modified Planning Game tries to solve conflicts between multiple customers. • Modified life-cycle emphasises requirements engineering and risk management. • There is a need for user training. • Early results are promising.

28. Questions? ?