第一讲敏捷实践与极限编程概述课件

第一讲：

敏捷实践与极限编程概述目录敏捷实践概述理解敏捷宣言迭代开发极限编程概述极限编程实践业界敏捷浪潮ISO9000（09版）标准将在原来八大原则的基础上新增敏捷原则2000年美国军方软件开发标准（DOD5000.2）推荐迭代为软件开发优选模式世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一Page3软件作坊软件过程控制重型过程2001~今敏捷正在流行软件规模小，以作坊式开发为主；硬件飞速发展，软件规模和复杂度激增，引发软件危机；引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机；软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢；随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。软件危机20世纪60年代80年代90年代软件开发顺应时代变化，从重型过程转向轻量型敏捷70年代敏捷诞生的历史背景Page4敏捷宣言揭示更好的软件开发方法敏捷宣言（2001年）是敏捷起源的基础，由上述4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作敏捷宣言Page5软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品传统开发敏捷开发敏捷更符合软件开发规律Page6敏捷对生产率、质量、满意度、成本有明显改进82%的项目生产率有提高78%的项目质量有提高78%的项目客户满意度有提高37%的项目成本有降低*以上数据来自DDJ2008由ScottAmbler发起的网上调查结果Page7对敏捷的常见误解误解一：敏捷开发意味着可以不需要文档、设计和计划误解二：敏捷只是一些优秀实践，或者是优秀实践的结合误解三：敏捷只适用于小项目开发误解四：敏捷只会对研发产生改变误解五：管理者不需要亲自了解敏捷，只需要管理上支持就可以了误解六：引入敏捷只需要按照既定的步骤去做就可以了误解七：敏捷是CMM的替代品，是另一种流程误解八：敏捷只注重特性的快速交付，在敏捷下架构不重要了Page8统一认识：敏捷=理念+优秀实践+具体应用理念（敏捷核心思想）敏捷包括3个层次优秀实践（敏捷的经验积累）具体应用（能够结合自身灵活应用才是真正敏捷）理念优秀实践具体应用Page9理念：聚焦客户价值(Value)，消除浪费软件业：45%的软件特性客户没有使用Source：StandishGroup来自5万个软件开发项目的调查Source：中国电信总工韦乐平Source：《如何提升软件开发效率》08年统计电信业：“电信级”带来的浪费“价值”在“敏捷宣言”中的体现产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费我司：研发版本废弃特性07.1-08.6年某产品线所有产品中重要特性无应用的比例达22%（需求变更和分析不足占63%）个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划Page10理念：激发团队(Team)潜能，加强协作团队是价值的真正创造者，应加强团队协作、激发团队潜能软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本强调个体与交互的项目试点，效率质量改善明显Source:08年测试行业超过30个项目试点Source：《经济学家2003》&DeMarco研究报告“团队”在“敏捷宣言”中的体现个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划效率流行度文档录制的视频录制的音频2人邮件沟通2人白板沟通2人电话沟通不支持问答形式支持问答形式研究表明面对面的沟通最有效

