SlideShare a Scribd company logo
1 of 134
Download to read offline
1
eXtreme Programming
‫תוכנה‬ ‫פרויקטי‬ ‫לפיתוח‬ ‫מתודולוגיה‬
‫חזן‬ ‫אורית‬ ‫ד"ר‬
‫והמדעים‬ ‫הטכנולוגיה‬ ‫להוראת‬ ‫המחלקה‬
‫הטכניון‬
2
eXtreme 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
eXtreme Programming
‫תוכנה‬ ‫פרוייקטי‬ ‫לפיתוח‬ ‫מתודולוגיה‬
:‫תוכנה‬ ‫בפיתוח‬ ‫היום‬ ‫עד‬ ‫ניסיונכם‬ ‫על-סמך‬
‫המאפיינות‬ ‫המרכזיות‬ ‫הבעיות‬ ‫מהן‬
?‫תוכנה‬ ‫פרויקטי‬
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
‫תוכנה‬ ‫פרוייקטי‬ ‫של‬ ‫מאפיינות‬ ‫בעיות‬
‫מקורה‬ ‫תוכנה‬ ‫בפיתוח‬ ‫האמיתית‬ ‫הסיבוכיות‬
‫האנושי‬ ‫בהיבט‬(‫הטכנולוגי‬ ‫)ולא‬
‫הבנה‬ ,‫באגים‬ ,‫בו‬ ‫ואי-עמידה‬ ‫לחוץ‬ ‫לו"ז‬ ,‫לקוחות‬
‫אי-שיתוף‬ ,‫צוות‬ ‫חברי‬ ‫בין‬ ‫תקשורת‬ ,‫תוכניות‬ ‫של‬
... ,‫אינטגרציה‬ ,‫מידע‬
6
‫נתונים‬ :‫תוכנה‬ ‫פרויקטי‬
75%‫התוכנה‬ ‫ממוצרי‬‫ללקוחות‬ ‫הנשלחים‬ ‫הגדולים‬‫נחשבים‬
‫ככישלון‬‫לדרישות‬ ‫מתאימים‬ ‫שאינם‬ ‫או‬ ‫כלל‬ ‫בשימוש‬ ‫שאינם‬ ‫או‬ :
‫הלקוחות‬.
Based on: Mullet, D. (July, 1999). The Software Crisis, Benchmarks Online - a monthly
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
What is eXtreme Programming
‫על‬ ‫יודעים‬ ‫אתם‬ ‫מה‬XP?
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
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
Why 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
How eXtreme Programming?
Two days in
eXtreme Programming
Development Environment
12
How eXtreme Programming?
Business Day
‫מיומנויות‬ ‫יישום‬XP‫דרישות‬ ‫להגדרת‬ ‫הקשורות‬
‫הפיתוח‬ ‫תהליך‬ ‫ותכנון‬ ‫התוכנה‬
‫נושא‬ ‫בחירת‬
‫במיומנויות‬ ‫התנסות‬
13
Business Day
 On-site customer
 Planning game
 Small releases
 Simple design
 Metaphor
Source: http://www.rolemodelsoftware.com/
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
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
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
‫הפסקה‬
18
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/
19
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
20
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
21
Development and Business Days – Reflection
Code/Technical
Perspective
Human/Social
Perspective
Refactoring
Simple design
Coding standards
Testing
Continuous integration
Small releases
Collective ownership
Pair programming
Sustainable pace
On-site customer
Planning game
Metaphor
22
The 12 XP practices
Note:
nothing is new;
gathering the
practices
together is XP
uniqueness
Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
23
eXtreme 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
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
25
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/
 eXtreme Programming: Kent Beck, 1996, Chrysler
26
Why XP?
 You do not do XP to save money;
However, XP shortens time to market
 XP is a mature software development
method
27
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
28
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
29
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)
30
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
31
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.
32
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)
33
XP in Practice: Conceptual Changes
 XP encourages:
Cooperation (vs. knowledge-is-power)
Simplicity (vs. habit-of-high-complexity)
Change in work habits
34
Why XP? – Cognitive and Social Analysis
‫היישעתב החמצלחת‬‫ה‬ ‫הסבר‬XP.‫וחברתית‬ ‫קוגניטיבית‬ ‫מבט‬ ‫מנקודת‬
Prisoner’s Dilemma
 Analysis of XP within the framework of the Prisoner’s
dilemma
Constructivism
 Analysis of XP within the framework of constructivism
 GAPS (abstraction, satisfaction)
