Extreme Programming Installed

Ron Jeffries was the on-site XP coach for the original Extreme Programming project, a large financial system for a major automotive manufacturer. An independent consultant who has been involved in eXtreme Programming for over more than four years, he has presented numerous talks and published several papers on the topic. Ron has been a systems developer for more years than most of you have been alive, and his teams have built operating systems, compilers, relational database systems, and a wide range of applications. He has not, as yet, run out of new ways to make mistakes (and resolve them). Ron has recently joined forces with Object Mentor, Inc., to help more people improve their software process. Ann Anderson is an independent consultant engaged full time in coaching XP and in teaching and using Smalltalk for financial applications development. Ann was a team member on the large payroll system that was the original proving ground for Extreme Programming. Throughout her career she has been involved in object-oriented projects spanning control systems, insurance, tax, and finance. Chet Hendrickson is a systems architect at ThoughtWorks, Inc, where he makes sure that programmers and customers know and understand their rights. Previously, Chet was a senior software systems specialist at a major automobile manufacturer, where he worked on a large operational finance system that was the test bed for Extreme Programming. He was the winner of the Project Manager Game at OOPSLA99 (although he thinks it might have been rigged). 0201708426AB05082001

(Whitaker)

Foreword. Preface. 1. Extreme Programming. Extreme Programming Is a Discipline of Software Development with Values of Simplicity, Communication, Feedback, and Courage. We Focus on the Roles of Customer, Manager, and Programmer and Accord Key Rights and Responsibilities to the People in Those Roles. 2. The Circle of Life. An XP Project Succeeds when the Customers Select Business Value to be Implemented, Based on the Teams Measured Ability to Deliver Functionality Over Time. 3. On-Site Customer. An XP Project Needs a Full-Time Customer to Provide Guidance. Heres a Summary of Why. 4. User Stories. Define Requirements with Stories, Written on Cards. 5. Acceptance Tests. Surely You Arent Going to Assume Youre Getting What You Need. Prove That It Works! Acceptance Tests Allow the Customer To Know When the System Works and Tell the Programmers What Needs To Be Done. Sidebar: Acceptance Test Samples. At First it Can Be Difficult Figuring Out How to Do Acceptance Tests. with a Little Practice, It Becomes Easy. 6. Story Estimation. Customers Need To Know How Much Stories Will Cost in Order to Choose Which Ones to Do and Which to Defer. Programmers Evaluate Stories to Provide That Information. Heres How. Interlude: Sense of Completion. XPs Nested Planning and Programming Cycles Keep the Project On Track and Provide a Healthy Sense of Accomplishment at Frequent Intervals. 7. Small Releases. The Outermost XP Cycle Is the Release. Small and Frequent Releases Provide Early Benefit to the Customer While Providing Early Feedback to the Programmers. Here Are Some Thoughts on How to Make It Happen. 8. Customer Defines Release. In Each Release Cycle, the Customer Controls Scope, Deciding What to Do and What to Defer, to Provide the Best Possible Release by the Due Date. Work Fits into the Calendar Based on Business Value, Difficulty, and the Teams Implementation Velocity. 9. Iteration Planning. Inside Each Release, an Extreme Team Plans Just a Few Weeks at a Time with Clear Objectives and Solid Estimates. 10. Quick Design Session. Within Each Iteration, Programmers Dont Stand Alone. Heres a Technique to Help Programmers Move Forward with Courage. Make It Part of Your Teams Ritual. 11. Programming. Its Called Extreme Programming, After All. Heres How We Do the Programming Part of Things. Sidebar: Code Quality. A Little More Detail on Something Close to Our Hearts: Simplicity. 12. Pair Programming. On an Extreme Programming Team, Two Programmers Sitting Together at the Same Machine Write All Production Code. 13. Unit Tests. Extreme Programmers Test Everything That Could Possibly Break, Using Automated Tests That Must Run Perfectly All the Time. Sidebar: xUnit. Use the Worlds Lightest Testing Tool. 14. Test First, by Intention. Code What You Want, Not How to Do It. Chet and Ron Do a Small Task Test First Trying Always to Express Intention in the Code Rather than Algorithm. 15. Releasing Changes. Using Collective Code Ownership and Comprehensive Unit Tests, an XP Team Releases Changes Rapidly and Reliably. 16. Do or Do Not. Weve Now Covered Most of the Programming Aspects of XP. Heres a Summary of Things We Do - and Things We Dont Do. 17. Experience Improves Estimates. With Each Iteration, We Gain Experience. Experience with Stories Helps Us Estimate Future Stories More Easily and More Accurately. 18. Resources, Scope, Quality, Time. Whos Doing What? How Much Is Finished? How Good Is It? When Will We Be Done? What Metrics Should We Keep? 19. Steering. The Estimates Are Wrong. Your Priorities Will Change. You Must Steer. 20. Steering the Iteration. To Steer Each Iteration, You Need to Track How Many Stories Are Getting Done and How Well the Task Estimates Are Holding Up. 21. Steering the Release. To Steer the Release, You Need to Track Whats Done, How Fast You Are Going, and How Well the System Works. 22. Handling Defects. Report `Em, Schedule `Em, Test and Fix `Em, Avoid `Em. Just Dont Call `Em B

(Whitaker)