Running an agile software development project

318 Pages·2008·4.932 MB·English

by  W M L Holcombe

Running an
Agile Software
Development Project
Mike Holcombe
UniversityofSheffield,UnitedKingdom
Copyright#2008byJohnWiley&Sons,Inc.Allrightsreserved.
PublishedbyJohnWiley&Sons,Inc.,Hoboken,NewJersey
PublishedsimultaneouslyinCanada
Nopartofthispublicationmaybereproduced,storedinaretrievalsystem,ortransmittedinanyform
orbyanymeans,electronic,mechanical,photocopying,recording,scanning,orotherwise,exceptas
permittedunderSection107or108ofthe1976UnitedStatesCopyrightAct,withouteithertheprior
writtenpermissionofthePublisher,orauthorizationthroughpaymentoftheappropriateper-copyfee
totheCopyrightClearanceCenter,Inc.,222RosewoodDrive,Danvers,MA01923,[phone],
fax[phone],oronthewebatwww.copyright.com.RequeststothePublisherforpermissionshould
beaddressedtothePermissionsDepartment,JohnWiley&Sons,Inc.,111RiverStreet,Hoboken,NJ
07030,[phone],fax[phone],oronlineathttp://www.wiley.com/go/permission.
LimitofLiability/DisclaimerofWarranty:Whilethepublisherandauthorhaveusedtheirbestefforts
inpreparingthisbook,theymakenorepresentationsorwarrantieswithrespecttotheaccuracyor
completenessofthecontentsofthisbookandspecificallydisclaimanyimpliedwarrantiesofmerchant-
abilityorfitnessforaparticularpurpose.Nowarrantymaybecreatedorextendedbysalesrepresentatives
orwrittensalesmaterials.Theadviceandstrategiescontainedhereinmaynotbesuitableforyour
situation.Youshouldconsultwithaprofessionalwhereappropriate.Neitherthepublishernorauthor
shallbeliableforanylossofprofitoranyothercommercialdamages,includingbutnotlimitedtospecial,
incidental,consequential,orotherdamages.
Forgeneralinformationonourotherproductsandservicesorfortechnicalsupport,pleasecontactour
CustomerCareDepartmentwithintheUnitedStatesat(800)762-2974,outsidetheUnitedStatesat(317)
572-3993orfax(317)572-4002.
Wileyalsopublishesitsbooksinvarietyofelectronicformats.Somecontentthatappearsinprintmay
notbeavailableinelectronicformats.FormoreinformationaboutWileyproducts,visitourwebsite
atwww.wiley.com.
LibraryofCongressCataloging-in-PublicationData:
Holcombe,W.M.L.(WilliamMichaelLloyd),1944-
Runninganagilesoftwaredevelopmentproject/byMikeHolcombe.
p. cm.
Includesbibliographicalreferencesandindex.
ISBN978-0-470-13669-0(cloth)
1. Computersoftware—development. 2. Agilesoftwaredevelopment.
3. eXtremeprogramming. I. Title.
QA76.76.D47H6472008
005.101--dc22 2008009444
PrintedintheUnitedStatesofAmerica
10 9 8 7 6 5 4 3 2 1
Contents
Preface xi
1. What Is an Agile Methodology? 1
1.1 Rapid Business Change: The Ultimate Driver 1
1.2 What Must Agile Methodologies be Able to Do? 2
1.3 Agility: What Is It and How Do We Achieve It? 2
1.4 Evolving Software: Obstacles and Possibilities 5
1.5 The Quality Agenda 6
1.6 Do We Really Need All This Mountain of Documentation? 9
1.7 The Human Factor 10
1.8 Some Agile Methodologies 11
1.8.1 DynamicSystemsDevelopmentMethod 12
1.8.2 Feature-DrivenDesign 13
1.8.3 Crystal 14
1.8.4 AgileModeling 14
1.8.5 SCRUM 15
1.8.6 SummaryTable 15
1.9 Review 16
Exercise 17
Conundrum 17
References 18
2. Extreme Programming Outlined 19
2.1 Some Guiding Principles 19
2.2 The Five Values 20
2.2.1 Communication 20
2.2.2 Feedback 22
2.2.3 Simplicity 24
2.2.4 Courage 24
2.2.5 Respect 25
2.3 The 12 Basic Practices of XP 25
2.3.1 Test-FirstProgramming 25
2.3.2 PairProgramming 26
2.3.3 On-SiteCustomer 27
2.3.4 ThePlanningGame 28
v
vi Contents
2.3.5 SystemMetaphor 29
2.3.6 Small,FrequentReleases 30
2.3.7 AlwaysUsetheSimplestSolutionThatAddsBusinessValue 30
2.3.8 ContinuousIntegration 31
2.3.9 CodingStandards 32
2.3.10 CollectiveCodeOwnership 32
2.3.11 Refactoring 33
2.3.12 Forty-HourWeek 33
2.4 Can XP Work? 34
2.5 The Evidence for XP 35
2.5.1 EvidenceforTestFirst 35
2.5.2 EvidenceforPairProgramming 36
2.5.3 EvidenceforXP 36
2.6 Preparing to XP 37
Exercise 37
Conundrum 38
References 39
3. Foundations: People and Teams Working Together 41
3.1 Software Engineering in Teams 41
3.2 Personalities and Team Success 42
3.3 Observations of Team Behavior in XP Projects 46
3.4 Setting Up a Team 50
3.5 Developing Team Skills 52
3.6 Training Together 54
3.7 Finding and Keeping a Client fora University-Based Project
ora Small Business Start-Up 54
3.8 The Organizational Framework 56
3.9 Planning 60
3.9.1 PERT(ProgramEvaluationandReviewTechnique) 61
3.9.2 GanttCharts 62
3.10 Dealing with Problems 65
3.10.1 BasicStrategies 65
3.10.2 WhenThingsGoReallyWrong 66
3.11 Risk Analysis 68
3.12 Review 69
Exercises 69
Conundrum 70
References 70
4. Starting an XP Project 73
4.1 Project Beginnings 73
4.1.1 ResearchingtheBusinessBackground 74
4.1.2 ExploringtheOutlineSystemDescription 76
Contents vii
4.2 The First Meetings with the Client 79
4.3 Business Analysis and Problem Discovery 80
4.4 The Initial Stages of Building a Requirements Document 82
4.5 Techniques for Requirements Elicitation 84
4.6 Putting Your Knowledge Together 85
4.7 Getting Technical 85
4.8 Developing the Requirements Documents 88
4.9 Specifying and Measuring the Quality Attributes of the System 91
4.9.1 IdentifyingAttributes 92
4.9.2 SpecifyingtheAcceptableLevelofanAttribute 94
4.9.3 UserCharacteristicsandUserInterfaceCharacteristics 95
4.10 The Formal Requirements Document and System Metaphor 96
4.10.1 Commentary 106
4.11 Contract Negotiation 108
4.12 Case Study: The Impact of Organizational Politics 114
4.13 Review 116
Conundrum 116
References 117
5. Identifying Stories and Preparing to Build 119
5.1 Looking at the User Stories 119
5.2 Collections of Stories 128
5.2.1 Pharmacovigilance 129
5.2.2 StampsSystem 131
5.2.3 DELTAH(DevelopingEuropeanLeadershipThrough
Action-LearninginHealthcare) 131
5.3 User Interfaces 139
5.4 Communicating Clearly with the Customerand Building
Confidence 141
5.5 Demonstrating the Non-Functional Requirements 143
5.5.1 Non-FunctionalRequirements 143
5.6 Estimating Resources 144
5.6.1 SoftwareCostEstimation 145
5.6.2 ObjectPointAnalysis 146
5.6.3 COSMICFFP 147
5.7 Review 149
Exercises 149
Conundrum 150
References 151
6. Bringing the System Togetheras a Coherent Concept 153
6.1 What isthe Problem? 153
6.2 A Simple Common Metaphor 156
6.3 Architectures and Patterns 159
viii Contents
6.4 Finite State Machines 160
6.5 Extreme Modeling (XM) 163
6.6 Multiple Stories and XXMs 166
6.7 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 181
7.1 Preparing to Build Functional Test Sets 181
7.1.1 TestsandTesting 181
7.1.2 TestingfromaModel 183
7.1.3 DevelopingtheModel 187
7.2 Testing with the Data in Mind 191
7.3 The Full Functional System Testing Strategy 192
7.4 The Thinking Behind the System Test Process 193
7.4.1 AnAlgorithmforDeterminingtheTransitionCover 198
7.5 Design for Test 201
7.5.1 DesignforTestPrinciple1:Controllability 202
7.5.2 DesignforTestPrinciple2: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 215
8.1 Basic Considerations 215
8.2 Identifying the Units 216
8.3 Unit Testing 219
8.4 More Complex Units 222
8.4.1 CaseExample:TheAddElementFunctioninJHotDraw 223
8.5 Automating Unit Tests 232
8.5.1 WritingUnitTestsinJUniti 233
8.5.2 ManagingTests 235
Contents ix
8.6 Documenting Unit Test Results 235
8.7 Review 237
Exercises 237
Conundrum 237
References 238
9. Evolving the System 239
9.1 Requirements Change 239
9.2 Changesto Basic Business Model and Functionality 240
9.3 Dealing with Change: Refining Stories 241
9.3.1 ChangestotheUnderlyingDataModel 241
9.3.2 ChangestotheStructureoftheInterface,Perhapsthe
IntroductionofaNewScreen 242
9.3.3 AddingaNewFunction 242
9.3.4 ChangingtheFunctionalityofaFunction 242
9.4 Changing the Model 242
9.4.1 ChangingaProcess 242
9.4.2 RemovingStates 244
9.4.3 AddingStates 245
9.4.4 AddingaCompleteMachine 246
9.4.5 AddingProcesses 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 251
10.1 What is Documentation forand Who Is Going to Use It? 251
10.2 Coding Standards and Documents for Programmers 252
10.3 Coding Standards for Java 253
10.3.1 GenesysCodingStandardforJava 253
10.3.2 BlankLines 255
10.4 Maintenance Documentation 262
10.5 User Manuals 263
10.6 Version Control 264
10.6.1 TheProjectArchive 265
10.6.2 NamingConventions 265
10.7 Deliveryand Finalization 266
10.8 Review 267
x Contents
Exercises 267
Conundrum 267
Reference 267
11. Reflecting 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 281
12.1 Keeping Fit 282
12.1.1 CorrectSittingPosition 283
12.1.2 CombatingRSI 284
12.2 General Well-Being 285
12.3 Mental Preparation 285
12.4 Diet 286
12.4.1 DietandBrainFunction 286
12.4.2 SummaryofDietaryInformation 287
12.5 Music and Work 288
12.6 Review 289
References 290
Appendix 291
Bibliography 305
Index 309
Preface
T
his 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
ofaprojectbasedaroundthisbook,studentsshouldbemuchmorelikerealsoftware
professionals than before, ready to embark on a career where professionalism, a
qualityorientation,andanunderstandingofthebusinesscontextarebetterdeveloped
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
teachingsoftwareengineeringthroughpracticalprojectworkinvolvingrealbusiness
clients.Inthesecondyearofourcomputerscienceandsoftwareengineeringdegree
programs,studentsareputintosmallteamsandspendonethirdoftheirtimeduringa
12-weekperiodbuildingabusinesssolutionfortheirclient—thisistheSoftwareHut
module.Typically,wehave3or4clientsandupto20teamsof4to6students.Teams
competetobuildthebestsolution,andeachclientwillthenchoosethisfromseveral
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.
Academicstendtoabstractawaythemessybitsandtreatsoftwaredevelopmentin
anidealizedandessentiallytrivialmanner.Manyofthetechniquesandnotationspro-
motedinacademejustdonotworkinreallife.Thereislittlerigorousscientificevi-
dencefortheirutilityinpractice,andtheyarederivedfromana¨ıveunderstandingof
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
1e-skills.com,theUKgovernmentboardresponsiblefortheITsector,hasidentifiedthisfactfor2006.
xi
xii Preface
programmingjobshavebeenoutsourcedtodevelopingcountries,andtheITindustry
now needs graduates with much more business understanding: Technical program-
ming 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 afterand currentlyare 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.
Suchacompanyhastodealwithmaintenancecontractsaswellasnewdevelopments,
anditisvitalthatthisisborneinmindbythedevelopers,especiallyastheworkforce
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).
Theintentionofthebookistousethenewideasfromtheso-calledagilemeth-
odologies, 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
basedon20yearsofexperienceofteachinginthiswayandmanagingsuchprojects.
Inall,I havemanagedaround100projects involvingacoupleof hundredteams, of
whichmosthavetriedtouseXPinthepast7years.Ihavelearnedagreatdealfrom
this and have adapted XP to fit in with the demands of such fixed-period projects.
Some mayargue that I am demanding too much from students, but I am convinced
thatwell-motivatedstudentswillbeabletoperformverywellusingtheseideas;they
notonlycandeliverexcellentsoftwaretotheirclients,butalsotheywilllearnmuch
more than from anyother typical course on software development, which will con-
centrate on lots of lectures and artificial exercises. As so many people comment,
successinthesoftwareindustryismuchmoredependentonpersonalandteamwork
skills than it is on technical knowledge. If you are unable to work effectively in a
team,thenyouwillbeoflittleusetoasoftwaredevelopmentcompanywhatevertech-
nical knowledgeyou have. These sorts of projects will teach you a great deal about
yourselfand,therealitiesofteamworkandofdealingwithrealclients.Oneofthekey
challengesyouwillfaceisgettingyourselforganizedandplanningandworkinginan
effective way. I have tried to give practical suggestions and mechanisms for doing
2Seehttp://www.genesys.shef.ac.uk.