Extreme Programming Applied: Playing to Win / Edition 1 available in Paperback
- Pub. Date:
Extreme Programming (XP) is a significant departure from traditional software development methods, one that is ushering in a change for both developers and business people. It is an agile methodology, which enables highly productive teams to produce quality software from rapidly changing or unclear requirements. XP is disciplined software craftsmanship, elevating best practices in software analysis, design, testing, implementation, and project management to a new level. Extreme Programming Applied helps you begin using the principles behind this revolutionary concept.
Even as the popularity of XP grows, many programmers and developers are still seeking practical advice on getting started. They find themselves in search of an XP roadmap, one that points to paths around the obstacles.
Extreme Programming Applied is just that roadmap, a pragmatic guide to getting started with Extreme Programming. It helps programmers and project managers take their first steps toward applying the XP discipline. This book is not a tutorial, however. It uses real-world experience to educate readers about how to apply XP in their organizations. The authors offer guidelines for implementing XP, illustrating key points with valuable stories from successful XP pioneers.
About the Author
Ken Auer is the founder and president of RoleModel Software, one of the world's first companies dedicated to Extreme Programming. He is well-known for his expertise in the practical application of object technology, and has been a frequent speaker and tutorial and workshop leader at various industry conferences for nearly fifteen years. He has published articles in numerous magazines (including Communications of the ACM) and is a contributing author to the Pattern Languages of Program Design series published by Addison-Wesley.
Roy Miller is a software developer at RoleModel Software. He has been developing software and managing software projects for more than seven years. He has published articles and papers on Java and Extreme Programming on IBM's developerWorks Web site and elsewhere, and speaks at conferences about how organizations can apply XP to increase competitive advantage.
Table of Contents
List of Pioneer Stories.
Introduction: Playing to Win!
0. BEFORE YOU START.
0. XP Distilled.
The Planning Game.
Collective Code Ownership.
The Practices Work Together.
I. THE RIGHT MINDSET.
1. The Courage to Begin.
The Organizational Imperative.
2. Introducing XP.
Bring a Friend.
Find a Target.
Assemble the Right Tools.
The Lone Wolf.
A Single Pair.
A Small Team.
A Small Team with a Lead Developer.
It's All Right to Feel Awkward.
3. Taming the Resistance.
Where Resistance Comes From.
The Result That Matters.
What Not to Do.
4. Manager Resistance.
The Manager Perspective on Winning.
XP Is Too New to Trust.
XP Is Simplistic.
Pair Programming Is Too Expensive.
I Can't Afford a Full-Time, On-Site Customer.
XP Is Too Informal.
Be Wary of “XP-Lite”.
5. Developer Resistance.
Developers Are Different.
The Developer Perspective on Winning.
XP Is Too Simplistic.
I Won't Like Pair Programming.
XP Is Weird.
XP Doesn't Give Us Enough Information.
6. Having the Right Attitude.
Honesty and Trust.
II. First Things First.
7. The Bare Essentials.
The First Step.
The XP Essentials.
Remember the XP Values.
Get Feedback Early and Often.
8. Exception Handling.
Handling XP Exceptions Like Code Exceptions.
An Odd Number of Developers.
The Customer Won't Write Stories.
The Customer Won't Write Acceptance Tests.
Management Sets Unrealistic Schedules.
Management Doesn't Like Your Estimates.
Management Won't Let You Pair.
The Cost of Tea in China Doubles.
9. Can We Talk?
Atmosphere and Environment.
It Doesn't Stop There.
10. Planning Roles and Reality.
How XP Planning Is Different.
How to Steer.
Out in the Open.
Requirements are a Dialogue—Not a Document.
A Tool to Introduce Reality.
How the Roles Work with Multiple Projects.
When Roles Are Clear.
The Xtreme Hour.
11. Project Planning.
Charting the Course.
The Planning Game.
The Customer Writes Stories.
The Developers Estimate.
Breaking Down Stories.
Back to Estimating.
Determining Iteration Size.
Sorting the Stories.
12. Iteration Planning.
What Plans Are.
The Iteration Planning Game.
Iteration Plan Verification.
One at a Time.
Fill Your Bag.
How to Start Planning.
The Art of Estimation.
The Last Word on Iterations and Planning.
13. Write the Tests, Run the Tests.
Keeping Code Clean.
Tests as Documentation.
How to Write Tests First.
What to Test.
How to Start Writing Tests First.
Testing User Interfaces.
Testing in Small Spaces.
Testing the Web.
Tests Have to Run Fast.
14. Stop the Maverick.
The Need for Speed.
How to Pair Program.
Don't Ignore Problem Children.
Taking It to the Next Level.
The Inevitable Objections.
When Not to Pair.
How to Start Pair Programming.
15. Making It Right.
Being Ready for Change.
Making Change Possible.
Putting Learning into Your Code.
How to Refactor.
When to Refactor.
When Not to Refactor.
When to Stop Refactoring.
How to Start Refactoring.
Why People Don't Refactor.
16. Pulling It Together.
How to Integrate Continuously.
How to Start Integrating Continuously.
Techniques to Make It Easier. Chapter 17 Staying on Process.
Why Teams Lose Their Way.
How to Get Back on Process.
III. THE REST OF THE STORY.
18. Designing the Simple.
Why People Don't Keep It Simple.
Why Keep Things Simple?
How to Start Doing Simple Design.
Why Not Start with Simple Design?
The Essential Design Tool.
19. It's Everybody's Job.
What Collective Ownership Means.
Moving From “I” to “We”.
Why Have Collective Code Ownership?
How to Start Having Collective Code Ownership.
Why Not Start with Collective Code Ownership?
20. Where's the Customer?
Why Have an On-Site Customer?
On-Site Versus Available When Needed.
How to Get an On-Site Customer.
Why Not Start with an On-Site Customer?
21. Knowing When You're Done.
Acceptance Tests as Documentation.
How to Write Acceptance Tests.
Automating Acceptance Tests.
What to Test.
How to Start Writing Acceptance Tests.
Why Not Start with Acceptance Testing?
22. Don't Get Distracted by the Code.
Why Have Coding Standards?
How to Start Having Coding Standards.
Why Not Start with a Coding Standard?
23. Overtime Is Not the Answer.
Why People Work Too Much.
What's Wrong with Burning the Midnight Oil?
How to Start Working Normal Hours.
Why Not Start with a 40-Hour Week?
24. Painting a Thousand Words.
Where the Concept of Metaphor Came From.
How to Start Creating Metaphors.
Why Not Start with a Metaphor?
25. Looking for Guidance.
Why You Do Need a Coach.
What If We Don't Have a Coach?
How to Coach.
How About a Player/Coach?
Why Start Without a Coach?
26. Keeping Score.
What to Track.
How to Track.
Why Not Start with a Tracker?
IV. UNCHARTED TERRITORY.
27. Selling XP.
How to Sell XP.
Developing a Track Record.
28. XP and Startups.
Selling to Startups.
Strategic Initiatives: Startups in Disguise.
29. Scaling XP.
Does Anything Really Scale?
Should You Need to Scale?
Why Can't XP Scale?
When to Scale.
How to Scale.
30. The Next Best Thing to Being There.
The Limits of Technology.
Can a Team Telecommute?
When to Try Distributed XP.
31. Measuring XP.
What to Measure.
The XP Challenge.
The Before-and-After Study.
What Having the Numbers Will Mean.
32. Where to Next?
"You're a fool to think this will ever work."
People have said that to all of us about Extreme Programming (XP). We've said it to ourselves about XP.
People told Christopher Columbus he was nuts when he wanted to sail west. People told the Pilgrims this before they got on the Mayflower. People told many of the early settlers of the American frontier the same thing.
Yet they all headed west. Why? They believed there was something better out there, and somebody had to be the first one to find out if they were right. The journey itself was treacherous for each of them. Once they got to their destination, there were more dangers. Some they suspected ahead of time. Some were total surprises. Of course, they were scared. But, as pioneers, they had no choice but to face their fears head-on. Sometimes they died. Sometimes they lived to face the next life-threatening challenge.
Stories from these brave fools made it back to the people they left behind, and then to people they didn't even know. Those who may not have been brave enough to take the first journey, or who didn't have the opportunity, were encouraged. They became the next wave of pioneers. They were better prepared than the first wave. Bravery and success (mixed with the excitement of knowing the risk they were taking) encouraged another wave. It didn't come easily, but eventually the West was settled.
We are the early pioneers. We don't have all the answers. We have celebrated some victories. We've reflected on some failures. We certainly have learned a lot. These are our letters home. We hope they will encourage the next wave to head west.
Who Should Read This Book
We wrote this book for software developers and for technical managers who are interested in Extreme Programming (XP). Perhaps they don't know how to get started or don't know how to go further than they've already gone. Our goal was to create a practical volume that would provide advice based on real-world experience.
We assume that people reading this book have either read Kent Beck's Extreme Programming Explained or have otherwise gained a general understanding of what Extreme Programming is. Kent's book is a manifesto that makes the case for XP. We accept the case as made, and we move on to helping those who want to act on it.
If you are a developer or a technical manager even mildly interested in XP, we assume you have at least one of these five burning questions:
- Does XP work where it has been tried?
- How does it work?
- How can I make the case for it within my organization?
- What's the best way to get started, given the resistance I'm likely to face?
- Once I've made the case for it and gotten started, how do I make it work within my organization?
Although we may not be able to answer all of these questions definitively for you, we hope to give you enough guidance to act immediately.
How to Read This Book
You can read this book in three different ways:
- As a collection of stories about how various people (including us) have started using XP in their organizations
- As advice about how to start using XP in your organization
- As a virtual coach to use as you begin introducing XP into your organization in your own unique way
The list of pioneer stories provides a complete listing of all the stories in this book. Each story has a title that captures its primary thrust. You can read just these stories and get a feel for how to make the case for XP and how to start using it.
We embedded the stories within the chapters of the book, where we provide some context for them and some advice based on our own experiences. You can read the book from cover to cover, skipping the stories entirely (they are highlighted in the text) to get the advice in its nonillustrated form.
Perhaps the best way to read the book, though, is as a cohesive whole. The stories put the advice we're giving in the context of organizations and projects with human beings acted on by real forces. It is the next best thing to having tried XP yourself.
Ultimately, we hope you do try it yourself. Think of this book as an instruction manual for achieving the goal Kent outlined in Extreme Programming Explained.
XP on the Web
A good reference bookshelf is an invaluable tool. The Internet puts mounds of information at your fingertips, but it hides it under a lot of junk. Finding what you need can be a needle-in-a-haystack exercise.
If you want to find out more about XP and some of the things we've referred to in this book, check out our XP Portal at http://www.rolemodelsoft.com/xp. There you will find things like pointers to
- Laurie Williams and Alistair Cockburn's research on pair programming
- Integration procedures using VisualAge for Java Enterprise
- A JAccept overview
We will update this portal over time.