Extreme Programming Installed (The XP Series)

Whether you believe XP can work or not, this book will cause you to think about software programming in ways you never had before. By now most of us are familiar with the basics of XP: simplicity, communication, feedback, and courage. At the core of the XP philosophy are the concepts of pair programming, writing unit tests before coding, and small incremental software releases. The emphasis is on quality and rapid turn around. The book opens with a foreword by Kent Beck. He is the creator of XP, and the author of Extreme Programming Explained. "XP was conceived and developed to address the specific needs of software development conducted by small teams in the face of vague and changing requirements." What this book does is to take it one step further by showing us how to implement the controversial principles of XP. The process begins by defining the roles of the customer, programmer, and manager. Each participant must provide a symmetric piece of the XP pie. The customer: determines what is to be done and how it is tested. The programmer: designs, tests, and builds. The manager: coordinates and facilitates the interactions between customer and programmer. The authors tell us that software analysis is done in stories. A story is a short description of how the system will behave. The requirements gathering phase consists of the customer telling a story of what the software is do. Written on 5x8 index cards these stories will be later refined, sorted by importance, and handed to the programming teams for implementation. "Stories should encompass a week or two of programmer time." Any more than a week and the story is too long, any less and the story should be combined with other stories and treated as a group. When the stories are done it is time to write the test code. Working on one story at a time the programmer writes a test for each task in a story, and then codes for that particular task until it works. After reading this book, readers will be amazed at the simplicity of the XP system. Metrics and modeling is not really necessary in the XP world. "Success is measured in Resources, Scope, Quality, and Time." The book was written in the clear and lighthearted manner we've come to expect from the XP family. You may not be ready to embrace the change, but XP installed is both interesting and thought provoking. Preface 7 Extreme Programming 9 The customer role 10 The programmer role 12 The manager role 14 Rights / Responsibilities 16 Manager and Customer Rights 16 Programmer Rights 17 You have the right to an overall plan, to know what can be accomplished, when, and at what cost. 17 You have the right to get the most possible value out of every programming week. 18 You have the right to see progress in a running system, proven to work by passing repeatable test... 18 You have the right to change your mind, to substitute functionality, and to change priorities wit... 18 You have the right to be informed of schedule changes, in time to choose how to reduce scope to r... 18 You have the right to know what is needed, with clear declarations of priority. 19 You have the right to produce quality work at all times. 19 You have the right to ask for and receive help from peers, superiors, and customers. 19 You have the right to make and update your own estimates. 19 You have the right to accept your responsibilities instead of having them assigned to you. 20 Project flow 20 Forward 23 Circle of Life 27 On-site Customer 31 On-site customers do real work 34 If the customer can’t be there 34 Summary 35 User Stories 37 Starting with stories 38 Sample Stories 39 Stories are promises for conversation 41 Do programmers ever write stories? 41 Can stories be too big or too small? 42 What if you don’t have all the stories? 43 What’s the next step with stories? 43 Acceptance Tests 45 Automating the tests 47 Timeliness 48 Acceptance Test Samples 49 Story Estimation 51 During project flow, estimate by comparison 52 Early on, start with intuitive time estimates 54 Spike Solution 55 Balancing an account. 56 Formatted reports 56 Database Access 57 Automatic Email 58 Spiking for estimation 58 Estimation Summary 59 Sense of Completion 61 Programmers set the rhythm 62 Small Releases 65 Payroll is all or nothing 66 Personnel System 67 Tax Package 68 Distributed manufacturing control system 68 Air traffic control system 69 Summary 70 Customer Defines Release 71 Release Planning Meeting 75 Iteration Planning 79 The planning meeting 80 Customer presents User Stories 81 Team brainstorms Engineering Tasks 81 Programmer signs up for work and estimates 82 Sign up for stories 82 An Iteration Planning Practice 84 Quick Design Session 87 Programming 89 Collective Code Ownership 93 Simple Design 93 Refactoring 95 Continuous Integration 96 Coding Standard 97 40-Hour Week 100 Summary 101 Code Quality 103 Pair Programming 107 Summary 111 Unit Tests 113 Testing bit by bit 114 Summary of testing steps 119 Testing questions 120 How do you test when you have an attached database? 120 What if your tests run really slowly? 121 What if you can’t figure out how to test a class? 122 Is it OK to test a class by just testing the classes that use it? 122 How do you know you have tested everything that could possibly break? 123 What do you do if you have a body of already-written code, but not many tests? 123 What about errors that only show up in collaborations between classes? 123 What about real time errors or multithreading errors? 124 What about GUIs? 124 My stuff can’t be tested because... 125 xUnit 127 Test-first, by Intention 129 Review Remarks 142 Summary 143 Releasing Changes 145 Do or Do Not 151 Experience improves estimates 155 Resources, Scope, Quality, Time 157 Resources 157 Scope 157 Quality 158 Time 158 Tracking and Reporting Scope 158 Tracking and Reporting Quality 160 What about other metrics? 167 You can't resist, can you? 168 Steering 171 Steering the Iteration 173 Get stories done 173 Improve estimates 173 Tracking 174 Benefits of Tracking 177 Steering the Release 179 Summary 181 Handling Defects 183 Reporting Problems 183 Scheduling Corrections 184 Test and Fix the Problem 185 Preventing Defects 185 Summary 186 Advanced Issue: Bug Databases 187 Advanced Practice: Tests as Database 191 Test to show a defect 193 Conclusion 195 Bonus Tracks 205 We’ll Try 207 How to estimate anything 217 Infrastructure 219 It’s Chet’s Fault 223 Balancing Hopes and Fears 225 Testing Improves Code 227 XPer Tries Java 231 A Java Perspective 241 Example 241 Model First 242 The GUI Connection 243 Testing Key Widgets 243 Testing Interconnection 245 Testing with a Fake Searcher 246 0, 1, Many 247 Record our Mental Stack 248 Adapter Implementation 249 TestN and More 250 Testing for Looks 251 Main 254 Conclusions 254 Resources 255 A True Story 257 Estimates and Promises 261 Estimate the entire project as accurately as possible 262 Track estimates to get project velocity 262 Refine the picture 263 Control the outcome 263 Everything that could possibly break 265 Does this mean to test every object and every method? 266 Test everything example 268 Questions about the example 272 Can the account go negative? How negative? 273 Can an account have fractions less than one penny? 273 Is there a maximum size on the account? 273 Summary response to the review questions 273 Preface......Page 7 Extreme Programming......Page 9 The customer role......Page 10 The programmer role......Page 12 The manager role......Page 14 Manager and Customer Rights......Page 16 You have the right to an overall plan, to know what can be accomplished, when, and at what cost.......Page 17 You have the right to be informed of schedule changes, in time to choose how to reduce scope to r.........Page 18 You have the right to make and update your own estimates.......Page 19 Project flow......Page 20 Forward......Page 23 Circle of Life......Page 27 On-site Customer......Page 31 If the customer can’t be there......Page 34 Summary......Page 35 User Stories......Page 37 Starting with stories......Page 38 Sample Stories......Page 39 Do programmers ever write stories?......Page 41 Can stories be too big or too small?......Page 42 What’s the next step with stories?......Page 43 Acceptance Tests......Page 45 Automating the tests......Page 47 Timeliness......Page 48 Acceptance Test Samples......Page 49 Story Estimation......Page 51 During project flow, estimate by comparison......Page 52 Early on, start with intuitive time estimates......Page 54 Spike Solution......Page 55 Formatted reports......Page 56 Database Access......Page 57 Spiking for estimation......Page 58 Estimation Summary......Page 59 Sense of Completion......Page 61 Programmers set the rhythm......Page 62 Small Releases......Page 65 Payroll is all or nothing......Page 66 Personnel System......Page 67 Distributed manufacturing control system......Page 68 Air traffic control system......Page 69 Summary......Page 70 Customer Defines Release......Page 71 Release Planning Meeting......Page 75 Iteration Planning......Page 79 The planning meeting......Page 80 Team brainstorms Engineering Tasks......Page 81 Sign up for stories......Page 82 An Iteration Planning Practice......Page 84 Quick Design Session......Page 87 Programming......Page 89 Simple Design......Page 93 Refactoring......Page 95 Continuous Integration......Page 96 Coding Standard......Page 97 40-Hour Week......Page 100 Summary......Page 101 Code Quality......Page 103 Pair Programming......Page 107 Summary......Page 111 Unit Tests......Page 113 Testing bit by bit......Page 114 Summary of testing steps......Page 119 How do you test when you have an attached database?......Page 120 What if your tests run really slowly?......Page 121 Is it OK to test a class by just testing the classes that use it?......Page 122 What about errors that only show up in collaborations between classes?......Page 123 What about GUIs?......Page 124 My stuff can’t be tested because.........Page 125 xUnit......Page 127 Test-first, by Intention......Page 129 Review Remarks......Page 142 Summary......Page 143 Releasing Changes......Page 145 Do or Do Not......Page 151 Experience improves estimates......Page 155 Scope......Page 157 Tracking and Reporting Scope......Page 158 Tracking and Reporting Quality......Page 160 What about other metrics?......Page 167 You can't resist, can you?......Page 168 Steering......Page 171 Improve estimates......Page 173 Tracking......Page 174 Benefits of Tracking......Page 177 Steering the Release......Page 179 Summary......Page 181 Reporting Problems......Page 183 Scheduling Corrections......Page 184 Preventing Defects......Page 185 Summary......Page 186 Advanced Issue: Bug Databases......Page 187 Advanced Practice: Tests as Database......Page 191 Test to show a defect......Page 193 Conclusion......Page 195 Bonus Tracks......Page 205 We’ll Try......Page 207 How to estimate anything......Page 217 Infrastructure......Page 219 It’s Chet’s Fault......Page 223 Balancing Hopes and Fears......Page 225 Testing Improves Code......Page 227 XPer Tries Java......Page 231 Example......Page 241 Model First......Page 242 Testing Key Widgets......Page 243 Testing Interconnection......Page 245 Testing with a Fake Searcher......Page 246 0, 1, Many......Page 247 Record our Mental Stack......Page 248 Adapter Implementation......Page 249 TestN and More......Page 250 Testing for Looks......Page 251 Conclusions......Page 254 Resources......Page 255 A True Story......Page 257 Estimates and Promises......Page 261 Track estimates to get project velocity......Page 262 Control the outcome......Page 263 Everything that could possibly break......Page 265 Does this mean to test every object and every method?......Page 266 Test everything example......Page 268 Questions about the example......Page 272 Summary response to the review questions......Page 273

• Software that performs required tasks and meets expectations
• Accurate estimation of time to completion and cost of development
• The opportunity to decide which features to include and which to defer
• Frequent small releases that incorporate continual customer feedback
• Constant integration and automated testing that insures clean code and robust performance

These are some of the many benefits of Extreme Programming (XP), a software development approach especially geared for smaller teams facing vague or rapidly changing requirements. Despite the "extreme" in its name, XP actually reduces risks--the risk of putting out software that is faulty, out of date at its release, over budget, or not fully capable of performing the tasks for which it was intended. Initially considered radical, XP has proven itself successful and is entering the mainstream of software development. The greatest challenge now facing software development managers and engineers is how to implement this beneficial approach.

Extreme Programming Installed explains the core principles of Extreme Programming and details each step in the XP development cycle. This book conveys the essence of the XP approach--techniques for implementation, obstacles likely to be encountered, and experience-based advice for successful execution.

You will learn the best approaches to

• Working with an on-site customer
• Defining requirements with user "stories"
• Estimating the time and cost of each story
• Delivering small, frequent releases
• Performing constant integration and frequent iterations
• Running design sessions to help programmers move forward with confidence
• xUnit automated testing
• Handling defects in the fast-paced, team-oriented XP environment
• How to refine estimates and steer the development effort through frequent changes

