Extreme Programming Applied: Playing to Win

Description

• Copyright 2002
• Dimensions: 7-1/4" x 9-1/4"
• Pages: 376
• Edition: 1st

• Book
• ISBN-10: 0-201-61640-8
• ISBN-13: 978-0-201-61640-8

Extreme Programming (XP) is a fundamentally different way to create software: simple, yet disciplined, lightweight yet powerful, flexible yet rigorous. It's catching on like wildfire, as developers who try it discover not only its effectiveness, but the pleasure it returns to their work. Extreme Programming Applied is the place to start for any developer or project manager preparing to use XP for the first time. In this book, two pioneers in XP practice offer a complete introduction to applying XP at all stages of the software development lifecycle -- design, testing, implementation, and deployment. They introduce XP's key principles in the context of actual development challenges, explaining why XP's "soft" approach is more appropriate to software development than the "civil engineering" paradigms that are so widespread nowadays. This book goes beyond explaining XP's elements: it shows how the pieces fit together, demonstrating exactly how to make XP work for real projects in real organizations. For all project managers, developers, software engineers, and others interested in more effective, flexible approaches to software development.



Extras

Related Article

Integrating XP into Your Existing Software Workshop

Web Resources

Click below for Web Resources related to this title:
Author Web Site



Sample Content

Downloadable Sample Chapter

Click below for Sample Chapter related to this title:
auerch3.pdf

Table of Contents

List of Pioneer Stories.


Foreword.


Preface.


Acknowledgments.


Introduction: Playing to Win!

0. BEFORE YOU START.

0. XP Distilled.

The Planning Game.

Testing.

Pair Programming.

Refactoring.

Simple Design.

Collective Code Ownership.

Continuous Integration.

On-Site Customer.

Small Releases.

40-Hour Week.

Coding Standards.

System Metaphor.

The Practices Work Together.

I. THE RIGHT MINDSET.

1. The Courage to Begin.

The Organizational Imperative.

Your Role.

2. Introducing XP.

Bring a Friend.

Find a Target.

Assemble the Right Tools.

Driving Spikes.

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.

Humility.

Sweet Freedom.

II. First Things First.

7. The Bare Essentials.

The First Step.

The XP Essentials.

Remember the XP Values.

Think Simply.

Get Feedback Early and Often.

Communicate.

Be Courageous.

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?

Pair Programming.

Stand-Up Meetings.

Planning.

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.

Learning Roles.

The Customer.

The Developer.

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.

Exploration Phase.

12. Iteration Planning.

What Plans Are.

The Iteration Planning Game.

Task Exploration.

Iteration Plan Verification.

One at a Time.

Fill Your Bag.

How to Start Planning.

The Art of Estimation.

Velocity.

The Last Word on Iterations and Planning.

13. Write the Tests, Run the Tests.

Keeping Code Clean.

Confidence.

Tests as Documentation.

How to Write Tests First.

What to Test.

How to Start Writing Tests First.

Testing Challenges.

Testing User Interfaces.

Testing in Small Spaces.

Testing the Web.

Tests Have to Run Fast.

14. Stop the Maverick.

Code Quality.

The Need for Speed.

Reducing Risk.

How to Pair Program.

Pair-Friendly Space.

Don't Ignore Problem Children.

Taking It to the Next Level.

The Inevitable Objections.

When Not to Pair.

Unusual Pairs.

Personal Space.

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.

Maintaining Speed.

Reducing Risk.

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.

Defining Simplicity.

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.

Customer Confidence.

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?

Rookie Coaches.

How to Coach.

Minimal Coaching.

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.

Erasing Objections.

How to Sell XP.

The Results.

Proving It.

Developing a Track Record.

Relationships Sell.

28. XP and Startups.

The Target.

The Pitch.

Entrepreneurs.

Venture Capitalists.

Selling to Startups.

Strategic Initiatives: Startups in Disguise.

Joining Them.

29. Scaling XP.

Does Anything Really Scale?

Should You Need to Scale?

Why Can't XP Scale?

When to Scale.

How to Scale.

Reserving Judgment.

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?
Index. 0201616408T09252001

Preface

"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:

1. Does XP work where it has been tried?
2. How does it work?
3. How can I make the case for it within my organization?
4. What's the best way to get started, given the resistance I'm likely to face?
5. 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:

1. As a collection of stories about how various people (including us) have started using XP in their organizations
2. As advice about how to start using XP in your organization
3. 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.

0201616408P09262001

Index

A-B Acceptance testing, 6-7, 55
    as documentation, 235
    automating, 238-239
    customer confidence, 233-235
    reasons to test, 239-241
    refusals by management, 80-81
    selecting code to test, 239-241
    tracking, 270
    writing tests, 235-237, 240-243
Agile methodologies, future role, 311-312
Architecture (system metaphor)
    creating, 258-259
    origin, 257-258
    XP practice, 11
Attitudes toward XP approach
    freedom, 62-65
    honesty and trust, 59-61
    humility, 61-62
Automatic tracking, feedback, 271-278
C
Coach role, development teams
    basics of coaching, 265-266
    player/coach roles, 266-268
    reasons for needing coaches, 262-263
    repercussions of not having coaches, 263-264
    rookie coaches, 264-265