业界调查：一个50人开发团队，每人平均30%时间用于编码，70%的时间用于与其他成员交流。研究表明1981年来自不同公司的优秀程序员生产率之比是7:1，而2007年最新的研究数据，则是40:1。人是软件开发的决定因素需求变更降低比例补充场景数TR4前发现缺陷比例版本周期缩短（周数）无线49.36%8855.90%2.82核心网45%19045.18%3.5网络31%33042.5%2.6业软30%30048.15%2.1公司平均38.84%90847.93%2.76Page11理念：不断调整以适应(Adapting)变化麦当劳是简单可预测生产过程《人月神话》：软件开发是人类最复杂工作之一，软件具有四个属性：复杂性、一致性、可变性和不可见性。软件开发是不可重复、探索性的、演进的，适应性过程。随软件规模增长，需求变化呈非线性增长软件开发是复杂不可预测的经验控制过程“适应变化”在“敏捷宣言”中的体现不断的根据经验调整，最终交付达到业务目标的产品软件开发规律再审视个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划Page12具体应用：因地制宜选择适合的敏捷实践团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化开发团队一站立会议排序的工作列表持续集成持续集成重构持续集成结对编程迭代开发++迭代开发+++++…+…+…开发团队三敏捷理念开发团队二敏捷理念敏捷理念Page13深入理解敏捷理念深入理解“适应变化”认请“客户是逐步发现真正需求”小批量是快速交付的关键通过迭代计划不断调整以适应需求变化应持续保持良好的软件架构利用多层次反馈不断调整以逼近目标深入理解“激发团队”认清团队的基本事实敏捷方式下管理者的转变敏捷方式下团队成员的转变深入理解“聚焦客户价值”标识和消除软件开发中的浪费交付刚刚好的系统随时构建质量，不容忍缺陷及时消除技术债务，持续保持快速响应Page14浪费类别浪费举例1部分完成的工作部分完成但没有最终落地的工作（没有转化成代码的设计文档；未及时合入的代码导致引发后续更多同步工作量）。2未应用特性开发完成但没有被客户应用的特性（2000多个功能客户只用了1%）。3再次学习人员频繁流动导致经验不能积累，反复重新学习；在多个环节移交时，接收信息者也需要重新学习；拥有某领域的专家，但在开发过程中需要此领域经验时，他却没参与，而是团队重新摸索。4移交知识信息的传递总是伴随信息丢失，隐形知识尤其困难，分工过细往往导致过多不必要的移交（如详细设计和实现分离，造成大量设计信息丢失）。5任务切换研究表明多任务工作会导致效率下降20%-40%（员工多头工作或杂事繁多）。6延迟因任务或资源相互依赖而导致工作停滞（集成时被关键模块阻塞，等待测试环境就绪）。7缺陷解决缺陷活动本身就是浪费，而且缺陷越遗留到后端浪费越大。聚焦客户价值，标识和消除软件开发中的浪费Source：《精益软件开发》Page15当质量、进度、资源冲突时，能改变的只有项目范围，即选择“交付刚刚好的系统”产品交付前，客户往往期望多而全的功能，产品交付后，客户把稳定的质量放在首位，尤其在电信领域，客户对产品质量要求是Alwayswork，不是Sometimes。与其为了满足多而全的功能导致交付延迟，质量不稳定，不如按时交付刚刚好的系统，保证其高质量运行。交付刚刚好的系统，基于对客户需求的深入理解，并花时间了解细节，简化（simplify）需求（降低复杂性）而不是简单地拒绝需求（delete）。做到“交付刚刚好的系统”，同时需要管理者有足够的勇气和果断决策聚焦客户价值，交付刚刚好的系统在项目明显超负荷时，管理者简单地期望靠团队workharder来解决，最终导致：质量下降项目延期客户不满意团队疲劳埋下长期隐患Page16缺陷遗留带来高额成本：对单独质量保证活动（如后端测试）的依赖，容易形成缺陷可以遗留到下个阶段的心理，导致缺陷发现成本升高（系统测试阶段缺陷定位和解决成本是开发阶段的10倍）例：某公司开发阶段和测试阶段发现缺陷的比例为7：3，而大量缺陷集中在后端发现，带来高额成本。聚焦客户价值，随时构建质量，不容忍缺陷从项目一开始就随时构建质量：形成零缺陷文化，不要容忍缺陷：发现缺陷应立即停下来解决，以保证在坚实的质量基础上前行。开发和测试紧密协作：测试人员参与到设计和开发过程中，共同预防缺陷的产生。例如：持续集成暴露的问题需立即解决Page17聚焦客户价值，及时消除技术债务，持续保持快速响应技术商务为什么会有技术债务：为满足短期商业目标，不影响其外部表现的情况下，会在技术方面进行一定的让步，这种让步虽对当前版本的质量影响甚微，但会严重影响后续版本响应客户需求的能力，从而形成技术债务。时间技术债务开发速率对待技术债务的态度：技术债务是有成本的，如不及时偿还，会随时间积累利息变高，导致开发效率大幅下降，从而降低客户响应能力。因此对待技术债务的态度是加以管理并及时偿还（如及时重构）。常见技术债务:日益腐烂的架构、圈复杂度高的代码、低的测试自动化率、不及时清除的静态检查告警等。Page18激发团队，认清团队的基本事实Source:JeffCSMTrainingmaterial信任是高绩效团队的基石信任承诺冲突创新关于团队激励：