35
Social analysis
36
Game Theory
‫כאשר‬ ‫החלטות‬ ‫וקבלת‬ ‫התנהגות‬ ‫ניתוח‬
‫אחד‬ ‫כל‬ ‫של‬ ‫מהחלטות‬ ‫הנובעות‬ ‫תוצאות‬
‫תלויות‬ "‫ב"משחק‬ ‫מהמשתתפים‬
.‫האחרים‬ ‫המשתתפים‬ ‫של‬ ‫בהחלטות‬
37
The Prisoner’s Dilemma: A’s perspective
B cooperates B competes
A cooperates +5 -10
A competes +10 0
38
The Prisoner’s Dilemma: The case of software
engineering – A’s perspective, Bonus
B cooperates B competes
A cooperates 50% 20%
A competes 80% 0%
39
The Prisoner’s Dilemma: The case of
software engineering – A’s perspective
B cooperates B competes
A cooperates +5 -10
A competes +10 -20
40
The Prisoner’s Dilemma:
The case of software engineering
.‫עמיתיהם‬ ‫עם‬ ‫פעולה‬ ‫לשתף‬ ‫מתבקשים‬ ‫תוכנה‬ ‫מפתחי‬ ‫בד"כ‬
‫שלהם‬ ‫הפעולה‬ ‫ששיתוף‬ ‫לוודא‬ ‫אפשרות‬ ‫אין‬ ‫התוכנה‬ ‫למפתחי‬
.‫הדדי‬ ‫יהיה‬
:‫האסיר‬ ‫דילמת‬ ‫לפי‬‫לשתף‬ ‫)לא‬ ‫לבגוד‬ ‫יעדיפו‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.(‫פעולה‬
‫הגרועות‬ ‫לתוצאות‬ ‫מביאה‬ ‫תוכנה‬ ‫בפיתוח‬ ‫כזו‬ ‫התנהגות‬
.‫הצוות‬ ‫חברי‬ ‫לכל‬ ‫ביותר‬
41
The Prisoner’s Dilemma: The case
of eXtreme Programming
‫הצוות‬ ‫חברי‬ ‫התחייבות‬‫על-פי‬ ‫לעבוד‬XP‫שכל‬ ‫מבטיחה‬
‫של‬ ‫המיומנויות‬ ‫על-פי‬ ‫יעבדו‬ ‫הצוות‬ ‫חברי‬XP.
‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫שאר‬ ‫שגם‬ (‫יודע)ת‬ ‫צוות‬ (‫חבר)ת‬ ‫כל‬
.‫מיומנויות‬ ‫אותן‬ ‫לפי‬ ‫לעבוד‬
‫האי-וודאות‬ ‫גורם‬(‫האסיר‬ ‫לדילמת‬ ‫המקור‬ ‫את‬ ‫)המהווה‬‫לא‬
.‫קיים‬
.‫מכך‬ ‫הרווחים‬ ‫את‬ ‫ויפיקו‬ ‫פעולה‬ ‫ישתפו‬ ‫כולם‬
42
The Prisoner’s Dilemma: The case of
Extreme Programming – A’s perspective
B cooperates
A cooperates +5
43
In what follows
-‫ל‬ ‫ביחס‬2-‫ו‬ ‫ערכים‬4‫של‬ ‫מיומנויות‬XP:
.‫מהם‬ ‫הנובעת‬ ‫פעולה‬ ‫שיתוף‬ ‫של‬ ‫המשמעות‬ ‫מהי‬
‫על-פי‬ ‫לעבוד‬ ‫מחויב‬ ‫הצוות‬ ‫שכל‬ ‫מהעובדה‬XP‫אחד‬ ‫שכל‬ ‫נובע‬
‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫ניצבים‬ ‫אינם‬ ‫הצוות‬ ‫מחברי‬ ‫ואחת‬
‫פעולה‬(‫המיומנות‬ ‫או‬ ‫מהערך‬ ‫הנובע‬ ‫מובן‬ ‫)באותו‬.
‫שנובע‬ ‫מהיתרון‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
‫מיומנות‬ ‫או‬ ‫ערך‬ ‫מאותו‬.
.‫זה‬ ‫פעולה‬ ‫משיתוף‬ ‫נתרם‬ ‫התוכנה‬ ‫פרויקט‬ ‫כל‬
44
The Prisoner’s Dilemma:
The value of courage
:‫פעולה‬ ‫שיתוף‬
.‫בעיה‬ ‫יש‬ ‫כאשר‬ ‫מתריעים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.‫ידע‬ ‫להם‬ ‫חסר‬ ‫כאשר‬ ‫להודות‬ ‫מתביישים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.‫עמיתיהם‬ ‫של‬ ‫קוד‬ ‫לשנות‬ ‫חוששים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
‫היא‬ ‫הפיתוח‬ ‫שסביבת‬ ‫מכיוון‬XP‫לא‬ ‫שהם‬ (‫יודע)ת‬ (‫אחד)ת‬ ‫כל‬ ,
‫שיפגינו‬ ‫היחידים‬courage‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬ ‫הם‬ ‫ולכן‬
.‫פעולה‬ ‫לשתף‬
.‫זה‬ ‫מערך‬ ‫מרוויחים‬ ‫הצוות‬ ‫וחברי‬ ‫הפרויקט‬
45
The Prisoner’s Dilemma:
The value of simplicity
:‫פעולה‬ ‫שיתוף‬
‫הפשוטה‬ ‫בצורה‬ ‫התוכנה‬ ‫בפיתוח‬ ‫הקשורות‬ ‫הפעולות‬ ‫כל‬ ‫יישום‬
.‫ביותר‬
.‫קוד‬ ‫מסבכים‬ ‫לא‬ ,‫למשל‬
‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP‫לערך‬ ‫גם‬ ‫מחויבים‬ ‫ולכן‬
.‫הזה‬
.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫ניצבים‬ ‫לא‬
.‫מרוויחים‬ ‫וכולם‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬
46
The Prisoner’s Dilemma:
Collective Ownership
 In practice “[a]nyone can change any code
anywhere in the system at any time.” (Beck, 2000).
:‫פעולה‬ ‫שיתוף‬.‫בקוד‬ ‫שיתוף‬:‫בגידה‬.‫קוד‬ ‫הסתרת‬
‫על-פי‬ ‫עובדים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬
.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬
‫פיתוח‬ ‫לתהליכי‬ ‫תורם‬ ‫הדבר‬ ,‫פעולה‬ ‫משתפים‬ ‫כולם‬
.‫נשכרים‬ ‫יוצאים‬ ‫וכולם‬ ‫התוכנה‬
47
The Prisoner’s Dilemma:
Coding Standards
:‫פעולה‬ ‫שיתוף‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫לפי‬ ‫פיתוח‬
:‫בגידה‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫על-פי‬ ‫לא‬ ‫פיתוח‬
‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP‫ועל-פי‬ ‫בכלל‬
.‫בפרט‬ ‫זו‬ ‫מיומנות‬
.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬
‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.‫סטנדרטים‬ ‫פי‬ ‫על‬ ‫קוד‬ ‫שבפיתוח‬
48
The Prisoner’s Dilemma:
Simple Design
‫מהערך‬ ‫נובע‬Simplicity
:‫פעולה‬ ‫שיתוף‬;‫האפשר‬ ‫ככל‬ ‫פשוט‬ ‫פיתוח‬:‫בגידה‬‫פיתוח‬
.‫הבנה‬ ‫על‬ ‫להקשות‬ ‫היכול‬ ‫מסובך‬
‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬
.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬
‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬
.‫שניתן‬ ‫ככל‬ ‫פשוט‬
49
The Prisoner’s Dilemma:
Sustainable Pace
‫בן‬ ‫עבדה‬ ‫שבוע‬40.‫חריגים‬ ‫מקרים‬ ‫למעט‬ ,‫שעות‬
:‫רציונאל‬.‫איכותי‬ ‫קוד‬ ‫מייצרים‬ ‫אינם‬ ‫עייפים‬ ‫מפתחים‬
‫אחרות‬ ‫מיומנויות‬)e.g., Pair Programming(.‫זה‬ ‫זמן‬ ‫של‬ ‫יעיל‬ ‫ניצול‬ ‫מבטיחות‬
:‫פעולה‬ ‫שיתוף‬‫עובדים‬8-9;‫ביום‬:‫בגידה‬‫שעות‬ ‫במשך‬ ‫עבודה‬
‫יותר‬ ‫רבות‬(‫להרשים‬ ‫מנת‬ ‫על‬ ,‫)למשל‬.
‫לפי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP.‫זו‬ ‫מיומנות‬ ‫לפי‬ ‫גם‬ ‫ולכן‬
.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬
‫בקצב‬ ‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬
.‫בו‬ ‫לעמוד‬ ‫שניתן‬
50
Cognitive analysis
51
Why XP?
:‫טענה‬‫תהליך‬ ‫היא‬ ‫תוכנה‬ ‫פיתוח‬ ‫סביבת‬ ‫הבנת‬
;‫מורכב‬XP.‫זה‬ ‫הבנה‬ ‫בתהליך‬ ‫תומכת‬
:‫קונסטרקטיביזם‬
.‫למידה‬ ‫תהליכי‬ ‫המסבירה‬ ‫תיאוריה‬
‫ועידון‬ ‫ארגון‬ ‫ע"י‬ ,‫קיימים‬ ‫מושגים‬ ‫בסיס‬ ‫על‬ ‫בהדרגה‬ ‫נבנה‬ ‫חדש‬ ‫ידע‬
.‫קיימים‬ ‫מנטאליים‬ ‫מבנים‬
‫בתהליך‬ ‫חשוב‬ ‫תפקיד‬ ‫הלמידה‬ ‫מסביבת‬ ‫שמתקבל‬ ‫למשוב‬
.‫הלמידה‬
52
‫של‬ ‫קוגניטיבי‬ ‫ניתוח‬XP
‫בחינת‬4‫מתוך‬12‫של‬ ‫המיומנויות‬XP‫דרך‬‫משקפיים‬
‫קונסטרוקטיביסטיות‬.
‫תומכים‬ ‫אלו‬ ‫מיומנויות‬‫סביבת‬ ‫של‬ ‫הדרגתית‬ ‫בהבנה‬
‫הפיתוח‬.
‫הערכים‬Communication-‫ו‬Feedback.‫תורמים‬ ‫הם‬ ‫אף‬
53
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
54
Cognitive and Social Analysis of XP
practices
Cognitive analysis Social analysis
Refactoring
Metaphor
Test-first
Small releases
Collective ownership
Sustainable pace
Simple design
Coding standards
55
Bridging Cognitive and Social Gaps
in Software Development using
Extreme Programming
Based on:
Hazzan, O. and Dubinsky, Y. (2003). Bridging cognitive and social chasms in software
development using Extreme Programming, Proceedings of the Fourth International
Conference on eXtreme Programming and Agile Processes in Software Engineering,
Genova, Italy, pp. 47-53.
56
?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬
‫כדי‬ ‫המערכת‬ ‫של‬ ‫כללית‬ ‫תמונה‬ ‫לקבל‬ ‫חייבת‬ ‫"אני‬
" .‫בכלל‬ ‫רלוונטית‬ ‫הזאת‬ ‫המתודה‬ ‫האם‬ ‫לדעת‬
‫שתי‬ ‫על‬ ‫לחשוב‬ ‫יכול‬ ‫הייתי‬ ‫שאם‬ ‫חושב‬ ‫באמת‬ ‫"אני‬
‫מגיע‬ ‫הייתי‬ ,‫מופשט‬ ‫יותר‬ ‫באופן‬ ‫האלה‬ ‫המחלקות‬
‫אני‬ ‫אבל‬ .‫אחת‬ ‫מחלקה‬ ‫ע"י‬ ‫לייצגן‬ ‫שניתן‬ ‫למסקנה‬
."‫שלי‬ ‫הבאה‬ ‫הפיתוח‬ ‫למשימת‬ ‫לעבור‬ ‫חייב‬
57
?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬
‫להיות‬ ‫מבלי‬ ‫הקוד‬ ‫על‬ ‫לחשוב‬ ‫זמן‬ ‫קצת‬ ‫צריכה‬ ‫אני‬
‫הייתי‬ ‫שאם‬ ‫בטוחה‬ ‫כמעט‬ ‫אני‬ .‫הפרטים‬ ‫בכל‬ ‫מוצפת‬
‫יכולה‬ ‫הייתי‬ ,‫לשחות‬ ‫וללכת‬ ‫עכשיו‬ ‫לעזוב‬ ‫יכולה‬
‫להישאר‬ ‫חייבת‬ ‫אני‬ ,‫לעשות‬ ‫מה‬ .‫אבל‬ .‫פתרון‬ ‫למצוא‬
."‫שלי‬ ‫הצוות‬ ‫כל‬ ‫כמו‬ ‫מאוחר‬
‫הוא‬ ‫כאשר‬ ‫למתכנת‬ ‫להצטרף‬ ‫יכול‬ ‫והייתי‬ ‫"הלוואי‬
‫ניתן‬ ‫אם‬ ‫בטוח‬ ‫לא‬ ‫אני‬ ?‫למה‬ .‫הקוד‬ ‫את‬ ‫יכתוב‬
-‫ה‬ ‫את‬ ‫לממש‬design-‫ב‬ ‫הזה‬C."
58
?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬
‫כדי‬ ‫המערכת‬ ‫של‬ ‫כללית‬ ‫תמונה‬ ‫לקבל‬ ‫חייבת‬ ‫"אני‬
" .‫בכלל‬ ‫רלוונטית‬ ‫הזאת‬ ‫המתודה‬ ‫האם‬ ‫לדעת‬
‫שתי‬ ‫על‬ ‫לחשוב‬ ‫יכול‬ ‫הייתי‬ ‫שאם‬ ‫חושב‬ ‫באמת‬ ‫"אני‬
‫מגיע‬ ‫היית‬ ,‫מופשט‬ ‫יותר‬ ‫באופן‬ ‫האלה‬ ‫המחלקות‬
‫אני‬ ‫אבל‬ .‫אחת‬ ‫מחלקה‬ ‫ע"י‬ ‫לייצגן‬ ‫שניתן‬ ‫למסקנה‬
."‫שלי‬ ‫הבאה‬ ‫הפיתוח‬ ‫למשימת‬ ‫לעבור‬ ‫חייב‬
59
?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬
‫להיות‬ ‫מבלי‬ ‫הקוד‬ ‫על‬ ‫לחשוב‬ ‫זמן‬ ‫קצת‬ ‫צריכה‬ ‫אני‬
‫הייתי‬ ‫שאם‬ ‫בטוחה‬ ‫כמעט‬ ‫אני‬ .‫הפרטים‬ ‫בכל‬ ‫מוצפת‬
‫מוצאת‬ ‫הייתי‬ ,‫לשחות‬ ‫וללכת‬ ‫עכשיו‬ ‫לעזוב‬ ‫יכולה‬
‫להישאר‬ ‫חייבת‬ ‫אני‬ ,‫לעשות‬ ‫מה‬ ‫אבל‬ .‫פתרון‬ ‫איזה‬
."‫שלי‬ ‫הצוות‬ ‫כל‬ ‫כמו‬ ‫מאוחר‬
‫את‬ ‫שיכתוב‬ ‫למתכנת‬ ‫להצטרף‬ ‫יכול‬ ‫והייתי‬ ‫"הלוואי‬
-‫ה‬ ‫את‬ ‫לממש‬ ‫ניתן‬ ‫אם‬ ‫בטוח‬ ‫לא‬ ‫אני‬ ?‫למה‬ .‫הקוד‬
design-‫ב‬ ‫הזה‬C.
60
?‫הבאות‬ ‫לאמירות‬ ‫משותף‬ ‫מה‬
•‫לקבל‬ ‫חייבת‬ ‫אני‬‫כללית‬ ‫תמונה‬... ‫של‬
•‫יכול‬ ‫הייתי‬ ‫שאם‬ ‫חושב‬ ‫באמת‬ ‫אני‬‫שתי‬ ‫על‬ ‫לחשוב‬
‫מופשט‬ ‫יותר‬ ‫באופן‬ ‫האלה‬ ‫המחלקות‬...
•‫הקוד‬ ‫על‬ ‫לחשוב‬ ‫זמן‬ ‫קצת‬ ‫צריכה‬ ‫אני‬‫להיות‬ ‫מבלי‬
‫הפרטים‬ ‫בכל‬ ‫מוצפת‬... .
•‫אם‬ ‫בטוח‬ ‫לא‬ ‫אני‬-‫ה‬ ‫את‬ ‫לממש‬ ‫ניתן‬design-‫ב‬ ‫הזה‬C.
Abstraction Level
61
Abstraction levelsingle multiple
A Cognitive Gap:
Abstraction
XP‫ביניהן‬ ‫המעבר‬ ‫ואת‬ ‫שונות‬ ‫הפשטה‬ ‫ברמות‬ ‫חשיבה‬ ‫.מנחה‬
62
abstraction gap:
single vs. multiple abstraction level
 Planning Game
 the release planning game is carried out on a high level of
abstraction; in the release planning a global view is gained
 the iteration planning game is carried out on a lower level of
abstraction; details are added only with respect to the
forthcoming iteration
 the entire team participates in the planning game; developers
see the entire picture of the system (and its parts)
63
abstraction gap (cont):
single vs. multiple abstraction level
 Small Releases
 guide not to stay for too long a time in too high level of
abstraction or too low level of abstraction
 Pair Programming
 the two individuals in the pair think at different levels of
abstraction; the same development task is thought about at
two different levels of abstraction
64
abstraction gap (cont):
single vs. multiple abstraction level
 Sustainable Pace
 enables detachment from the details involved in software
development and thinking on higher levels of abstraction
 Refactoring and Simple Design
 in order to improve a piece of code one has to examine it from
a higher level of abstraction
 examining low level of abstraction (the code) from higher level
of abstraction (the design that guides the simplicity)
65
Satisfaction
needs, points of view
individual collective
A Social Gap:
Satisfaction
XP‫בצוות‬ ‫הפרטים‬ ‫של‬ ‫הצרכים‬ ‫בסיפוק‬ ‫להסתפק‬ ‫לא‬ ‫מנחה‬
‫הצוות‬ ‫חברי‬ ‫שאר‬ ‫צרכי‬ ‫את‬ ‫גם‬ ‫לשקול‬ ‫.אלא‬
66
satisfaction gap:
individual vs. collective satisfaction
 On-site Customer
 enables developers to refrain from making decisions with
respect to customer’s needs without first checking with the
customer as to what is really needed
67
satisfaction 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 that
the collective gains from pair programming
 Coding Standards
 reduces programmers’ tendency to write code in a way that is
understood only to them
68
satisfaction gap (cont):
individual vs. collective satisfaction
 Collective Ownership
 one knows that everyone looks at what one programs and
improves it if it is not good enough
 one postpones immediate satisfaction to move on and
improves one’s code prior to its integration
 Sustainable Pace
 one can dedicate more time to one’s personal life without
having to satisfy the expectations of co-workers to put in long
hours of overtime
69
satisfaction gap (cont):
individual vs. collective satisfaction
 Refactoring
 it is not sufficient that the code passes all tests, it should also
be refactored, restructured and improved
 one should postpone his or her immediate needs and invest
more effort in refactoring before moving on
 Simple design
 it is not sufficient that the code passes all the tests, its design
should also be simplified as much as possible before one
moves on to the next development task
70
Gaps: Summary
A cognitive gap: abstraction
A social gaps: satisfaction
 Suggestions for additional gaps?
71
How eXtreme Programming?
 Refactoring
72
Refactoring in Extreme
Programming
73
Agenda
 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
Introductory Questions
‫עושים‬ ‫אתם‬ ‫מה‬ ?‫שכתבתם‬ ‫מקוד‬ ‫מרוצים‬ ‫לא‬ ‫אתם‬ ‫מתי‬
?‫כאלה‬ ‫במצבים‬
‫כל‬ ‫הקוד‬ ‫את‬ ‫לכתוב‬ ‫מכם‬ ‫מבקשת‬ ‫שלכם‬ ‫הצוות‬ ‫ראש‬
?‫תגיבו‬ ‫כיצד‬ .‫יותר‬ ‫קריא‬ ‫יהיה‬ ‫שהוא‬
‫הוא‬ ‫תוכנה‬ ‫בפיתוח‬ ‫לו‬ ‫שחשוב‬ ‫שמה‬ ‫מספר‬ ‫לצוות‬ ‫חבר‬
‫כל‬ ‫את‬ ‫עובר‬ ‫שכתב‬ ‫שהקוד‬ ‫ברגע‬ ,‫לכן‬ .‫רץ‬ ‫שהקוד‬
‫המבנה‬ ‫את‬ ‫משפר‬ ‫ולא‬ ‫הקוד‬ ‫את‬ ‫עוזב‬ ‫הוא‬ ,‫הבדיקות‬
?‫תגיבו‬ ‫כיצד‬ .‫שלו‬ ‫והעיצוב‬
75
Example
 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
Example
 A given design:
 Is it well designed?
 In what cases may it
cause problems?
 Would you change it?
 If yes:
suggest alternative designs.
77
Example – 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 is
tangled with the presentation logic.
78
Example – Reflection
 How it emerges? – In general
“One day you are adding one little subclass to do a little
job. The next day you are adding other subclasses to do
the same job in other parts of the hierarchy. A week (or
month or year) later you are swimming in spaghetti.
Without a paddle.” (Fowler)
79
Example – 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
Example – 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 subclasses
that begin with the same adjective, you probably are doing two
jobs with one hierarchy.”
 Why it can not be coded “correctly” at the first
stage?
 Step-by-step refactoring (Fowler’s style)
81
Example – Step by Step Refactoring
 First step: identify the jobs being done by the
hierarchy.
 Job #1: capturing variation according to type of deal.
 Job #2: capturing variation according to presentation
style.
82
 Second step: decide which job is more
important.
The dealness of the object is far more
important than the presentation style.
Leave Deal alone and extract the
presentation style to its own hierarchy.
Example – Step by Step Refactoring
83
Example – Step by Step Refactoring
 Third step: use Extract Class to create a
presentation style.
 Extract Class
 You have one class doing work that should be done by
two.
 Create a new class and move the relevant fields and
methods from the old class into the new class.
84
Example – Step by Step Refactoring
 Fourth step: Create subclasses of the extracted
class and initialize the instance variable to the
appropriate subclass.
Adding subclasses of
presentation style
85
Example – Step by Step Refactoring
 Fifth step: Use Move Method and Move Field to
move the presentation-related methods and
variables of the deal subclasses to the
presentation style subclasses.
No code left in the classes
Tabular Active Deal and Tabular
Passive Deal. Remove them.
86
Example – Step by Step Refactoring
 Sixth step: Separate the hierarchies: Distinguish
between single and tabular.
87
Example
Original Refactored

88
Example - Reflection
 What did we do?
 Is there a difference between the two designs? If
yes – what is it?
 How is this change supposed to improve our life?
 In what way may the change be useful for someone
who did not write the code?
 How did the need for refactoring emerge?
 Couldn’t we write the code refactored from the
beginning?
89
Example - Summary
 Tease Apart Inheritance
You have an inheritance hierarchy that is doing
two jobs at once.
Create two hierarchies and use delegation to
invoke one from the other.
 This format guides Fowler’s book.
90
Example - Summary
 Delegation:
 The ability of an object to issue a message to another
object in response to a message. Delegation can be used
as 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
Refactoring
 In what follows:
What is refactoring?
Why refactoring?
When refactoring? When not?
How refactoring?
Why refactoring hard?
XP and refactoring
92
Refactoring
 Fowler: Refactoring is the process of changing a software
system in such a way that it does not alter the external
(observable) behavior of the code yet improves its
internal structure, to make it easier to understand and
cheaper to modify.
 Kent (in Fowler, p. 51): Refactoring is the process of
taking a running program and adding to its value, not by
changing its behavior but by giving it more of these
qualities that enable us to continue developing at speed.
93
Refactoring
 What do programmers do when refactoring:
remove duplication
improve communication and program
comprehension
add simplicity
add flexibility
94
Refactoring – Metaphors
 Three metaphors for refactoring :
relationships with your program
parenthesis
health
95
Refactoring – Metaphors I
[Refactoring] is like a new kind of relationship with your
program. When you really understand refactoring, the
design of the system is as fluid and plastic and moldable
to you as the individual characters in a source code file.
You can feel the whole design at once. You can see how
it might flex and change – a little this way and this is
possible, a little that way and that is possible. (Kent, in
Fowler, p. 333)
96
Refactoring – 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.
Let's take the case of
A.method1() = ... b.doThis(); b.doThat(); ...
I change the code to
B.doThisThat() = doThis(); doThat().
A.method1() = ... b.doThisThat(); ...
97
Refactoring – 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 of
parentheses, and when I move code out of one method
or class to another, I visualize it just as moving symbols
from one set of parentheses to another. Of course, the
net effect of the computation has to be the same, […] it
has to be a behavior preserving transformation.”
98
Refactoring – 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 fooling
ourselves if we continue to ignore good behavior.
 Near-term and long-term benefits.
99
Refactoring
 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
Why 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
Why Refactoring
 Refactoring makes software easier to understand
 helps make your code more readable
 increases program comprehension: leads to higher
levels of understanding that otherwise may be missed
102
Why Refactoring
 Refactoring helps you program faster
sounds counterintuitive
less bugs, no patches
helps correct bugs: errors need to be modified
only in one place
103
Refactoring
 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
When refactoring
 You have written some code. Now, if you work
by 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
When refactoring
Fowler, Chapter 3 – Bad smells in Code
 Duplicated Code:
 “If you see the same code structure in more than one
place, you can be sure that your program will be better
if you find a way to unify them”.
 Extract Method: When you have the same expression
in two methods of the same class.
106
When refactoring
Fowler, Chapter 3 – Bad smells in Code
 Long Method:
 “the longer the procedure is, the more difficult it is to
understand”.
 Extract method: find parts of the methods that seem
to go nicely together and make a new method.
107
When refactoring
Fowler, Chapter 3 – Bad smells in Code
 Comments:
 “if you need a comment to explain what a block of code
does, try Extract Method. If the method is already
extracted but you still need a comment to explain what it
does, use Rename Method.”
 “when you feel the need to write a comment, first try to
refactor the code so that any comment becomes
superfluous”.
 “a comment is a good place to say why you did something.
This kind of information helps future modifiers”.
108
When shouldn't you refactor?
 When the code is a mess and it would
be better to start from the beginning.
 Factors that will be discussed later:
Culture
Internal resistance
109
Refactoring
 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
How Refactoring
 Rasmusson (2002): “The team must refactor all the
time, to the fullest extent. When we didn't follow this
rule, the code became more cumbersome to work
with”.
 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
How 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 the
book.
 Some IDEs (Integrated development environments)
offer Refactoring menu
 Example: Eclipse, IntelliJ
112
Refactoring
 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
Why refactoring hard?
 Sub-questions:
Why people do not refactor naturally?
Why does refactoring raise resistance?
114
Why refactoring hard?
 Culture:
“refactoring is an overhead activity. I’m paid to write
new, 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 develop
code, it is not viewed by you as an additional work.
115
Why refactoring hard?
 Internal resistance: Why are developers reluctant to
refactor? (Opdyke, in Fowler’s book, p. 313)
 it should be executed when the code runs and all the
tests 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 the
project to reap the benefits.
 developers might not understand how to refactor.
 refactoring might break the existing program.
116
Refactoring
 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
XP and Refactoring
 Refactoring is part of eXtreme Programming:
 Refactoring can be carried out without XP, but it has
additional 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
XP and Refactoring
 Mutual relationships of refactoring and other XP practices
Source: Beck, K. (2000).
eXtreme Programming
explained, Addison Wesley.
119
XP and Refactoring
 Connection to XP practices - example
Testing: “Whenever I do refactoring, the first step is
always the same. I need to build a solid set of tests for
that section of code. The tests are essential because
even though I follow refactoring structures to avoid
most of the opportunities for introducing bugs, I'm still
human and still make mistakes.Thus I need solid
tests.” (Fowler, p. 17)
120
Refactoring
 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
Refactoring – Summary
 Refactoring requires awareness!
 Main Message:
 We should not skip refactoring.
 Software development is a process that cannot be
envisioned in advance.
 Refactoring can be performed without XP but it gets its
power from its integration with the other XP practices.
 Refactoring may improve programming skills.
122
Summary
eXtreme programming:
 What?
 Why?
 How?
123
Conferences
 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
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/whatIsXp.php
125
 Questions (Musical cards)
126
Appendices
 XP and the CMM
 XP conception of failure and success
127
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.
128
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.
129
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.
130
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.
131
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.
132
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”.
133
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.
134
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.

More Related Content

What's hot

ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)Amardeep Vishwakarma
 