Code, programming standards, 10-11
    basics, 246-247
    reasons, 245-248
Code integration (continuous), 9, 71
    basics, 199-201
    risk reduction, 198-199
    speed, 197-198
Code ownership, collective, 9
    defined, 224
    initial steps, 224-226
    reasons for, 225
Code refactoring
    basics, 192-193, 195-196
    benefits, change, 190-191
    benefits, learning, 191-192
    resistance, 196
    timing, 193-195
    XP practices, 8, 71
Code, testing
    acceptance testing, 6-7, 55
    acceptance testing, as documentation, 235
    acceptance testing, automating, 238-239
    acceptance testing, customer confidence, 233-235
    acceptance testing, reasons to test, 239-241
    acceptance testing, refusals by management, 80-81
    acceptance testing, selecting code to test, 239-241
    acceptance testing, tracking, 270
    acceptance testing, writing tests, 235-237, 240-243
    unit testing, 6-7, 71
    writing tests, as documentation, 155
    writing tests, challenges, 162-165
    writing tests, clean code, 154-155
    writing tests, initial steps, 157-161
    writing tests, selecting code to test, 160
    writing tests, test/code cycles, 159
Coding standards, 10-11
    basics, 246-247
    reasons, 245-248
Collective code ownership, 9
    defined, 224
    initial steps, 224-226
    reasons, 225
Communication (XP core value), 4, 74, 76
    environment, 90-96
    pair programming, 84-86
    planning, 89-90
    role in planning, 99
    stand-up meetings, 87-89
Continuous integration of code, 9, 71
    basics, 199-201
    risk reduction, 198-199
    speed, 197-198
Core values (XP)
    communication, 4, 74, 76, 83-96
    communication, environment, 90-96
    communication, pair programming, 84-86
    communication, planning, 89-90, 99
    communication, stand-up meetings, 87-89
    communication, workplace environment, 90-96
    courage, 4, 74, 76, 82
    feedback, 4, 74-75
    feedback, activities to be tracked, 269-270
    feedback, automatic tracking, 271-278
    simplicity, 4, 8, 74
    simplicity, resistance to XP, developers, 46-48
    simplicity, resistance to XP, managers, 35-36
Costs, managers' reasons for resistance to XP, 36-39
Courage (XP core value), 4
    essentials, 74, 76
    realistic times for projects, 82
CppUnit (C++) testing, 161
CRC cards, design tools, 216, 220
Customer stories
    customers not providing, 80
    Initial Planning Game, breaking down stories, 129-132
    Initial Planning Game, sorting stories, 134-135
    Initial Planning Game, writing stories, 123-124
    iteration planning, breaking into tasks, 139-144
    role in planning, 104-107
    XP initial steps, 23 D
Debugging sessions, pair programming, 180-181
Developers
    distributed teams, 301-304
    estimations in Initial Planning Game, 125-129
    role in planning, 100-101, 103-104
    team's role in Planning Game, 5
    teams, coach role, 261-268
    teams, tracker role, 269-278
Developers, resistance to XP approach
    countering, with results, 30-31
    major sources, 30
    perspective of developers, 46
    reasons, dislike of pair programming, 48-50
    reasons, documentation weaknesses, 52-58
    reasons, simplistic, 46-48
    reasons, weirdness, 50-52
    tactics using XP, 31
Distributed teams
    reasons for trying, 303-304
    technology limitations, 301-302
    telecommuting, 302
Documentation
    acceptance testing, 235
    lack of, resistance to XP approach, 52-58
    resistance of developers to XP, 52-58
    writing tests, 155
Driving spikes, 17
    XP initial steps, 23 E
Entrepreneurs, marketing targets, 291
Environment (workplace)
    aspect of communication, 90-96
    pair programming, 175-176, 185-186
Estimations
    iteration planning, 144-147
    XP practice, 71
Exception handling. See also Resistance to XP approach, managers and developers
    management obstacles, estimates not accepted, 82
    management obstacles, no acceptance testing, 80-81
    management obstacles, no customer stories, 80
    management obstacles, unrealistic schedules, 81-82
    pair programming obstacles, 78-80, 82
Exploration phase, project planning, 135-136
Extreme Hour, role in planning, 114-117
Extreme Programming. See XP
F-H
Feedback (XP core value), 4, 74-75
    activities to be tracked, 269-270
    automatic tracking, 271-278
    basics, 270-271
Fill-your-bag approach, iteration planning, 145
Forty-hour week work schedules, 10
    initial steps, 254-255
 

Introduction

We shouldn't ever have to survive another software project.

Survival is a good thing. But when it is your focus, it's not that fun or rewarding. In the end, you are not much better off than when you started. In some ways, you are worse off. That's not where you want to be. And once you've realized you survived, it certainly feels better, but you don't want to start the journey over again.

There are all sorts of books about surviving software projects. Some say that the best you can hope for is survival. Many experienced in the industry say the same thing. If you were counseling a young person about his future career options, you would not say, "Think about a career in software--with a lot of hard work, and by learning a few key techniques, you can survive."