当团队自管理时效率最高人们对自己做出的承诺比别人要求的承诺更认真人们会尽力做到最好在强大的压力下努力工作，人们会自然而然地降低对质量的要求关于团队绩效：

当团队成员不被打扰时，工作效率最高当团队解决自我问题时，提升最快广泛的、面对面的交流是团队工作最高效的方式关于团队构建：团队生产率大于相同数目的个体生产率之和当不同技能领域的人员组成团队并聚焦于工作时，产品更健壮Page19激发团队，敏捷方式下管理者的转变管理者努力“控制”团队：制定详细的工作计划，并做出详细的工作安排指令性工作方式监控过程基于复杂规则的管理管理者努力“激发”团队：通过目标来牵引团队自主工作帮助团队提供资源，排除障碍营造团队自我管理的工作氛围作为教练辅导团队进步基于简单原则的管理，原则简单但必须被遵守敏捷方式下对管理者最大的挑战是学会放松”控制”(loosecontrol)传统方式敏捷方式Page20激发团队，敏捷方式下团队成员的转变团队成员是“听从安排的独立贡献者”:被动等待主管下指令安排工作独立工作为主，协作少以文档和邮件为主要沟通方式只关注个体任务“做完”，不关注团队目标能力相对单一，学习动力不足敏捷方式的管理者从被动到主动的心态转变是团队成员适应敏捷开发的关键团队成员是“全方位的积极参与者”:共同参与计划制定和任务安排团队协作贯穿工作始终面对面交流是主要沟通方式关注团队目标，共担责任能力要求更广，主动学习适应岗位要求传统方式敏捷方式Page21期望客户一开始就想清楚他们真正要的东西是不现实的。我们应当通过不断的向客户交付可用的产品，启发客户逐步的发现真正的需求。残酷现实客户是逐步发现他真正要的东西开发人员逐步发现如何开发产品满足客户需求在这个过程中随时可能发生变化美好愿望客户知道自己要的是什么开发人员知道如何开发来满足客户需求在开发过程中需求不会发生变化我们认识到预期需求实际需求价值时间适应变化，认清“客户是逐步发现真正需求”Page22适应变化，小批量是快速交付的关键我们首先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。——摘自敏捷软件的十二个原则在需求响应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率更高。在资源利用率相同的情况下，批量越小，交付周期更短。减小批量不仅带来缩短交付周期，而且还带来提高质量、促进创新、降低管理成本、更高的效率等其他好处，大幅提升商业价值。减少批量的好处资源利用率交付周期大批量中批量小批量Source：CraigLarman减小批量1.减少排队3.缩短交付周期2.加快反馈4.增强质量5.改善创新6.降低管理成本7.更高的效率$$排队理论：小批量与缩短交付周期、人员有效产出的关系Page23适应变化，通过迭代计划不断调整以适应需求变化正确做计划方法在每一轮迭代开始，只详细确定本次迭代的工作内容，并严格执行，对后续较远的迭代内容只做粗略的计划，避免浪费。项目范围常发生变化需求出现了增加、删除、优先级调整（如图E、O、P、J）工作量在需求细化后发现离原始工作量估计有偏差，引发计划调整；（如图中I）客户使用了产品后，发现有些需求已不再需要（如图中D、G）变化无法一次性预测，一开始制作大而全的计划易造成浪费应根据迭代积累的经验和需求变化的情况对计划不断调整和细化Page24良好软件架构是适应变化的基石大型软件项目的特点是庞大、复杂、生命周期长，因此需要良好架构来保证长期的演进，避免大规模的返工；优秀的架构通过可扩展性来很好地适应需求的变化，对敏捷起到支持作用，相反拙劣的架构会阻碍敏捷；良好架构使系统部件处于松耦合状态，有助于制定出合适的增量开发/集成计划，使分层分级的持续集成更加容易实施。软件架构需要尽早验证和持续维护新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定；增量开发需识别影响架构的需求，优先实现，规避架构风险；通过重构及时维护和优化架构（偿还技术债务），使架构保持生命力。适应变化，应持续保持良好的软件架构Page25适应变化，利用多层次反馈不断调整以逼近目标结对编程单元测试持续集成站立会议/回顾会议客户验收对代码质量的反馈对单元功能的反馈对团队运作的反馈对系统功能的反馈对客户需求的反馈利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整自身行为，并逐步逼近靶心多层次反馈手段Page26符合敏捷软件开发的12条原则我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。业务人员和开发人员必须相互合作，项目中的每一天都不例外。激发个体的斗志，围绕被激励起来的个人构建项目，为他们提供所需的环境和支援，辅以信任，从而达成目标。不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。Page27符合敏捷软件开发的12条原则可工作的软件是进度的首要度量标准。敏捷过程倡导可持续的开发速度。责任人、开发人员和用户应能够共同维持一个长期的、恒定的开发速度。坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。以简洁为本，是极力减少不必要工作量的一门艺术。最好的架构、需求和设计出自于自组织团队。团队定期地反思如何能提高成效，并依此调整团队的举止表现。Page28什么是迭代式开发迭代开发将整个软件生命周期分成多个小的迭代（一般2-4周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。迭代式开发的好处通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要通过小批量减少排队，提供更灵活、快速的交付能力平滑人力资源的使用，避免出现瓶颈迭代式开发的关键要点每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈迭代推荐采用固定的周期（2-4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期敏捷软件开发核心——迭代开发迭代1迭代2迭代3反馈反馈迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上Page29敏捷软件开发典型场景PO（productowner产品拥有者，即客户）和开发团队对产品业务目标形成共识PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明PO对每轮迭代（2－4周）交付的可工作软件进行现场验收和反馈回到第3步，开始下一轮迭代迭代每日工作站立会议特性开发特性测试持续集成交付可以工作的软件迭代计划回顾确定一个迭代的工作内容产品和利益相关人①②③、⑦④⑤⑥Page30极限编程概述历史

