开发分享代码

高级软件工程第七节课:敏捷开发主讲:刘驰2ContentAgileDevelopment介绍XPScrum3AgileProcess‐敏捷的开发流程AgileProcess(敏捷开发流程)是一种软件开发流程的泛称共通的特性:客户与开发人员形成密切合作的团队,因为客户无法于初期定义完整的规格和功能,而开发人员于开发过程中也常常无法知悉外在环境或业务的变动,所以需要两者密切合作方能开发适用的软件.
项目最终的目标是可执行的程序,因此所有的中间产品必须经过审慎评估,确认有助于最终目标,才需要制作中间产品.
采用Iterative与Incremental方式分阶段进行,密集review是否符合需求.
流程可以简单,但规划与执行必须严谨.
强调团队合作,赋予高度的责任,团队有自主权得以因应变化做调整4敏捷开发的概念敏捷开发是一种以人为核心、迭代、循序渐进的开发方法在敏捷开发中,项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征.
5敏捷开发的核心价值(CoreValue)ProcessandtoolsProcessandtoolsIndividualsandinteractionsIndividualsandinteractionsoverFollowingaplanFollowingaplanRespondingtochangeRespondingtochangeoverComprehensivedocumentationComprehensivedocumentationWorkingsoftwareWorkingsoftwareoverContractnegotiationContractnegotiationCustomercollaborationCustomercollaborationover6敏捷开发原则(Principles)1.
最高目标是通过快速的和经常的发布软件满足客户的需要2.
提交软件的周期为几个星期到几个月3.
产生正确的软件是衡量进度的首要标准4.
主动接受需求的改变而不是拒绝5.
商务人员和开发人员工作在一起6.
个人必须有动力,要创造环境支持他们的要求,信任他们7.
最有效的交流方法是面对面的交流8.
最好的结构,需求和设计来自于自组织的团队(self‐organizingteam),允许任何人提出想法和建议9.
持续改进设计和编码10.
鼓励正常工作,减少长时间加班11.
保持简单,减少不必要的部分,认识到简单的设计比复杂的设计更难(simpledesignishardertoproduce)12.
定期调整过程,获得更高效率7设计原则沿袭设计模式的SOLID原则SRP单一职责原则SRP:SingleResponsibilityPrincipleOCP开放封闭原则OCP:Open-ClosedPrincipleLSPLiskov替换原则LSP:LiskovSubstitutionPrincipleDIP依赖倒置原则DIP:DependencyInvertionPrincipleISP接口隔离原则ISP:InterfaceSeparatePrinciple8敏捷开发-迭代计划最新版本验收测试发布计划迭代计划开发项目周期91.
XP2.
ScrumContentOutlineTraditionallifecyclevs.
XPXPmotto:"embracechange"HowdoesthisattitudecomparewiththatimplicitwithtraditionalwaterfallsoftwarelifecycleXPvaluesXPpracticesPairprogrammingAnXPdevelopmentroadmap10ExtremeProgramming(XP)DevelopedbyKentBeck"alight‐weightmethodologyforsmalltomedium‐sizedteamsdevelopingsoftwareinthefaceofvagueorrapidlychangingrequirements.
"Alternativeto"heavy‐weight"softwaredevelopmentmodels(whichtendtoavoidchangeandcustomers)"ExtremeProgrammingturnstheconventionalsoftwareprocesssideways.
Ratherthanplanning,analyzing,anddesigningforthefar‐flungfuture,XPprogrammersdoalloftheseactivitiesalittleatatimethroughoutdevelopment.
"‐‐IEEEComputer,October1999soextremeheneversmiles!
11SuccessesinIndustryChryslerComprehensiveCompensationsystemAfterfindingsignificant,initialdevelopmentproblems,BeckandJeffriesrestartedthisdevelopmentusingXPprinciplesThepayrollsystempayssome10,000monthly‐paidemployeesandhas2,000classesand30,000methods,wentintoproductionalmostonschedule,andisstilloperationaltoday(Anderson1998)FordMotorCompanyVCAPSsystemSpentfourunsuccessfulyearstryingtobuildtheVehicleCostandProfitSystemusingtraditionalwaterfallmethodologyXPdeveloperssuccessfullyimplementedthatsysteminlessthanayearusingExtremeProgramming(Beck2000).
12EmbracechangeIntraditionalsoftwarelifecyclemodels,thecostofchangingaprogramrisesexponentiallyovertimeWhywoulditcostmoretomakelargechangesduringtestingthanduringrequirementsspecificationAkeyassumptionofXPisthatthecostofchangingaprogramcanbeholdmostlyconstantovertimeHenceXPisalightweight(agile)process:Insteadoflotsofdocumentationnailingdownwhatcustomerwantsupfront,XPemphasizesplentyoffeedbackEmbracechange:iterateoften,designandredesign,codeandtestfrequently,keepthecustomerinvolvedDeliversoftwaretothecustomerinshort(2week)iterationsEliminatedefectsearly,thusreducingcosts13FourCoreValuesofXPCommunicationSimplicityFeedbackCourage14CommunicationWhatdoeslackofcommunicationdotoprojectsXPemphasizesvalueofcommunicationinmanyofitspractices:On‐sitecustomer,userstories,pairprogramming,collectiveownership(popularwithopensourcedevelopers),dailystandupmeetings,etc.
XPemploysacoachwhosejobisnoticingwhenpeoplearen'tcommunicatingandreintroducethem15Simplicity''Dothesimplestthingthatcouldpossiblywork''(DTSTTCPW)principleElsewhereknownasKISSAcoachmaysayDTSTTCPWwhenheseesanXPdeveloperdoingsomethingneedlesslycomplicatedYAGNIprinciple(''Youain'tgonnaneedit'')Howdosimplicityandcommunicationsupporteachother16FeedbackFeedbackatdifferenttimescalesUnitteststellprogrammersstatusofthesystemWhencustomerswritenewuserstories,programmersestimatetimerequiredtodeliverchangesProgrammersproducenewreleasesevery2‐3weeksforcustomerstoreview17CourageThecouragetocommunicateandacceptfeedbackThecouragetothrowcodeaway(prototypes)Thecouragetorefactorthearchitectureofasystem1812XPPracticesThePlanningGameSmallReleasesMetaphorSimpleDesignTest‐drivendevelopmentRefactoringPairProgrammingCollectiveOwnershipContinuousIntegration40‐HoursaWeekOn‐SiteCustomerCodingStandards19PlanningGameCustomercomesupwithalistofdesiredfeaturesforthesystemEachfeatureiswrittenoutasauserstoryTypicallywrittenin2‐3sentenceson4x6storycardsDevelopersestimatehowmuchefforteachstorywilltake,andhowmuchefforttheteamcanproduceinagiventimeinterval(iteration)Projectvelocity=howmanydayscanbecommittedtoaprojectperweekGivendevelopers'estimatesandprojectvelocity,thecustomerprioritizeswhichuserstoriestoimplement20PlanningGameWriteaStory(Customer)SpikeaStory(Developer)Estimateastory(Developer)SplitaStory(Customer)Sortstoriesbyvalue(Customer)Declarevelocity(Developer)ExplorationPlanning"toobig""don'tknowhow"21SmallandsimpleSmallreleasesStartwiththesmallestusefulfeaturesetReleaseearlyandoften,addingafewfeatureseachtimeReleasescanbedatedrivenoruserstorydrivenSimpledesignAlwaysusethesimplestpossibledesignthatgetsthejobdoneTherequirementswillchangetomorrow,soonlydowhat'sneededtomeettoday'srequirements(remember,YAGNI)22Test‐DrivenDevelopment(TDD)Testfirst:beforeaddingafeature,writeatestforit!
Ifcodehasnoautomatedtestcase,itisassumeditdoesnotworkWhenthecompletetestsuitepasses100%,thefeatureisacceptedTestscomeintwobasicflavors…UnitTestsautomatetestingoffunctionalityasdeveloperswriteitEachUTtypicallytestsonlyasingleclass,orasmallclusterofclassesUTstypicallyuseaframework,suchasJUnit(xUnit)ExperimentsshowthatTDDreducesdebuggingtimeIncreasesconfidencethatnewfeatureswork,andworkwitheverythingIfabugisdiscoveredduringdevelopment,addatestcasetomakesureitdoesn'tcomeback!
AcceptanceTests(orFunctionalTests)arespecifiedbythecustomertotestthattheoverallsystemisfunctioningasspecifiedWhenallacceptancetestspass,thatuserstoryisconsideredcompleteCouldbeascriptofuserinterfaceactionsandexpectedresultsIdeallyacceptancetestsshouldbeautomated,eitherusingaunittestingframework,oraseparateacceptancetestingframework23SustainablePaceCodingisamarathon,notasprint.
Teamworks40hoursaweek‐MAXIMUM!
Tiredpeoplearen'tproductive24PairprogrammingTwoprogrammersworktogetheratonemachineDriverenterscode,whilenavigatorcritiquesitPeriodicallyswitchrolesResearchresults:PairprogrammingincreasesproductivityHigherqualitycode(15%fewerdefects)inabouthalfthetime(58%)Williams,L.
,Kessler,R.
,Cunningham,W.
,&Jeffries,R.
Strengtheningthecaseforpairprogramming.
IEEESoftware,17(3),July/August2000Requiresproximityinlaborworkenvironment25MoreXPpracticesRefactoringRefactoroutanyduplicatecodegeneratedinacodingsessionYoucandothiswithconfidencethatyoudidn'tbreakanythingbecauseyouhavethetestsCollectivecodeownershipNosingleperson"owns"amoduleAnydevelopercanworkonanypartofthecodebaseatanytimeContinuousintegrationAllchangesareintegratedintothecodebaseatleastdailyTestshavetorun100%bothbeforeandafterintegration26MoreXPPracticesOn‐sitecustomerDevelopmentteamhascontinuousaccesstoareallivecustomer,thatis,someonewhowillactuallybeusingthesystem,oraproxyCodingstandardsEveryonecodestothesamestandardsIdeally,youshouldn'tbeabletotellbylookingatitwhoontheteamhastouchedaspecificpieceofcode27DailyStandupMeetingGoal:IdentifyitemstobeaccomplishedforthedayandraiseissuesEveryoneattends,includingthecustomerNotadiscussionforumTakediscussionsofflineEveryonegetstospeak15minutes28KindergartenlessonsWilliams,L.
andKessler,R.
,"AllIReallyNeedtoKnowaboutPairProgrammingILearnedInKindergarten,"CommunicationsoftheACM(May2000)Shareeverything.
(Collectivecodeownership)Playfair.
(Pairprogramming—navigatormustnotbepassive)Don'thitpeople.
(Giveandreceivefeedback.
Stayontrack.
)Cleanupyourownmess.
(Unittesting.
)Washyourhandsbeforeyoueat.
(Washyourhandsofskepticism:buy‐iniscrucialtopairprogramming.
)Flush.
(Test‐drivendevelopment,refactoring.
)Takeanapeveryafternoon.
(40‐hourweek.
)Beawareofwonder.
(Ego‐lessprogramming,metaphor.
)29XPpractices—ARoadMap(fromwww.
extremeprogramming.
org)30XPemphasizesiteration31XPemphasizescommunication32TDD33341.
XP2.
ScrumContentScrumisanagileprocessthatallowsustofocusondeliveringthehighestbusinessvalueintheshortesttime.
Itallowsustorapidlyandrepeatedlyinspectactualworkingsoftware(everytwoweekstoonemonth).
Thebusinesssetsthepriorities.
Teamsself-organizetodeterminethebestwaytodeliverthehighestpriorityfeatures.
Everytwoweekstoamonthanyonecanseerealworkingsoftwareanddecidetoreleaseitasisorcontinuetoenhanceitforanothersprint.
Scrumin100words36ScrumScrumScrumOriginsJeffSutherlandInitialscrumsatEaselCorpin1993IDXand500+peopledoingScrumKenSchwaberADMScrumpresentedatOOPSLA96withSutherlandAuthorofthreebooksonScrumMikeBeedleScrumpatternsinPLOPD4KenSchwaberandMikeCohnCo‐foundedScrumAlliancein2002,initiallywithintheAgileAllianceScrumhasbeenusedby:MicrosoftYahooGoogleElectronicArtsHighMoonStudiosLockheedMartinPhilipsSiemensNokiaCapitalOneBBCIntuitIntuitNielsenMediaFirstAmericanRealEstateBMCSoftwareIpswitchJohnDeereLexisNexisSabreSalesforce.
comTimeWarnerTurnerBroadcastingOceScrumhasbeenusedfor:CommercialsoftwareIn‐housedevelopmentContractdevelopmentFixed‐priceprojectsFinancialapplicationsISO9001‐certifiedapplicationsEmbeddedsystems24x7systemswith99.
999%uptimerequirementstheJointStrikeFighterVideogamedevelopmentFDA‐approved,life‐criticalsystemsSatellite‐controlsoftwareWebsitesHandheldsoftwareMobilephonesNetworkswitchingapplicationsISVapplicationsSomeofthelargestapplicationsinuse40Scrum特点自我管理的团队"sprint"为周期迭代的产品开发一系列"产品Backlog"记录了产品需求没有特定的工程实践惯例在以生成规则创造的敏捷开发环境交付产品是其中一种"敏捷方法"41SCRUM开发流程基本假设是『开发软件就像开发新产品,无法一开始就能定义FinalProduct的规程,过程中需要研发、创意、尝试错误,所以没有一种固定的流程可以保证项目成功』Scrum将软件开发团队比拟成橄榄球队有明确的最高目标熟悉开发流程中所需具备的最佳典范与技术具有高度自主权紧密地沟通合作以高度弹性解决各种挑战碓保每天、每个阶段都朝向目标有明确的推进因此SCRUM非常适用于产品开发项目.
42SCRUM开发流程通常以30天为一个迭代周期(Sprint)由客户提供新产品的SRS开始,开发团队与客户于每一个阶段开始时挑选该完成的规格部份,开发团队必须尽力于30天后交付成果团队每天用15分钟开会检查每个成员的进度与计划,了解困难并设法排除,决定第二天的任务安排.
SCRUM特别强调开发队伍和管理层的交流协作.
每天,开发队伍都会向管理层汇报进度,如有问题会向管理层求助.
43Scrum示意图迭代每30天DailySCRUM每24小时高优先级可运行的软件工作项分解产品订单ProductBacklog产品订单ProductBacklog迭代订单SprintBacklog迭代订单SprintBacklog新的功能增量新的功能增量迭代规划会议SprintPlan一般不超过8小时.
前4个小时:产品负责人向团队展示最高优先级的产品,团队则向他询问产品Backlog的内容、目的、含义及意图.
后4小时:团队计划本Sprint的安排迭代规划会议SprintPlan一般不超过8小时.
前4个小时:产品负责人向团队展示最高优先级的产品,团队则向他询问产品Backlog的内容、目的、含义及意图.
后4小时:团队计划本Sprint的安排迭代复审会议SprintReview一般4个小时,由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况迭代复审会议SprintReview一般4个小时,由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况迭代回顾会议SprintRetrospective一般3个小时,ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内,对开发过程做出修改,使它在下一个Sprint周期中更加有效和令人愉快迭代回顾会议SprintRetrospective一般3个小时,ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内,对开发过程做出修改,使它在下一个Sprint周期中更加有效和令人愉快每日站立会议DailyScrumMeeting在简会上,每个成员主要回答三个问题;–自上次SCRUM简会后的一天了(昨天),你做了什么–从现在到下次SCRUM简会的一天里(今天),你要做什么–在实现SCRUM及项目目标的工作中,你遇到哪些困难吗每日站立会议DailyScrumMeeting在简会上,每个成员主要回答三个问题;–自上次SCRUM简会后的一天了(昨天),你做了什么–从现在到下次SCRUM简会的一天里(今天),你要做什么–在实现SCRUM及项目目标的工作中,你遇到哪些困难吗产品负责人Scrum主管开发团队44Sprint交付产品的固定的时间箱,建议2‐3周一次迭代包括design,coding,testing,anddocumentation一旦迭代开始,仅ScrumTeam能增加或者删除Sprintbacklog中的items当迭代的目标变的没有意义的时候,才能终止迭代开发对于ProductBacklog,不允许迭代内的需求变更:需求优先级调整仅存在于迭代之间45顺序vs.
迭代开发过程Scrum并非以一段时间集中完成一个过程.
.
.
而是将所有过程中必须的每一部分集中在这段时间内完成需求设计代码测试46Scrum框架ProductownerScrumMasterTeamRolesSprintplanningSprintreviewSprintretrospectiveDailyscrummeetingCeremoniesProductbacklogSprintbacklogBurndownchartsArtifactsScrumFrameworkSprintplanningSprintreviewSprintretrospectiveDailyscrummeetingCeremoniesProductbacklogSprintbacklogBurndownchartsArtifactsProductownerScrumMasterTeamRoles48ProductOwner(PO)Backlog优先级制定、开发版本规划必须确保驱动开发的SRS只有一份受管理层,客户等影响但仅PO有权调整Backlog与相关成员协同工作来确定ProductBacklog的items消除关于Backlog的疑惑,确保理解一致,消除干扰49ScrumMaster项目管理的代表确保SCRUM的成功实施SCRUM保护团队以免受干扰50ScrumTeam5‐10人自组织的团队跨功能团队没有角色区分(QA,Programmers,UIDesigners,etc.
)全职、对工作交付负责只有sprint之间能换团队只要交付工作需求,授权做任何事情.
51Scrum角色及职责火腿鸡蛋!
三思过后我决定不和你开餐馆了.
因为我全身心投入,而你只牵涉入内!
52Chickens&PigsPigs:ScrumTeam成员:他们承诺对迭代目标交付负责Chickens:项目组有关的成员,但并不专注于项目以观察者的形式参加ScrummeetingProductownerScrumMasterTeamRolesScrumFrameworkProductbacklogSprintbacklogBurndownchartsArtifactsSprintplanningSprintreviewSprintretrospectiveDailyscrummeetingCeremoniesSprintplanningmeetingSprintprioritizationAnalyzeandevaluateproductbacklogSelectsprintgoalSprintplanningDecidehowtoachievesprintgoal(design)Createsprintbacklog(tasks)fromproductbacklogitems(userstories/features)EstimatesprintbackloginhoursSprintgoalSprintgoalSprintbacklogSprintbacklogBusinessconditionsBusinessconditionsTeamcapacityTeamcapacityProductbacklogProductbacklogTechnologyTechnologyCurrentproductCurrentproduct55如何定义Sprint团队自己从产品的backlog中选择一些他们能够完成的任务作为此次迭代的backlog任务被确认并且每一任务估计工作量应该在1‐16小时左右迭代的backlog的确定是团队协作的结果,而不只由scrummaster决定概要设计已经讨论过编写后台和中间层(8小时)编写界面(4小时)编写测试用例(4小时)写类foo(6小时)更新性能测试用例(4小时)NochangesduringasprintPlansprintdurationsaroundhowlongyoucancommittokeepingchangeoutofthesprintChange2013/11/1457DailyScrumz每天15分钟z团队面对面站立成圈z为项目信息同步可视化z避免无关的讨论58团队成员需要回答3个问题昨天你做了什么昨天你做了什么11今天你将要做什么今天你将要做什么22你有需要帮助的地方吗你有需要帮助的地方吗33对于ScrumMaster来说这些问答不是工作进度报告他们是团队成员彼此的承诺59迭代结果的验收团队需要演示所完成的迭代工作使用演示形式展示新功能或者底层架构的实现非正式2小时的提前准备不需要正式演示文档整个团队都需要参加邀请所有关注产品的人参加60有关迭代的回顾周期性的回顾,总结工作中的经验和教训一般15–30分钟在每个迭代结束时开始做整个团队都需要参加ScrumMaster产品所有者团队可能还包括客户Start/Stop/ContinueWholeteamgathersanddiscusseswhatthey'dliketo:StartdoingStartdoingStopdoingStopdoingContinuedoingContinuedoingThisisjustoneofmanywaystodoasprintretrospective.
ProductownerScrumMasterTeamRolesScrumFrameworkSprintplanningSprintreviewSprintretrospectiveDailyscrummeetingCeremoniesProductbacklogSprintbacklogBurndownchartsArtifacts63产品Backlog需求项目中待完成的工作列表理想的是每一个待完成的工作都将对客户和用户产生价值产品所有者将对这个列表进行优先级排序每个迭代开始前优先级的排序工作还需要再度修正一组产品backlog一组产品backlog64实例:产品BacklogBacklog列表估计工作量顾客可以酒店预定3顾客可以取消预定.
5顾客可以提前更改预定的日期.
3酒店工作人员可以出具RevPAR(revenue‐per‐available‐room)报告8提高对突发事情的处理能力8.
.
.
30.
.
.
5065管理迭代的Backlog团队个人将要签收自己的工作工作不是单向的分配每天更新个人剩余工作量估计团队中任何人都可以添加、删减或者更改迭代中的工作项目为了迭代目标以及将发布的结果而工作如果对将要面对的困难不清楚,最好先定义一个相对工作量较大的工作项目然后适时在以后将其分散成较小额工作量的几个部分66实例:迭代Backlog任务MonTuesWedThurFri编写用户界面848编写中间层1612104测试中间层81616118编写在线帮助12编写Foo类88888增加对错误的日志记录8467BurnDown迭代燃尽图表BurndownChartsAreusedtorepresent"workdone".
ArewonderfulInformationRadiators3Types:SprintBurndownChart(progressoftheSprint)ReleaseBurndownChart(progressofrelease)ProductBurndownchart(progressoftheProduct)X‐Axis:time(usuallyindays)Y‐Axis:remainingeffortSprintBurndownChartDepictsthetotalSprintBackloghoursremainingperdayShowstheestimatedamountoftimetoreleaseIdeallyshouldburndowntozerototheendoftheSprintActuallyisnotastraightlineCanbumpUPTime(workingdays)Remainingwork(hrs)ReleaseBurndownChartWillthereleasebedoneonrighttimeX‐axis:sprintsY‐axis:amountofremaininghrsTheestimatedworkremainingcanalsoburnupAlternativeReleaseBurndownChartConsistsofbars(oneforeachsprint)ValuesontheY‐axis:positiveANDnegativeIsmoreinformativethenasimplechartProductBurndownChartIsa"bigpicture"viewofproject'sprogress(allthereleases)ScalingScrumAtypicalScrumteamis6‐10peopleJeffSutherland‐uptoover800people"ScrumofScrums"orwhatcalled"Meta‐Scrum"FrequencyofmeetingsisbasedonthedegreeofcouplingbetweenpacketsScalingScrumPro/ConAdvantagesCompletelydevelopedandtestedfeaturesinshortiterationsSimplicityoftheprocessClearlydefinedrulesIncreasingproductivitySelf‐organizingeachteammembercarriesalotofresponsibilityImprovedcommunicationCombinationwithExtremeProgrammingDrawbacks"Undisciplinedhacking"(nowrittendocumentation)ViolationofresponsibilityCurrentmainlycarriedbytheinventorsReviewBackupeXtremeProgramming2013/11/1480XP‐eXtremeProgramming极限编程,最轻量级的开发流程,其最主要的精神是『在客户有系统需求时,给予及时满意的可执行程序』,所以最适合需求快速变动的项目强调客户所要的是workable的执行码,所以把与撰写程序无关的工作降至最低,并要求客户与开发人员最好以side‐by‐side的方式一起工作2013/11/1481XP强调4个因素交流(communication),XP要求程序员之间以及和用户之间有大量而迅速的交流简单(simplicity),XP要求设计和实现简单和干净反馈(feedback)通过测试得到反馈,尽快提交软件并根据反馈修改勇气(courage).
勇敢的面对需求和技术上的变化2013/11/1482XP开发流程开发人员随时可以和客户进行有效沟通,撰写userstories以确认需求.
简易快速的系统设计,撰写独立的验证程序以解决特殊困难的问题,找出算法即可丢弃验证程序.
规划多次小型阶段的项目计划,以最快速度完成每一阶段的程序交付客户,客户负责Acceptancetests;Coding前必须完成UnitTest与Acceptancetests程序,所有模块整合前都须经过UnitTests;开发人员必须快速响应Bug与需求变更;要求二人一组使用一台计算机设计程序,当一人coding时,另一人负责思考与设计;程序必须符合程序规范,并常做程序的重构(Re‐factoring).
83XP原则和实践‐Planning‐userstoriesuserstoriesUserstories类似usecase,描述用户所见的系统功能,但避免使用大量的文档,userstories由用户编写(不仅限于描述用户界面).
Userstories使用用户的语言编写,不使用技术性的语言,每个userstories限于几句话.
Userstories用于在releaseplan会议上对开发时间进行评估,也用于产生验收测试(acceptancetest),必须使用可以自动进行的验收测试保证软件的正确性.
Userstories与传统的用户需求的区别在于详细的程度,userstories并不会确定需求的每个细节,它只是用来简单的描述系统功能,供开发人员进行估计开发进度,在开发过程中开发人员和用户会不断的交流以讨论细节问题.
Userstory应该专注于功能,不应该过分注重用户界面等细节.
一般一个userstoriy在1‐3周的时间完成,如果估计超过3周,说明userstory太大了,需要细分.
2013/11/1484XP原则和实践‐Planning‐releaseplanreleaseplan召开一个releaseplan会议,产生releaseplan.
Releaseplan将用于指定每个iteration的计划.
开发人员对每个userstory估计开发时间(在不被打断,无其他工作情况下的开发时间,包括测试),用户对userstories给出优先级,releaseplan会议并不制订每个iteration的计划.
Releaseplan要用户,开发人员和管理者都同意,在完成功能范围(scope),使用资源(resource),时间(time)和质量(quality)上达成一致(一般质量是不能改变的)2013/11/1485XP原则和实践‐Planning‐smallreleasesmallreleaseoftenandsmallrelease是XP的一个原则,每个release完成一些用户有意义的功能集合,尽快的提交给用户以获得反馈,及时调整,提交的越晚,调整越困难.
2013/11/1486XP原则和实践‐Planning‐projectvelocityprojectvelocity团队在开发过程中要收集数据,以便于对自己的开发速度进行评估,用于以后的releaseplan2013/11/1487XP原则和实践‐Planning‐iterationiteration每个smallrelease的周期称为iteration,每个iteration约为1‐3周,在一个项目中保持每个iteration的时间相等,不要超前制定计划,每个iteration的计划在iteration的开始时制定.
这样能够更灵活的应付变化.
不要急于完成本次iteration没有包括的功能.
要注重每个iteration的时间限制,当团队觉得不能按时完成iteration时,召开一次iterationplan会议,重新评估,减少一些userstories.
2013/11/1488XP原则和实践‐Planning‐iterationplaniterationplan在每个iteration开始的时候召开会议,从releaseplan中选择还没有实现的用户最迫切需要的userstories.
上一个iteration中没有通过验收测试的功能也要在这个iteration中实现.
可以根据上一个iteration的实践调整团队速度.
Userstories和失败的测试被分解成programmingtask,task使用技术语言编写,作为iterationplan的详细描述.
程序员主动领取task并估计完成时间,每个task应该在1‐3天内完成,超过3天的task应该被细分.
如果整个团队需要的时间多于或少于规定的iteration时间,调整userstories.
2013/11/1489XP原则和实践‐Planning‐movepeoplearoundmovepeoplearound不要使每个开发人员局限于一项工作,不要使某项工作依赖于一个开发人员,增加知识共享,减少信息孤岛,多进行交流和培训.
当项目中的所有人对所有模块都了解并可以进行开发时是效率最高的,鼓励开发人员在不同iteration中开发不同的模块.
2013/11/1490XP原则和实践‐Planning‐stand‐upmeetingstand‐upmeeting每天工作开始之前,开5‐10分钟的stand‐up会议(站立会议),站立的目的是为了强迫节省时间,会议的目的是交流,提出存在的问题,但不要在会议上解决问题.
开一个所有人员参加的短会比多个个别人员参加的会议要高效.
在会议上提出的问题可以由少数人讨论解决,这个少数人参加的会议如果涉及到代码,可以在计算机前讨论.
2013/11/1491XP原则和实践‐Planning‐fixXPwhenitbreaksfixXPwhenitbreaksXP并不是一成不变的,当团队觉得需要修改的时候,可以根据自己的情况进行修改,任何修改都要经过整个团队的讨论和达成一致92XP原则和实践‐Designing‐1Simplicity保持简单的设计,在完成同样的功能的情况下,选择简单的设计,不要急于设计没有计划的功能,应该认识到:keepingadesignsimpleisadifficultjobSystemmetaphor使用统一的术语描述系统,在用户,管理者和开发人员之间使用统一的术语.
这将使交流清晰.
CRCcard使用CRC(Class,Responsibilities,andCollaboration)card进行系统设计,鼓励更多的人参加设计.
每个CRC卡片表示系统中一个对象,写上对象的名字,责任和每个责任需要交互的其他对象.
可以模拟对象之间的交互.
CRC卡片是易于理解的,但是是非正式的,如果需要正式的文档,要将卡片转换为相应的文档.
spikesolutionneveraddfunctionearlyRefactoringwheneverandwherever2013/11/1493XP原则和实践‐Designing‐2spikesolution使用spikesolution减低风险,当遇到技术难题或设计问题时,使用简单的程序进行测试,找出问题,在不同的解决方法之间进行评估.
在早期进行实验可以有效的降低风险.
neveraddfunctionearly不要过早的设计没有计划的功能,在一个需求经常变化的环境中,过早的设计经常是没有用的.
RefactoringwheneverandwhereverXP鼓励对设计和代码经常进行重构(Refactoring),目的是去除冗余,提高质量,保持设计简单.
重构必须以完全测试为检验条件2013/11/1494XP原则和实践‐Coding‐1customerisalwaysavailable用户是项目组的成员之一,用户的参加贯穿整个开发过程,用户与开发人员之间的交流是重要的codingstandard使用统一的编码标准,这是保持代码整洁和共享代码的基础codingunittestfirsttestfirst是XP的一个特点,在编写代码之前先编写单元测试代码,单元测试代码和代码由同一个程序员完成.
先编写测试代码可以使程序员更好的理解需求,避免直接编码造成的理解偏差,对需求的不清晰,可以在编写测试代码时就发现.
测试代码也是检验程序是否完成的标准.
编码工作应该是以下工作的循环:1编写测试代码2运行测试程序,确认失败3编写实现这个测试程序要求功能的代码,不需要实现其他的功能,只需要实现刚刚满足测试程序的功能4运行测试程序,确认成功实践证明,testfirst方式需要的编码实践少于先编码,后写测试代码95XP原则和实践‐Coding‐2PairProgrammingPairprogramming是XP的特色,它要求两个程序员在一台计算机上同时进行编程工作.
共用鼠标和键盘,通常一个人进行战略上的思考,程序架构和函数,类之间的关系,一个人进行输入和战术上的思考,完成函数和类.
两个人可以经常交换角色.
sequentialintegration要保证源代码库的状态是可标识的,同一时间,只允许一个pair的程序进行整和和测试,这样可以缩小问题产生的范围.
不同的pair可以在自己的机器上随时进行整和和测试.
oftenintegration只要有可能就进行代码整合,周期可以在几个小时,最好不要超过一天.
2013/11/1496XP原则和实践‐Coding‐3共同拥有代码鼓励每个人对项目中的任何人提出新的想法,任何开发人员对项目中的任何代码都可以进行增加功能,改正错误和重构.
优化工作放在最后先使系统能够正常工作,不要猜测系统的瓶颈,要实际测量NOOT!
不要长时间的加班,大多数加班并不能挽回已有的延迟,连续超过两个星期的加班说明有问题存在.
向一个已经延迟的项目填加人员也不是一个好的选择.
97XP原则和实践‐Testing‐1所有的代码都有单元测试单元测试是XP的基石,XP中的单元测试应该是可以自动进行的,所以可以很快的进行所有的单元测试,单元测试应该在编码之前创建.
单元测试的代码和代码一起release,没有单元测试的代码不能够release.
使用自动单元测试可以系统整合时节省大量的发现错误和改正的时间.
单元测试越完善,节省的时间越多.
代码在release前必须通过所有的单元测试发现bug后,首先增加测试在实际运行中发现bug,首先增加acceptancetest,然后增加unittest,在增加完测试后在查找和修改代码,增加的测试保证同样的错误不会再出现acceptancetestacceptancetest根据userstories在iterationplan会议上创建,它也应该可以自动运行以便可以经常运行.