您的当前位置：首页 Case Study Extreme Programming in a University Environment

Case Study Extreme Programming in a University Environment

来源：筏尚旅游网

CaseStudy:ExtremeProgramminginaUniversityEnvironment

MatthiasM.M¨ullerWalterF.Tichy

ComputerScienceDepartment

Universit¨atKarlsruheAmFasanengarten576128Karlsruhe,Germanymuellermtichy@ira.uka.de

Abstract

ExtremeProgramming(XP)isanewandcontrover-sialsoftwareprocessforsmallteams.ApracticaltrainingcourseattheuniversityofKarlsruheledtothefollowingob-servationsaboutthekeypracticesofXP.First,itisunclearhowtoreapthepotentialbeneﬁtsofpairprogramming,al-thoughpairprogrammingproduceshighqualitycode.Sec-ond,designinginsmallincrementsappearsproblematicbutensuresrapidfeedbackaboutthecode.Third,whileauto-matedtestingishelpful,writingtestcasesbeforecodingisachallenge.Andlast,itisdifﬁculttoimplementXPwith-outcoaching.ThispaperalsoprovidessomeguidelinesforthosestartingoutwithXP.

programmers,workingtogetheratoneterminal),frequentintegrationofchanges,automatedregressiontesting,devel-opmentinsmallincrements,andoccasionalrestructuring(calledrefactoring).Requirementsandtheorderoffeaturedevelopmentaredeterminedincrementally(calledPlanningGameinXP).XPisdesignedforateamofsoftwareengi-neerstobecomeaproductiveunitthatembraceschangesandincorporatesthemquicklyintoanevolvingsystem.InitialexperiencereportswithXPareenthusiastic.Forinstance,ChetHendriksonofDaimlerChryslerwrites:

When[followingXP],wehavebeenthebestsoftwaredevelopmentteamonthefaceoftheearth.[1]

OthersviewExtremeProgrammingasafancynameforhacking[10].Thispapertriestomovetowardsafaireval-uationofXP.ItreportsontheexperiencesmadeinanXPcourseheldattheuniversityofKarlsruheinthesummerterm2000.Subjectsweregraduatestudents.Themainpur-poseofthecoursewastogatherexperiencewithXPinanunbiasedfashion,withouthavingtocomeupwithapre-ordainedresultonewayortheother.Ingeneral,theexpe-riencewithXPwaspositive,althoughthispaperpresentssomecaveats,somesuggestionsfortheXP-beginner,andproposalsforthorough,evaluativeresearch.ThestudyfocusedonPairProgramming:Allprogrammingtasksaredonein

pairsatonedisplay,keyboard,andmouse;IterationPlanning:Designingandimplementingonlythe

functionalityrequiredforasmallsetofnewfeatures.Testing:Testcasesspecifythefunctionalityandarererun

continuously;Refactoring:Restructuringthecodewhileretainingits

functionality.Scalability:WhatisanappropriateteamsizeforXP?

1.Introduction