极限编程的创始者是肯特·贝克、沃德·坎宁安和罗恩·杰弗里斯，他们在为克莱斯勒综合报酬系统（ChryslerComprehensiveCompensationSystem）(C3)的薪水册项目工作时提出了极限编程方法；1999年10月发行《极限编程解析》(2005第二版出版)KentBeck什么是极限编程？ExtremeProgramming（极限编程，简称XP）是由KentBeck在1996年提出的；XP是一个轻量级的、灵巧的软件开发方法，是敏捷方法中罪著名的一个；强调程序设计师团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软体版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，也更注重做为软体开发中人的作用。Page31极限编程实践完整团队我们希望客户、管理者和开发人员紧密地工作在一起，以便彼此知晓对方所面临的问题，并共同去解决这些问题。XP团队中的客户是指定义产品的特性并排列这些特性优先级的人或者团体。最好的情况是客户和开发人员在同一个房间中工作，次一点的情况是客户和开发人员之间的距离在100米内。如果确实无法和客户在一起工作，那么就去寻找能够在一起工作、愿意并能够代替真正客户的人。极限编程实践用户故事为了进行项目计划，必须要知道和项目需求有关的内容，但是却无须知道得太多。对于做计划而言，了解需求只需要做到能够估算它的程度就足够了。需求的特定细节很可能会随实践而改变。因此，在离真正实现需求还很早的时候就去捕获该需求的特定细节，很可能会导致做无用功以及对需求不成熟的关注。用户故事--就是正在进行的关于需求谈话的助记符。它是一个计划工具，客户可以使用它并根据它的优先级和估算代价来安排实现该需求的实践。极限编程实践

