Foreword
Preface
Part 1. Why XP?
Who Cares About Process, Anyway?
The XP Equation
XP Values
Communication
Feedback
Simplicity
Courage
Assuming Sufficiency
Sufficient Time
Sufficient Resources
Constant Cost of Change
Developer Effectiveness
Freedom to Experiment
Part 2. Extreme Programming Practices
Coding Practices
1. Code and Design Simply
2. Refactor Mercilessly
3. Develop Coding Standards
4. Develop a Common Vocabulary
Developer Practices
1. Adopt Test-Driven Development
2. Practice Pair Programming
3. Adopt Collective Code Ownership
4. Integrate Continually
Business Practices
1. Add a Customer to the Team
2. Play the Planning Game
3. Release Regularly
4. Work at a Sustainable Pace
Part 3. XP Events
Iteration Planning
Stories and Tasks
Estimates and Schedules
The First Iteration
The Iteration
Releasing
Part 4. Extreme Programming Artifacts
Story Cards
Task Cards
The Bullpen
Part 5. Roles in Extreme Programming
The Customer
Customer Rights
Customer Responsibilities
The Developer
Developer Rights
Developer Responsibilities
Supplementary Roles
The Tracker
The Coach
Part 6. Coding, XP Style
Do the Simplest Thing That Could Possibly Work
You Aren't Gonna Need It
Once and Only Once
Part 7. Adopting XP
Before You Start
Eliminating Fear and Working Together
Starting Feedback
Including Managers and Customers
Now That You're Extreme
Part 8. Further Resources
XP Resources
Index

While not a programmer by job title, I do write a lot of scripts, and I try to maintain thethreemodules that I have on CPAN. I wanted to learn about XP and at least get a basic understanding of its principles and how they all work together, with an eye towards eventually adopting some of its practices into how I code.

Chromatic starts off by explaining the reasons for using XP. "The goal of software development is to create good systems that meet business needs with the available resources. XP can help you do just that."

The material is broken down into eight sections, each one covering a specific topic. Section 1 deals with describing XP and its values, and the problem that it was intended to solve.

Section 2 dives in the meat of XP, covering each of the twelve core practices of XP, breaking them down into three groups, Coding, Developing, and Business.

Section 3 covers the various events that happen within an XP development cycle. He breaks down the first phase (Iteration Planning) into three sections, then goes on to cover the Iteration and Releasing.

Section 4 deals with the physical items that XP uses to keep track of events, such as story and task cards. The Bullpen, which is defined as a large open area with plenty of powerful pc's with room for at least two programmers at each one (Pair Programming), several large chalkboards or whiteboards, and plenty of sticky notes and pens.

Section 5 deals with the roles in XP, and the rights and responsibilities of each of those roles. As developers, we need to follow team guidelines, implement only what is necessary, and communicate constantly with the customer.

Section 6 deals with the coding style of XP, which follows three basic principles. "Do the simplest thing that could work", "You aren't gonna need it", and "Once and only once". Chromatic also points out that the last one is quite similar to the principle mentioned in The Pragmatic Programmer, "Don't Repeat Yourself".

Sections 7 and 8 deal with how to go about implementing XP and where you can find more resources on this subject.

This book was very well written and concise, and it lays out precisely the necessary strategies and information needed to start down the XP path. I emphatically recommend this book for anyone who uses or is going to be using XP for software development.

If you are going to write a book review then by all means review the book. What did you agree with? What did you not agree with? The single paragraph synopsis at the end was useless because you lost me as a reader back in paragraphs two.