If you are a professional reading this book, whether you just live in a world with room for improvement or dwell in the depths of despair, you are probably looking for something better than the status quo. You are hoping that Extreme Programming (XP) is something better, and you want to find out whether the promise that others have seen in XP has actually panned out. You see a lot of obstacles between you and that wonderful place you'd like to be. You wonder whether "The Promised Land" is even attainable, and whether the journey is worth taking.

Like many promising things that have come before it, XP is no silver bullet. It does not offer a formula for wild success on your next (or current) software project. On the other hand, XP, when executed well, allows you to shake off many of the problems of mainstream approaches that can keep you from succeeding.

To illustrate some of the problems with mainstream approaches, we offer the following composites of real people we have met in the software world.

The Pitiful Programmer

Many very intelligent programmers we know seem to go from one failed project to another. Often the next project seems full of promise. There's new technology to learn and you look forward to learning it. Often, you start with enthusiasm, but it goes south in a hurry.

It becomes clear that your leadership has made unreasonable promises and set the bar too high. The inevitable technical and organizational obstacles spring up, but the deadline does not change. Scope creeps. Maybe, after Herculean efforts (often at the expense of family, social life, and physical or mental health), the project actually produces something. Not something to be truly proud of, mind you, but something. Equally likely, the project gets cancelled, to no one's surprise. The warning signs of impending failure were all over the place and screaming for attention.

This is the norm. Being part of a project that provides an enriching learning environment, produces something good, and doesn't kill you along the way is a fantasy, an unattainable dream. The pitiful programmer comes to believe that success is just luck, and the chances of success are too slim to count on. The best you can hope for is to survive without being maimed.

The Die-Hard Developer

Many very intelligent and talented programmers we know seem to have overcome some great obstacles to produce software that actually ships. Life is not so bad, most of the time. You were given part of the software to develop, figured it out, used some of the best design practices in the industry, and worked hard to hit your deadlines. Then came integration.

On the project plan, there is this little block of time where everything comes together. You and everybody on the team cross your fingers. Soon, each of you finds out a few assumptions others made about your software. Of course, the process of getting there is not pretty. Things are going wrong and you have to spend just as much time defending your work as you do trying to get all of the software to come together as planned. You work late into the night to pull it out, but you are bruised and battered. The pristine software you submitted to be integrated has been patched and hacked in so many ways, it's barely recognizable. Management may appreciate these heroics or lay blame for the problems that required the heroics.

This is the norm. Being part of a project that provides a way to avoid these intense storms is a fantasy, an unattainable dream. The die-hard developer believes there has to be a way to avoid this, but hasn't yet seen it. The best you can hope for is to survive the storms to get to the next relative calm.

The Sad Sponsor

Many business people we know doubt that they'll ever get quality software delivered on time and within budget. Who can blame them? They ran the numbers before the project started. They vetted the numbers with all the right people and got a unanimous "go," after a painfully slow process in which the company spent a bunch of indirect money deciding whether to spend the direct money. Everyone was excited about the possibilities. Then reality set in.

Several months into the project, the software team started requesting additional resources in order to hit the target date. They blame you for changing the requirements or for providing vague requirements in the first place. After reluctantly cutting into the hoped-for profit, you learn that the software team doubts it will ship anywhere close to the planned release date. And the "minor" functionality changes that some stakeholders requested produce a groundswell of resistance from the developers, who get the shakes when asked to deliver. They seem to have forgotten that the stakeholders are the ones paying their salaries.

The software must ship or the budget will have been blown with nothing to show for it. Even if it does ship, there's still a good chance you will get fired for incompetence because the incremental profit promised won't materialize. The next release doesn't look any better. Is there any chance you can survive in this organization with this reputation?

This is the norm. The best you can hope for is to survive without looking like an idiot.

The Smelly Software

Both the developer and the sponsor are battered and bloody at the end of the typical project. The project delivered either subpar software or decent software over budget. The end user identifies a handful of significant problems in the software. There are some nice features, but not the ones that really give the users the desired bang for the bucks they spent. Everyone is at least a little bit ashamed of what they shipped . . . in private.

This shouldn't be surprising. Scope got out of hand fast and changing requirements invalidated the original design. Pretty soon, nobody even remembered the original design anymore. Under the intense time pressure, developers took all sorts of shortcuts and did all sorts of dumb things. The sponsor spent a lot of time dealing with the concerns coming out of development and missed some significant needs of the end users. Remember, sponsors, developers, and programmers are all just trying to survive. Communication broke down, too. Who had time for meetings or coordination? Alternatively, who had time for anything but meetings and rationalization?

In the end, the software they created is not in the best shape. It's full of bugs, or is a patchwork of fixes commented with "Not sure why this works-- DON'T TOUCH!" It's brittle. Changing it is so risky that developers perform unnatural acts to squeeze new features into spots not made to accept anything new, because that's the only way to avoid new bugs. Management and customers don't understand why it seems to be so hard to get the new features in for the next release. Now the pressure is on again.

Developers don't want to produce software like this. Customers don't want to buy and use it either.

How Things Got So Bad



Updates

Submit Errata

