Jeffries_-_eXtreme_Programming_Installed.pdf

(899 KB) Pobierz
xpinstall.book
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 1 Extreme Programming . . . . . . . . . . . . . . . . 9
Extreme Programming is a discipline of software develop-
ment with values of simplicity, communication, feedback
and courage. We focus on the roles of customer, manager,
and programer and accord key rights and responsibilities to
those in those roles.
Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Chapter 2 Circle of Life . . . . . . . . . . . . . . . . . . . . . . 27
An XP project succeeds when the customers select business
value to be implemented, based on the team’s measured
ability to deliver functionality over time.
Chapter 3 On-site Customer . . . . . . . . . . . . . . . . . . . 31
An XP project needs a full-time customer to provide guid-
ance. Here’s a summary of why ...
Chapter 4 User Stories . . . . . . . . . . . . . . . . . . . . . . . 37
Define requirements with stories, written on cards.
Chapter 5 Acceptance Tests . . . . . . . . . . . . . . . . . . . 45
Surely you aren’t going to assume you’re getting what you
need. Prove that it works! Acceptance tests allow the custom-
er to know when the system works, and tell the programmers
what needs to be done.
Sidebar - Chapter 5 Acceptance Test Samples . . . . . . 49
At first it can be difficult figuring out how to do acceptance
tests. With a little practice it becomes easy.
Chapter 6 Story Estimation . . . . . . . . . . . . . . . . . . . . 51
Customers need to know how much stories will cost, in order
to choose which ones to do and which to defer. Programmers
evaluate stories to provide that information. Here’s how.
1
Sense of Completion . . . . . . . . . . . . . . . . . . . . . . . . .61
XP’s nested planning and programming cycles keep the
project on track, and provide a healthy sense of accomplish-
ment at frequent intervals.
Chapter 7 Small Releases . . . . . . . . . . . . . . . . . . . . . .65
The outermost XP cycle is the release. Small and frequent re-
leases provide early benefit to the customer while providing
early feedback to the programmers. Here are some thoughts
on how to make it happen.
Chapter 8 Customer Defines Release . . . . . . . . . . . . .71
In each release cycle, the customer controls scope, deciding
what to do and what to defer, to provide the best possible re-
lease by the due date. Work fits into the calendar, based on
business value, difficulty, and the team’s implementation
velocity.
Chapter 9 Iteration Planning . . . . . . . . . . . . . . . . . . .79
Inside each release, an Extreme team plans just a few weeks
at a time, with clear objectives and solid estimates.
Chapter 10 Quick Design Session . . . . . . . . . . . . . . .87
Within each iteration, programmers don’t stand alone.
Here’s a technique to help programmers move forward with
courage. Make it part of your team’s ritual.
Chapter 11 Programming . . . . . . . . . . . . . . . . . . . . .89
It’s called Extreme Programming, after all. Here’s how we
do the programming part of things.
Integration is a bear. We can’t put it off forever. Let’s do it
all the time instead.
Sidebar - Chapter 11 Code Quality . . . . . . . . . . . . .103
A little more detail on something close to our hearts:
simplicity.
Chapter 12 Pair Programming . . . . . . . . . . . . . . . . .107
2
On an Extreme Programming team, two programmers sit-
ting together at the same machine write all production
code.
Chapter 13 Unit Tests . . . . . . . . . . . . . . . . . . . . . . 113
Extreme Programmers test everything that could possibly
break, using automated tests that must run perfectly all the
time.
Sidebar - Chapter 13 xUnit . . . . . . . . . . . . . . . . . . . 127
Use the world’s lightest testing tool.
Chapter 14 Test-first, by Intention . . . . . . . . . . . . . 129
Code what you want, not how to do it. Chet and Ron do a
small task test first, trying always to express intention in the
code rather than algorithm.
Chapter 15 Releasing Changes . . . . . . . . . . . . . . . . 145
Using collective code ownership and comprehensive unit
tests, an XP team releases changes rapidly and reliably.
Chapter 16 Do or Do Not . . . . . . . . . . . . . . . . . . . 151
We’ve now covered most of the programming aspects of XP.
Here’s a summary of things we do — and things we don’t.
Chapter 17 Experience improves estimates . . . . . . . 155
Each iteration we gain experience. Experience with stories
helps us estimate future stories more easily and more accu-
rately.
Chapter 18 Resources, Scope, Quality, Time . . . . . . 157
Who’s doing what? How much is finished? How good is it?
When will we be done? What metrics should we keep?
Chapter 19 Steering . . . . . . . . . . . . . . . . . . . . . . . . 171
The estimates are wrong. Your priorities will change. You
must steer.
Chapter 20 Steering the Iteration . . . . . . . . . . . . . . 173
3
To steer each iteration, you need to track stories getting
done, and how well the task estimates are holding up.
Chapter 21 Steering the Release . . . . . . . . . . . . . . . .179
To steer the release, you need to track what’s done, how fast
you are going, and how well the system works.
Chapter 22 Handling Defects . . . . . . . . . . . . . . . . . .183
Report ’em, schedule ’em, test and fix ’em, avoid ’em. Just
don’t call ’em bugs.
Sidebar - Chapter 22 Advanced Issue:
Bug Databases . . . . . . . . . . . . . . . . . . . .187
Sidebar - Chapter 22 Advanced Practice:
Tests as Database . . . . . . . . . . . . . . . . . .191
Sidebar - Chapter 22 Test to show a defect . . . . . . .193
When a defect is detected, begin with a test.
Chapter 23 Conclusion . . . . . . . . . . . . . . . . . . . . . .195
Section I Bonus Tracks . . . . . . . . . . . . . . . . . . . . . 205
Here are some things we’ve paid a lot to learn. Since you
bought the album, we wanted to give you a little something
extra. Thank you, and we hope we passed the audition.
Chapter 24 We’ll Try . . . . . . . . . . . . . . . . . . . . . . . .207
“We’ll try” can be the saddest words a programmer has ever
spoken, and most of us have spoken them more than once.
We’ve covered this material in other forms already, but it
bears repeating here.
Chapter 25 How to estimate anything . . . . . . . . . . .217
Sometimes estimating stories seems scary. Keep your heads,
4
stick together, and break the story down into small parts.
You’ll be surprised what you can do.
Chapter 26 Infrastructure . . . . . . . . . . . . . . . . . . . . 219
What about that database you need to build first? What
about that framework? What about that syntax-directed
command compiler? Get over it!
Chapter 27 It’s Chet’s Fault . . . . . . . . . . . . . . . . . . 223
Are you looking for someone to blame? This chapter explains
how to know whose fault it is. Now move on and solve your
problems.
Chapter 28 Balancing Hopes and Fears . . . . . . . . . . 225
Chapter 29 Testing Improves Code . . . . . . . . . . . . 227
An example showing how writing some tests can cause you
to improve the code.
Chapter 30 XPer Tries Java . . . . . . . . . . . . . . . . . . . 231
After the C3 project ended most of the team was transferred
to work on the human resources intranet. I found how they
were using the principles of XP to improve their lives on a
new project heartening. What follows is a description of how
Rich Garzaniti, exC3er and devoted XPer is introducing
testing and modern development tools into an environment
where none existed.
Chapter 31 A Java Perspective . . . . . . . . . . . . . . . . . 241
We would like to thank Bill Wake for allowing us to use his
article. It is the second in a series entitled "The Test/Code
Cycle in XP". His website http://users.vnet.net/wwake
contains the entire series plus a whole lot more.
Chapter 32 A True Story . . . . . . . . . . . . . . . . . . . . 257
Ron Jeffries [re]learns something about simplicity.
5

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin