Details

<p>Preface xi</p> <p><b>1. What Is an Agile Methodology? 1</b></p> <p>1.1 Rapid Business Change: The Ultimate Driver 1</p> <p>1.2 What Must Agile Methodologies be Able to Do? 2</p> <p>1.3 Agility: What Is It and How Do We Achieve It? 2</p> <p>1.4 Evolving Software: Obstacles and Possibilities 5</p> <p>1.5 The Quality Agenda 6</p> <p>1.6 Do We Really Need All This Mountain of Documentation? 9</p> <p>1.7 The Human Factor 10</p> <p>1.8 Some Agile Methodologies 11</p> <p>1.8.1 Dynamic Systems Development Method 12</p> <p>1.8.2 Feature-Driven Design 13</p> <p>1.8.3 Crystal 14</p> <p>1.8.4 Agile Modeling 14</p> <p>1.8.5 Scrum 15</p> <p>1.8.6 Summary Table 15</p> <p>1.9 Review 16</p> <p>Exercise 17</p> <p>Conundrum 17</p> <p>References 18</p> <p><b>2. Extreme Programming Outlined 19</b></p> <p>2.1 Some Guiding Principles 19</p> <p>2.2 The Five Values 20</p> <p>2.2.1 Communication 20</p> <p>2.2.2 Feedback 22</p> <p>2.2.3 Simplicity 24</p> <p>2.2.4 Courage 24</p> <p>2.2.5 Respect 25</p> <p>2.3 The 12 Basic Practices of XP 25</p> <p>2.3.1 Test-First Programming 25</p> <p>2.3.2 Pair Programming 26</p> <p>2.3.3 On-Site Customer 27</p> <p>2.3.4 The Planning Game 28</p> <p>2.3.5 System Metaphor 29</p> <p>2.3.6 Small, Frequent Releases 30</p> <p>2.3.7 Always Use the Simplest Solution That Adds Business Value 30</p> <p>2.3.8 Continuous Integration 31</p> <p>2.3.9 Coding Standards 32</p> <p>2.3.10 Collective Code Ownership 32</p> <p>2.3.11 Refactoring 33</p> <p>2.3.12 Forty-Hour Week 33</p> <p>2.4 Can XP Work? 34</p> <p>2.5 The Evidence for XP 35</p> <p>2.5.1 Evidence for Test First 35</p> <p>2.5.2 Evidence for Pair Programming 36</p> <p>2.5.3 Evidence for XP 36</p> <p>2.6 Preparing to XP 37</p> <p>Exercise 37</p> <p>Conundrum 38</p> <p>References 39</p> <p><b>3. Foundations: People and Teams Working Together 41</b></p> <p>3.1 Software Engineering in Teams 41</p> <p>3.2 Personalities and Team Success 42</p> <p>3.3 Observations of Team Behavior in XP Projects 46</p> <p>3.4 Setting Up a Team 50</p> <p>3.5 Developing Team Skills 52</p> <p>3.6 Training Together 54</p> <p>3.7 Finding and Keeping a Client for a University-Based Project or a Small Business Start-Up 54</p> <p>3.8 The Organizational Framework 56</p> <p>3.9 Planning 60</p> <p>3.9.1 PERT (Program Evaluation and Review Technique) 61</p> <p>3.9.2 Gantt Charts 62</p> <p>3.10 Dealing with Problems 65</p> <p>3.10.1 Basic Strategies 65</p> <p>3.10.2 When Things Go Really Wrong 66</p> <p>3.11 Risk Analysis 68</p> <p>3.12 Review 69</p> <p>Exercises 69</p> <p>Conundrum 70</p> <p>References 70</p> <p><b>4. Starting an XP Project 73</b></p> <p>4.1 Project Beginnings 73</p> <p>4.1.1 Researching the Business Background 74</p> <p>4.1.2 Exploring the Outline System Description 76</p> <p>4.2 The First Meetings with the Client 79</p> <p>4.3 Business Analysis and Problem Discovery 80</p> <p>4.4 The Initial Stages of Building a Requirements Document 82</p> <p>4.5 Techniques for Requirements Elicitation 84</p> <p>4.6 Putting Your Knowledge Together 85</p> <p>4.7 Getting Technical 85</p> <p>4.8 Developing the Requirements Documents 88</p> <p>4.9 Specifying and Measuring the Quality Attributes of the System 91</p> <p>4.9.1 Identifying Attributes 92</p> <p>4.9.2 Specifying the Acceptable Level of an Attribute 94</p> <p>4.9.3 User Characteristics and User Interface Characteristics 95</p> <p>4.10 The Formal Requirements Document and System Metaphor 96</p> <p>4.10.1 Commentary 106</p> <p>4.11 Contract Negotiation 108</p> <p>4.12 Case Study: The Impact of Organizational Politics 114</p> <p>4.13 Review 116</p> <p>Conundrum 116</p> <p>References 117</p> <p><b>5. Identifying Stories and Preparing to Build 119</b></p> <p>5.1 Looking at the User Stories 119</p> <p>5.2 Collections of Stories 128</p> <p>5.2.1 Pharmacovigilance 129</p> <p>5.2.2 Stamps System 131</p> <p>5.2.3 DELTAH (Developing European Leadership Through Action-Learning in Healthcare) 131</p> <p>5.3 User Interfaces 139</p> <p>5.4 Communicating Clearly with the Customer and Building Confidence 141</p> <p>5.5 Demonstrating the Non-Functional Requirements 143</p> <p>5.5.1 Non-Functional Requirements 143</p> <p>5.6 Estimating Resources 144</p> <p>5.6.1 Software Cost Estimation 145</p> <p>5.6.2 Object Point Analysis 146</p> <p>5.6.3 Cosmic Ffp 147</p> <p>5.7 Review 149</p> <p>Exercises 149</p> <p>Conundrum 150</p> <p>References 151</p> <p><b>6. Bringing the System Together as a Coherent Concept 153</b></p> <p>6.1 What is the Problem? 153</p> <p>6.2 A Simple Common Metaphor 156</p> <p>6.3 Architectures and Patterns 159</p> <p>6.4 Finite State Machines 160</p> <p>6.5 Extreme Modeling (XM) 163</p> <p>6.6 Multiple Stories and XXMs 166</p> <p>6.7 Building the Architecture to Suit the Application: A Dynamic System Metaphor 171</p> <p>6.8 Another Look at Estimation 177</p> <p>6.9 Review 179</p> <p>Exercise 180</p> <p>Conundrum 180</p> <p>References 180</p> <p><b>7. Designing the System Tests 181</b></p> <p>7.1 Preparing to Build Functional Test Sets 181</p> <p>7.1.1 Tests and Testing 181</p> <p>7.1.2 Testing from a Model 183</p> <p>7.1.3 Developing the Model 187</p> <p>7.2 Testing with the Data in Mind 191</p> <p>7.3 The Full Functional System Testing Strategy 192</p> <p>7.4 The Thinking Behind the System Test Process 193</p> <p>7.4.1 An Algorithm for Determining the Transition Cover 198</p> <p>7.5 Design for Test 201</p> <p>7.5.1 Design for Test Principle 1: Controllability 202</p> <p>7.5.2 Design for Test Principle 2: Observability 202</p> <p>7.6 Test Documentation 203</p> <p>7.7 Non-Functional Testing 205</p> <p>7.7.1 Reliability 206</p> <p>7.7.2 Usability 206</p> <p>7.7.3 Efficiency 207</p> <p>7.7.4 Portability 207</p> <p>7.8 Testing Internet Applications and Web Sites 207</p> <p>7.9 Review 209</p> <p>Exercise 210</p> <p>Conundrum 213</p> <p>References 213</p> <p><b>8. Units and Their Tests 215</b></p> <p>8.1 Basic Considerations 215</p> <p>8.2 Identifying the Units 216</p> <p>8.3 Unit Testing 219</p> <p>8.4 More Complex Units 222</p> <p>8.4.1 Case Example: The AddElement Function in JHotDraw 223</p> <p>8.5 Automating Unit Tests 232</p> <p>8.5.1 Writing Unit Tests in JUniti 233</p> <p>8.5.2 Managing Tests 235</p> <p>8.6 Documenting Unit Test Results 235</p> <p>8.7 Review 237</p> <p>Exercises 237</p> <p>Conundrum 237</p> <p>References 238</p> <p><b>9. Evolving the System 239</b></p> <p>9.1 Requirements Change 239</p> <p>9.2 Changes to Basic Business Model and Functionality 240</p> <p>9.3 Dealing with Change: Refining Stories 241</p> <p>9.3.1 Changes to the Underlying Data Model 241</p> <p>9.3.2 Changes to the Structure of the Interface, Perhaps the Introduction of a New Screen 242</p> <p>9.3.3 Adding a New Function 242</p> <p>9.3.4 Changing the Functionality of a Function 242</p> <p>9.4 Changing the Model 242</p> <p>9.4.1 Changing a Process 242</p> <p>9.4.2 Removing States 244</p> <p>9.4.3 Adding States 245</p> <p>9.4.4 Adding a Complete Machine 246</p> <p>9.4.5 Adding Processes 246</p> <p>9.5 Testing for Changed Requirements 247</p> <p>9.6 Refactoring the Code 248</p> <p>9.7 Estimating the Cost of Change 249</p> <p>9.8 Review 249</p> <p>Exercises 250</p> <p>Conundrum 250</p> <p>Reference 250</p> <p><b>10. Documenting and Delivering the System 251</b></p> <p>10.1 What is Documentation for and Who Is Going to Use It? 251</p> <p>10.2 Coding Standards and Documents for Programmers 252</p> <p>10.3 Coding Standards for Java 253</p> <p>10.3.1 Genesys Coding Standard for Java 253</p> <p>10.3.2 Blank Lines 255</p> <p>10.4 Maintenance Documentation 262</p> <p>10.5 User Manuals 263</p> <p>10.6 Version Control 264</p> <p>10.6.1 The Project Archive 265</p> <p>10.6.2 Naming Conventions 265</p> <p>10.7 Delivery and Finalization 266</p> <p>10.8 Review 267</p> <p>Exercises 267</p> <p>Conundrum 267</p> <p>Reference 267</p> <p><b>11. Reflecting on the Process 269</b></p> <p>11.1 Skills and Lessons Learned 269</p> <p>11.2 The XP Experience 270</p> <p>11.3 Personal and Team Assessment 270</p> <p>11.4 Review 271</p> <p>Exercises 271</p> <p>11.5 Conundrums: Discussion 271</p> <p>11.6 A Final Word 277</p> <p><b>12. Lifestyle Matters 281</b></p> <p>12.1 Keeping Fit 282</p> <p>12.1.1 Correct Sitting Position 283</p> <p>12.1.2 Combating RSI 284</p> <p>12.2 General Well-Being 285</p> <p>12.3 Mental Preparation 285</p> <p>12.4 Diet 286</p> <p>12.4.1 Diet and Brain Function 286</p> <p>12.4.2 Summary of Dietary Information 287</p> <p>12.5 Music and Work 288</p> <p>12.6 Review 289</p> <p>References 290</p> <p>Appendix 291</p> <p>Bibliography 305</p> <p>Index 309</p>

