Your SlideShare is downloading. ×
eXtreme programming
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

eXtreme programming

578
views

Published on

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
578
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1eXtreme Programming‫תוכנה‬ ‫פרויקטי‬ ‫לפיתוח‬ ‫מתודולוגיה‬‫חזן‬ ‫אורית‬ ‫ד"ר‬‫והמדעים‬ ‫הטכנולוגיה‬ ‫להוראת‬ ‫המחלקה‬‫הטכניון‬
  • 2. 2eXtreme Programming‫תוכנה‬ ‫פרוייקטי‬ ‫לפיתוח‬ ‫מתודולוגיה‬ Round 1: What is eXtreme Programming Why eXtreme Programming? How eXtreme Programming? Actual implementation Round 2: What is eXtreme Programming? Further details Why eXtreme Programming? Further analysis How eXtreme Programming? Further elaboration
  • 3. 3eXtreme 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 productProblems in software development
  • 5. 5‫תוכנה‬ ‫פרוייקטי‬ ‫של‬ ‫מאפיינות‬ ‫בעיות‬‫מקורה‬ ‫תוכנה‬ ‫בפיתוח‬ ‫האמיתית‬ ‫הסיבוכיות‬‫האנושי‬ ‫בהיבט‬(‫הטכנולוגי‬ ‫)ולא‬‫הבנה‬ ,‫באגים‬ ,‫בו‬ ‫ואי-עמידה‬ ‫לחוץ‬ ‫לו"ז‬ ,‫לקוחות‬‫אי-שיתוף‬ ,‫צוות‬ ‫חברי‬ ‫בין‬ ‫תקשורת‬ ,‫תוכניות‬ ‫של‬... ,‫אינטגרציה‬ ,‫מידע‬
  • 6. 6‫נתונים‬ :‫תוכנה‬ ‫פרויקטי‬75%‫התוכנה‬ ‫ממוצרי‬‫ללקוחות‬ ‫הנשלחים‬ ‫הגדולים‬‫נחשבים‬‫ככישלון‬‫לדרישות‬ ‫מתאימים‬ ‫שאינם‬ ‫או‬ ‫כלל‬ ‫בשימוש‬ ‫שאינם‬ ‫או‬ :‫הלקוחות‬.Based on: Mullet, D. (July, 1999). The Software Crisis, Benchmarks Online - a monthlypublication 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. 7What is eXtreme Programming‫על‬ ‫יודעים‬ ‫אתם‬ ‫מה‬XP?
  • 8. 8What 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 adjustedto bigger teams.
  • 9. 9Why 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. 10Why XP? big companies using XP in at least some capacity Ford Motor, Chrysler, IBM, HP smaller software houses: Mayford Technologies RoleModel Software tutorials: Industrial Logic, Object Mentor
  • 11. 11How eXtreme Programming?Two days ineXtreme ProgrammingDevelopment Environment
  • 12. 12How eXtreme Programming?Business Day‫מיומנויות‬ ‫יישום‬XP‫דרישות‬ ‫להגדרת‬ ‫הקשורות‬‫הפיתוח‬ ‫תהליך‬ ‫ותכנון‬ ‫התוכנה‬‫נושא‬ ‫בחירת‬‫במיומנויות‬ ‫התנסות‬
  • 13. 13Business Day On-site customer Planning game Small releases Simple design MetaphorSource: http://www.rolemodelsoftware.com/
  • 14. 14Business 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 anoverview of the entiredevelopment process Simple means Very detailed Levels of abstraction
  • 15. 15Business Day – Reflection 5 practices (out of 12)Planning gameOn-site customerSmall releasesSimple designMetaphor On-site customer Customer’s on-goingfeedback Small releases On-going opportunity toupdate/changerequirements
  • 16. 16Business Day – Reflection 5 practices (out of 12)Planning gameOn-site customerSmall releasesSimple designMetaphor Simple design Develop only what isneeded for yourdevelopment task Metaphor Bridges customers-developers-business gaps
  • 17. 17‫הפסקה‬
  • 18. 18Development 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/
  • 19. 19Development 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
  • 20. 20Development 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 doesntproduce code), gradual process Sustainable pace (40-hour week) Intense and productive work, developers are not tired
  • 21. 21Development and Business Days – ReflectionCode/TechnicalPerspectiveHuman/SocialPerspectiveRefactoringSimple designCoding standardsTestingContinuous integrationSmall releasesCollective ownershipPair programmingSustainable paceOn-site customerPlanning gameMetaphor
  • 22. 22The 12 XP practicesNote:nothing is new;gathering thepracticestogether is XPuniquenessSource: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
  • 23. 23eXtreme Programming‫תוכנה‬ ‫פרוייקטי‬ ‫לפיתוח‬ ‫מתודולוגיה‬ Round 1: What is eXtreme Programming Why eXtreme Programming? How eXtreme Programming? Round 2: What is eXtreme Programming? Further details Why eXtreme Programming? Further analysis How eXtreme Programming? Further elaboration
  • 24. 24What 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
  • 25. 25What is eXtreme Programming Agile Software Development Methodology Other agile methods: SCRUM, Feature DrivenDevelopment, DSDM All acknowledge that the main issue of softwaredevelopment is people: customers, communication Manifesto for Agile Software Development: http://agilemanifesto.org/ eXtreme Programming: Kent Beck, 1996, Chrysler
  • 26. 26Why XP? You do not do XP to save money;However, XP shortens time to market XP is a mature software developmentmethod
  • 27. 27Why 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 intime
  • 28. 28Why XP? – Analysis Shorter development period: Code is easy-to-work with: less bugs: unit tests code is more readable & workable (invest now to gain benefitslater):pair programming, refactoring, coding standards Development is manageable and controlled: accurate estimation: small releases meets customer needs: customer on-site, planning game,acceptance tests
  • 29. 29Why XP? – Analysis Shorter development period (cont): Knowledge sharing, if one leaves everything continuesas usual: pair programming, collective ownership Production is increased: pair programming (work all the time),sustainable pace Cost for requirements change/update/elaboration isCONSTANT: simple design, planning game (redundant featuresare not added by customer and developers)
  • 30. 30Why 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 RatioRequirements 1Design 3-6Coding 10Development testing 15-40Acceptance testing 30-70Operation 40-1000
  • 31. 31Why XP? Under the assumption that “the later a requirements isintroduced the more expensive it is”, customers (anddevelopers) try to make a “complete” list of requirements. Under the assumption that “cost for introducing an update inthe requirements is constant”, customers (and developers)do not assume what the customer will need and developexactly and only what is needed.
  • 32. 32Why XP? You do not use XP to save money;However, XP shortens time to market XP is a mature software developmentmethod (at least CMM level 3)
  • 33. 33XP in Practice: Conceptual Changes XP encourages:Cooperation (vs. knowledge-is-power)Simplicity (vs. habit-of-high-complexity)Change in work habits
  • 34. 34Why XP? – Cognitive and Social Analysis‫היישעתב החמצלחת‬‫ה‬ ‫הסבר‬XP.‫וחברתית‬ ‫קוגניטיבית‬ ‫מבט‬ ‫מנקודת‬Prisoner’s Dilemma Analysis of XP within the framework of the Prisoner’sdilemmaConstructivism Analysis of XP within the framework of constructivism GAPS (abstraction, satisfaction)
  • 35. 35Social analysis
  • 36. 36Game Theory‫כאשר‬ ‫החלטות‬ ‫וקבלת‬ ‫התנהגות‬ ‫ניתוח‬‫אחד‬ ‫כל‬ ‫של‬ ‫מהחלטות‬ ‫הנובעות‬ ‫תוצאות‬‫תלויות‬ "‫ב"משחק‬ ‫מהמשתתפים‬.‫האחרים‬ ‫המשתתפים‬ ‫של‬ ‫בהחלטות‬
  • 37. 37The Prisoner’s Dilemma: A’s perspectiveB cooperates B competesA cooperates +5 -10A competes +10 0
  • 38. 38The Prisoner’s Dilemma: The case of softwareengineering – A’s perspective, BonusB cooperates B competesA cooperates 50% 20%A competes 80% 0%
  • 39. 39The Prisoner’s Dilemma: The case ofsoftware engineering – A’s perspectiveB cooperates B competesA cooperates +5 -10A competes +10 -20
  • 40. 40The Prisoner’s Dilemma:The case of software engineering.‫עמיתיהם‬ ‫עם‬ ‫פעולה‬ ‫לשתף‬ ‫מתבקשים‬ ‫תוכנה‬ ‫מפתחי‬ ‫בד"כ‬‫שלהם‬ ‫הפעולה‬ ‫ששיתוף‬ ‫לוודא‬ ‫אפשרות‬ ‫אין‬ ‫התוכנה‬ ‫למפתחי‬.‫הדדי‬ ‫יהיה‬:‫האסיר‬ ‫דילמת‬ ‫לפי‬‫לשתף‬ ‫)לא‬ ‫לבגוד‬ ‫יעדיפו‬ ‫הצוות‬ ‫חברי‬ ‫כל‬.(‫פעולה‬‫הגרועות‬ ‫לתוצאות‬ ‫מביאה‬ ‫תוכנה‬ ‫בפיתוח‬ ‫כזו‬ ‫התנהגות‬.‫הצוות‬ ‫חברי‬ ‫לכל‬ ‫ביותר‬
  • 41. 41The Prisoner’s Dilemma: The caseof eXtreme Programming‫הצוות‬ ‫חברי‬ ‫התחייבות‬‫על-פי‬ ‫לעבוד‬XP‫שכל‬ ‫מבטיחה‬‫של‬ ‫המיומנויות‬ ‫על-פי‬ ‫יעבדו‬ ‫הצוות‬ ‫חברי‬XP.‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫שאר‬ ‫שגם‬ (‫יודע)ת‬ ‫צוות‬ (‫חבר)ת‬ ‫כל‬.‫מיומנויות‬ ‫אותן‬ ‫לפי‬ ‫לעבוד‬‫האי-וודאות‬ ‫גורם‬(‫האסיר‬ ‫לדילמת‬ ‫המקור‬ ‫את‬ ‫)המהווה‬‫לא‬.‫קיים‬.‫מכך‬ ‫הרווחים‬ ‫את‬ ‫ויפיקו‬ ‫פעולה‬ ‫ישתפו‬ ‫כולם‬
  • 42. 42The Prisoner’s Dilemma: The case ofExtreme Programming – A’s perspectiveB cooperatesA cooperates +5
  • 43. 43In what follows-‫ל‬ ‫ביחס‬2-‫ו‬ ‫ערכים‬4‫של‬ ‫מיומנויות‬XP:.‫מהם‬ ‫הנובעת‬ ‫פעולה‬ ‫שיתוף‬ ‫של‬ ‫המשמעות‬ ‫מהי‬‫על-פי‬ ‫לעבוד‬ ‫מחויב‬ ‫הצוות‬ ‫שכל‬ ‫מהעובדה‬XP‫אחד‬ ‫שכל‬ ‫נובע‬‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫ניצבים‬ ‫אינם‬ ‫הצוות‬ ‫מחברי‬ ‫ואחת‬‫פעולה‬(‫המיומנות‬ ‫או‬ ‫מהערך‬ ‫הנובע‬ ‫מובן‬ ‫)באותו‬.‫שנובע‬ ‫מהיתרון‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬‫מיומנות‬ ‫או‬ ‫ערך‬ ‫מאותו‬..‫זה‬ ‫פעולה‬ ‫משיתוף‬ ‫נתרם‬ ‫התוכנה‬ ‫פרויקט‬ ‫כל‬
  • 44. 44The Prisoner’s Dilemma:The value of courage:‫פעולה‬ ‫שיתוף‬.‫בעיה‬ ‫יש‬ ‫כאשר‬ ‫מתריעים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬.‫ידע‬ ‫להם‬ ‫חסר‬ ‫כאשר‬ ‫להודות‬ ‫מתביישים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬.‫עמיתיהם‬ ‫של‬ ‫קוד‬ ‫לשנות‬ ‫חוששים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬‫היא‬ ‫הפיתוח‬ ‫שסביבת‬ ‫מכיוון‬XP‫לא‬ ‫שהם‬ (‫יודע)ת‬ (‫אחד)ת‬ ‫כל‬ ,‫שיפגינו‬ ‫היחידים‬courage‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬ ‫הם‬ ‫ולכן‬.‫פעולה‬ ‫לשתף‬.‫זה‬ ‫מערך‬ ‫מרוויחים‬ ‫הצוות‬ ‫וחברי‬ ‫הפרויקט‬
  • 45. 45The Prisoner’s Dilemma:The value of simplicity:‫פעולה‬ ‫שיתוף‬‫הפשוטה‬ ‫בצורה‬ ‫התוכנה‬ ‫בפיתוח‬ ‫הקשורות‬ ‫הפעולות‬ ‫כל‬ ‫יישום‬.‫ביותר‬.‫קוד‬ ‫מסבכים‬ ‫לא‬ ,‫למשל‬‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP‫לערך‬ ‫גם‬ ‫מחויבים‬ ‫ולכן‬.‫הזה‬.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫ניצבים‬ ‫לא‬.‫מרוויחים‬ ‫וכולם‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬
  • 46. 46The Prisoner’s Dilemma:Collective Ownership In practice “[a]nyone can change any codeanywhere in the system at any time.” (Beck, 2000).:‫פעולה‬ ‫שיתוף‬.‫בקוד‬ ‫שיתוף‬:‫בגידה‬.‫קוד‬ ‫הסתרת‬‫על-פי‬ ‫עובדים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬‫פיתוח‬ ‫לתהליכי‬ ‫תורם‬ ‫הדבר‬ ,‫פעולה‬ ‫משתפים‬ ‫כולם‬.‫נשכרים‬ ‫יוצאים‬ ‫וכולם‬ ‫התוכנה‬
  • 47. 47The Prisoner’s Dilemma:Coding Standards:‫פעולה‬ ‫שיתוף‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫לפי‬ ‫פיתוח‬:‫בגידה‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫על-פי‬ ‫לא‬ ‫פיתוח‬‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP‫ועל-פי‬ ‫בכלל‬.‫בפרט‬ ‫זו‬ ‫מיומנות‬.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬.‫סטנדרטים‬ ‫פי‬ ‫על‬ ‫קוד‬ ‫שבפיתוח‬
  • 48. 48The Prisoner’s Dilemma:Simple Design‫מהערך‬ ‫נובע‬Simplicity:‫פעולה‬ ‫שיתוף‬;‫האפשר‬ ‫ככל‬ ‫פשוט‬ ‫פיתוח‬:‫בגידה‬‫פיתוח‬.‫הבנה‬ ‫על‬ ‫להקשות‬ ‫היכול‬ ‫מסובך‬‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬.‫שניתן‬ ‫ככל‬ ‫פשוט‬
  • 49. 49The Prisoner’s Dilemma:Sustainable Pace‫בן‬ ‫עבדה‬ ‫שבוע‬40.‫חריגים‬ ‫מקרים‬ ‫למעט‬ ,‫שעות‬:‫רציונאל‬.‫איכותי‬ ‫קוד‬ ‫מייצרים‬ ‫אינם‬ ‫עייפים‬ ‫מפתחים‬‫אחרות‬ ‫מיומנויות‬)e.g., Pair Programming(.‫זה‬ ‫זמן‬ ‫של‬ ‫יעיל‬ ‫ניצול‬ ‫מבטיחות‬:‫פעולה‬ ‫שיתוף‬‫עובדים‬8-9;‫ביום‬:‫בגידה‬‫שעות‬ ‫במשך‬ ‫עבודה‬‫יותר‬ ‫רבות‬(‫להרשים‬ ‫מנת‬ ‫על‬ ,‫)למשל‬.‫לפי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP.‫זו‬ ‫מיומנות‬ ‫לפי‬ ‫גם‬ ‫ולכן‬.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬‫בקצב‬ ‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬.‫בו‬ ‫לעמוד‬ ‫שניתן‬
  • 50. 50Cognitive analysis
  • 51. 51Why XP?:‫טענה‬‫תהליך‬ ‫היא‬ ‫תוכנה‬ ‫פיתוח‬ ‫סביבת‬ ‫הבנת‬;‫מורכב‬XP.‫זה‬ ‫הבנה‬ ‫בתהליך‬ ‫תומכת‬:‫קונסטרקטיביזם‬.‫למידה‬ ‫תהליכי‬ ‫המסבירה‬ ‫תיאוריה‬‫ועידון‬ ‫ארגון‬ ‫ע"י‬ ,‫קיימים‬ ‫מושגים‬ ‫בסיס‬ ‫על‬ ‫בהדרגה‬ ‫נבנה‬ ‫חדש‬ ‫ידע‬.‫קיימים‬ ‫מנטאליים‬ ‫מבנים‬‫בתהליך‬ ‫חשוב‬ ‫תפקיד‬ ‫הלמידה‬ ‫מסביבת‬ ‫שמתקבל‬ ‫למשוב‬.‫הלמידה‬
  • 52. 52‫של‬ ‫קוגניטיבי‬ ‫ניתוח‬XP‫בחינת‬4‫מתוך‬12‫של‬ ‫המיומנויות‬XP‫דרך‬‫משקפיים‬‫קונסטרוקטיביסטיות‬.‫תומכים‬ ‫אלו‬ ‫מיומנויות‬‫סביבת‬ ‫של‬ ‫הדרגתית‬ ‫בהבנה‬‫הפיתוח‬.‫הערכים‬Communication-‫ו‬Feedback.‫תורמים‬ ‫הם‬ ‫אף‬
  • 53. 53XP practices - Cognitive analysis• Small releasesGradual process of knowledge construction re requirements• RefactoringGradual process of knowledge construction re codes structure andreadability• Test driven development• Metaphor
  • 54. 54Cognitive and Social Analysis of XPpracticesCognitive analysis Social analysisRefactoringMetaphorTest-firstSmall releasesCollective ownershipSustainable paceSimple designCoding standards
  • 55. 55Bridging Cognitive and Social Gapsin Software Development usingExtreme ProgrammingBased on:Hazzan, O. and Dubinsky, Y. (2003). Bridging cognitive and social chasms in softwaredevelopment using Extreme Programming, Proceedings of the Fourth InternationalConference on eXtreme Programming and Agile Processes in Software Engineering,Genova, Italy, pp. 47-53.
  • 56. 56?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬‫כדי‬ ‫המערכת‬ ‫של‬ ‫כללית‬ ‫תמונה‬ ‫לקבל‬ ‫חייבת‬ ‫"אני‬" .‫בכלל‬ ‫רלוונטית‬ ‫הזאת‬ ‫המתודה‬ ‫האם‬ ‫לדעת‬‫שתי‬ ‫על‬ ‫לחשוב‬ ‫יכול‬ ‫הייתי‬ ‫שאם‬ ‫חושב‬ ‫באמת‬ ‫"אני‬‫מגיע‬ ‫הייתי‬ ,‫מופשט‬ ‫יותר‬ ‫באופן‬ ‫האלה‬ ‫המחלקות‬‫אני‬ ‫אבל‬ .‫אחת‬ ‫מחלקה‬ ‫ע"י‬ ‫לייצגן‬ ‫שניתן‬ ‫למסקנה‬."‫שלי‬ ‫הבאה‬ ‫הפיתוח‬ ‫למשימת‬ ‫לעבור‬ ‫חייב‬
  • 57. 57?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬‫להיות‬ ‫מבלי‬ ‫הקוד‬ ‫על‬ ‫לחשוב‬ ‫זמן‬ ‫קצת‬ ‫צריכה‬ ‫אני‬‫הייתי‬ ‫שאם‬ ‫בטוחה‬ ‫כמעט‬ ‫אני‬ .‫הפרטים‬ ‫בכל‬ ‫מוצפת‬‫יכולה‬ ‫הייתי‬ ,‫לשחות‬ ‫וללכת‬ ‫עכשיו‬ ‫לעזוב‬ ‫יכולה‬‫להישאר‬ ‫חייבת‬ ‫אני‬ ,‫לעשות‬ ‫מה‬ .‫אבל‬ .‫פתרון‬ ‫למצוא‬."‫שלי‬ ‫הצוות‬ ‫כל‬ ‫כמו‬ ‫מאוחר‬‫הוא‬ ‫כאשר‬ ‫למתכנת‬ ‫להצטרף‬ ‫יכול‬ ‫והייתי‬ ‫"הלוואי‬‫ניתן‬ ‫אם‬ ‫בטוח‬ ‫לא‬ ‫אני‬ ?‫למה‬ .‫הקוד‬ ‫את‬ ‫יכתוב‬-‫ה‬ ‫את‬ ‫לממש‬design-‫ב‬ ‫הזה‬C."
  • 58. 58?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬‫כדי‬ ‫המערכת‬ ‫של‬ ‫כללית‬ ‫תמונה‬ ‫לקבל‬ ‫חייבת‬ ‫"אני‬" .‫בכלל‬ ‫רלוונטית‬ ‫הזאת‬ ‫המתודה‬ ‫האם‬ ‫לדעת‬‫שתי‬ ‫על‬ ‫לחשוב‬ ‫יכול‬ ‫הייתי‬ ‫שאם‬ ‫חושב‬ ‫באמת‬ ‫"אני‬‫מגיע‬ ‫היית‬ ,‫מופשט‬ ‫יותר‬ ‫באופן‬ ‫האלה‬ ‫המחלקות‬‫אני‬ ‫אבל‬ .‫אחת‬ ‫מחלקה‬ ‫ע"י‬ ‫לייצגן‬ ‫שניתן‬ ‫למסקנה‬."‫שלי‬ ‫הבאה‬ ‫הפיתוח‬ ‫למשימת‬ ‫לעבור‬ ‫חייב‬
  • 59. 59?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬‫להיות‬ ‫מבלי‬ ‫הקוד‬ ‫על‬ ‫לחשוב‬ ‫זמן‬ ‫קצת‬ ‫צריכה‬ ‫אני‬‫הייתי‬ ‫שאם‬ ‫בטוחה‬ ‫כמעט‬ ‫אני‬ .‫הפרטים‬ ‫בכל‬ ‫מוצפת‬‫מוצאת‬ ‫הייתי‬ ,‫לשחות‬ ‫וללכת‬ ‫עכשיו‬ ‫לעזוב‬ ‫יכולה‬‫להישאר‬ ‫חייבת‬ ‫אני‬ ,‫לעשות‬ ‫מה‬ ‫אבל‬ .‫פתרון‬ ‫איזה‬."‫שלי‬ ‫הצוות‬ ‫כל‬ ‫כמו‬ ‫מאוחר‬‫את‬ ‫שיכתוב‬ ‫למתכנת‬ ‫להצטרף‬ ‫יכול‬ ‫והייתי‬ ‫"הלוואי‬-‫ה‬ ‫את‬ ‫לממש‬ ‫ניתן‬ ‫אם‬ ‫בטוח‬ ‫לא‬ ‫אני‬ ?‫למה‬ .‫הקוד‬design-‫ב‬ ‫הזה‬C.
  • 60. 60?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬•‫לקבל‬ ‫חייבת‬ ‫אני‬‫כללית‬ ‫תמונה‬... ‫של‬•‫יכול‬ ‫הייתי‬ ‫שאם‬ ‫חושב‬ ‫באמת‬ ‫אני‬‫שתי‬ ‫על‬ ‫לחשוב‬‫מופשט‬ ‫יותר‬ ‫באופן‬ ‫האלה‬ ‫המחלקות‬...•‫הקוד‬ ‫על‬ ‫לחשוב‬ ‫זמן‬ ‫קצת‬ ‫צריכה‬ ‫אני‬‫להיות‬ ‫מבלי‬‫הפרטים‬ ‫בכל‬ ‫מוצפת‬... .•‫אם‬ ‫בטוח‬ ‫לא‬ ‫אני‬-‫ה‬ ‫את‬ ‫לממש‬ ‫ניתן‬design-‫ב‬ ‫הזה‬C.Abstraction Level
  • 61. 61Abstraction levelsingle multipleA Cognitive Gap:AbstractionXP‫ביניהן‬ ‫המעבר‬ ‫ואת‬ ‫שונות‬ ‫הפשטה‬ ‫ברמות‬ ‫חשיבה‬ ‫.מנחה‬
  • 62. 62abstraction gap:single vs. multiple abstraction level Planning Game the release planning game is carried out on a high level ofabstraction; in the release planning a global view is gained the iteration planning game is carried out on a lower level ofabstraction; details are added only with respect to theforthcoming iteration the entire team participates in the planning game; developerssee the entire picture of the system (and its parts)
  • 63. 63abstraction gap (cont):single vs. multiple abstraction level Small Releases guide not to stay for too long a time in too high level ofabstraction or too low level of abstraction Pair Programming the two individuals in the pair think at different levels ofabstraction; the same development task is thought about attwo different levels of abstraction
  • 64. 64abstraction gap (cont):single vs. multiple abstraction level Sustainable Pace enables detachment from the details involved in softwaredevelopment and thinking on higher levels of abstraction Refactoring and Simple Design in order to improve a piece of code one has to examine it froma higher level of abstraction examining low level of abstraction (the code) from higher levelof abstraction (the design that guides the simplicity)
  • 65. 65Satisfactionneeds, points of viewindividual collectiveA Social Gap:SatisfactionXP‫בצוות‬ ‫הפרטים‬ ‫של‬ ‫הצרכים‬ ‫בסיפוק‬ ‫להסתפק‬ ‫לא‬ ‫מנחה‬‫הצוות‬ ‫חברי‬ ‫שאר‬ ‫צרכי‬ ‫את‬ ‫גם‬ ‫לשקול‬ ‫.אלא‬
  • 66. 66satisfaction gap:individual vs. collective satisfaction On-site Customer enables developers to refrain from making decisions withrespect to customer’s needs without first checking with thecustomer as to what is really needed
  • 67. 67satisfaction gap (cont):individual vs. collective satisfaction Pair Programming crossing the gap between individual’s tendency to skip tests,check email, browse the web, etc. and the the benefits thatthe collective gains from pair programming Coding Standards reduces programmers’ tendency to write code in a way that isunderstood only to them
  • 68. 68satisfaction gap (cont):individual vs. collective satisfaction Collective Ownership one knows that everyone looks at what one programs andimproves it if it is not good enough one postpones immediate satisfaction to move on andimproves one’s code prior to its integration Sustainable Pace one can dedicate more time to one’s personal life withouthaving to satisfy the expectations of co-workers to put in longhours of overtime
  • 69. 69satisfaction gap (cont):individual vs. collective satisfaction Refactoring it is not sufficient that the code passes all tests, it should alsobe refactored, restructured and improved one should postpone his or her immediate needs and investmore effort in refactoring before moving on Simple design it is not sufficient that the code passes all the tests, its designshould also be simplified as much as possible before onemoves on to the next development task
  • 70. 70Gaps: SummaryA cognitive gap: abstractionA social gaps: satisfaction Suggestions for additional gaps?
  • 71. 71How eXtreme Programming? Refactoring
  • 72. 72Refactoring in ExtremeProgramming
  • 73. 73Agenda Introductory questions Example Refactoring: Focus on its nature, not on techniques What is refactoring? Why refactoring? How refactoring? Why refactoring hard? XP and refactoring Summary
  • 74. 74Introductory Questions‫עושים‬ ‫אתם‬ ‫מה‬ ?‫שכתבתם‬ ‫מקוד‬ ‫מרוצים‬ ‫לא‬ ‫אתם‬ ‫מתי‬?‫כאלה‬ ‫במצבים‬‫כל‬ ‫הקוד‬ ‫את‬ ‫לכתוב‬ ‫מכם‬ ‫מבקשת‬ ‫שלכם‬ ‫הצוות‬ ‫ראש‬?‫תגיבו‬ ‫כיצד‬ .‫יותר‬ ‫קריא‬ ‫יהיה‬ ‫שהוא‬‫הוא‬ ‫תוכנה‬ ‫בפיתוח‬ ‫לו‬ ‫שחשוב‬ ‫שמה‬ ‫מספר‬ ‫לצוות‬ ‫חבר‬‫כל‬ ‫את‬ ‫עובר‬ ‫שכתב‬ ‫שהקוד‬ ‫ברגע‬ ,‫לכן‬ .‫רץ‬ ‫שהקוד‬‫המבנה‬ ‫את‬ ‫משפר‬ ‫ולא‬ ‫הקוד‬ ‫את‬ ‫עוזב‬ ‫הוא‬ ,‫הבדיקות‬?‫תגיבו‬ ‫כיצד‬ .‫שלו‬ ‫והעיצוב‬
  • 75. 75Example A given design Source: Martin Fowler, Kent Beck (Contributor), John Brant(Contributor), William Opdyke, don Roberts. (2002). Refactoring:Improving the Design of Existing Code, Addison-Wesley.
  • 76. 76Example A given design: Is it well designed? In what cases may itcause problems? Would you change it? If yes:suggest alternative designs.
  • 77. 77Example – Reflection How it emerged? Deal was originally being used to display a single deal. Someone wanted a table of deals. The subclass Tabular Active Deal displays a table. Now you want tables of passive deals. Another subclass is added. Small changes in many places. The code has become complicated, time is pressing, ... Adding a new kind of deal is hard, because the deal logic istangled with the presentation logic.
  • 78. 78Example – Reflection How it emerges? – In general“One day you are adding one little subclass to do a littlejob. The next day you are adding other subclasses to dothe same job in other parts of the hierarchy. A week (ormonth or year) later you are swimming in spaghetti.Without a paddle.” (Fowler)
  • 79. 79Example – Reflection Problems in tangled inheritance: It leads to code duplication. It makes changes more difficult: Strategies for solving a certain problem are spread around. The resulting code is hard to understand.
  • 80. 80Example – Reflection How tangled inheritance can be observed? Spot for a single inheritance hierarchy that is doing 2 jobs. “If every class at a certain level in the hierarchy has subclassesthat begin with the same adjective, you probably are doing twojobs with one hierarchy.” Why it can not be coded “correctly” at the firststage? Step-by-step refactoring (Fowler’s style)
  • 81. 81Example – Step by Step Refactoring First step: identify the jobs being done by thehierarchy. Job #1: capturing variation according to type of deal. Job #2: capturing variation according to presentationstyle.
  • 82. 82 Second step: decide which job is moreimportant.The dealness of the object is far moreimportant than the presentation style.Leave Deal alone and extract thepresentation style to its own hierarchy.Example – Step by Step Refactoring
  • 83. 83Example – Step by Step Refactoring Third step: use Extract Class to create apresentation style. Extract Class You have one class doing work that should be done bytwo. Create a new class and move the relevant fields andmethods from the old class into the new class.
  • 84. 84Example – Step by Step Refactoring Fourth step: Create subclasses of the extractedclass and initialize the instance variable to theappropriate subclass.Adding subclasses ofpresentation style
  • 85. 85Example – Step by Step Refactoring Fifth step: Use Move Method and Move Field tomove the presentation-related methods andvariables of the deal subclasses to thepresentation style subclasses.No code left in the classesTabular Active Deal and TabularPassive Deal. Remove them.
  • 86. 86Example – Step by Step Refactoring Sixth step: Separate the hierarchies: Distinguishbetween single and tabular.
  • 87. 87ExampleOriginal Refactored
  • 88. 88Example - Reflection What did we do? Is there a difference between the two designs? Ifyes – what is it? How is this change supposed to improve our life? In what way may the change be useful for someonewho did not write the code? How did the need for refactoring emerge? Couldn’t we write the code refactored from thebeginning?
  • 89. 89Example - Summary Tease Apart InheritanceYou have an inheritance hierarchy that is doingtwo jobs at once.Create two hierarchies and use delegation toinvoke one from the other. This format guides Fowler’s book.
  • 90. 90Example - Summary Delegation: The ability of an object to issue a message to anotherobject in response to a message. Delegation can be usedas an alternative to inheritance. Contrast: inheritance.Source: OMG Unified Modeling Language Specification. More about inheritance vs. delegation:http://www-inst.eecs.berkeley.edu/~cs61a-tb/week8/oop.html
  • 91. 91Refactoring In what follows:What is refactoring?Why refactoring?When refactoring? When not?How refactoring?Why refactoring hard?XP and refactoring
  • 92. 92Refactoring Fowler: Refactoring is the process of changing a softwaresystem in such a way that it does not alter the external(observable) behavior of the code yet improves itsinternal structure, to make it easier to understand andcheaper to modify. Kent (in Fowler, p. 51): Refactoring is the process oftaking a running program and adding to its value, not bychanging its behavior but by giving it more of thesequalities that enable us to continue developing at speed.
  • 93. 93Refactoring What do programmers do when refactoring:remove duplicationimprove communication and programcomprehensionadd simplicityadd flexibility
  • 94. 94Refactoring – Metaphors Three metaphors for refactoring :relationships with your programparenthesishealth
  • 95. 95Refactoring – Metaphors I[Refactoring] is like a new kind of relationship with yourprogram. When you really understand refactoring, thedesign of the system is as fluid and plastic and moldableto you as the individual characters in a source code file.You can feel the whole design at once. You can see howit might flex and change – a little this way and this ispossible, a little that way and that is possible. (Kent, inFowler, p. 333)
  • 96. 96Refactoring – Metaphors II Parenthesis (by Alistair Cockburn): “I started seeing 5*a + b*a as 3 operations on 6 things.(5+b)*a is 2 operations on 3 things.You can see the jump to OO programming.Lets take the case ofA.method1() = ... b.doThis(); b.doThat(); ...I change the code toB.doThisThat() = doThis(); doThat().A.method1() = ... b.doThisThat(); ...
  • 97. 97Refactoring – Metaphors II Alistair Cockburn (cont.): […] That change corresponds(in my mind, anyway) exactly to the (5+b)*a refactoring.Nowadays, I see a method and a class as a set ofparentheses, and when I move code out of one methodor class to another, I visualize it just as moving symbolsfrom one set of parentheses to another. Of course, thenet effect of the computation has to be the same, […] ithas to be a behavior preserving transformation.”
  • 98. 98Refactoring – Metaphors III Refactoring as health:exercises and eating a proper diet. The culture we live in. We can always make excuses, but we are only foolingourselves if we continue to ignore good behavior. Near-term and long-term benefits.
  • 99. 99Refactoring Main questions: What is refactoring? OK Why refactoring? When refactoring? When not? How refactoring? Why refactoring hard? Why people do not do that? XP and refactoring
  • 100. 100Why Refactoring Refactoring improves the design of the software fosters the examination of the software design removes duplicated code: reduces the amount of code the code says everything once and only once
  • 101. 101Why Refactoring Refactoring makes software easier to understand helps make your code more readable increases program comprehension: leads to higherlevels of understanding that otherwise may be missed
  • 102. 102Why Refactoring Refactoring helps you program fastersounds counterintuitiveless bugs, no patcheshelps correct bugs: errors need to be modifiedonly in one place
  • 103. 103Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? How refactoring? Why refactoring hard? Why people do not do that? XP and refactoring
  • 104. 104When refactoring You have written some code. Now, if you workby XP, you should refactor it. How would you find what to refactor? What clues in the code may guide you? Fowler, chapter 3 – Bad smells in code
  • 105. 105When refactoringFowler, Chapter 3 – Bad smells in Code Duplicated Code: “If you see the same code structure in more than oneplace, you can be sure that your program will be betterif you find a way to unify them”. Extract Method: When you have the same expressionin two methods of the same class.
  • 106. 106When refactoringFowler, Chapter 3 – Bad smells in Code Long Method: “the longer the procedure is, the more difficult it is tounderstand”. Extract method: find parts of the methods that seemto go nicely together and make a new method.
  • 107. 107When refactoringFowler, Chapter 3 – Bad smells in Code Comments: “if you need a comment to explain what a block of codedoes, try Extract Method. If the method is alreadyextracted but you still need a comment to explain what itdoes, use Rename Method.” “when you feel the need to write a comment, first try torefactor the code so that any comment becomessuperfluous”. “a comment is a good place to say why you did something.This kind of information helps future modifiers”.
  • 108. 108When shouldnt you refactor? When the code is a mess and it wouldbe better to start from the beginning. Factors that will be discussed later:CultureInternal resistance
  • 109. 109Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? Why refactoring hard? Why people do not do that? XP and refactoring
  • 110. 110How Refactoring Rasmusson (2002): “The team must refactor all thetime, to the fullest extent. When we didnt follow thisrule, the code became more cumbersome to workwith”. Most of the time it is done in small and local places Sometimes: a sequence of refactoring Refactoring requires high level of awareness All the time Two hats: adding functions and refactoring
  • 111. 111How refactoring Resources for specific refactoring: Refactoring Home Page: http://www.refactoring.com Martin Fowler, Kent Beck (Contributor), John Brant(Contributor), William Opdyke, don Roberts (1999).Refactoring: Improving the Design of Existing Code,Addison-Wesley. Many of the citations in this refactoring presentation are from thebook. Some IDEs (Integrated development environments)offer Refactoring menu Example: Eclipse, IntelliJ
  • 112. 112Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? OK Why refactoring hard? Why people do not refactor? XP and refactoring
  • 113. 113Why refactoring hard? Sub-questions:Why people do not refactor naturally?Why does refactoring raise resistance?
  • 114. 114Why refactoring hard? Culture:“refactoring is an overhead activity. I’m paid to writenew, revenue-generating features”. “What do I tell my manager?” When it is part of XP – You do not have a problem When it is not part of XP: Don’t tell!! Treat it as part of the profession: This is how you developcode, it is not viewed by you as an additional work.
  • 115. 115Why refactoring hard? Internal resistance: Why are developers reluctant torefactor? (Opdyke, in Fowler’s book, p. 313) it should be executed when the code runs and all thetests pass. It seems that time is wasted now. if the benefits are long-term, why exert the effort now?In the long term, developers might not be with theproject to reap the benefits. developers might not understand how to refactor. refactoring might break the existing program.
  • 116. 116Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? OK Why refactoring hard? OK XP and refactoring
  • 117. 117XP and Refactoring Refactoring is part of eXtreme Programming: Refactoring can be carried out without XP, but it hasadditional value with XP It has similar targets to those that XP inspires When refactoring is part of XP: refactoring becomes part of the routine it stops feeling like an overhead activity
  • 118. 118XP and Refactoring Mutual relationships of refactoring and other XP practicesSource: Beck, K. (2000).eXtreme Programmingexplained, Addison Wesley.
  • 119. 119XP and Refactoring Connection to XP practices - exampleTesting: “Whenever I do refactoring, the first step isalways the same. I need to build a solid set of tests forthat section of code. The tests are essential becauseeven though I follow refactoring structures to avoidmost of the opportunities for introducing bugs, Im stillhuman and still make mistakes.Thus I need solidtests.” (Fowler, p. 17)
  • 120. 120Refactoring Main questions: What is refactoring OK Why refactoring? OK When refactoring? When not? OK How refactoring? OK Why people do not refactoring? OK XP and refactoring OK
  • 121. 121Refactoring – Summary Refactoring requires awareness! Main Message: We should not skip refactoring. Software development is a process that cannot beenvisioned in advance. Refactoring can be performed without XP but it gets itspower from its integration with the other XP practices. Refactoring may improve programming skills.
  • 122. 122SummaryeXtreme programming: What? Why? How?
  • 123. 123Conferences XP 2004: Fifth International Conference on Extreme P, June 6-10, 2004, Garmisch-Partenkirchen,Germany Agile Development Conference, June 23-26, 2004,Salt Lake City, Utah. XP Agile Universe 2004, August 2004, Calgary,Alberta, CA.
  • 124. 124ReferencesBeck, K. (2000). Extreme Programming Explained: EmbraceChange, Addison Wesley.Ron Jeffries, What is Extreme Programming?:http://www.xprogramming.com/xpmag/whatisxp.htmeXtreme Programming at the TechnionRoleModel:http://www.rolemodelsoftware.com/process/whatIsXp.php
  • 125. 125 Questions (Musical cards)
  • 126. 126Appendices XP and the CMM XP conception of failure and success
  • 127. 127Why XP? – XP is a Mature Method The Capability Maturity Model for Software (CMM orSW-CMM): a model for judging the maturity of thesoftware processes of an organization and foridentifying the key practices that are required toincrease the maturity of these processes. The Software CMM has become a de facto standardfor assessing and improving software processes.
  • 128. 128Why XP? – XP is a Mature Method The SW-CMM has been developed by the software communitywith stewardship by the SEI. past experiences in process improvement such as TQM academic business theories practical experiences of successful projects gained from companiessuch as IBM The CMM has five levels of process capability maturity.
  • 129. 129Why 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 haveserious problems meeting deadlines and functionality requirements withinbudgets. management generally is unaware that processes exist and often makesdecisions that hurt more than help.
  • 130. 130Why 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 aredocumented and can be repeated. Level 3 - Defined: graduates the best practices of individual projects to an organizationalprocess. adds concepts of organizational training, process management, andprogram management.
  • 131. 131Why XP? – XP is a Mature Method Levels 4 and 5: use information and measurements defined in levels 2and 3 to understand why the process behaves the wayit does so it can be improved. Level 5: the process is mature enough to prevent defectsinstead of reacting to them and to insert new technologyand process improvements knowing exactly how theorganizational process will be affected.
  • 132. 132Why XP? – XP is a Mature Method The CMM has become popular around the world becauseof its ability to be applied practically to any softwareenvironment. It describes what process components should be inplace (such as recording requirements, planning andtracking activities, estimating, etc.), but not how toimplement them. eXtreme Programming fits as a framework for “how toimplement the processes”.
  • 133. 133XP in practice:Success and failure3 Sep, 2002: XP - An interview with Kent BeckQ: What are the issues you see your clients struggling with?KB: One of the issues is redefining failure or redefiningsuccess. For example, you think that you have a greatidea for a project, and its going to take you nine months toreally have it ready for the market. You [may] discoverafter four weeks that you are going one-tenth the speedthat you thought you would, and you cancel the project. Isthat a failure or success? In many organizations, this isperceived as a failure.
  • 134. 134XP in practice:Success and failure3 Sep, 2002: XP: An interview with Kent BeckKB (cont’): In the XP world, providing information that allowsyou to constantly make that decision after four or eightweeks (out of a nine-month development cycle) is whatyoure there for. In the XP world, you call that a dramaticsuccess. Now you have this cultural mismatch between howoutsiders are going to view your outcome and how you viewit inside the team. A lot of people [clients] struggle with that.They think that canceling a project is a bad thing, but I thinkthat canceling a project is a good thing -- as long as youcancel the right one.