Gives students a comprehensive source of information about every aspect of XP implementation and use.
Helps students master every phase of XP participation, from every standpoint: technical, management, and client.
Offers students a powerful sense of what it feels like to participate in an XP project.
Helps students more clearly understand the challenges they may face in implementing XP.
Helps students understand why refactoring is central to successful XP projects—and how to perform refactoring in ways that maximize its value.
The one-stop guide for everyone getting started with eXtreme Programming!
Practically overnight, Extreme Programming (XP) has become one of the world's leading agile methodologies. Now, there's an easy, concise introduction that delivers all the guidance and best practices you need to make XP work in your organization!
A Practical Guide to eXtreme Programming doesn't just introduce key XP principles such as simplicity, communication, and feedback: it shows how to make them work in the real world. Using a start-to-finish case study, this book covers the entire project lifecycle, every key task, and the role of every XP participantdevelopers, managers, and customers. Coverage includes:
Want all the benefits XP can provide? Want to implement XP as smoothly and painlessly as possible? This is the place to start!
(NOTE: Each section ends with a conclusion.)
Foreword by Scott W. Ambler.
I. THE GAME.1. Extreme Principles.
Work with Your Customers. Using Metaphors to Describe Difficult Concepts. Plan. Keeping Meetings Short. Test First. Keep it Simple. Program in Pairs. Code to Standards. Own it Collectively. Integrate Continuously. Refactor. Release in Small Increments. Don't Burn Out (40-Hour Work Week). Embrace Change.2. The Players.
Two Teams. The Customer Team. The Development Team. The Role of Roles. Establishing Rights.
II. CONCEPTUALIZING THE SYSTEM.3. Creating a Vision of the System.
Conceptualizing the System. The Vision Card. The Metaphor. Metaphors for Development.4. Writing User Stories.
The Philosophy of User Stories. User Stories. Numbering the Stack. Appendix to Chapter 4.5. Writing Acceptance Tests.
What Is an Acceptance Test? Writing Tests. Difficulty with Acceptance Tests. Infinitely Many Acceptance Tests. Automating Acceptance Tests. Conclusion.6. One Simple Solution.
What Are We Looking for? Keep It Simple. Conceptual Solution Spikes. Conclusion.7. Watching Our Words.
The Problem. What's in a Name. Constant Refactoring and Communicating.
III. PLANNING.8. Providing Estimates.
Proving Estimates. Assumptions, Splitting. Planning Spikes. Conclusion.9. Planning Releases.
Velocity. The Cost of the Release. Establishing Priorities. Pair Programming. Creating the Release Plan. Conclusion.10. Planning Iterations.
Creating a Series of Iterations. The Setting for Iteration Planning. The First Iteration. Subsequent Iterations. Scheduling Iterations. Conclusion.11. Tactical Planning.
Beginning an Iteration. Volunteering for Tasks. Standup Meetings. Tracking the Project. Finishing Early.
IV. DEVELOPMENT.12. Pair Programming.
The Mechanics of Pair Programming. Development as a Conversation. Peer Pressure. Double the Fun. The Net Effect. As Fast as the Slowest. Conclusion.13. Test First.
The XP Project. Why Test? What to Test. When to Test. How to Test: A Testing Framework. Warranted Assumptions Revisited: Test Driven Development. Conclusion.14. Design.
Design and XP. Where Design Patterns Fit in XP. Architecture and XP. Agile Modeling. What is Agile Modeling (AM)? Overview of the Values, Principles, and Practices of Agile Modeling (AM).15. Code With Intention.
What's in a Name. Simplicity is the Ultimate Complexity. Warranted Assumptions. Let the Compiler Tell You. “No Comment”. Collective Code Ownership. Better to Burn Out than to Fade Away? Happy Developers Are Productive Developers. Get a Life. Conclusion.16. Refactoring.
Examples of Refactorings. Courage. Code Smells. When to Refactor. The Two Hats. Refactoring to Patterns. Example of Refactoring. Conclusion.17. Relentless Integration.
Some Practical Advice. Only Check in When Tests Pass at 100 Percent. An Antipattern. Approaches to Integration. What About Code Reviews. The Impact of Collective Code Ownership.
V. DELIVERY.18. Delivering the System.
Delivery Day. Productionizing. Testing. Celebrating Victories.
VI. ADDITIONAL TOPICS.19. Adopting and Adapting XP.
Understanding XP. Adopting XP. Methods of Adoption. Adapting XP. XP Practices. Return on Investment. Conclusion.20. Scaling XP.
Large-Scale Development. Organizing the Large XP Project. Open and Honest Communication. Integration. The Importance of Good People. Conclusion.21. The Future of XP.
Where XP is Going. On to the Battlefield. A Holonic Approach to XP. Software Development as a Craft. Evolving XP.Appendix: Example.
The principles of extreme programming have changed the way we think about software development.The Need to be Extreme
Both business people and software developers often view traditional software development techniques as too slow. Business people view software as a competitive advantage, and a competitive advantage can never be realized too quickly. Software developers believe that their traditional software development processes create too much overhead in their quest to deliver this advantage as quickly as possible.
The need to deliver software more quickly caused Kent Beck, Ward Cunningham, and Ron Jeffries to explore the extremes of certain development practices. The first XP project, the Chrysler Comprehensive Compensation system (code name C3), was, on one hand, constrained and, on the other, pushed to its limits. This practice was called "setting the dials to ten." The result was a breakthrough in the software development called XP.
Beck was certainly the driving force behind taking this project, and the multitude of others that have followed, to the extreme, and he continues to evolve XP. His vision continues as he asks us to question the basic principles of software engineering. Naturally, many of these principles are being replaced with new and better ones. New principles, such as working with a real live customer instead of a specification, are quickly gaining acceptance in the software community. The idea of creating tests before the software is written is quickly becoming a vital part of every software development process.
This book attempts to capture one point in the evolution of XP. We have examined the principles and have created what we believe to be effective practices. As a result, we believe that this short guide serves as a practical one from which to learn XP.
We used some of the XP principles to write this book (adapted, of course, for book writing). For example, various things that one of our customers felt we needed to cover were written on index cards and scheduled into the iterations of the book. This book has been continuously integrated and refactored. Hopefully, you, another customer, will like the finished product.Follow Up
To obtain the code from the appendix as well as other information about this book and XP in general, we invite you to visit Saorsa Development Inc.'s web site at