The authors present the personal reflections of those who have been through the eXtreme Programming experience. Readers will benefit from first hand accounts of hard-won wisdom on topics such as the art of estimation, managing development infrastructure, solving problems without finger-pointing, the importance of simplicity, and how to introduce modern development tools into an environment where none existed.

0201708426B04062001

Extreme Programming (XP) is a revolutionary lightweight methodology that's supercharging software development in organizations worldwide. Perfect for small teams producing software with fast-changing requirements, XP can save time and money while dramatically improving quality. In XP Installed , three participants in DaimlerChrysler's breakthrough XP project cover every key practice associated with XP implementation. The book consists of a connected collection of essays, presented in the order the practices would actually be implemented during a project. Ideal as both a start-to-finish tutorial and quick reference, the book demonstrates exactly how XP can promote better communication, quality, control, and predictability. An excellent complement to the best selling Extreme Programming Explained , it also works perfectly on a standalone basis, for any developer or team that wants to get rolling with XP fast . Extreme Programming Installed is a short presentation of the core practices composing the emerging discipline of Extreme Programming (XP). The book is a connected collection of essays by experienced users of XP, and the material is presented in the order in which it should be implemented in a development project. The authors' unique approach allows this book to be used in a tutorial/user guide fashion, while the individual essays can be continually accessed as a quick reference to specific aspects of XP. The result is a book that allows the reader to improve the quality of their software development efforts with XP.