Always Learning

Extreme Programming Applied: Playing to Win
Ken Auer
Roy Miller

ISBN-10: 0201616408
ISBN-13:  9780201616408

Publisher:  Addison-Wesley Professional
Copyright:  2002
Format:  Paper; 384 pp
Published:  10/01/2001
Status: Instock


Customers outside the U.S., click here.


Print this content

In this section:


Description


Features


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



Back to top

Print this content

In this section:


Sample Chapter

View a Sample Chapter PDF:/samplechapter/0201616408.pdf


Author Bios

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.



0201616408AB09172001


Backcover Copy

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.



0201616408B09172001

Back to top

Print this content

This product is a member of the following series. Click on the series name to see the full list of products in the series.

Back to top

Log in to the Instructor Resource Center

Login name: 

  Password: 

Forgot login/password?  |  Need to redeem an access code?

        

Instructor Resource Center File Download

This work is protected by local and international copyright laws and is provided solely for the use of instructors in teaching their courses and assessing student learning. Dissemination or sale of any part of this work (including on the World Wide Web) will destroy the integrity of the work and is not permitted. The work and materials from this site should never be made available to students except by instructors using the accompanying text in their classes. All recipients of this work are expected to abide by these restrictions and to honor the intended pedagogical purposes and the needs of other instructors who rely on these materials.

Cancel     I accept, proceed with download

Print this content

Pearson Higher Education offers special pricing when you choose to package your text with other student resources. If you're interested in creating a cost-saving package for your students contact your Pearson Higher Education representative.

Back to top