Running an agile software development project/by Mike Holcombe. ..... team, then you will be of little use to a software development company whatever tech-.
Running an Agile Software Development Project
Running an Agile Software Development Project Mike Holcombe University of Sheffield, United Kingdom
Copyright # 2008 by John Wiley & Sons, Inc. All rights reserved. Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 750-4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permission. Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com. Library of Congress Cataloging-in-Publication Data: Holcombe, W. M. L. (William Michael Lloyd), 1944Running an agile software development project/by Mike Holcombe. p. cm. Includes bibliographical references and index. ISBN 978-0-470-13669-0 (cloth) 1. Computer software—development. 2. Agile software development. 3. eXtreme programming. I. Title. QA76.76.D47H647 2008 005.10 1--dc22 2008009444 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1
Contents
Preface
xi
1. What Is an Agile Methodology?
1
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8
Rapid Business Change: The Ultimate Driver 1 What Must Agile Methodologies be Able to Do? 2 Agility: What Is It and How Do We Achieve It? 2 Evolving Software: Obstacles and Possibilities 5 The Quality Agenda 6 Do We Really Need All This Mountain of Documentation? The Human Factor 10 Some Agile Methodologies 11 1.8.1 1.8.2 1.8.3 1.8.4 1.8.5 1.8.6
Dynamic Systems Development Method Feature-Driven Design 13 Crystal 14 Agile Modeling 14 SCRUM 15 Summary Table 15 16
9
12
1.9 Review Exercise 17 Conundrum 17 References 18
2. Extreme Programming Outlined 2.1 2.2
Some Guiding Principles The Five Values 20 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5
2.3
Communication Feedback 22 Simplicity 24 Courage 24 Respect 25
19 19 20
The 12 Basic Practices of XP 2.3.1 2.3.2 2.3.3 2.3.4
25 Test-First Programming 25 Pair Programming 26 On-Site Customer 27 The Planning Game 28
v
vi
Contents 2.3.5 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 2.3.11 2.3.12
System Metaphor 29 Small, Frequent Releases 30 Always Use the Simplest Solution That Adds Business Value Continuous Integration 31 Coding Standards 32 Collective Code Ownership 32 Refactoring 33 Forty-Hour Week 33 2.4 Can XP Work? 34 2.5 The Evidence for XP 35 2.5.1 Evidence for Test First 35 2.5.2 Evidence for Pair Programming 36 2.5.3 Evidence for XP 36 2.6 Preparing to XP 37 Exercise 37 Conundrum 38 References 39
3. Foundations: People and Teams Working Together 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9
41
41 Software Engineering in Teams Personalities and Team Success 42 Observations of Team Behavior in XP Projects 46 Setting Up a Team 50 Developing Team Skills 52 Training Together 54 Finding and Keeping a Client for a University-Based Project 54 or a Small Business Start-Up The Organizational Framework 56 Planning 60
3.9.1 PERT (Program Evaluation and Review Technique) 3.9.2 Gantt Charts 62 3.10 Dealing with Problems 65 3.10.1 Basic Strategies 65 3.10.2 When Things Go Really Wrong 66 3.11 Risk Analysis 68 3.12 Review 69 Exercises 69 Conundrum 70 References 70
4. Starting an XP Project 4.1
30
Project Beginnings
73 4.1.1 Researching the Business Background 74 4.1.2 Exploring the Outline System Description 76
61
73
vii
Contents
4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9
The First Meetings with the Client 79 Business Analysis and Problem Discovery 80 The Initial Stages of Building a Requirements Document 82 Techniques for Requirements Elicitation 84 Putting Your Knowledge Together 85 Getting Technical 85 Developing the Requirements Documents 88 Specifying and Measuring the Quality Attributes of the System 4.9.1 Identifying Attributes 92 4.9.2 Specifying the Acceptable Level of an Attribute 94 4.9.3 User Characteristics and User Interface Characteristics
4.10
The Formal Requirements Document and System Metaphor 4.10.1 Commentary
114
5. Identifying Stories and Preparing to Build
5.3 5.4 5.5
Looking at the User Stories Collections of Stories 128
95 96
106
4.11 Contract Negotiation 108 4.12 Case Study: The Impact of Organizational Politics 4.13 Review 116 Conundrum 116 References 117
5.1 5.2
91
119
119
5.2.1 Pharmacovigilance 129 5.2.2 Stamps System 131 5.2.3 DELTAH (Developing European Leadership Through Action-Learning in Healthcare) 131 User Interfaces 139
Communicating Clearly with the Customer and Building 141 Confidence Demonstrating the Non-Functional Requirements 143
5.5.1 Non-Functional Requirements 143 144 5.6.1 Software Cost Estimation 145 5.6.2 Object Point Analysis 146 5.6.3 COSMIC FFP 147 5.7 Review 149 Exercises 149 Conundrum 150 References 151
5.6
Estimating Resources
6. Bringing the System Together as a Coherent Concept 6.1 6.2 6.3
What is the Problem? 153 A Simple Common Metaphor 156 Architectures and Patterns 159
153
viii
Contents
6.4 6.5 6.6 6.7
Finite State Machines 160 Extreme Modeling (XM) 163 Multiple Stories and XXMs 166 Building the Architecture to Suit the Application: A Dynamic System Metaphor 171 6.8 Another Look at Estimation 177 6.9 Review 179 Exercise 180 Conundrum 180 References 180 7. Designing the System Tests 7.1
7.2 7.3 7.4
181
Preparing to Build Functional Test Sets
181
7.1.1 Tests and Testing 181 7.1.2 Testing from a Model 183 7.1.3 Developing the Model 187 Testing with the Data in Mind 191
The Full Functional System Testing Strategy The Thinking Behind the System Test Process
192 193 7.4.1 An Algorithm for Determining the Transition Cover 7.5 Design for Test 201 7.5.1 Design for Test Principle 1: Controllability 202 7.5.2 Design for Test Principle 2: Observability 202 7.6 Test Documentation 203 7.7 Non-Functional Testing 205 7.7.1 Reliability 206 7.7.2 Usability 206 7.7.3 Efficiency 207 7.7.4 Portability 207 7.8 Testing Internet Applications and Web Sites 207 7.9 Review 209 Exercise 210 Conundrum 213 References 213
8. Units and Their Tests 8.1 8.2 8.3 8.4 8.5
Basic Considerations Identifying the Units Unit Testing 219 More Complex Units
198
215 215 216
222 8.4.1 Case Example: The AddElement Function in JHotDraw Automating Unit Tests 232 8.5.1 Writing Unit Tests in JUniti 233 8.5.2 Managing Tests 235
223
Contents
8.6 Documenting Unit Test Results 8.7 Review 237 Exercises 237 Conundrum 237 References 238 9. Evolving the System 9.1 9.2 9.3
235
239
Requirements Change 239 Changes to Basic Business Model and Functionality Dealing with Change: Refining Stories 241
240
9.3.1 Changes to the Underlying Data Model 241 9.3.2 Changes to the Structure of the Interface, Perhaps the Introduction of a New Screen 242 9.3.3 Adding a New Function 242 9.3.4 Changing the Functionality of a Function 242 9.4 Changing the Model 242 9.4.1 Changing a Process 242 9.4.2 Removing States 244 9.4.3 Adding States 245 9.4.4 Adding a Complete Machine 246 9.4.5 Adding Processes 246 9.5 Testing for Changed Requirements 247 9.6 Refactoring the Code 248 9.7 Estimating the Cost of Change 249 9.8 Review 249 Exercises 250 Conundrum 250 Reference 250
10. Documenting and Delivering the System 10.1 10.2 10.3
10.4 10.5 10.6
10.7 10.8
251
What is Documentation for and Who Is Going to Use It? 251 Coding Standards and Documents for Programmers 252 Coding Standards for Java 253 10.3.1 Genesys Coding Standard for Java 10.3.2 Blank Lines 255 Maintenance Documentation 262 User Manuals 263 Version Control 264 10.6.1 The Project Archive 265 10.6.2 Naming Conventions 265 Delivery and Finalization 266 Review 267
253
ix
x
Contents
Exercises Conundrum Reference
267 267 267
11. Ref lecting on the Process
269
11.1 Skills and Lessons Learned 269 11.2 The XP Experience 270 11.3 Personal and Team Assessment 270 11.4 Review 271 Exercises 271 11.5 Conundrums: Discussion 271 11.6 A Final Word 277 12. Lifestyle Matters 12.1
281
Keeping Fit
282 12.1.1 Correct Sitting Position 283 12.1.2 Combating RSI 284 12.2 General Well-Being 285 12.3 Mental Preparation 285 12.4 Diet 286 12.4.1 Diet and Brain Function 286 12.4.2 Summary of Dietary Information 12.5 Music and Work 288 12.6 Review 289 References 290
287
Appendix
291
Bibliography
305
Index
309
Preface
This book is a radical departure from the usual book on software engineering and design methodologies. Its purpose is to put software development into a context where professional skills are developed as well as the technical skills. At the end of a project based around this book, students should be much more like real software professionals than before, ready to embark on a career where professionalism, a quality orientation, and an understanding of the business context are better developed than ever before. The target audience is computer science and software engineering students in their second or third year or in a master’s program who have already covered the basics of programming and design and who have had some experience of building a small piece of software. Software developers who have graduated and are about to embark on their first commercial project will also find the topics of interest. Those interested in starting up their own software house might also find some part of this book useful. The contents have evolved over 15 years or so during which time I have been teaching software engineering through practical project work involving real business clients. In the second year of our computer science and software engineering degree programs, students are put into small teams and spend one third of their time during a 12-week period building a business solution for their client—this is the Software Hut module. Typically, we have 3 or 4 clients and up to 20 teams of 4 to 6 students. Teams compete to build the best solution, and each client will then choose this from several that are supplied. The competitive aspect is generally positive, and the clients have always had several excellent software systems to choose from and use in their businesses. This long practical experience has shown me that much of what is written in academic software engineering books and taught in university courses is largely irrelevant to practical real-world software development. Academics tend to abstract away the messy bits and treat software development in an idealized and essentially trivial manner. Many of the techniques and notations promoted in academe just do not work in real life. There is little rigorous scientific evidence for their utility in practice, and they are derived from a naı¨ve understanding of the very real pressures that exist in business. This lack of understanding of the business world is now proving to be a serious issue—a handicap, even—in terms of recent computing graduates getting good jobs in the IT industry. In the United Kingdom, only 28% of IT graduates found graduate-level jobs in the IT industry (this includes IT posts in industry and commerce generally).1 Many traditional 1
e-skills.com, the UK government board responsible for the IT sector, has identified this fact for 2006.
xi
xii
Preface
programming jobs have been outsourced to developing countries, and the IT industry now needs graduates with much more business understanding: Technical programming skills are less critical, and many companies are happy to recruit graduates from other disciplines and train them up in the relevant technical material. However, computing graduates who do have these business skills are highly sought after and currently are gaining very highly paid jobs on leaving university. About 13 years ago, I introduced an extension to the Software Hut. This is for fourth year master’s degree students. It is a commercial software company called Genesys Solutions.2 This company runs all year, and the students spend one third of their time in it. The students actually run the company. It has its own premises and equipment. The students negotiate contracts, prices, and delivery with clients and then work in a number of development teams to deliver. There is a marketing department and a systems administration department to maintain the infrastructure. Such a company has to deal with maintenance contracts as well as new developments, and it is vital that this is borne in mind by the developers, especially as the workforce at Genesys changes every year, and the original developers may have left the company when maintenance is needed. This company has been a great success—it seems to be unique in the world. Customers often return for extensions to existing software and new developments. The University of Sheffield has recently spun the company out. It is now a fully fledged and legally registered commercial company called epiGenesys. (http://www.epigenesys.co.uk). The intention of the book is to use the new ideas from the so-called agile methodologies, particularly the approach known as extreme programming, or XP, as the vehicle for teaching practical project development skills. XP is a rapidly evolving set of ideas that can be applied in many different application areas; we focus here on the use of XP practices in the development of some real software for a business client, perhaps from a local company or another part of the university. The book is based on 20 years of experience of teaching in this way and managing such projects. In all, I have managed around 100 projects involving a couple of hundred teams, of which most have tried to use XP in the past 7 years. I have learned a great deal from this and have adapted XP to fit in with the demands of such fixed-period projects. Some may argue that I am demanding too much from students, but I am convinced that well-motivated students will be able to perform very well using these ideas; they not only can deliver excellent software to their clients, but also they will learn much more than from any other typical course on software development, which will concentrate on lots of lectures and artificial exercises. As so many people comment, success in the software industry is much more dependent on personal and teamwork skills than it is on technical knowledge. If you are unable to work effectively in a team, then you will be of little use to a software development company whatever technical knowledge you have. These sorts of projects will teach you a great deal about yourself and, the realities of teamwork and of dealing with real clients. One of the key challenges you will face is getting yourself organized and planning and working in an effective way. I have tried to give practical suggestions and mechanisms for doing 2
See http://www.genesys.shef.ac.uk.
Preface
xiii
this. At the end of such a project, you will be amazed at what you will have achieved. The appendices contain examples of systems built by my students. The book will also address the connections between IT development and business pragmatics through the use at the end of each chapter of Conundrums. These are based on real scenarios that either I have faced or have been experienced by business colleagues. In many cases, these explore the dilemmas between following the established philosophy of academic software engineering and the realities of businesses driven by the need to make money. Some basic principles governing the book’s philosophy are as follows: 1. It assumes that the readers will be engaged in a real rather than an academic software project. This means the project is for an external business client, and this factor will expose the students to the very real problems of requirements capture and the need for the highest quality software if the client is to be able to use it in their business. Most team-based projects are designed around problems posed by the instructor and often lack credibility with students, most of whom respond enthusiastically to the challenge of building something useful for a client. 2. It assumes that the readers will be reading it as members of a software development team and will be able to undertake the key activities together. 3. It aims to develop self-learning (and lifelong learning skills in the readers); this is a problem-based learning approach, and it is expected that the students will have the need to supplement their reading by consulting the literature, textbooks, articles in the professional press, and so forth. This is not intended to be an exhaustive and self-contained book on software engineering and software project management. I am convinced that, given the responsibility, students will rise to the challenge and develop intellectually and personally far more from this approach than from traditional educational approaches. 4. The book is not a large tome; it emphasizes the XP philosophy on minimal but informative and reliable documentation, and much of it is taken up with real examples from commercial agile projects. 5. Unlike existing XP books, this one deals with some of the practical details and provides effective methods and models for achieving high-quality software construction in an “agile” manner. Life is never as simple as most writers seem to imagine; sticking to pure XP is rarely going to work in most projects, but adapting it to suit the context—both in terms of clients and developers—has proved extraordinary effective. 6. There is an accompanying Website, http://agile.genesys.shef.ac.uk, for instructors/coaches that provides practical advice on how to motivate students, organize real group projects, and deal with many of the problems that arise in a simple and effective way. This is based on more than 15 years of running real software projects with student teams.
xiv
Preface
7. No specific programming language is used because particular projects will require particular implementation vehicles, but some reference is made to the language Java. Some may claim that I am asking for too much documentation, too many models, too much systematic testing, and so forth. Everything that is discussed here is here for a reason and is often prompted by problems we have had with projects—delivering late, poor-quality systems, maintenance problems, and so on. Delivering high-quality software in a timely fashion is a big challenge, and these techniques have worked well. Many people have helped me with this book; first, all my students who have taught me so much over the years. In particular, Francisco Macias, Sharifah SeydAbdullah, Chris Thomson, Phil McMinn, Alex Bell, and all the students from Genesys Solutions and the Software Hut over the years. I must also thank my academic colleagues Marian Gheorghe, Andy Stratton, Helen Parker, Kirill Bogdanov, Tony Simons, and Tony Cowling for helping me with many aspects of the work but especially Marian, Helen, and Andy who have played a large part in making our real student projects such an amazing success. A number of XP industrial experts from around the world have looked at drafts of this book, including Ivan Moore, Tim Lewis, and Graham Thomas. Fellow academics and collaborating researchers from a number of universities who have also been a great help include Mike Pont, Giancarlo Succi, Michelle Marchesi, Bernard Rumpe, Leon Moonens, Andres Barravalle, and Jose Canos. Kent Beck has taken a detailed interest in the book and in what my students have been doing. He is a key influence and is always trying to keep me from being too conventional! Amanda Watkinson, Jonathan Collett, and Vernon Green, senior developers at IBM, have been mentors for Genesys students for a number of years, and they have contributed a lot of important advice and support that is reflected in many aspects of this work. I would also like to thank a number of anonymous reviewers whose comments on drafts have helped to improve the book immeasurably. Finally, I must thank my wife Jill whose tolerance and support were invaluable. MIKE HOLCOMBE Sheffield, United Kingdom May 2008