短交付周期XP项目每两周交付一次可以工作的软件。每两周的迭代都实现了利益相关者的一些需求，在每次迭代结束时，会给利益相关者演示迭代生成的系统，以得到他们的反馈。迭代计划：每次迭代通常耗时两周。迭代是一次较小的交付，可能会被加入到产品中，也可能不会。它由客户根据开发人员确定的预算而选择一些用户故事组成；一旦迭代开始，客户就统一不再修改当次迭代中用户素材的定义和优先级别；迭代期间，开发人员可以自由地将用户素材分解成为任务（task），并根据最具技术和商务意义的顺序来开发这些任务。极限编程实践短交付周期（续）发布计划：XP团队通常会创建一个计划来规划随后大约6次迭代的内容。一次发布通常需要3个月的工作。它表示了一次较大的交付，通常此次交付会被加入到产品中。发布计划是由一组客户根据开发人员给出的预算所选择的、排好优先级别的用户故事组成。发布计划不是一成不变的，客户可以随时改变计划的内容，他可以取消用户素材，编写新的用户素材，或者改变用户素材的优先级别。但是客户应该更改后面迭代的内容，尽量不要更改下一次迭代。极限编程实践验收测试可以以客户指定的验收测试（AcceptanceTests）的形式来记录有关用户故事的细节。用户故事的验收测试是在就要实现该用户故事之前或实现该用户故事的同时进行编写的。验收测试使用能够让它们自动并且反复运行的某种脚本语言编写，这些测试共同来验证系统按照客户指定的行为运转。验收测是由业务分析师、质量保证专家以及测试人员在迭代期间编写的，这些测试成为真正的项目需求文档一旦通过一项验收测试，那么就加入到已通过的验收测试集中，并决不允许该测试再次失败。极限编程实践结对编程—不会降低编程效率，反而会大大减少缺陷率所有产品（production）代码都是由结对的程序员使用同一台电脑共同完成的。结对人员中的一位控制键盘并输入代码，另一位观察输入的代码并寻找着代码中的错误和可以改进的地方。结对编程的代码是由两人共同设计、共同编写的，两人功劳均等。结对的关系每天至少改变一次，以便于每个程序员在一天中可以在两个不同的结对中工作。在一个迭代期间，每个团队成员应该和所有其他的团队成员在一起工作过，并且他们应该参与了本次迭代中所涉及的每项工作。这样可以促进知识在团队中的传播。专家”也需要与团队中的其他成员结对。极限编程实践测试驱动开发编写所有产品代码的目的都是为了使失败的单元测试能够通过。首先编写一个单元测试，由于它要测试的功能还不存在，因此它会运行失败，然后，编写代码使测试通过。编写测试用例和代码之间的更迭速度是很快的，基本上在几分钟左右。这样的方式非常利于重构。这样一种方式可以激发程序员去解除各个模块之间的耦合，这样能够独立地对它们进行测试。面向对象设计的原则在进行这种解除耦合方面具有巨大的帮助作用。极限编程实践集体所有结对编程中的每一对都具有签出（checkout）任何模块并对它进行改进的权力。没有程序员对任何一个特定的模块或技术单独负责，每个人都参与GUI方面的工作；每个人都参与中间件方面的工作；每个人都参与数据库方面的工作。没有人比其他人在一个模块或者技术上具有更多的权威。任何人都可以多从事自己擅长的一方面，但是不会被限制在自己的专业领域内。极限编程实践持续集成XP团队每天会进行多次系统构建，他们会重新创建整个系统。集成时要采用系统最终结果发布的形式—CD或Web。程序员的模块在签入/集成前必须保证模块已经通过所有测试。可持续的开发速度软件项目不是全速短跑，而是马拉松长跑。XP团队必须要以一种可持续的速度前进，必须要有意识地保持稳定、适中的速度。XP的规则是不允许团队加班工作。在版本发布前的一个星期是该规则的惟一例外如果发布目标就在眼前并且可以一蹴而就，则允许加班。极限编程实践开放的工作空间开放的房间：桌子/椅子面对面，墙上挂满了各种图表；人和人之间的距离必须足够近，能够互相听到对方的谈话。密歇根大学的一项研究表明，在“充满积极讨论的屋子（warroom）”里工作，