1. 1 eXtreme Programming מתודולוגיה לפיתוח פרויקטי תוכנה ד"ר אורית חזן המחלקה להוראת הטכנולוגיה והמדעים, הטכניון oritha@techunix.technion.ac.il

2. 2 eXtreme Programming מתודולוגיה לפיתוח פרוייקטי תוכנה What is eXtreme Programming Why eXtreme Programming?  Social analysis  Cognitive analysis

3. 3 eXtreme Programming מתודולוגיה לפיתוח פרוייקטי תוכנה על-סמך ניסיונכם עד היום בפיתוח תוכנה:  מהן הבעיות המרכזיות המאפיינות פרויקטי תוכנה?

4. 4 Google: "problems with software development”  Requirements are complex  Clients usually do not know all the requirements in advance  Requirements may be changing  Frequent changes are difficult to manage  Process bureaucracy (documents over development)  It takes longer  The result is not right the first time  It costs more  Applying the wrong process for the product Problems in software development

5. 5 בעיות מאפיינות של פרוייקטי תוכנה  הסיבוכיות האמיתית בפיתוח תוכנה מקורה בהיבט האנושי (ולא הטכנולוגי) לקוחות, לו"ז לחוץ ואי-עמידה בו, באגים, הבנה של תוכניות, תקשורת בין חברי צוות, אי-שיתוף מידע, אינטגרציה,...

6. 6 פרויקטי תוכנה: נתונים  75% ממוצרי התוכנה הגדולים הנשלחים ללקוחות נחשבים ככישלון: או שאינם בשימוש כלל או שאינם מתאימים לדרישות הלקוחות. Based on: Mullet, D. (July, 1999). The Software Crisis, Benchmarks Online - a monthlyThe Software Crisis publication of Academic Computing Services 2(7).  עלות תיקונם של באגים בתוכנה בארה"ב נאמדת בכל שנה ב- 59.5 ביליון $ The National Institute of Standards and Technology (NIST), New Release of June 28, 2002. לשם השוואה: ב- Q2 של 2003 הושקעו בארה"ב בתוכנה 200 ביליון $

7. 7 What is eXtreme Programming מה אתם יודעים על XP? (לא Windows XP)

8. 8 What is eXtreme Programming eXtreme Programming צמחה בתעשייה. Differences from traditional methodologies  Emphasis on people vs. development activities & schedule  XP specifies how to behave; still leaves freedom 12 practices 4 values: feedback, simplicity, communication, courage The meaning of ‘eXtreme’ Optimum: teams up to 12 developers; can be adjusted to bigger teams.

9. 9 Why XP? Survey:  31 XP/Agile-methods early adopter projects  14 firms  Findings: Cost reduction: 5-7% on average Time to market compression: 25-50% reduction  This datum will be explained later

10. 10 Why XP? big companies using XP in at least some capacity  Ford Motor, Chrysler, IBM, HPHP smaller software houses:  Mayford Technologies Mayford Technologies  RoleModel Software RoleModel Software tutorials: Industrial Logic, Object Mentor Industrial LogicObject Mentor

11. 11 Project Timetable : 1 release - 3 iterations (2 months - 9 weeks) Week 4, Release 1, Iteration 2 Week 3, Release 1, Iteration 1 Week 2, Release 1, Iteration 1 Week 1, Release 1, Iteration 1 Week 8, Release 1, Iteration 3 Week 7, Release 1, Iteration 3 Week 6, Release 1, Iteration 2 Week 5, Release 1, Iteration 2 Release 2 starts Week 9, Release 1, Iteration 3 Business Day

12. 12 How eXtreme Programming? Two days in eXtreme Programming Development Environment

13. 13 Business Day On-site customer Planning game Small releases Simple design Metaphor Source: http://www.rolemodelsoftware.com/

