eXtreme programming

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
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
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
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
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
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
 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
 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)

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
A cooperates 50% 20%
A competes 80% 0%

39
The Prisoner’s Dilemma: The case of
software engineering – A’s perspective
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 value of courage
:‫פעולה‬ ‫שיתוף‬
.‫בעיה‬ ‫יש‬ ‫כאשר‬ ‫מתריעים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.‫ידע‬ ‫להם‬ ‫חסר‬ ‫כאשר‬ ‫להודות‬ ‫מתביישים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.‫עמיתיהם‬ ‫של‬ ‫קוד‬ ‫לשנות‬ ‫חוששים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
‫היא‬ ‫הפיתוח‬ ‫שסביבת‬ ‫מכיוון‬XP‫לא‬ ‫שהם‬ (‫יודע)ת‬ (‫אחד)ת‬ ‫כל‬ ,
‫שיפגינו‬ ‫היחידים‬courage‫האם‬ ‫הדילמה‬ ‫בפני‬ ‫עומדים‬ ‫לא‬ ‫הם‬ ‫ולכן‬
.‫פעולה‬ ‫לשתף‬
.‫זה‬ ‫מערך‬ ‫מרוויחים‬ ‫הצוות‬ ‫וחברי‬ ‫הפרויקט‬

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

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

47
Coding Standards
:‫פעולה‬ ‫שיתוף‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫לפי‬ ‫פיתוח‬
:‫בגידה‬.‫שנקבעו‬ ‫הסטנדרטים‬ ‫על-פי‬ ‫לא‬ ‫פיתוח‬
‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬XP‫ועל-פי‬ ‫בכלל‬
.‫בפרט‬ ‫זו‬ ‫מיומנות‬
.‫פעולה‬ ‫לשתף‬ ‫האם‬ ‫מתלבטים‬ ‫אינם‬ ‫הצוות‬ ‫חברי‬
‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫הצוות‬ ‫חברי‬ ‫כל‬
.‫סטנדרטים‬ ‫פי‬ ‫על‬ ‫קוד‬ ‫שבפיתוח‬

48
Simple Design
‫מהערך‬ ‫נובע‬Simplicity
:‫פעולה‬ ‫שיתוף‬;‫האפשר‬ ‫ככל‬ ‫פשוט‬ ‫פיתוח‬:‫בגידה‬‫פיתוח‬
.‫הבנה‬ ‫על‬ ‫להקשות‬ ‫היכול‬ ‫מסובך‬
‫על-פי‬ ‫לעבוד‬ ‫מחויבים‬ ‫כולם‬XP.‫זו‬ ‫מיומנות‬ ‫על-פי‬ ‫גם‬ ‫ולכן‬
‫קוד‬ ‫שבפיתוח‬ ‫מהיתרונות‬ ‫ומרוויחים‬ ‫פעולה‬ ‫משתפים‬ ‫כולם‬
.‫שניתן‬ ‫ככל‬ ‫פשוט‬

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

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):
 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):
 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):
 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
 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
 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
 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
 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
 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
 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.

83
 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
 Fourth step: Create subclasses of the extracted
class and initialize the instance variable to the
appropriate subclass.
Adding subclasses of
presentation style

85
 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
 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?
 Why refactoring hard? Why people do not do that?

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?

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
 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
 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:
 When refactoring? When not? OK

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:
 How refactoring? OK
 Why refactoring hard? Why people do not refactor?

113
Why refactoring hard?
 Sub-questions:
Why people do not refactor naturally?
Why does refactoring raise resistance?

114
 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
 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:
 Why refactoring hard? OK

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:
 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
 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
 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
 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
 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
 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.

eXtreme programming

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to eXtreme programming (20)

Recently uploaded (20)

eXtreme programming