Xp(Xtreme Programming) presentation
Xp(Xtreme Programming) presentationXp(Xtreme Programming) presentation
Xp(Xtreme Programming) presentationMuaazZubairi
 
Invincible React States with Domain Driven Design
Invincible React States with Domain Driven Design Invincible React States with Domain Driven Design
Invincible React States with Domain Driven Design Prateek
 
Lean Implementation of Organizational Process Focus (OPF) and Risk Management...
Lean Implementation of Organizational Process Focus (OPF) and Risk Management...Lean Implementation of Organizational Process Focus (OPF) and Risk Management...
Lean Implementation of Organizational Process Focus (OPF) and Risk Management...aamahdys
 
eXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OvervieweXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OverviewGurtej Pal Singh
 
Introduction to Extreme Programming
Introduction to Extreme ProgrammingIntroduction to Extreme Programming
Introduction to Extreme ProgrammingNaresh Jain
 
Extreme programming - a quick and agile overview !
Extreme programming - a quick and agile overview !Extreme programming - a quick and agile overview !
Extreme programming - a quick and agile overview !Vinit Kumar Singh
 
Sterling Barton Movemements of a Hypnotic Nature
Sterling Barton Movemements of a Hypnotic NatureSterling Barton Movemements of a Hypnotic Nature
Sterling Barton Movemements of a Hypnotic NatureBrent Barton
 