14. 14 Business Day – Reflection 5 practices (out of 12)  Planning game  On-site customer  Small releases  Simple design  Metaphor Planning game  All developers participate  All have the same load  All developers get an overview of the entire development process  Simple means  Very detailed  Levels of abstraction

15. 15 Business Day – Reflection 5 practices (out of 12)  Planning game  On-site customer  Small releases  Simple design  Metaphor On-site customer  Customer’s on-going feedback Small releases  On-going opportunity to update/change requirements

16. 16 Business Day – Reflection 5 practices (out of 12)  Planning game  On-site customer  Small releases  Simple design  Metaphor Simple design  Develop only what is needed for your development task Metaphor  Bridges customers- developers-business gaps

17. 17 Development Day Stand-up meeting The development environment Pair programming Test driven development (acceptance, unit-test) Code standards Refactoring Simple design Continuous integration (one integration machine) Collective ownership Sustainable pace (40-hour week) Source: http://www.rolemodelsoftware.com/

18. 18 Development Day - Reflection The development environment  All see all; fosters communication Stand-up meeting  All know what all do Pair programming  Each task is thought on two levels of abstraction Unit test (automatic test first)  First: improves understanding; Automatic: testing is easy  Developers program and test  Testing becomes manageable  Success vs. failure

19. 19 Development Day - Reflection Continuous integration  Reduces integration risks in later stages Collective ownership  Important in companies with high turnover Coding standards Refactoring and simple design  Code improvement is part of the methodology (though it doesn't produce code), gradual process Sustainable pace (40-hour week)  Intense and productive work, developers are not tired

20. 20 Development and Business Days – Reflection Human/Social Perspective Code/Technical Perspective Collective ownership Pair programming Sustainable pace On-site customer Planning game Metaphor Refactoring Simple design Coding standards Testing Continuous integration Small releases

21. 21 The 12 XP practices Note: nothing is new; gathering the practices together is XP uniqueness Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.

22. 22 What is eXtreme Programming Differences from traditional methodologies  All developers are involved with requirements-design-code-testing  Emphasis on people vs. development activities & schedule  XP specifies how to behave; still leaves freedom and place for creativity The meaning of ‘eXtreme’ 12 practices 4 values: feedback, simplicity, communication, courage

23. 23 What is eXtreme Programming Agile Software Development Methodology  Other agile methods: SCRUM, Feature Driven Development, DSDM  All acknowledge that the main issue of software development is people: customers, communication Manifesto for Agile Software Development: http://agilemanifesto.org/ http://agilemanifesto.org/ eXtreme Programming: Kent Beck, 1996, Chrysler

24. 24 Why XP? You do not do XP to save money; However, XP shortens time to market XP is a mature software development method

25. 25 Why XP? Survey:  31 XP/Agile-methods early adopter projects, 14 firms  Findings: Cost reduction: 5-7% on average Time to market compression: 25-50% reduction in time

26. 26 Why XP? – Analysis Shorter development period:  Code is easy-to-work with: less bugs: unit tests code is more readable & workable (invest now to gain benefits later):pair programming, refactoring, coding standards  Development is manageable and controlled: accurate estimation: small releases meets customer needs: customer on-site, planning game, acceptance tests

27. 27 Why XP? – Analysis Shorter development period (cont):  Knowledge sharing, if one leaves everything continues as usual: pair programming, collective ownership  Production is increased: pair programming (work all the time), sustainable pace  Cost for requirements change/update/elaboration is CONSTANT: simple design, planning game (redundant features are not added by customer and developers)

28. 28 Why XP? Barry W. Boehm (1981). Software Engineering Economics, Englewood Cliffs, N.J.: Prentice Hall.  63 software development projects in corporations such as IBM. Phase of requirement change Cost Ratio Requirements 1 Design 3-6 Coding 10 Development testing 15-40 Acceptance testing 30-70 Operation 40-1000

29. 29 Why XP? Under the assumption that “the later a requirements is introduced the more expensive it is”, customers (and developers) try to make a “complete” list of requirements. Under the assumption that “cost for introducing an update in the requirements is constant”, customers (and developers) do not assume what the customer will need and develop exactly and only what is needed.

30. 30 Why XP? You do not use XP to save money; However, XP shortens time to market XP is a mature software development method (at least CMM level 3)

31. 31 XP in Practice: Conceptual Changes XP encourages:  Cooperation (vs. knowledge-is-power)  Simplicity (vs. habit-of-high-complexity)  Change in work habits

32. 32 Why XP? – Cognitive and Social Analysis ניתוח XP מנקודת מבט קוגניטיבית וחברתית.  Game Theory: Prisoner’s Dilemma  Learning Theory: Constructivism

33. 33 Social analysis

34. 34 Game Theory ניתוח התנהגות וקבלת החלטות כאשר תוצאות הנובעות מהחלטות של כל אחד מהמשתתפים ב"משחק" תלויות בהחלטות של המשתתפים האחרים.

35. 35 The Prisoner’s Dilemma: A’s perspective B competes מלשין B cooperates לא מלשין -10 יש עדות מרשיעה רק ביחס ל- A, B משוחרר +5 אין עדות מרשיעה A cooperates לא מלשין 0 יש עדות מרשיעה, העונש מופחת בגלל ההלשנה +10 יש עדות מרשיעה רק ביחס ל- B, A משוחרר A competes מלשין

36. 36 The Prisoner’s Dilemma: The case of software engineering – A’s perspective, Bonus B competesB cooperates 20%50%A cooperates 0%80%A competes

37. 37 The Prisoner’s Dilemma: The case of software engineering – A’s perspective B competesB cooperates -10+5A cooperates -20 +10A competes

38. 38 The Prisoner’s Dilemma: The case of software engineering בד"כ מפתחי תוכנה מתבקשים לשתף פעולה עם עמיתיהם. למפתחי התוכנה אין אפשרות לוודא ששיתוף הפעולה שלהם יהיה הדדי. לפי דילמת האסיר: כל חברי הצוות יעדיפו לבגוד (לא לשתף פעולה). התנהגות כזו בפיתוח תוכנה מביאה לתוצאות הגרועות ביותר לכל חברי הצוות.

39. 39 The Prisoner’s Dilemma: The case of eXtreme Programming התחייבות חברי הצוות לעבוד על-פי XP מבטיחה שכל חברי הצוות יעבדו על-פי המיומנויות של XP. כל חבר(ת) צוות יודע(ת) שגם שאר חברי הצוות מחויבים לעבוד לפי אותן מיומנויות. גורם האי-וודאות (המהווה את המקור לדילמת האסיר) לא קיים. כולם ישתפו פעולה ויפיקו את הרווחים מכך.

40. 40 The Prisoner’s Dilemma: The case of Extreme Programming – A’s perspective B cooperates +5 A cooperates

41. 41 In what follows ביחס ל-2 ערכים ו- 4 מיומנויות של XP:  מהי המשמעות של שיתוף פעולה הנובעת מהם.  מהעובדה שכל הצוות מחויב לעבוד על-פי XP נובע שכל אחד ואחת מחברי הצוות אינם ניצבים בפני הדילמה האם לשתף פעולה (באותו מובן הנובע מהערך או המיומנות).  כל חברי הצוות משתפים פעולה ומרוויחים מהיתרון שנובע מאותו ערך או מיומנות.  כל פרויקט התוכנה נתרם משיתוף פעולה זה.

42. 42 The Prisoner’s Dilemma: The value of courage שיתוף פעולה:  כל חברי הצוות מתריעים כאשר יש בעיה.  כל חברי הצוות אינם מתביישים להודות כאשר חסר להם ידע.  כל חברי הצוות אינם חוששים לשנות קוד של עמיתיהם. מכיוון שסביבת הפיתוח היא XP, כל אחד(ת) יודע(ת) שהם לא היחידים שיפגינו courage ולכן הם לא עומדים בפני הדילמה האם לשתף פעולה. הפרויקט וחברי הצוות מרוויחים מערך זה.

43. 43 Kent Beck: Kent Beck explains when XP is not appropriate:  "[i]t's more the social or business environment. If your organization punishes honest communications and you start to communicate honestly, you'll be destroyed." An interview with Kent Beck, June 17, 2003, Working smarter, not harder, IBM website: http://www-106.ibm.com/developerworks/library/j-beck/ http://www-106.ibm.com/developerworks/library/j-beck/

44. 44 The Prisoner’s Dilemma: The value of simplicity שיתוף פעולה:  יישום כל הפעולות הקשורות בפיתוח התוכנה בצורה הפשוטה ביותר.  למשל, לא מסבכים קוד. כולם מחויבים לעבוד על-פיXP ולכן מחויבים גם לערך הזה. לא ניצבים בפני הדילמה האם לשתף פעולה. כולם משתפים פעולה וכולם מרוויחים.

45. 45 The Prisoner’s Dilemma: Collective Ownership In practice “[a]nyone can change any code anywhere in the system at any time.” (Beck, 2000).  שיתוף פעולה: שיתוף בקוד. בגידה: הסתרת קוד.  כולם עובדים על-פי XP ולכן גם על-פי מיומנות זו.  לא עומדים בפני הדילמה האם לשתף פעולה.  כולם משתפים פעולה, הדבר תורם לתהליכי פיתוח התוכנה וכולם יוצאים נשכרים.

46. 46 The Prisoner’s Dilemma: Coding Standards שיתוף פעולה: פיתוח לפי הסטנדרטים שנקבעו. בגידה: פיתוח לא על-פי הסטנדרטים שנקבעו. כל חברי הצוות מחויבים לעבוד על-פי XP בכלל ועל-פי מיומנות זו בפרט. חברי הצוות אינם מתלבטים האם לשתף פעולה. כל חברי הצוות משתפים פעולה ומרוויחים מהיתרונות שבפיתוח קוד על פי סטנדרטים.

47. 47 The Prisoner’s Dilemma: Simple Design נובע מהערך Simplicity שיתוף פעולה: פיתוח פשוט ככל האפשר; בגידה: פיתוח מסובך היכול להקשות על הבנה. כולם מחויבים לעבוד על-פי XP ולכן גם על-פי מיומנות זו. חברי הצוות אינם מתלבטים האם לשתף פעולה. כולם משתפים פעולה ומרוויחים מהיתרונות שבפיתוח קוד פשוט ככל שניתן.

48. 48 The Prisoner’s Dilemma: Sustainable Pace שבוע עבדה בן 40 שעות, למעט מקרים חריגים. רציונאל: מפתחים עייפים אינם מייצרים קוד איכותי. מיומנויות אחרות (e.g., Pair Programming) מבטיחות ניצול יעיל של זמן זה. שיתוף פעולה: עובדים 8-9 ביום; בגידה: עבודה במשך שעות רבות יותר (למשל, על מנת להרשים). כל חברי הצוות מחויבים לעבוד לפי XP ולכן גם לפי מיומנות זו. חברי הצוות אינם מתלבטים האם לשתף פעולה. כולם משתפים פעולה ומרוויחים מהיתרונות שבפיתוח קוד בקצב שניתן לעמוד בו.

49. 49 Cognitive analysis

50. 50 Why XP? טענה: הבנת סביבת פיתוח תוכנה היא תהליך מורכב; XP תומכת בתהליך הבנה זה. קונסטרקטיביזם:  תיאוריה המסבירה תהליכי למידה.  ידע חדש נבנה בהדרגה על בסיס מושגים קיימים, ע"י ארגון ועידון מבנים מנטאליים קיימים.  למשוב שמתקבל מסביבת הלמידה תפקיד חשוב בתהליך הלמידה.

51. 51 ניתוח קוגניטיבי של XP בחינת 4 מתוך 12 המיומנויות של XP דרך משקפיים קונסטרוקטיביסטיות. מיומנויות אלו תומכות בהבנה הדרגתית של סביבת הפיתוח. הערכים Communication ו- Feedback אף הם תורמים.

52. 52 XP practices - Cognitive analysis Small releases Gradual process of knowledge construction re requirements Refactoring Gradual process of knowledge construction re code's structure and readability Test driven development Metaphor

53. 53 Cognitive and Social Analysis of XP practices Social analysisCognitive analysis Collective ownership Sustainable pace Simple design Coding standards Refactoring Metaphor Test-first Small releases

54. 54 Summary eXtreme programming:  What?  Why? Cognitive and Social analysis  How?

55. 55 References Beck, K. (2000). Extreme Programming Explained: Embrace Change, Addison Wesley. Ron Jeffries, What is Extreme Programming?: http://www.xprogramming.com/xpmag/whatisxp.htm eXtreme Programming at the Technion RoleModel:http://www.rolemodelsoftware.com/process/whatIs Xp.phphttp://www.rolemodelsoftware.com/process/whatIs Xp.php

56. 56 Questions

57. 57 Appendices  XP and the CMM  XP conception of failure and success

58. 58 Why XP? – XP is a Mature Method The Capability Maturity Model for Software (CMM or SW-CMM): a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes. The Software CMM has become a de facto standard for assessing and improving software processes.

59. 59 Why XP? – XP is a Mature Method The SW-CMM has been developed by the software community with stewardship by the SEI.  past experiences in process improvement such as TQM  academic business theories  practical experiences of successful projects gained from companies such as IBM The CMM has five levels of process capability maturity.

60. 60 Why XP? – XP is a Mature Method The first – undisciplined:  processes may be loosely defined and rarely understood.  estimates of cost and schedule are poor and consequently projects have serious problems meeting deadlines and functionality requirements within budgets.  management generally is unaware that processes exist and often makes decisions that hurt more than help.

61. 61 Why XP? – XP is a Mature Method Level 2 - Repeatable:  puts project management practices such as requirements definition, configuration management, and quality assurance in place that are documented and can be repeated. Level 3 - Defined:  graduates the best practices of individual projects to an organizational process.  adds concepts of organizational training, process management, and program management.

62. 62 Why XP? – XP is a Mature Method Levels 4 and 5:  use information and measurements defined in levels 2 and 3 to understand why the process behaves the way it does so it can be improved. Level 5:  the process is mature enough to prevent defects instead of reacting to them and to insert new technology and process improvements knowing exactly how the organizational process will be affected.

63. 63 Why XP? – XP is a Mature Method The CMM has become popular around the world because of its ability to be applied practically to any software environment. It describes what process components should be in place (such as recording requirements, planning and tracking activities, estimating, etc.), but not how to implement them. eXtreme Programming fits as a framework for “how to implement the processes”.

64. 64 XP in practice: Success and failure 3 Sep, 2002: XP - An interview with Kent Beck Q: What are the issues you see your clients struggling with? KB: One of the issues is redefining failure or redefining success. For example, you think that you have a great idea for a project, and it's going to take you nine months to really have it ready for the market. You [may] discover after four weeks that you are going one-tenth the speed that you thought you would, and you cancel the project. Is that a failure or success? In many organizations, this is perceived as a failure.

65. 65 XP in practice: Success and failure 3 Sep, 2002: XP: An interview with Kent Beck KB (cont’): In the XP world, providing information that allows you to constantly make that decision after four or eight weeks (out of a nine-month development cycle) is what you're there for. In the XP world, you call that a dramatic success. Now you have this cultural mismatch between how outsiders are going to view your outcome and how you view it inside the team. A lot of people [clients] struggle with that. They think that canceling a project is a bad thing, but I think that canceling a project is a good thing -- as long as you cancel the right one.