Running an Agile Software Development Project

327 Pages·2008·5.6 MB·English

by  Mike Holcombe

Running an
Agile Software
Development Project

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