<b>Mike Holcombe, BSC, MSC, PHD</b>, is Professor of Computer Science at the University of Sheffield, UK. He is also founder of Genesys Solutions, which is a student-run commercial software house that is strongly supported by IBM (winning the IBM International Eclipse Innovation Award in 2004 and 2005) and is also designated as a Microsoft Innovation Center. The University of Sheffield has recently "spun out" this company as epiGenesys Ltd. Dr. Holcombe's research interests include software and systems biology. A former dean of the faculty of engineering at the University of Sheffield, he is a Fellow of the British Computer Society and a Fellow of the Institute of Mathematics and Its Applications. He is on the editorial board of the journal <i>BioSystems</i> and <i>Software Testing, Verification and Reliability</i> (Wiley). He is also on the editorial board of the <i>International Journal of Agile and Extreme Software Development</i> and has been appointed to the Academic Advisory Board of Microsoft.

<b>A Practical Approach To Building Small To Medium Software Systems For Real Business Clients</b> <p>Based on more than 100 actual commercial projects, this book clearly explains how to run an agile software development project that delivers high-quality, high-value solutions to business clients. It concentrates on the practical, social, business, and management aspects as well as the technical issues involved.</p> <p>Professor Holcombe successfully connects readers with the wave of "Agile 2.0" concepts that take the techniques of agile development and place them in the service of business goals. Since it is widely believed that the use of Windows XP will become much more common in coming years, readers should be armed with cutting-edge knowledge of the latest practices in the field. Further features of the book include:</p> <ul> <li> <p>Case studies provide real-world examples and describe how XP was introduced into the environment</p> </li> <li> <p>Analysis is provided to help readers determine which elements of XP are suitable for the unique challenges and environments for different projects</p> </li> <li> <p>Problems of a failing agile project and how they can be fixed are covered, including insight into which managerial techniques can be employed</p> </li> <li> <p>An Instructor's Guide provides practical advice on how to motivate students, organize real group projects, and deal, in a simple and effective way, with many of the problems that arise</p> </li> <li> <p>A sample syllabus, sample tests, and additional case study information are available on an instructor's password-protected ftp site</p> </li> </ul> <p><i>Running an Agile Software Development Project</i> is an indispensable guide for professional software developers, engineers, and project managers interested in learning how to use agile processes. It is also a valuable textbook for advanced undergraduate- and graduate-level students in computer engineering and software engineering courses.</p>

US