Xp exterme-programming-model
Xp exterme-programming-modelXp exterme-programming-model
Xp exterme-programming-modelAli MasudianPour
 
Pm soln9416141129710
Pm soln9416141129710Pm soln9416141129710
Pm soln9416141129710Nikhil Todkar
 
Is software engineering research addressing software engineering problems?
Is software engineering research addressing software engineering problems?Is software engineering research addressing software engineering problems?
Is software engineering research addressing software engineering problems?Gail Murphy
 
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt Neil Ernst
 
Waterfallacies V1 1
Waterfallacies V1 1Waterfallacies V1 1
Waterfallacies V1 1Jorge Boria
 
Agile Software Development Approaches
Agile Software Development ApproachesAgile Software Development Approaches
Agile Software Development Approachesdcsunu
 
IS3242 Case Presentation
IS3242 Case PresentationIS3242 Case Presentation
IS3242 Case PresentationJ M
 
Technical Debt - PHPBenelux
Technical Debt - PHPBeneluxTechnical Debt - PHPBenelux
Technical Debt - PHPBeneluxenaramore
 
Workshop on software product development the backdrop
Workshop on software product development   the backdropWorkshop on software product development   the backdrop
Workshop on software product development the backdropJoy Prabhakaran
 
Extreme programming (xp) | David Tzemach
Extreme programming (xp) | David TzemachExtreme programming (xp) | David Tzemach
Extreme programming (xp) | David TzemachDavid Tzemach
 

What's hot (20)

ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)ABC of Agile (Scrum & Extreme Programming)
ABC of Agile (Scrum & Extreme Programming)
 
Xp(Xtreme Programming) presentation
Xp(Xtreme Programming) presentationXp(Xtreme Programming) presentation
Xp(Xtreme Programming) presentation
 
Invincible React States with Domain Driven Design
Invincible React States with Domain Driven Design Invincible React States with Domain Driven Design
Invincible React States with Domain Driven Design
 
