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
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
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$ ביליון
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
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)
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
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.
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
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
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
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.