1 eXtreme Programming מתודולוגיה לפיתוח פרויקטי תוכנה ד"ר אורית חזן המחלקה להוראת הטכנולוגיה והמדעים, הטכניון

1

eXtreme Programmingמתודולוגיה לפיתוח פרויקטי תוכנה

ד"ר אורית חזן

המחלקה להוראת הטכנולוגיה והמדעים, הטכניון

[email protected]

2

eXtreme Programming מתודולוגיה לפיתוח פרוייקטי תוכנה

What is eXtreme Programming

Why eXtreme Programming?

Social analysis

Cognitive analysis

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 ביליון 200$בתוכנה הושקעו בארה"ב 2003 של

7


מה אתם יודעים עלXP?

(Windows 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

Project Timetable: 1 release - 3 iterations (2 months - 9 weeks)

Week 1, Release 1, Iteration 1









Release 2 starts

Business Day Business Day

Business Day

Business Day

12

How eXtreme Programming?

Two days in

eXtreme Programming

Development Environment

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 gameOn-site customerSmall releasesSimple designMetaphor

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




On-site customer

Customer’s on-going

feedback

Small releases

On-going opportunity to

update/change

requirements

16




Simple design

Develop only what is

needed for your

development task

Metaphor Bridges customers-

developers-business gaps

17

Development Day

Stand-up meeting The development environment

Pair programming Test driven development (acceptance, unit-test) Code standards Refactoring Simple design Continuous integration (one integration machine) Collective ownership Sustainable pace (40-hour week)

Source: http://www.rolemodelsoftware.com/

18

Development Day - Reflection

The development environment All see all; fosters communication

Stand-up meeting All know what all do

Pair programming Each task is thought on two levels of abstraction

Unit test (automatic test first) First: improves understanding; Automatic: testing is easy

Developers program and test

Testing becomes manageable

Success vs. failure

19

Development Day - Reflection

Continuous integration

Reduces integration risks in later stages

Collective ownership Important in companies with high turnover

Coding standards

Refactoring and simple design Code improvement is part of the methodology (though it doesn't

produce code), gradual process

Sustainable pace (40-hour week) Intense and productive work, developers are not tired

20

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

21

The 12 XP practices

Note:nothing is new; gathering the practices together is XP uniqueness

Source: Beck, K. (2000). eXtreme Programming explained, Addison Wesley.

22


Differences from traditional methodologies

All developers are involved with requirements-design-code-testing

Emphasis on people vs. development activities & schedule

XP specifies how to behave; still leaves freedom and place for creativity

The meaning of ‘eXtreme’

12 practices

4 values: feedback, simplicity, communication, courage

23


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

24

Why XP ?

You do not do XP to save money;

However, XP shortens time to market

XP is a mature software development

method

25

Why XP ?

Survey:

31 XP/Agile-methods early adopter projects, 14 firms

Findings:

Cost reduction: 5-7% on average

Time to market compression: 25-50% reduction in

time

26

Why XP? – Analysis Shorter development period:

Code is easy-to-work with:

less bugs: unit tests

code is more readable & workable (invest now to gain benefits

later):pair programming, refactoring, coding standards

Development is manageable and controlled:

accurate estimation: small releases

meets customer needs: customer on-site, planning game, acceptance

tests

27

Why XP? – Analysis Shorter development period )cont(:

Knowledge sharing, if one leaves everything continues

as usual: pair programming, collective ownership

Production is increased: pair programming (work all the time),

sustainable pace

Cost for requirements change/update/elaboration is

CONSTANT: simple design, planning game (redundant features

are not added by customer and developers)

28

Why XP ?Barry W. Boehm (1981). Software Engineering Economics,

Englewood Cliffs, N.J.: Prentice Hall.

63 software development projects in corporations such as IBM.

Phase of requirement change Cost Ratio

Requirements 1

Design 3-6

Coding 10

Development testing 15-40

Acceptance testing 30-70

Operation 40-1000

29

Why XP ? Under the assumption that “the later a requirements is

introduced the more expensive it is”, customers (and

developers) try to make a “complete” list of requirements.

Under the assumption that “cost for introducing an update in

the requirements is constant”, customers (and developers) do

not assume what the customer will need and develop exactly

and only what is needed.

30

Why XP ?

You do not use XP to save money;

However, XP shortens time to market

XP is a mature software development

method (at least CMM level 3)

31

XP in Practice: Conceptual Changes

XP encourages:

Cooperation (vs. knowledge-is-power)

Simplicity (vs. habit-of-high-complexity)

Change in work habits

32

Why XP? – Cognitive and Social Analysis

ניתוחXP מנקודת מבט קוגניטיבית

וחברתית.

Game Theory: Prisoner’s Dilemma

Learning Theory: Constructivism

33

Social analysis

34

Game Theory

ניתוח התנהגות וקבלת החלטותכאשר תוצאות הנובעות מהחלטות

של כל אחד מהמשתתפים ב"משחק" תלויות בהחלטות של המשתתפים

האחרים.

35

The Prisoner’s Dilemma: A’s perspective

B cooperates

לא מלשין

B competes

מלשין

A cooperates

לא מלשין

+5אין עדות מרשיעה

-10יש עדות מרשיעה רק ביחס

משוחררA, Bל-

A competes

מלשין

+10יש עדות מרשיעה רק ביחס

משוחררB, Aל-

0יש עדות מרשיעה, העונש

מופחת בגלל ההלשנה

36

The Prisoner’s Dilemma: The case of software engineering – A’s perspective, Bonus

B cooperatesB competes

A cooperates50%20%

A competes80%0%

37

The Prisoner’s Dilemma: The case of software engineering – A’s perspective

B cooperatesB competes

A cooperates+5-10

A competes+10-20

38

The Prisoner’s Dilemma: The case of software engineering

בד"כ מפתחי תוכנה מתבקשים לשתף פעולה עם

עמיתיהם.

למפתחי התוכנה אין אפשרות לוודא ששיתוף הפעולה

שלהם יהיה הדדי.

:כל חברי הצוות יעדיפו לבגוד (לא לפי דילמת האסיר

לשתף פעולה).

התנהגות כזו בפיתוח תוכנה מביאה לתוצאות הגרועות

ביותר לכל חברי הצוות.

39

The Prisoner’s Dilemma: The case of eXtreme Programming

לעבוד על-פי התחייבות חברי הצוותXP מבטיחה שכל

. XPחברי הצוות יעבדו על-פי המיומנויות של

כל חבר(ת) צוות יודע(ת) שגם שאר חברי הצוות

מחויבים לעבוד לפי אותן מיומנויות.

(המהווה את המקור לדילמת האסיר) גורם האי-וודאות

לא קיים.

.כולם ישתפו פעולה ויפיקו את הרווחים מכך

40

The Prisoner’s Dilemma: The case of Extreme Programming – A’s perspective

B cooperates

A cooperates+5

41

In what follows-מיומנויות של 4 ערכים ו- 2ביחס ל XP:

.מהי המשמעות של שיתוף פעולה הנובעת מהם

מהעובדה שכל הצוות מחויב לעבוד על-פי XP נובע שכל

אחד ואחת מחברי הצוות אינם ניצבים בפני הדילמה האם

.(באותו מובן הנובע מהערך או המיומנות) לשתף פעולה

כל חברי הצוות משתפים פעולה ומרוויחים מהיתרון שנובע

. מאותו ערך או מיומנות

.כל פרויקט התוכנה נתרם משיתוף פעולה זה

42

The Prisoner’s Dilemma: The value of courage

:שיתוף פעולה

.כל חברי הצוות מתריעים כאשר יש בעיה

.כל חברי הצוות אינם מתביישים להודות כאשר חסר להם ידע

.כל חברי הצוות אינם חוששים לשנות קוד של עמיתיהם

מכיוון שסביבת הפיתוח היאXP כל אחד(ת) יודע(ת) שהם לא ,

ולכן הם לא עומדים בפני הדילמה האם courageהיחידים שיפגינו

לשתף פעולה.

.הפרויקט וחברי הצוות מרוויחים מערך זה

43

Kent Beck : Kent Beck explains when XP is not appropriate:

"[i]t's more the social or business

environment. If your organization punishes

honest communications and you start to

communicate honestly, you'll be destroyed." An interview with Kent Beck, June 17, 2003, Working smarter, not harder,

IBM website: http://www-106.ibm.com/developerworks/library/j-beck/

44

The Prisoner’s Dilemma: The value of simplicity

:שיתוף פעולה יישום כל הפעולות הקשורות בפיתוח התוכנה בצורה

הפשוטה ביותר.

.למשל, לא מסבכים קוד

כולם מחויבים לעבוד על-פיXP ולכן מחויבים גם לערך הזה.

.לא ניצבים בפני הדילמה האם לשתף פעולה

.כולם משתפים פעולה וכולם מרוויחים

45

The Prisoner’s Dilemma: Collective Ownership

In practice “[a]nyone can change any code

anywhere in the system at any time.” (Beck, 2000).

:הסתרת קוד. בגידה:שיתוף בקוד. שיתוף פעולה

כולם עובדים על-פי XP.ולכן גם על-פי מיומנות זו

.לא עומדים בפני הדילמה האם לשתף פעולה

כולם משתפים פעולה, הדבר תורם לתהליכי פיתוח

התוכנה וכולם יוצאים נשכרים.

46

The Prisoner’s Dilemma: Coding Standards

:פיתוח לפי הסטנדרטים שנקבעו. שיתוף פעולה

:פיתוח לא על-פי הסטנדרטים שנקבעו.בגידה

כל חברי הצוות מחויבים לעבוד על-פיXP בכלל

ועל-פי מיומנות זו בפרט.

.חברי הצוות אינם מתלבטים האם לשתף פעולה

כל חברי הצוות משתפים פעולה ומרוויחים

מהיתרונות שבפיתוח קוד על פי סטנדרטים.

47

The Prisoner’s Dilemma: Simple Design

נובע מהערךSimplicity

:פיתוח בגידה: פיתוח פשוט ככל האפשר; שיתוף פעולה

מסובך היכול להקשות על הבנה.

כולם מחויבים לעבוד על-פיXP.ולכן גם על-פי מיומנות זו


כולם משתפים פעולה ומרוויחים מהיתרונות שבפיתוח

קוד פשוט ככל שניתן.

48

The Prisoner’s Dilemma: Sustainable Pace

שעות, למעט מקרים חריגים.40שבוע עבדה בן

:מפתחים עייפים אינם מייצרים קוד איכותי. רציונאל

מיומנויות אחרות)e.g., Pair Programming( .מבטיחות ניצול יעיל של זמן זה

:עבודה במשך שעות בגידה: ביום; 8-9עובדים שיתוף פעולה

. (למשל, על מנת להרשים)רבות יותר

כל חברי הצוות מחויבים לעבוד לפיXP.ולכן גם לפי מיומנות זו


כולם משתפים פעולה ומרוויחים מהיתרונות שבפיתוח קוד

בקצב שניתן לעמוד בו.

49

Cognitive analysis

50

Why XP?

:הבנת סביבת פיתוח תוכנה היא תהליך טענה

תומכת בתהליך הבנה זה. XPמורכב;

:קונסטרקטיביזם.תיאוריה המסבירה תהליכי למידה

ידע חדש נבנה בהדרגה על בסיס מושגים קיימים, ע"י ארגון

ועידון מבנים מנטאליים קיימים.

למשוב שמתקבל מסביבת הלמידה תפקיד חשוב בתהליך

הלמידה.

51

XPניתוח קוגניטיבי של

המיומנויות של 12 מתוך 4בחינת XP משקפיים דרך

. קונסטרוקטיביסטיות

בהבנה הדרגתית של סביבת מיומנויות אלו תומכות

.הפיתוח

הערכים Communication -ו Feedback .אף הם תורמים

52

XP practices - Cognitive analysis

• Small releasesGradual process of knowledge construction re requirements

• RefactoringGradual process of knowledge construction re code's structure and

readability

• Test driven development

• Metaphor

53

Cognitive and Social Analysis of XP practices

Cognitive analysisSocial analysis

Refactoring

Metaphor

Test-first

Small releases

Collective ownership

Sustainable pace

Simple design

Coding standards

54

Summary

eXtreme programming:

What?

Why? Cognitive and Social analysis

How?

55

ReferencesBeck, 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

56

Questions

57

Appendices

XP and the CMM

XP conception of failure and success

58

Why XP? – XP is a Mature Method

The Capability Maturity Model for Software (CMM or

SW-CMM): a model for judging the maturity of the

software processes of an organization and for

identifying the key practices that are required to

increase the maturity of these processes.

The Software CMM has become a de facto standard

for assessing and improving software processes.

59


The SW-CMM has been developed by the software community

with stewardship by the SEI.

past experiences in process improvement such as TQM

academic business theories

practical experiences of successful projects gained from companies

such as IBM

The CMM has five levels of process capability maturity.

60


The first – undisciplined:

processes may be loosely defined and rarely understood.

estimates of cost and schedule are poor and consequently projects have

serious problems meeting deadlines and functionality requirements within

budgets.

management generally is unaware that processes exist and often makes

decisions that hurt more than help.

61


Level 2 - Repeatable:

puts project management practices such as requirements definition,

configuration management, and quality assurance in place that are

documented and can be repeated.

Level 3 - Defined:

graduates the best practices of individual projects to an organizational

process.

adds concepts of organizational training, process management, and

program management.

62


Levels 4 and 5:

use information and measurements defined in levels 2 and 3

to understand why the process behaves the way it does so

it can be improved.

Level 5:

the process is mature enough to prevent defects instead of

reacting to them and to insert new technology and process

improvements knowing exactly how the organizational process

will be affected.

63


The CMM has become popular around the world because of

its ability to be applied practically to any software

environment.

It describes what process components should be in place

(such as recording requirements, planning and tracking

activities, estimating, etc.), but not how to implement them.

eXtreme Programming fits as a framework for “how to

implement the processes”.

64

XP in practice: Success and failure

3 Sep, 2002: XP - An interview with Kent Beck

Q: What are the issues you see your clients struggling with?

KB: One of the issues is redefining failure or redefining

success. For example, you think that you have a great

idea for a project, and it's going to take you nine months to

really have it ready for the market. You [may] discover

after four weeks that you are going one-tenth the speed

that you thought you would, and you cancel the project. Is

that a failure or success? In many organizations, this is

perceived as a failure.

65

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.

Documents

1 eXtreme Programming מתודולוגיה לפיתוח פרויקטי תוכנה ד"ר אורית חזן המחלקה להוראת הטכנולוגיה והמדעים, הטכניון