XP In 10 slides
XP In 10 slidesXP In 10 slides
XP In 10 slides
 
Lean Implementation of Organizational Process Focus (OPF) and Risk Management...
Lean Implementation of Organizational Process Focus (OPF) and Risk Management...Lean Implementation of Organizational Process Focus (OPF) and Risk Management...
Lean Implementation of Organizational Process Focus (OPF) and Risk Management...
 
eXtreme programming (XP) - An Overview
eXtreme programming (XP) - An OvervieweXtreme programming (XP) - An Overview
eXtreme programming (XP) - An Overview
 
Introduction to Extreme Programming
Introduction to Extreme ProgrammingIntroduction to Extreme Programming
Introduction to Extreme Programming
 
Extreme programming - a quick and agile overview !
Extreme programming - a quick and agile overview !Extreme programming - a quick and agile overview !
Extreme programming - a quick and agile overview !
 
Sterling Barton Movemements of a Hypnotic Nature
Sterling Barton Movemements of a Hypnotic NatureSterling Barton Movemements of a Hypnotic Nature
Sterling Barton Movemements of a Hypnotic Nature
 
Xp exterme-programming-model
Xp exterme-programming-modelXp exterme-programming-model
Xp exterme-programming-model
 
Pm soln9416141129710
Pm soln9416141129710Pm soln9416141129710
Pm soln9416141129710
 
Is software engineering research addressing software engineering problems?
Is software engineering research addressing software engineering problems?Is software engineering research addressing software engineering problems?
Is software engineering research addressing software engineering problems?
 
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt
Measure It, Manage It, Ignore It - Software Practitioners and Technical Debt
 
Waterfallacies V1 1
Waterfallacies V1 1Waterfallacies V1 1
Waterfallacies V1 1
 
Agile Software Development Approaches
Agile Software Development ApproachesAgile Software Development Approaches
Agile Software Development Approaches
 
IS3242 Case Presentation
IS3242 Case PresentationIS3242 Case Presentation
IS3242 Case Presentation
 
Technical Debt - PHPBenelux
Technical Debt - PHPBeneluxTechnical Debt - PHPBenelux
Technical Debt - PHPBenelux
 
Extreme Programming ppt
Extreme Programming pptExtreme Programming ppt
Extreme Programming ppt
 
Workshop on software product development the backdrop
Workshop on software product development   the backdropWorkshop on software product development   the backdrop
Workshop on software product development the backdrop
 
Extreme programming (xp) | David Tzemach
Extreme programming (xp) | David TzemachExtreme programming (xp) | David Tzemach
Extreme programming (xp) | David Tzemach
 

Viewers also liked

Stress management
Stress managementStress management
Stress managementJean Pаoli
 
Mgmt forum MTC 5
Mgmt forum MTC 5Mgmt forum MTC 5
Mgmt forum MTC 5Jean Pаoli
 
Innovation management speaker notes
Innovation management speaker notesInnovation management speaker notes
Innovation management speaker notesJean Pаoli
 
Design patterns intro
Design patterns introDesign patterns intro
Design patterns introJean Pаoli
 
CMMi 4 techstaff
CMMi 4 techstaffCMMi 4 techstaff
CMMi 4 techstaffJean Pаoli
 
SW development process and the leading indicator
SW development process and the leading indicatorSW development process and the leading indicator
SW development process and the leading indicatorJean Pаoli
 
Cohr managing stress training
Cohr managing stress trainingCohr managing stress training
Cohr managing stress trainingJean Pаoli
 
Effective prioritization & zbb
Effective prioritization & zbbEffective prioritization & zbb
Effective prioritization & zbbJean Pаoli
 
PMC post implementation review
PMC post implementation reviewPMC post implementation review
PMC post implementation reviewJean Pаoli
 
Diversity in thinking styles (part 1)
Diversity in thinking styles (part 1)Diversity in thinking styles (part 1)
Diversity in thinking styles (part 1)Jean Pаoli
 

Viewers also liked (16)

Stress management
Stress managementStress management
Stress management
 
Stress
StressStress
Stress
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Mgmt forum MTC 5
Mgmt forum MTC 5Mgmt forum MTC 5
Mgmt forum MTC 5
 
08060 c foils
08060 c foils08060 c foils
08060 c foils
 
Innovation management speaker notes
Innovation management speaker notesInnovation management speaker notes
Innovation management speaker notes
 
Design patterns intro
Design patterns introDesign patterns intro
Design patterns intro
 
CMMi 4 techstaff
CMMi 4 techstaffCMMi 4 techstaff
CMMi 4 techstaff
 
SW development process and the leading indicator
SW development process and the leading indicatorSW development process and the leading indicator
SW development process and the leading indicator
 
Cohr managing stress training
Cohr managing stress trainingCohr managing stress training
Cohr managing stress training
 
Effective prioritization & zbb
Effective prioritization & zbbEffective prioritization & zbb
Effective prioritization & zbb
 
PMC post implementation review
PMC post implementation reviewPMC post implementation review
PMC post implementation review
 
PMP study TTT
PMP study TTTPMP study TTT
PMP study TTT
 
Diversity in thinking styles (part 1)
Diversity in thinking styles (part 1)Diversity in thinking styles (part 1)
Diversity in thinking styles (part 1)
 
Pmp study: time
Pmp study: timePmp study: time
Pmp study: time
 
Unified process
Unified processUnified process
Unified process
 

Similar to eXtreme programming

Agile Development Ultimate Slides
Agile Development Ultimate SlidesAgile Development Ultimate Slides
Agile Development Ultimate Slidesgilashikwa
 
Periodic Table of Agile Principles and Practices
Periodic Table of Agile Principles and PracticesPeriodic Table of Agile Principles and Practices
Periodic Table of Agile Principles and PracticesJérôme Kehrli
 
se01.ppt
se01.pptse01.ppt
se01.pptxiso
 
Extreme programming
Extreme programmingExtreme programming
Extreme programmingMr SMAK
 
Agile Values, Principles and Practices
Agile Values, Principles and PracticesAgile Values, Principles and Practices
Agile Values, Principles and Practicesjackcrews
 
Xp presentation 2003
Xp presentation 2003Xp presentation 2003
Xp presentation 2003eaiti
 
Extreme Programming (XP) as A Popular Agile methodology.
Extreme Programming (XP) as A Popular Agile methodology.Extreme Programming (XP) as A Popular Agile methodology.
Extreme Programming (XP) as A Popular Agile methodology.Ali Shaikh
 
Mca5020 advanced software engineering-de
Mca5020   advanced software engineering-deMca5020   advanced software engineering-de
Mca5020 advanced software engineering-desmumbahelp
 
Agile And Agile Software Development
Agile And Agile Software DevelopmentAgile And Agile Software Development
Agile And Agile Software DevelopmentAmanda Hengel
 
An Introduction to Extreme Programming (XP) Development Methodology Process i...
An Introduction to Extreme Programming (XP) Development Methodology Process i...An Introduction to Extreme Programming (XP) Development Methodology Process i...
An Introduction to Extreme Programming (XP) Development Methodology Process i...Salus One Ed
 
1.extreme programming-NCCA
1.extreme programming-NCCA1.extreme programming-NCCA
1.extreme programming-NCCAGTU
 
XP vs Lean vs FDD
XP vs Lean vs FDDXP vs Lean vs FDD
XP vs Lean vs FDDSuman Guha
 
Extreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP PracticesExtreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP PracticesDavid Hanson
 
Mca5020 advanced software engineering-de
Mca5020   advanced software engineering-deMca5020   advanced software engineering-de
Mca5020 advanced software engineering-desmumbahelp
 
Developing An Information System Development
Developing An Information System DevelopmentDeveloping An Information System Development
Developing An Information System DevelopmentSandra Gibson
 
Georgia State Presentation
Georgia State PresentationGeorgia State Presentation
Georgia State Presentationpatrickbrandt
 
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
Extreme  Programming    Talk Wise  Consulting   Www.TalkwiseconsultingExtreme  Programming    Talk Wise  Consulting   Www.Talkwiseconsulting
Extreme Programming Talk Wise Consulting Www.Talkwiseconsultingtalkwiseone
 

Similar to eXtreme programming (20)

Agile Development Ultimate Slides
Agile Development Ultimate SlidesAgile Development Ultimate Slides
Agile Development Ultimate Slides
 
Periodic Table of Agile Principles and Practices
Periodic Table of Agile Principles and PracticesPeriodic Table of Agile Principles and Practices
Periodic Table of Agile Principles and Practices
 
se01.ppt
se01.pptse01.ppt
se01.ppt
 
Agile Engineering Practices
Agile Engineering PracticesAgile Engineering Practices
Agile Engineering Practices
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Agile Values, Principles and Practices
Agile Values, Principles and PracticesAgile Values, Principles and Practices
Agile Values, Principles and Practices
 
Xp presentation 2003
Xp presentation 2003Xp presentation 2003
Xp presentation 2003
 
Extreme Programming (XP) as A Popular Agile methodology.
Extreme Programming (XP) as A Popular Agile methodology.Extreme Programming (XP) as A Popular Agile methodology.
Extreme Programming (XP) as A Popular Agile methodology.
 