ExtremeProgramming(XP)isalightweightsoftwaredevelopmentprocessforsmallteamsdealingwithvagueorrapidlychangingrequirements.XPbreakswithanumberoftraditionalsoftwareengineeringpractices.First,docu-mentationisalmostentirelynon-existent.Theonly”docu-mentation”isasetofindexcardsonwhichtheteammem-bersscribbleplannedfeaturesofthesystem.Otherthanthat,thesourcecodeistheonlydocumentation.Theratio-naleisthatwritingdocumentationslowsdowndevelopersandismostlyneglectedanyway.Second,thereisnosoft-warespeciﬁcation.Executabletestcases,writtenbeforethecodeisdeveloped,serveasasubstitute.Third,thereisnoseparatedesignortestingphase.Instead,design,imple-mentationandtestaredonetogether,insmallincrements.Fourth,thereisanexplicitprohibitionagainstdesignforchange;onlythesimplestpossibledesignsatisfyingthefea-tureofthemomentshouldbeimplemented.Fifth,therearenoformalreviewsorinspections.However,XPpre-scribesacombinationofspecialpracticesinstead.Thema-joronesarepairprogramming(allcodeiswrittenbytwo

Duringthecourse,thestudentsfacedseveralmajorprob-lemsfollowingXP.First,itwasdifﬁculttodesigninsmallincrements.Thestudentsnicknamedit”designingwithblinders”.Theirdesignswerebothlargeandgoodenoughsotheyneverneededtorefactor.Anotherproblemwascausedbyhavingtowritetestcasesbeforecoding.Thisapproachwasnewtothestudentsandtheyhadproblemsac-ceptingandfollowingit,eventhoughtheyfoundautomaticregressiontestinguseful.Studentslearntfromeachotherduringpairprogramming,butthebeneﬁtleveledoffovertime.Theyalsofoundinterestingwaystoshareworkinpairs,butitremainsunclearhowtostructurepairprogram-mingwithoutlossofproductivity.Theamountofcommu-nicationinvolvedintheplanninggameturnedouttobepro-hibitiveforlargerteams.ThispartofXPdeﬁnitelydoesnotscale.Finally,withoutcontinuoussupervision,encourage-mentandcajoling,studentswouldhavefollowedXPprac-ticesincompletely,ifatall.

2.RelatedWork

ToﬁndoutmoreaboutXP,theauthorsrecommendanoverviewwrittenbyKentBeck[1].Adetailedtreatmentisgiveninabook[2].

AboutthevariouspracticesofXP,onlypairprogram-minghasbeenevaluatedtoacertainextent.BisantandLyle[3]investigatedtheeffectofatwo-personinspectionmethodonprogrammerproductivity.Theyusedapretest-posttestdesignwithacontrolgroup,employing29under-graduatestudents.Thestudentsintheexperimentgroupperformedadesigninspection,acodeinspection,orboth.Duringtheinspections,twostudentspairedofffor20min-utesandtriedtoﬁnderrors.Thestudentsinthecontrolgroupdevelopedtheprogramsontheirown.BisantandLylereportedasigniﬁcantimprovementintheexperimentgroupasaresultofusingthetwo-personinspectionmethod.Thetimesavingwasgreaterthanthetimelostinthepairinspectionsteps.Thisresultmayhavemoretodowiththebeneﬁtsofinspectionsthanwithpairing.

Therearesomeclaimsthatapairismorethantwiceasproductiveasanindividual.Nosek[7]conductedanex-perimentaboutcontinuouspairprogramming,butfoundnosupportforthisclaim.Fivepairsandﬁveindividualpro-fessionalssolvedachallengingproblem.Theevaluationoftheposttestquestionnaireshowedthatpairsenjoyedtheproblem-solvingprocessmoreandthatthepairsweremoreconﬁdentintheirsolutions.Onaverage,asingleindividualtook41%moretimethanapair(thoughnotstatisticallysig-niﬁcantatthelevel).Putanotherway,thismeansthattwoindividuals,workingindependently,willbe30%moreproductivethanapair.Nosekarguesthatthelossofproduc-tivityismadeupbybetterquality,buthehasnostrongdatatosupportthisclaim.Williamsalsoreportshighconﬁdence

ofpairsintheproblem-solvingprocess[4,9].Sheobservedareductionofthenumberoferrorswhilepairprogrammingwithasigniﬁcanceof.Williamsmeasuredalsoareductioninworkingtimewhencomparingindividualstopairs,butshecouldnotgiveestimatesabouttheproductiv-ityeffectsofpairprogramming.SimilartoNosek,Williamsarguesthattheproductivitylossofpairsmightbegainedbackwhendebugging.Insum,therealbeneﬁtsofpairpro-grammingareunclear.

3.TheXPCourse

Thecoursewasheldinthesummertermof2000.Partici-pantswereCSgraduatestudentswhoneededtotakeaprac-ticaltrainingcourseaspartoftheirdegreerequirements.Mostofthestudentshadexperiencewithteamwork,butonlyonewithpairprogramming.Onlyonestudenthadde-velopedmovinggraphicaldisplaysofthesortneededfortheproject.Twelvestudentsbeganthecourse;onedroppedaftertheﬁrstthreeweeksbecauseoflackoftime;therestcompleted.

Intheﬁrstthreeweeks,studentssolvedsmallprogram-mingexercisestofamiliarizethemselveswiththeprogram-mingenvironmentandtolearnXPpractices.TheexercisesintroducedjUnit(thetestingframeworkusedthroughoutthecourse),pairprogramming,thetestpracticesofXP(writetestcasesbeforecoding,executethemautomaticallywithjUnit),andrefactoring.Theremainingeightweeksweredevotedtoaprojectonvisualtrafﬁcsimulation.ThecourselanguagewasJava.AllstudentshadexperiencewithJavafromtheirearlyundergraduatecourses.Table1summarizesthecoursedetails.

Table1.Summaryofcoursedetails.Numberofparticipants

graduatestudents

Courselanguage

jUnit

VersioncontrolFirstexercise

240-660min

Visualizationtool(VT)

Duration

Thirdexercise

HTMLortextoutput

DurationProject

8weeks,

toolcombinedwithascannertoreaddatafromatextﬁle.Thethirdexerciseextendedthevisualizationtoolwithout-putinHTMLoratextformat.Theremainingeightweekswerespentwithprojectwork.Theprojectwastheimple-mentationofatrafﬁcsimulationwithcars,trafﬁclights,andtrains.

Thestudentsmetweeklyforworkingtogetherinsixpairs.Theypairedvoluntarilywithdifferentpartnersforeachexerciseandtheproject.TheloosecouplingofpairswithinateamisacommonpracticeinXP.Aftertheﬁrstthreeprogrammingproblems,onestudentleftthecourseandoneoftheinstructors(Matthias)ﬁlledin,inordertohavesixfullpairs.However,Matthiastriednotgivehisteamanunfairadvantagebyprovidinghintsthatotherswouldn’tget.

Fortheproject,thestudentsweredividedupintotwoteamswiththreepairseach.Eachteamwastaskedwiththefullproject,includingthegraphicalrepresentation,thefunctionalityforthemovingcars,theright-of-wayrules,andthetrafﬁclightcontrol.Figure1showsasnapshotofthetrafﬁcsimulationwithsevencars,acrossroad,andarailway.Therailwaywasmeantasanextension,butneverimplementedduetolackoftime.

4.2.IterationPlanning

Givenasetofnewfeaturestoimplement,XP’sguide-linessaytodevelopthesimplestpossiblesolution.Therationaleisthatsoftwarechangesarecheapandnotimeshouldbewasteddevelopingunneededgenerality.

Thisrecipeprovedproblematic.Allourstudentscon-tinuouslyplannedforthefuture.Inordertogetstudentstofocusonjustthenextsetoffeatures,theinstructorshadtopubliclyabandononespeculativefeatureafteranother.Forexample,atthebeginningoftheproject,astreetedi-torwasmentionedthatwouldsimplifytheconstructionofthetrafﬁcscenarios.Thestudentsalsoheardabouttrainsandlevelcrossings.Theinstructorsmadeitclearthatthesewerespeculativeextensionsthatwouldprobablynotbeim-plemented.Butoncetheseideaswereout,ourstudentswouldcontinuouslythinkaheadtoaccommodatetrains,levelcrossings,andthestreeteditor.Attheendoftheproject,itbecameclearthattheyhadalwaysplannedforthesefeatures.Yetthefeatureswereneveradded,becausetimeranout.Wewonderwhatwouldhavehappenedifwehadmentionedovertakingcars.

Theauthorsdonotknowwhythinkingaboutminimalsolutionsishard.Perhapsthisisbecauseourstudentshavebeentrainedtodesignforthefuture.Theyaretoldinthesoftwareengineeringcorecoursethatthereisonethingforcertainabouteveryusefulsoftware,andthatischange.Theyshouldplanforlikelychangeswithinformationhid-ing,extensibledesigns,etc.ItisquitetellingthatstudentscalledtheXP-approach“designwithblinders”.Thinkingaheadmayalsobeasignofaningrained(andcommend-able)thoroughness,adesiretoajobwellandtobedissatis-ﬁedwithshoddywork.

Insummary,theauthorsexpectthatafairnumberofgoodsoftwaredesignerswillhavedifﬁcultywithignor-ingknowledgeaboutfutureextensions.Atthispoint,itisunclearwhetherminimalisticdesignismerelyamatteroftraining,oractuallyabadidea.Itisclearwhatmustbedone,though,ifonewantstopracticetheXPapproachwithsomewhatexperiencedpersonnel:withholdinforma-tionaboutfutureextensions.ThisisprobablytheapproachforthenextiterationoftheXPcourse.Atalaterstage,itmaybepossibletodiscloselotsoffeaturesandstillaskdeveloperstofocusononlyoneatatime.

4.3.Testing

TherearetwoaspectsoftestinginXP:ﬁrst,towritethetestcasesbeforecoding,andsecond,tomakethemexecuteautomaticallyforregressiontesting.

Writingtestcasesbeforecodingisasubstituteforspeci-ﬁcation.Whatexactlydothemethodsdo,whatparametersdotheytake,andwhatarethe(testable)results?Thisap-

proachwasnewtomoststudents.Only25%appliedittotheirdevelopmentpriortothecourse,seetable4.Moststu-dentsadopteditnaturallyrightfromstart,someneededourinterventionintheearlystageoftheproject,butonepairadopteditnotuntiltheyneededthetestcasesforrestruc-turingthecode.ThispairdevelopedtheJavaclassforthecrossroadswithouthavingwrittentheaccompanyingtestclass.Whenaskedwhethertheyforgotthetestcasestheyanswered:

No,wedidn’t.Whyshouldweimplementtestcasesifwedon’tknowexactlywhatwehavetodo?Wearestillﬁguringoutthedesiredfunction-ality.

Theinstructorurgedthemtowritethetests.Atthenextmeeting,theyhadthetestcaseswritten,buttheyhadalsochangedboththeunderlyingrepresentationandtheinter-face.Theycleanedupthecodewhileestablishingthenec-essarytestcasesatthesametime.Theresultwasthattherewasnorunningprogramfortwoweeks.Hadtheyhadthetestcases,theycouldhaveﬁrstconcentratedonrestructur-ingandthenevolvingtheinterface,whilealwayshavingarunningsystemfortherestoftheteam.

Thepairsbuildingthegraphicaldisplaywereunabletoprovidefullyautomatedtestcases.Theywrotethetestcases(trafﬁcscenarios)andwatchedthedisplayforerrors.Toautomatethesetestswouldhaverequiredstoringbitmapsandcomparingthem,whichseemedtoomucheffortunderthecircumstances.

Attheendofthecourse,thestudentswereconvincedofthebeneﬁtsofwritingtestcasespriortocoding.Itisthetestingapproachthatthestudentsconsideredthebestpracticeintheﬁnalreviewofthecourse.87%statedthattheexecutionofthetestcasesstrengthenedtheirconﬁdenceinthecodeandallofthemwereplanningtotryoutthispracticeafterthecourse,seetable4.AllstudentssawjUnitasasuitabletestframework.

Writingtestsforcessoftwareengineerstodistinguishbe-tweenthefunctionalitytoimplementandthebasecondi-tionsunderwhichtheimplementationhastowork.ThesebaseconditionsarespeciﬁedandwrittendownwithXPinformoftestcases.Theconditionsareveriﬁedeverytimethetestcasesareexecuted.

Re-executingtestcaseswasuniformallyseenaspositive.Seeingthebeneﬁtsofautomaticregressiontestsincreasedparticipants’motivationtowriteexecutabletestcasesearly.Participantsalsoreportedanincreaseinconﬁdenceintheirsoftware,butoneparticipantalsonotedthatregressiontest-ingcanproduceafalsesenseofconﬁdence.

Insummary,therearesituationswheretestcasesaredif-ﬁculttoautomate(graphics)orarewastedeffort(duringprototyping).Butwritingtestcasesearly,especiallywhentherearenospeciﬁcations,andregressiontestingwereseenasbeneﬁcial.

4.4.Refactoring

Thestudentsnevergottoapointwheretheyneededtorefactor.Oneteamhadacompletedesignthatdidnotneedtobeimproved,theotherteamhadasituation(thecross-roadsexampleintheprecedingsection)whereoneteamsortofrefactoredaprototype,butwithoutthebeneﬁtoftestcases.Lackofrefactoringmaybecausedbyacombinationofseveralfactors:thesmallsizeofprojectanddoingfullratherthanminimaldesigns.

4.5.Scaling

Withiniterationplanning,teammembersbreakdowntherequirementsfromthePlanningGameintosmallpieces.Later,thesepiecesareprocessedinpairs.Thedivisionoftherequirementsrequiresthattheteammembersagreeonacommonterminology.Otherwise,teammemberslosealotoftime.ThecommunicationproblemisonelimitationtotheteamsizeofXPbecauselargerteamsfacemuchmorecommunicationoverheadthansmallerones.Thislimitationisabitrelaxedifteammembershaveworkedtogetherbe-fore.

Duringdevelopment(afteriterationplanning),commu-nicationneedsarealsohigh.Studentsinitiallythoughtpairscouldworkindependentlybutquicklymovedtoteamses-sions.XPrequiresanongoinginformationexchange.Thisintercommunicationaspectismorecrucialintheﬁrststagesofanewproject,becausethesoftwareissmallandthepairsarelikelytoworkonthesamecomponents.Thesmallandemergingsoftwarealsoforcestheteammemberstoex-changevagueandchanginginformation[5].Thisdepen-denceoninformalcommunicationdiminisheswithprojectagebutneverdisappears.Themainstrategyatthebegin-ningofanXPprojectistodevelopasfastaspossibleasmallpieceofrunningsoftwarewhichcontainsmanysmallclasses,asmentionedin[2].Withthissoftwarelayout,thewholeteamcanstarttoworkontheprojectasearlyaspos-sible.

Insummary,teamsizeisacrucialfactorforXP.Smallteamsofnotmorethaneightengineershavelesscommuni-cationoverheadandarethereforemoreefﬁcientthanlargerones.Lorgeetal[6]pointoutthatsmallgroupsaremoreef-ﬁcientworkingonabstractproblemsthanlargerones.TheauthorsexpecttheoptimalgroupsizeofXPtobeintherangeofsixtoeightindividuals,whichisnotmuchlargerthantheactualteamsizesinthecourse.

Therearetwoconclusionstodrawforthenextcourse.First,instructorshavetoinsistaboutteammeetings,be-causetheinformalinformationexchangecannotbere-placedbye-mailorothermeansofcommunication.Andsecond,asastudentprojectinauniversitycoursealwayssuffersfromatremendouslackoftime,itispreferableto

provideasoftwareskeletonatthebeginningfromwhichtheycanstartdevelopment.

5.ConclusionsandOpenQuestions

ThispaperpresentedexperiencesaboutXPwithCom-puterSciencegraduatestudents.Thecourseincludedthreesimpletasksandaproject.Alldevelopmentworkwasdoneinpairs.Projectteamsconsistedofsixstudents(threepairs).Aftersomeinitialdifﬁculties,bothteamsadoptedtheXPmethods.

Theauthorsmadethefollowingobservations.1.Pairprogrammingisadoptedeasilyandanenjoyablewaytocode.However,itisunclearwhattypeofworknottodoinpairsandhowbesttostructurepairin-teraction.Additionalresearchisneededtocomparetheeffectivenessofpairprogrammingwithreviewingtechniques.2.Designinsmallincrements(“designwithblinders”)isdifﬁcult.Holisticdesignbehaviormaybedifﬁculttoabandonandmoreresearchisneededtotestwhetherthisisactuallyagoodidea.Ifonewantsdeveloperstodesigninsmallincrements,atleastonepairmembershouldbetrainedinit.3.Writingtestcasesbeforecodingisnoteasilyadoptedandissometimesimpractical.Isitreallyessentialtowritethetestcasesﬁrstandthenthecode,orisitpos-sibletodoittheotherwayaround?4.Duetothecommunicationoverhead,XPasisdoesnotscalewell.Itisdeﬁnitelymeantforsmallteams(6-8members).5.XPrequirescoachinguntilitisfullyadopted.Aretheseconclusionsgeneralizabletoprofessionalsoft-waredevelopers?ThesubjectsarecertainlycomparabletoyoungprofessionalswithanundergraduatedegreeinCom-puterScience.Whethermoreexperienceddevelopersareaswillingasstudentstoadoptanewprocessisquestionable.Observations4and5willlikelyholdingeneral.Theeffectsofpairprogramming,smallincrements,andXP’stestingpracticesaresubjecttofutureresearch.

6.Acknowledgments

WethankthestudentsoftheXPcourse:DanielHahn,DanielLindner,GerdFlaig,HannaHakala,JensLukowski,MarcusDenker,OlafKleine,PaulSchmidt,ThomasHoll,TobiasK¨ufner,andUlfKrum.

References

[1]K.Beck.Embracingchangewithextremeprogramming.

IEEEComputer,pages70–77,Oct.1999.

[2]K.Beck.ExtremeProgrammingExplained.AddisonWes-ley,1999.

[3]D.BisantandJ.Lyle.Atwo-personinspectionmethodto

improveprogrammingproductivity.IEEETransactionsonSoftwareEngineering,15(10):1294–1304,Oct.19.

[4]A.CockburnandL.Williams.Thecostsandbeneﬁtsof

pairprogramming.IneXtremeProgrammingandFlexibleProcessesinSoftwareEngineering,XP2000,Cagliari,Italy,June2000.

[5]R.KrautandL.Streeter.Coordinationinsoftwaredevel-opment.CommunicationsoftheACM,38(3):69–81,Mar.1995.

[6]I.Lorge,D.Fox,J.Davitz,andM.Brenner.Asurveyof

studiescontrastingthequalityofgroupperformanceandin-dividualpermformance.PsychologicalBulletin,55(6):337–372,Nov.1958.

[7]J.Nosek.Thecaseforcollaborativeprogramming.Commu-nicationsoftheACM,41(3):105–108,Mar.1998.

[8]L.WilliamsandR.Kessler.AllIreallyneedtoknowabout

pairprogrammingIlearnedinkindergarten.Communica-tionsoftheACM,43(5):108–114,May2000.

[9]L.Williams,R.Kessler,W.Cunningham,andR.Jeffries.

Strengtheningthecaseforpair-programming.IEEESoft-ware,pages19–25,July/Aug.2000.

[10]N.Wirth,Septmber1999.personalcommunication.

Table2.Descriptionofthestudentsandtheirexperiencespriortothecourse.Topic

ExperienceinteamworkExperienceinpairprogrammingWorkingalonewhilepairprogramming

Durationphasesduringofindividualpairprogrammingwork

Howwas(severalanswersqualityallowed)assured

RefactoringdonepriortothecourseWhenwas(severalanswersrefactoredallowed)

Answers

little:average:well:partner:both:bad:average:good:no:yes:no:yes:

4%74%22%13%87%17%35%48%4%96%9%91%

Table4.Evaluationofthequestionnaireafterthecourse.

Topic

Enjoymentofpairprogramming

Acceptajobinindustrywithpairprogramming

Pairprogramming(severalanswersallowed)wastestime

Taskassignment(severalanswerswhileallowed)pairprogrammingTwodisplaysbetterthanone?Advantages(severalanswersofpairallowed)programming

Requirements(severalanswersforallowed)pairpartners

Speciﬁcationwithtestcasespriortothecourse

Didtheimplementationonlymeetthespeciﬁcationsofthetestcases......orveriﬁedthetestcasesonlythemostnecessaryparts

Strengthenedtestcasesconﬁdenceinprogram

TryingoutXP’stestingpracticeafterthecoursejUnitwellsuited

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文