Mca5020 advanced software engineering-de
Mca5020   advanced software engineering-deMca5020   advanced software engineering-de
Mca5020 advanced software engineering-de
 
Agile And Agile Software Development
Agile And Agile Software DevelopmentAgile And Agile Software Development
Agile And Agile Software Development
 
An Introduction to Extreme Programming (XP) Development Methodology Process i...
An Introduction to Extreme Programming (XP) Development Methodology Process i...An Introduction to Extreme Programming (XP) Development Methodology Process i...
An Introduction to Extreme Programming (XP) Development Methodology Process i...
 
A littlebook about agile
A littlebook about agileA littlebook about agile
A littlebook about agile
 
1.extreme programming-NCCA
1.extreme programming-NCCA1.extreme programming-NCCA
1.extreme programming-NCCA
 
Xp Slideshow
Xp SlideshowXp Slideshow
Xp Slideshow
 
XP vs Lean vs FDD
XP vs Lean vs FDDXP vs Lean vs FDD
XP vs Lean vs FDD
 
Extreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP PracticesExtreme Programming: An Introduction to XP Practices
Extreme Programming: An Introduction to XP Practices
 
Mca5020 advanced software engineering-de
Mca5020   advanced software engineering-deMca5020   advanced software engineering-de
Mca5020 advanced software engineering-de
 
Developing An Information System Development
Developing An Information System DevelopmentDeveloping An Information System Development
Developing An Information System Development
 
Georgia State Presentation
Georgia State PresentationGeorgia State Presentation
Georgia State Presentation
 
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
Extreme  Programming    Talk Wise  Consulting   Www.TalkwiseconsultingExtreme  Programming    Talk Wise  Consulting   Www.Talkwiseconsulting
Extreme Programming Talk Wise Consulting Www.Talkwiseconsulting
 

Recently uploaded

Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 

Recently uploaded (20)

Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 

eXtreme programming

  • 1. 1 eXtreme Programming ‫תוכנה‬ ‫פרויקטי‬ ‫לפיתוח‬ ‫מתודולוגיה‬ ‫חזן‬ ‫אורית‬ ‫ד"ר‬ ‫והמדעים‬ ‫הטכנולוגיה‬ ‫להוראת‬ ‫המחלקה‬ ‫הטכניון‬
  • 2. 2 eXtreme 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. 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 monthly 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?
  • 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, HP  smaller software houses:  Mayford Technologies  RoleModel Software  tutorials: Industrial Logic, Object Mentor
  • 11. 11 How eXtreme Programming? Two days in eXtreme Programming Development Environment
  • 12. 12 How eXtreme Programming? Business Day ‫מיומנויות‬ ‫יישום‬XP‫דרישות‬ ‫להגדרת‬ ‫הקשורות‬ ‫הפיתוח‬ ‫תהליך‬ ‫ותכנון‬ ‫התוכנה‬ ‫נושא‬ ‫בחירת‬ ‫במיומנויות‬ ‫התנסות‬
  • 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
  • 18. 18 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/
  • 19. 19 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
  • 20. 20 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
  • 21. 21 Development and Business Days – Reflection Code/Technical Perspective Human/Social Perspective Refactoring Simple design Coding standards Testing Continuous integration Small releases Collective ownership Pair programming Sustainable pace On-site customer Planning game Metaphor
  • 22. 22 The 12 XP practices Note: nothing is new; gathering the practices together is XP uniqueness Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
  • 23. 23 eXtreme 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. 24 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
  • 25. 25 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/  eXtreme Programming: Kent Beck, 1996, Chrysler
  • 26. 26 Why XP?  You do not do XP to save money; However, XP shortens time to market  XP is a mature software development method
  • 27. 27 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
  • 28. 28 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
  • 29. 29 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)
  • 30. 30 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
  • 31. 31 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.
  • 32. 32 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)
  • 33. 33 XP in Practice: Conceptual Changes  XP encourages: Cooperation (vs. knowledge-is-power) Simplicity (vs. habit-of-high-complexity) Change in work habits
  • 34. 34 Why XP? – Cognitive and Social Analysis ‫היישעתב החמצלחת‬‫ה‬ ‫הסבר‬XP.‫וחברתית‬ ‫קוגניטיבית‬ ‫מבט‬ ‫מנקודת‬ Prisoner’s Dilemma  Analysis of XP within the framework of the Prisoner’s dilemma Constructivism  Analysis of XP within the framework of constructivism  GAPS (abstraction, satisfaction)
  • 36. 36 Game Theory ‫כאשר‬ ‫החלטות‬ ‫וקבלת‬ ‫התנהגות‬ ‫ניתוח‬ ‫אחד‬ ‫כל‬ ‫של‬ ‫מהחלטות‬ ‫הנובעות‬ ‫תוצאות‬ ‫תלויות‬ "‫ב"משחק‬ ‫מהמשתתפים‬ .‫האחרים‬ ‫המשתתפים‬ ‫של‬ ‫בהחלטות‬
  • 37. 37 The Prisoner’s Dilemma: A’s perspective B cooperates B competes A cooperates +5 -10 A competes +10 0
  • 38. 38 The Prisoner’s Dilemma: The case of software engineering – A’s perspective, Bonus B cooperates B competes A cooperates 50% 20% A competes 80% 0%
  • 39. 39 The Prisoner’s Dilemma: The case of software engineering – A’s perspective B cooperates B competes A cooperates +5 -10 A competes +10 -20
  • 40. 40 The Prisoner’s Dilemma: The case of software engineering .‫עמיתיהם‬ ‫עם‬ ‫פעולה‬ ‫לשתף‬ ‫מתבקשים‬ ‫תוכנה‬ ‫מפתחי‬ ‫בד"כ‬ ‫שלהם‬ ‫הפעולה‬ ‫ששיתוף‬ ‫לוודא‬ ‫אפשרות‬ ‫אין‬ ‫התוכנה‬ ‫למפתחי‬ .‫הדדי‬ ‫יהיה‬ :‫האסיר‬ ‫דילמת‬ ‫לפי‬‫לשתף‬ ‫)לא‬ ‫לבגוד‬ ‫יעדיפו‬ ‫הצוות‬ ‫חברי‬ ‫כל‬ .(‫פעולה‬ ‫הגרועות‬ ‫לתוצאות‬ ‫מביאה‬ ‫תוכנה‬ ‫בפיתוח‬ ‫כזו‬ ‫התנהגות‬ .‫הצוות‬ ‫חברי‬ ‫לכל‬ ‫ביותר‬
  • 41. 41 The Prisoner’s Dilemma: The case of eXtreme Programming ‫הצוות‬ ‫חברי‬ ‫התחייבות‬‫על-פי‬ ‫לעבוד‬XP‫שכל‬ ‫מבטיחה‬ ‫של‬ ‫המיומנויות‬ ‫על-פי‬ ‫יעבדו‬ ‫הצוות‬ ‫חברי‬XP. ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫שאר‬ ‫שגם‬ (‫יודע)ת‬ ‫צוות‬ (‫חבר)ת‬ ‫כל‬ .‫מיומנויות‬ ‫אותן‬ ‫לפי‬ ‫לעבוד‬ ‫האי-וודאות‬ ‫גורם‬(‫האסיר‬ ‫לדילמת‬ ‫המקור‬ ‫את‬ ‫)המהווה‬‫לא‬ .‫קיים‬ .‫מכך‬ ‫הרווחים‬ ‫את‬ ‫ויפיקו‬ ‫פעולה‬ ‫ישתפו‬ ‫כולם‬
  • 42. 42 The Prisoner’s Dilemma: The case of Extreme Programming – A’s perspective B cooperates A cooperates +5
  • 43. 43 In what follows -‫ל‬ ‫ביחס‬2-‫ו‬ ‫ערכים‬4‫של‬ ‫מיומנויות‬XP: .‫מהם‬ ‫הנובעת‬ ‫פעולה‬ ‫שיתוף‬ ‫של‬ ‫המשמעות‬ ‫מהי‬ ‫על-פי‬ ‫לעבוד‬ ‫מחויב‬ ‫הצוות‬ ‫שכל‬ ‫מהעובדה‬XP‫אחד‬ ‫שכל‬ ‫נובע‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫ניצבים‬ ‫אינם‬ ‫הצוות‬ ‫מחברי‬ ‫ואחת‬ ‫פעולה‬(‫המיומנות‬ ‫או‬ ‫מהערך‬ ‫הנובע‬ ‫מובן‬ ‫)באותו‬. ‫שנובע‬ ‫מהיתרון‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬ ‫מיומנות‬ ‫או‬ ‫ערך‬ ‫מאותו‬. .‫זה‬ ‫פעולה‬ ‫משיתוף‬ ‫נתרם‬ ‫התוכנה‬ ‫פרויקט‬ ‫כל‬
  • 44. 44 The Prisoner’s Dilemma: The value of courage :‫פעולה‬ ‫שיתוף‬ .‫בעיה‬ ‫יש‬ ‫כאשר‬ ‫מתריעים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬ .‫ידע‬ ‫להם‬ ‫חסר‬ ‫כאשר‬ ‫להודות‬ ‫מתביישים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬ .‫עמיתיהם‬ ‫של‬ ‫קוד‬ ‫לשנות‬ ‫חוששים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬ ‫היא‬ ‫הפיתוח‬ ‫שסביבת‬ ‫מכיוון‬XP‫לא‬ ‫שהם‬ (‫יודע)ת‬ (‫אחד)ת‬ ‫כל‬ , ‫שיפגינו‬ ‫היחידים‬courage‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬ ‫הם‬ ‫ולכן‬ .‫פעולה‬ ‫לשתף‬ .‫זה‬ ‫מערך‬ ‫מרוויחים‬ ‫הצוות‬ ‫וחברי‬ ‫הפרויקט‬
  • 45. 45 The Prisoner’s Dilemma: The value of simplicity :‫פעולה‬ ‫שיתוף‬ ‫הפשוטה‬ ‫בצורה‬ ‫התוכנה‬ ‫בפיתוח‬ ‫הקשורות‬ ‫הפעולות‬ ‫כל‬ ‫יישום‬ .‫ביותר‬ .‫קוד‬ ‫מסבכים‬ ‫לא‬ ,‫למשל‬ ‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP‫לערך‬ ‫גם‬ ‫מחויבים‬ ‫ולכן‬ .‫הזה‬ .‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫ניצבים‬ ‫לא‬ .‫מרוויחים‬ ‫וכולם‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬
  • 46. 46 The Prisoner’s Dilemma: Collective Ownership  In practice “[a]nyone can change any code anywhere in the system at any time.” (Beck, 2000). :‫פעולה‬ ‫שיתוף‬.‫בקוד‬ ‫שיתוף‬:‫בגידה‬.‫קוד‬ ‫הסתרת‬ ‫על-פי‬ ‫עובדים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬ .‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬ ‫פיתוח‬ ‫לתהליכי‬ ‫תורם‬ ‫הדבר‬ ,‫פעולה‬ ‫משתפים‬ ‫כולם‬ .‫נשכרים‬ ‫יוצאים‬ ‫וכולם‬ ‫התוכנה‬
  • 47. 47 The Prisoner’s Dilemma: Coding Standards :‫פעולה‬ ‫שיתוף‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫לפי‬ ‫פיתוח‬ :‫בגידה‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫על-פי‬ ‫לא‬ ‫פיתוח‬ ‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP‫ועל-פי‬ ‫בכלל‬ .‫בפרט‬ ‫זו‬ ‫מיומנות‬ .‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬ .‫סטנדרטים‬ ‫פי‬ ‫על‬ ‫קוד‬ ‫שבפיתוח‬
  • 48. 48 The Prisoner’s Dilemma: Simple Design ‫מהערך‬ ‫נובע‬Simplicity :‫פעולה‬ ‫שיתוף‬;‫האפשר‬ ‫ככל‬ ‫פשוט‬ ‫פיתוח‬:‫בגידה‬‫פיתוח‬ .‫הבנה‬ ‫על‬ ‫להקשות‬ ‫היכול‬ ‫מסובך‬ ‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬ .‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬ .‫שניתן‬ ‫ככל‬ ‫פשוט‬
  • 49. 49 The Prisoner’s Dilemma: Sustainable Pace ‫בן‬ ‫עבדה‬ ‫שבוע‬40.‫חריגים‬ ‫מקרים‬ ‫למעט‬ ,‫שעות‬ :‫רציונאל‬.‫איכותי‬ ‫קוד‬ ‫מייצרים‬ ‫אינם‬ ‫עייפים‬ ‫מפתחים‬ ‫אחרות‬ ‫מיומנויות‬)e.g., Pair Programming(.‫זה‬ ‫זמן‬ ‫של‬ ‫יעיל‬ ‫ניצול‬ ‫מבטיחות‬ :‫פעולה‬ ‫שיתוף‬‫עובדים‬8-9;‫ביום‬:‫בגידה‬‫שעות‬ ‫במשך‬ ‫עבודה‬ ‫יותר‬ ‫רבות‬(‫להרשים‬ ‫מנת‬ ‫על‬ ,‫)למשל‬. ‫לפי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP.‫זו‬ ‫מיומנות‬ ‫לפי‬ ‫גם‬ ‫ולכן‬ .‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫בקצב‬ ‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬ .‫בו‬ ‫לעמוד‬ ‫שניתן‬
  • 51. 51 Why XP? :‫טענה‬‫תהליך‬ ‫היא‬ ‫תוכנה‬ ‫פיתוח‬ ‫סביבת‬ ‫הבנת‬ ;‫מורכב‬XP.‫זה‬ ‫הבנה‬ ‫בתהליך‬ ‫תומכת‬ :‫קונסטרקטיביזם‬ .‫למידה‬ ‫תהליכי‬ ‫המסבירה‬ ‫תיאוריה‬ ‫ועידון‬ ‫ארגון‬ ‫ע"י‬ ,‫קיימים‬ ‫מושגים‬ ‫בסיס‬ ‫על‬ ‫בהדרגה‬ ‫נבנה‬ ‫חדש‬ ‫ידע‬ .‫קיימים‬ ‫מנטאליים‬ ‫מבנים‬ ‫בתהליך‬ ‫חשוב‬ ‫תפקיד‬ ‫הלמידה‬ ‫מסביבת‬ ‫שמתקבל‬ ‫למשוב‬ .‫הלמידה‬
  • 52. 52 ‫של‬ ‫קוגניטיבי‬ ‫ניתוח‬XP ‫בחינת‬4‫מתוך‬12‫של‬ ‫המיומנויות‬XP‫דרך‬‫משקפיים‬ ‫קונסטרוקטיביסטיות‬. ‫תומכים‬ ‫אלו‬ ‫מיומנויות‬‫סביבת‬ ‫של‬ ‫הדרגתית‬ ‫בהבנה‬ ‫הפיתוח‬. ‫הערכים‬Communication-‫ו‬Feedback.‫תורמים‬ ‫הם‬ ‫אף‬
  • 53. 53 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
  • 54. 54 Cognitive and Social Analysis of XP practices Cognitive analysis Social analysis Refactoring Metaphor Test-first Small releases Collective ownership Sustainable pace Simple design Coding standards
  • 55. 55 Bridging Cognitive and Social Gaps in Software Development using Extreme Programming Based on: Hazzan, O. and Dubinsky, Y. (2003). Bridging cognitive and social chasms in software development using Extreme Programming, Proceedings of the Fourth International Conference 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. 61 Abstraction levelsingle multiple A Cognitive Gap: Abstraction XP‫ביניהן‬ ‫המעבר‬ ‫ואת‬ ‫שונות‬ ‫הפשטה‬ ‫ברמות‬ ‫חשיבה‬ ‫.מנחה‬
  • 62. 62 abstraction gap: single vs. multiple abstraction level  Planning Game  the release planning game is carried out on a high level of abstraction; in the release planning a global view is gained  the iteration planning game is carried out on a lower level of abstraction; details are added only with respect to the forthcoming iteration  the entire team participates in the planning game; developers see the entire picture of the system (and its parts)
  • 63. 63 abstraction gap (cont): single vs. multiple abstraction level  Small Releases  guide not to stay for too long a time in too high level of abstraction or too low level of abstraction  Pair Programming  the two individuals in the pair think at different levels of abstraction; the same development task is thought about at two different levels of abstraction
  • 64. 64 abstraction gap (cont): single vs. multiple abstraction level  Sustainable Pace  enables detachment from the details involved in software development and thinking on higher levels of abstraction  Refactoring and Simple Design  in order to improve a piece of code one has to examine it from a higher level of abstraction  examining low level of abstraction (the code) from higher level of abstraction (the design that guides the simplicity)
  • 65. 65 Satisfaction needs, points of view individual collective A Social Gap: Satisfaction XP‫בצוות‬ ‫הפרטים‬ ‫של‬ ‫הצרכים‬ ‫בסיפוק‬ ‫להסתפק‬ ‫לא‬ ‫מנחה‬ ‫הצוות‬ ‫חברי‬ ‫שאר‬ ‫צרכי‬ ‫את‬ ‫גם‬ ‫לשקול‬ ‫.אלא‬
  • 66. 66 satisfaction gap: individual vs. collective satisfaction  On-site Customer  enables developers to refrain from making decisions with respect to customer’s needs without first checking with the customer as to what is really needed
  • 67. 67 satisfaction 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 that the collective gains from pair programming  Coding Standards  reduces programmers’ tendency to write code in a way that is understood only to them
  • 68. 68 satisfaction gap (cont): individual vs. collective satisfaction  Collective Ownership  one knows that everyone looks at what one programs and improves it if it is not good enough  one postpones immediate satisfaction to move on and improves one’s code prior to its integration  Sustainable Pace  one can dedicate more time to one’s personal life without having to satisfy the expectations of co-workers to put in long hours of overtime
  • 69. 69 satisfaction gap (cont): individual vs. collective satisfaction  Refactoring  it is not sufficient that the code passes all tests, it should also be refactored, restructured and improved  one should postpone his or her immediate needs and invest more effort in refactoring before moving on  Simple design  it is not sufficient that the code passes all the tests, its design should also be simplified as much as possible before one moves on to the next development task
  • 70. 70 Gaps: Summary A cognitive gap: abstraction A social gaps: satisfaction  Suggestions for additional gaps?
  • 73. 73 Agenda  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. 74 Introductory Questions ‫עושים‬ ‫אתם‬ ‫מה‬ ?‫שכתבתם‬ ‫מקוד‬ ‫מרוצים‬ ‫לא‬ ‫אתם‬ ‫מתי‬ ?‫כאלה‬ ‫במצבים‬ ‫כל‬ ‫הקוד‬ ‫את‬ ‫לכתוב‬ ‫מכם‬ ‫מבקשת‬ ‫שלכם‬ ‫הצוות‬ ‫ראש‬ ?‫תגיבו‬ ‫כיצד‬ .‫יותר‬ ‫קריא‬ ‫יהיה‬ ‫שהוא‬ ‫הוא‬ ‫תוכנה‬ ‫בפיתוח‬ ‫לו‬ ‫שחשוב‬ ‫שמה‬ ‫מספר‬ ‫לצוות‬ ‫חבר‬ ‫כל‬ ‫את‬ ‫עובר‬ ‫שכתב‬ ‫שהקוד‬ ‫ברגע‬ ,‫לכן‬ .‫רץ‬ ‫שהקוד‬ ‫המבנה‬ ‫את‬ ‫משפר‬ ‫ולא‬ ‫הקוד‬ ‫את‬ ‫עוזב‬ ‫הוא‬ ,‫הבדיקות‬ ?‫תגיבו‬ ‫כיצד‬ .‫שלו‬ ‫והעיצוב‬
  • 75. 75 Example  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. 76 Example  A given design:  Is it well designed?  In what cases may it cause problems?  Would you change it?  If yes: suggest alternative designs.
  • 77. 77 Example – 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 is tangled with the presentation logic.
  • 78. 78 Example – Reflection  How it emerges? – In general “One day you are adding one little subclass to do a little job. The next day you are adding other subclasses to do the same job in other parts of the hierarchy. A week (or month or year) later you are swimming in spaghetti. Without a paddle.” (Fowler)
  • 79. 79 Example – 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. 80 Example – 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 subclasses that begin with the same adjective, you probably are doing two jobs with one hierarchy.”  Why it can not be coded “correctly” at the first stage?  Step-by-step refactoring (Fowler’s style)
  • 81. 81 Example – Step by Step Refactoring  First step: identify the jobs being done by the hierarchy.  Job #1: capturing variation according to type of deal.  Job #2: capturing variation according to presentation style.
  • 82. 82  Second step: decide which job is more important. The dealness of the object is far more important than the presentation style. Leave Deal alone and extract the presentation style to its own hierarchy. Example – Step by Step Refactoring
  • 83. 83 Example – Step by Step Refactoring  Third step: use Extract Class to create a presentation style.  Extract Class  You have one class doing work that should be done by two.  Create a new class and move the relevant fields and methods from the old class into the new class.
  • 84. 84 Example – Step by Step Refactoring  Fourth step: Create subclasses of the extracted class and initialize the instance variable to the appropriate subclass. Adding subclasses of presentation style
  • 85. 85 Example – Step by Step Refactoring  Fifth step: Use Move Method and Move Field to move the presentation-related methods and variables of the deal subclasses to the presentation style subclasses. No code left in the classes Tabular Active Deal and Tabular Passive Deal. Remove them.
  • 86. 86 Example – Step by Step Refactoring  Sixth step: Separate the hierarchies: Distinguish between single and tabular.
  • 88. 88 Example - Reflection  What did we do?  Is there a difference between the two designs? If yes – what is it?  How is this change supposed to improve our life?  In what way may the change be useful for someone who did not write the code?  How did the need for refactoring emerge?  Couldn’t we write the code refactored from the beginning?
  • 89. 89 Example - Summary  Tease Apart Inheritance You have an inheritance hierarchy that is doing two jobs at once. Create two hierarchies and use delegation to invoke one from the other.  This format guides Fowler’s book.
  • 90. 90 Example - Summary  Delegation:  The ability of an object to issue a message to another object in response to a message. Delegation can be used as 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. 91 Refactoring  In what follows: What is refactoring? Why refactoring? When refactoring? When not? How refactoring? Why refactoring hard? XP and refactoring
  • 92. 92 Refactoring  Fowler: Refactoring is the process of changing a software system in such a way that it does not alter the external (observable) behavior of the code yet improves its internal structure, to make it easier to understand and cheaper to modify.  Kent (in Fowler, p. 51): Refactoring is the process of taking a running program and adding to its value, not by changing its behavior but by giving it more of these qualities that enable us to continue developing at speed.
  • 93. 93 Refactoring  What do programmers do when refactoring: remove duplication improve communication and program comprehension add simplicity add flexibility
  • 94. 94 Refactoring – Metaphors  Three metaphors for refactoring : relationships with your program parenthesis health
  • 95. 95 Refactoring – Metaphors I [Refactoring] is like a new kind of relationship with your program. When you really understand refactoring, the design of the system is as fluid and plastic and moldable to you as the individual characters in a source code file. You can feel the whole design at once. You can see how it might flex and change – a little this way and this is possible, a little that way and that is possible. (Kent, in Fowler, p. 333)
  • 96. 96 Refactoring – 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. Let's take the case of A.method1() = ... b.doThis(); b.doThat(); ... I change the code to B.doThisThat() = doThis(); doThat(). A.method1() = ... b.doThisThat(); ...
  • 97. 97 Refactoring – 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 of parentheses, and when I move code out of one method or class to another, I visualize it just as moving symbols from one set of parentheses to another. Of course, the net effect of the computation has to be the same, […] it has to be a behavior preserving transformation.”
  • 98. 98 Refactoring – 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 fooling ourselves if we continue to ignore good behavior.  Near-term and long-term benefits.
  • 99. 99 Refactoring  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. 100 Why 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. 101 Why Refactoring  Refactoring makes software easier to understand  helps make your code more readable  increases program comprehension: leads to higher levels of understanding that otherwise may be missed
  • 102. 102 Why Refactoring  Refactoring helps you program faster sounds counterintuitive less bugs, no patches helps correct bugs: errors need to be modified only in one place
  • 103. 103 Refactoring  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. 104 When refactoring  You have written some code. Now, if you work by 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. 105 When refactoring Fowler, Chapter 3 – Bad smells in Code  Duplicated Code:  “If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them”.  Extract Method: When you have the same expression in two methods of the same class.
  • 106. 106 When refactoring Fowler, Chapter 3 – Bad smells in Code  Long Method:  “the longer the procedure is, the more difficult it is to understand”.  Extract method: find parts of the methods that seem to go nicely together and make a new method.
  • 107. 107 When refactoring Fowler, Chapter 3 – Bad smells in Code  Comments:  “if you need a comment to explain what a block of code does, try Extract Method. If the method is already extracted but you still need a comment to explain what it does, use Rename Method.”  “when you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous”.  “a comment is a good place to say why you did something. This kind of information helps future modifiers”.
  • 108. 108 When shouldn't you refactor?  When the code is a mess and it would be better to start from the beginning.  Factors that will be discussed later: Culture Internal resistance
  • 109. 109 Refactoring  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. 110 How Refactoring  Rasmusson (2002): “The team must refactor all the time, to the fullest extent. When we didn't follow this rule, the code became more cumbersome to work with”.  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. 111 How 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 the book.  Some IDEs (Integrated development environments) offer Refactoring menu  Example: Eclipse, IntelliJ
  • 112. 112 Refactoring  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. 113 Why refactoring hard?  Sub-questions: Why people do not refactor naturally? Why does refactoring raise resistance?
  • 114. 114 Why refactoring hard?  Culture: “refactoring is an overhead activity. I’m paid to write new, 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 develop code, it is not viewed by you as an additional work.
  • 115. 115 Why refactoring hard?  Internal resistance: Why are developers reluctant to refactor? (Opdyke, in Fowler’s book, p. 313)  it should be executed when the code runs and all the tests 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 the project to reap the benefits.  developers might not understand how to refactor.  refactoring might break the existing program.
  • 116. 116 Refactoring  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. 117 XP and Refactoring  Refactoring is part of eXtreme Programming:  Refactoring can be carried out without XP, but it has additional 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. 118 XP and Refactoring  Mutual relationships of refactoring and other XP practices Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.
  • 119. 119 XP and Refactoring  Connection to XP practices - example Testing: “Whenever I do refactoring, the first step is always the same. I need to build a solid set of tests for that section of code. The tests are essential because even though I follow refactoring structures to avoid most of the opportunities for introducing bugs, I'm still human and still make mistakes.Thus I need solid tests.” (Fowler, p. 17)
  • 120. 120 Refactoring  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. 121 Refactoring – Summary  Refactoring requires awareness!  Main Message:  We should not skip refactoring.  Software development is a process that cannot be envisioned in advance.  Refactoring can be performed without XP but it gets its power from its integration with the other XP practices.  Refactoring may improve programming skills.
  • 123. 123 Conferences  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. 124 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/whatIsXp.php
  • 126. 126 Appendices  XP and the CMM  XP conception of failure and success
  • 127. 127 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.
  • 128. 128 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.
  • 129. 129 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.
  • 130. 130 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.
  • 131. 131 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.
  • 132. 132 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”.
  • 133. 133 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.
  • 134. 134 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.