华为敏捷开发介绍ppt课件.ppt

PSST质量与成本管理部/系统工程部,华为敏捷软件开发解读,2009年06月 N.001,Page 2,关于管理者和软件开发相关人员掌握敏捷知识的要求 为落实敏捷软件开发在我司的顺利推行，使广大软件开发管理者和开发人员深刻领会敏捷核心理念，熟练掌握敏捷实践方法，从而达到增强应对需求变化的能力、提高产品质量、提升开发效率和缩短交付周期等方面的目标。为此，特提出如下要求：PM及以上管理者要深刻领会敏捷核心理念、理解我司敏捷推行策略、了解各种敏捷实践。软件开发相关人员（含PL、软件开发人员、软件测试人员、软件架构人员、系统分析人员、与软件相关的资料人员和研发质量人员）要深刻理解敏捷理念、掌握敏捷实践、了解我司敏捷推行策略。通过敏捷相关知识的考试是软件开发相关人员任职资格的基本要求。考试试题分为管理者版本和员工版本，分别针对管理者和员工应知应会的知识进行考试。敏捷学习参考材料包括：华为敏捷开发解读及相关附件。,目录,敏捷概述正确理解敏捷我司敏捷开发实施策略我司敏捷案例,Page 4,业界敏捷浪潮,ISO 9000（09版）标准将在原来八大原则的基础上新增敏捷原则2000年美国军方软件开发标准（DOD 5000.2）推荐迭代为软件开发优选模式世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一,Page 5,软件作坊,软件过程控制,重型过程,2001今 敏捷正在流行,软件规模小，以作坊式开发为主；硬件飞速发展，软件规模和复杂度激增，引发软件危机；引入成熟生产制造管理方法，以“过程为中心”分阶段来控制软件开发（瀑布模型），一定程度上缓解了软件危机；软件失败的经验促使过程被不断增加约束和限制，软件开发过程日益“重型化”，开发效率降低、响应速度变慢；随着信息时代到来，需求变化更快，交付周期成为企业核心竞争力，轻量级的，更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。,软件危机,20世纪60年代,80年代,90年代,软件开发顺应时代变化，从重型过程转向轻量型敏捷,70年代,敏捷诞生的历史背景,Page 6,敏捷宣言揭示更好的软件开发方法,敏捷宣言（ 2001年）是敏捷起源的基础，由上述4个简单的价值观组成，敏捷宣言的签署推动了敏捷运动敏捷宣言本质是揭示一种更好的软件开发方式，启迪人们重新思考软件开发中的价值和如何更好的工作,敏捷宣言,Page 7,软件更像一个活着的植物，软件开发是自底向上逐步有序的生长过程，类似于植物自然生长敏捷开发遵循软件客观规律，不断的进行迭代增量开发，最终交付符合客户价值的产品,传统开发,敏捷开发,敏捷更符合软件开发规律,Page 8,敏捷对生产率、质量、满意度、成本有明显改进,82%的项目生产率有提高,78%的项目质量有提高,78%的项目客户满意度有提高,37%的项目成本有降低,* 以上数据来自DDJ 2008由Scott Ambler发起的网上调查结果,目录,敏捷概述正确理解敏捷统一敏捷认识敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例,Page 10,对敏捷的常见误解,误解一： 敏捷开发意味着可以不需要文档、设计和计划误解二： 敏捷只是一些优秀实践，或者是优秀实践的结合误解三： 敏捷只适用于小项目开发误解四： 敏捷只会对研发产生改变误解五： 管理者不需要亲自了解敏捷，只需要管理上支持就可以了误解六： 引入敏捷只需要按照既定的步骤去做就可以了误解七： 敏捷是CMM的替代品，是另一种流程误解八： 敏捷只注重特性的快速交付，在敏捷下架构不重要了,Page 11,统一认识：敏捷=理念+优秀实践+具体应用,理念,优秀实践,具体应用,理念（敏捷核心思想）敏捷包括3个层次 优秀实践（敏捷的经验积累） 具体应用（能够结合自身灵活应用才是真正敏捷）,Page 12,理念：聚焦客户价值(Value)，消除浪费,软件业：45%的软件特性客户没有使用,Source：Standish Group 来自5万个软件开发项目的调查,Source：中国电信总工韦乐平在华为公司工程与技术大会上的讲话,Source：如何提升软件开发效率08年统计,电信业：“电信级”带来的浪费,“价值”在“敏捷宣言”中的体现,产品商业成功为目标，聚焦客户价值、围绕价值流消除浪费,我司：研发版本废弃特性,07.1-08.6年某产品线所有产品中重要特性无应用的比例达22%（需求变更和分析不足占63%）,Page 13,理念：激发团队(Team)潜能，加强协作,我司试点开发测试拉通，效率质量改善明显,团队是价值的真正创造者，应加强团队协作、激发团队潜能软件开发是一种团队活动，首先应做到提升沟通效率降低交流成本,Source: 08年测试行业超过30个项目试点,Source：经济学家2003& DeMarco 研究报告,“团队”在“敏捷宣言”中的体现,研究表明面对面的沟通最有效 业界调查：一个50人开发团队，每人平均30%时间用于编码，70%的时间用于与其他成员交流。,研究表明1981年来自不同公司的优秀程序员生产率之比是7:1，而2007年最新的研究数据，则是40:1。,人是软件开发的决定因素,Page 14,理念：不断调整以适应(Adapting)变化,麦当劳是简单可预测生产过程,人月神话：软件开发是人类最复杂工作之一，软件具有四个属性：复杂性、一致性、可变性和不可见性。软件开发是不可重复、探索性的、演进的，适应性过程。,随软件规模增长，需求变化呈非线性增长,软件开发是复杂不可预测的经验控制过程,“适应变化”在“敏捷宣言”中的体现,不断的根据经验调整，最终交付达到业务目标的产品,软件开发规律再审视,Page 15,优秀实践: 业界敏捷优秀实践概览,结对编程,测试驱动开发,客户参与验收,计划游戏,代码集体所有,每日站立会议,产品backlog（带优先级的需求清单）,燃烧图,迭代计划会议,回顾会议,Scrum Master,Product Owner,Anatomy（系统解剖）,One Track,Systemakut（缺陷管理和决策）,重构,完整团队,稳定开发节奏,Lagomising（需求决策）,隐喻,电信业偏重大规模产品实践、Scrum偏重项目管理，XP偏重编程实践,电信业,Scrum,XP,持续集成,迭代交付,Page 16,开发团队一,具体应用：因地制宜选择适合的敏捷实践,团队在透彻理解敏捷理念的基础上，可以灵活选择最适合自己的实践，避免教条化,站立会议,排序的工作列表,持续集成,持续集成,重构,持续集成,结对编程,迭代开发,+,+,迭代开发,+,+,+,+,+,+,+,开发团队三,敏捷理念,开发团队二,敏捷理念,敏捷理念,Page 17,敏捷转型是系统性工程,敏捷转型7个方面优先级,Source：Cutter Agile Transformation（Jim Highsmith大师）,敏捷转型是系统工程，覆盖7个方面：实践、绩效考核、组织、过程、文化、管控、技术和业务对齐敏捷在敏捷转型不同阶段，敏捷转型框架的7个方面引入的优先级不一样，初期以实践为主,Numbers represent typical relative importance at each stage.,目录,敏捷概述正确理解敏捷统一认识敏捷敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例,Page 19,深入理解敏捷理念,深入理解“适应变化”认请“客户是逐步发现真正需求”小批量是快速交付的关键通过迭代计划不断调整以适应需求变化应持续保持良好的软件架构利用多层次反馈不断调整以逼近目标,深入理解“激发团队”认清团队的基本事实敏捷方式下管理者的转变敏捷方式下团队成员的转变,深入理解“聚焦客户价值”标识和消除软件开发中的浪费交付刚刚好的系统随时构建质量，不容忍缺陷及时消除技术债务，持续保持快速响应,Page 20,聚焦客户价值，标识和消除软件开发中的浪费,Source：精益软件开发,Page 21,当质量、进度、资源冲突时，能改变的只有项目范围，即选择“交付刚刚好的系统”产品交付前，客户往往期望多而全的功能，产品交付后，客户把稳定的质量放在首位，尤其在电信领域，客户对产品质量要求是Always work，不是Sometimes。与其为了满足多而全的功能导致交付延迟，质量不稳定，不如按时交付刚刚好的系统，保证其高质量运行。交付刚刚好的系统，基于对客户需求的深入理解，并花时间了解细节，简化（simplify）需求（降低复杂性）而不是简单地拒绝需求（delete）。做到“交付刚刚好的系统”，同时需要管理者有足够的勇气和果断决策,聚焦客户价值，交付刚刚好的系统,在项目明显超负荷时，管理者简单地期望靠团队work harder来解决，最终导致：质量下降项目延期客户不满意团队疲劳埋下长期隐患,Page 22,缺陷遗留带来高额成本：对单独质量保证活动（如后端测试）的依赖，容易形成缺陷可以遗留到下个阶段的心理，导致缺陷发现成本升高（系统测试阶段缺陷定位和解决成本是开发阶段的10倍）例1：E公司开发阶段和测试阶段发现缺陷的比例为7：3，而我司大量缺陷集中在后端发现，带来高额成本。例2：我司顾问指出：华为测试和开发“相隔1000英里”。,聚焦客户价值，随时构建质量，不容忍缺陷,从项目一开始就随时构建质量：形成零缺陷文化，不要容忍缺陷：发现缺陷应立即停下来解决，以保证在坚实的质量基础上前行。开发和测试紧密协作：测试人员参与到设计和开发过程中，共同预防缺陷的产生。,例如：持续集成暴露的问题需立即解决,Page 23,聚焦客户价值，及时消除技术债务，持续保持快速响应,为什么会有技术债务：为满足短期商业目标，不影响其外部表现的情况下，会在技术方面进行一定的让步，这种让步虽对当前版本的质量影响甚微，但会严重影响后续版本响应客户需求的能力，从而形成技术债务。,对待技术债务的态度：技术债务是有成本的，如不及时偿还，会随时间积累利息变高，导致开发效率大幅下降，从而降低客户响应能力。因此对待技术债务的态度是加以管理并及时偿还（如及时重构）。,常见技术债务:日益腐烂的架构、圈复杂度高的代码、低的测试自动化率、不及时清除的静态检查告警等。,Page 24,激发团队，认清团队的基本事实,Source: Jeff CSM Training material,信任是高绩效团队的基石,信任,承诺,冲突,创新,关于团队激励： 当团队自管理时效率最高人们对自己做出的承诺比别人要求的承诺更认真人们会尽力做到最好在强大的压力下努力工作，人们会自然而然地降 低对质量的要求关于团队绩效： 当团队成员不被打扰时，工作效率最高当团队解决自我问题时，提升最快广泛的、面对面的交流是团队工作最高效的方式关于团队构建：团队生产率大于相同数目的个体生产率之和当不同技能领域的人员组成团队并聚焦于工作 时，产品更健壮,Page 25,激发团队，敏捷方式下管理者的转变,管理者努力“控制” 团队：制定详细的工作计划，并做出详细的工作安排指令性工作方式监控过程基于复杂规则的管理,管理者努力“激发”团队：通过目标来牵引团队自主工作帮助团队提供资源，排除障碍营造团队自我管理的工作氛围作为教练辅导团队进步基于简单原则的管理，原则简单但必须被遵守,敏捷方式下对管理者最大的挑战是学会放松”控制”(loose control),传统方式,敏捷方式,Page 26,激发团队，敏捷方式下团队成员的转变,团队成员是“听从安排的独立贡献者”:被动等待主管下指令安排工作独立工作为主，协作少以文档和邮件为主要沟通方式只关注个体任务“做完”，不关注团队目标能力相对单一，学习动力不足,敏捷方式的管理者,从被动到主动的心态转变是团队成员适应敏捷开发的关键,团队成员是“全方位的积极参与者”:共同参与计划制定和任务安排团队协作贯穿工作始终面对面交流是主要沟通方式关注团队目标，共担责任能力要求更广，主动学习适应岗位要求,传统方式,敏捷方式,Page 27,残酷现实客户是逐步发现他真正要的东西开发人员逐步发现如何开发产品满足客户需求在这个过程中随时可能发生变化,美好愿望客户知道自己要的是什么开发人员知道如何开发来满足客户需求在开发过程中需求不会发生变化,期望客户一开始就想清楚他们真正要的东西是不现实的。我们应当通过不断的向客户交付可用的产品，启发客户逐步的发现真正的需求。,我们认识到,适应变化，认清“客户是逐步发现真正需求”,Page 28,适应变化，小批量是快速交付的关键,我们首先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 摘自敏捷软件的十二个原则,在需求响应周期相同的情况下，批量（一次开发的需求量）越小，资源利用率更高。在资源利用率相同的情况下，批量越小，交付周期更短。,减小批量不仅带来缩短交付周期，而且还带来提高质量、促进创新、降低管理成本、更高的效率等其他好处，大幅提升商业价值。,减少批量的好处,Source：Craig Larman,减小批量,1.减少排队,3.缩短交付周期,2.加快反馈,4.增强质量,5.改善创新,6.降低管理成本,7.更高的效率,$,排队理论：小批量与缩短交付周期、人员有效产出的关系,Page 29,适应变化，通过迭代计划不断调整以适应需求变化,正确做计划方法在每一轮迭代开始，只详细确定本次迭代的工作内容，并严格执行，对后续较远的迭代内容只做粗略的计划，避免浪费。,项目范围常发生变化需求出现了增加、删除、优先级调整（如图E、O、P、J）工作量在需求细化后发现离原始工作量估计有偏差，引发计划调整；（如图中I）客户使用了产品后，发现有些需求已不再需要（如图中D、G）,变化无法一次性预测，一开始制作大而全的计划易造成浪费应根据迭代积累的经验和需求变化的情况对计划不断调整和细化,Page 30,适应变化，应持续保持良好的软件架构,良好软件架构是适应变化的基石电信软件的特点是庞大、复杂、生命周期长，因此需要良好架构来保证长期的演进，避免大规模的返工；优秀的架构通过可扩展性来很好地适应需求的变化，对敏捷起到支持作用，相反拙劣的架构会阻碍敏捷；良好架构使系统部件处于松耦合状态，有助于制定出合适的增量开发/集成计划，使分层分级的持续集成更加容易实施。软件架构需要尽早验证和持续维护新产品开发通过早期迭代来实现和验证架构，有利于架构的尽早稳定；增量开发需识别影响架构的需求，优先实现，规避架构风险；通过重构及时维护和优化架构（偿还技术债务），使架构保持生命力。,Page 31,适应变化，利用多层次反馈不断调整以逼近目标,结对编程,单元测试,持续集成,站立会议/回顾会议,客户验收,对代码质量的反馈,对单元功能的反馈,对团队运作的反馈,对系统功能的反馈,对客户需求的反馈,利用多层次反馈手段，在变化的环境中让团队准确地了解与目标的差距，不断调整自身行为，并逐步逼近靶心,多层次反馈手段,目录,敏捷概述正确理解敏捷统一认识敏捷敏捷理念解读敏捷实践解读我司敏捷开发实施策略我司敏捷案例,Page 33,敏捷实践概览,技术实践,迭代计划会议每日站立会议可视化管理迭代验收迭代回顾会议,管理实践,产品Backlog（需求清单）迭代Backlog完成标准,敏捷团队角色Product Owner（PO）Scrum MasterTeam完整团队实践,团队,用户故事结对编程TDD（测试驱动开发）持续集成Anatomy系统解剖,工作件,敏捷软件开发是以短周期迭代为核心，包含团队、工作件、管理和技术优秀实践的集合,迭代开发,Page 34,敏捷软件开发典型场景,PO和开发团队对产品业务目标形成共识PO建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序PO每轮迭代前，Review需求列表，并筛选高优先级需求进入本轮迭代开发开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明PO对每轮迭代（24周）交付的可工作软件进行现场验收和反馈回到第3步，开始下一轮迭代,Page 35,什么是迭代式开发迭代开发将整个软件生命周期分成多个小的迭代（一般2-4周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，每一次迭代都可以生成一个稳定和被验证过的软件版本。,迭代式开发的好处通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险通过提供功能渐增的产品，持续从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要通过小批量减少排队，提供更灵活、快速的交付能力平滑人力资源的使用，避免出现瓶颈,迭代式开发的关键要点每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈迭代推荐采用固定的周期（2-4周），迭代内工作不能完成，应当缩减交付范围而不是延长周期,敏捷软件开发核心迭代开发,迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上,Page 36,敏捷团队包括3个核心角色: PO(Product Owner)、Scrum Master(Scrum教练)和Team(开发产品),敏捷团队的三个核心角色,Marketing,用户,用服,管理,.etc,利益相关人,SM,SM,SM,SM：Scrum MasterPO：Product Owner,Page 37,敏捷团队的角色职责,Page 38,什么是完整团队敏捷开发中，以Story为单位的持续交付要求系统组、开发和测试等跨功能团队进行密切协同，相互独立的功能团队难以应对。完整团队是跨功能领域（需求分析师、设计师、开发人员、测试人员、资料人员等）的人员组成一个团队，坐在一起工作，团队成员遵循同一份计划，服从于同一个项目经理。,完整团队的好处有助于团队成员形成共同目标和全局意识，促进各功能领域的拉通和融合；通过面对面沟通提升沟通效率。实现团队成员的高度协同，支撑高密度地、持续地、短周期的交付。,完整团队的关键要点成员来自多功能领域：团队拥有完成目标所需的各职能成员；坐在一起办公：团队成员无障碍地沟通；团队保持相对稳定：临时组建的团队生产效率较低，团队稳定非常关键。,完整团队聚焦客户需求交付，提高协作效率,敏捷团队实践：完整团队,Page 39,产品Backlog关键要点清楚表述列表中每个需求任务对用户带来的价值，做为优先级排序的重要参考；动态的需求管理而非“冻结”方式，PO持续地管理和及时刷新需求清单，在每轮迭代前，都要重新筛选出高优先级需求进入本轮迭代；迭代的需求分析过程，而非一次性分析清楚所有需求（只对近期迭代要做的需求进行详细分析，其它需求停留在粗粒度）。,敏捷工作件：产品Backlog,什么是产品Backlog经过优先级排序的动态刷新的产品需求清单，用来制定发布计划和迭代计划。,产品Backlog的好处通过需求的动态管理应对变化，避免浪费；易于优先交付对用户价值高的需求。,产品Backlog是需求动态管理的载体,Page 40,什么是迭代Backlog迭代Backlog是团队在一轮迭代中的“任务”（Task）清单，是团队的详细迭代开发计划；当团队接收从产品Backlog挑选出要在本轮迭代实现的需求时，召开团队迭代计划会议，将需求转化为具体的“任务”；每项任务信息包括当前剩余工作量和责任人。,敏捷工作件：迭代Backlog,迭代Backlog的好处将需求分解成更细小的任务，利于对迭代内进度进行精确控制；剩余工作量可用来实时跟踪团队当前进展。,迭代Backlog关键要点“任务”由团队成员自己分解和定义，而不是上级指派，支撑需求完成的所有工作都可以列为任务；任务要落实到具体的责任人；任务粒度要小，工作量大于两天的任务要进一步分解；用小时做为任务剩余工作量的估计单位，并每日重估计和刷新。,迭代Backlog提供精细的迭代开发计划,任务,责任人,状态,剩余工时,日期,Page 41,敏捷工作件：完成标准（Definition of Done）,什么是完成标准基于“随时可向用户发布”的目标制定衡量团队工作是否已完成的标准，由团队和PO形成共识；,完成标准的好处共同协商的完成标准是团队的自我承诺，团队会更认真；用于准确评估团队工作进展；清晰和明确的完成标准保证了每次迭代是高质量的。,完成标准的关键要点团队自协商：团队根据项目实际情况来定义完成标准，并严格遵守；有层次：一般分为三个层次：Story级别，迭代级和发布级，每个级别都有各自的完成标准。,Story完成标准样例,迭代完成标准样例,发布完成标准样例,代码合入主干,代码符合规范,代码100%检视,通过验收测试,通过迭代验收,系统测试用例100%通过,通过性能测试,所有Story完成,通过回归测试,所有缺陷解决,更新配套资料,完成标准的样例,代码100%通过单元测试,持续集成无错误,完成标准确保团队每一步前进都奠定在坚实的质量基础之上,Page 42,敏捷管理实践：迭代计划会议,什么是迭代计划会议每轮迭代启动前，团队共同讨论本轮迭代详细开发计划的过程，输入是产品Backlog，输出是团队迭代Backlog；多团队迭代计划会议要分层召开版本迭代计划会议：将产品Backlog（需求）分配给团队；团队迭代计划会议：将选取的产品Backlog需求转换成迭代Backlog（任务） ，分配给团队成员；迭代计划会议内容：澄清需求、对“完成标准”达成一致工作量估计、根据团队能力确定本轮迭代交付内容；细化、分配迭代任务和初始工作计划。,迭代计划会议的好处通过充分讨论，使团队成员对任务和完成标准理解一致；团队共同参与，促进团队成员更认真对待自己的承偌。,迭代计划会议的关键要点充分参与：Scrum Master确保PO和Team充分参与讨论，达成理解一致；相互承诺：Team承诺完成迭代Backlog中的需求并达到”完成标准“，PO承诺在短迭代周期不增加需求（2-4周）；确定内部任务：Team和PO协商把一些内部任务放入迭代中（例如重构、持续集成环境搭建等），由PO考虑并与其他外部需求一起排序 。,迭代计划会议由团队共同确定迭代交付内容和完成标准,Page 43,敏捷管理实践：每日站立会议,什么是每日站立会议每日工作前，团队成员的例行沟通机制，由Scrum Master组织，Team成员全体站立参加聚焦在下面的三个主题：我昨天为本项目做了什么？我计划今天为本项目做什么？我需要什么帮助以更高效的工作？,每日站立会议的关键要点准时开始：按计划会议制定的时间地点开会，形成团队成员的自然习惯；高效会议：会议限时15分钟，每个人都保持站立，依次发言，不讨论与会议三个主题无关的事情（如技术解决方案等）；问题跟踪：Scrum Master应该记录下所有的问题并跟踪解决；,每日站立会议的好处增加团队凝聚力，产生积极的工作氛围及时暴露风险和问题；促进团队内成员的沟通和协调。,每日站立会议促进团队沟通协调，及时暴露问题,Page 44,敏捷管理实践：可视化管理,可视化管理的好处简单，一目了然 ，降低管理成本；实时状态显示，及时暴露问题；信息同源使团队理解一致，提升团队凝聚力；激励先进，鞭策后进，增强团队进取心。,什么是可视化管理将项目状态 (进度、质量等)通过物理实体（如白板，大屏幕）实时展示，让团队所有成员直观地获取当前项目进展信息。,可视化管理的关键要点物理实体：可视化一定要做到物理上的实体化，大家在公开场所都容易看到，触摸到，（存在电脑中的文件不是可视化的）；内容精简，易懂：信息展示一目了然，切实对团队有帮助，切忌贪多求全，难以分辨；实时刷新：延迟的信息拖延问题暴露，降低运作效率。,可视化管理及时暴露问题，激励团队,Story墙（展示Story进度）,缺陷走势图（展示缺陷解决进展）,Anatomy视图（展示系统集成进展）,Page 45,敏捷管理实践：迭代验收,什么是迭代验收每次迭代开发结束时举行，通过演示可工作的软件检查需求是否满足客户要求；由Scrum Master组织， PO和用户代表（外部或内部利益相关人）负责验收、Team负责演示可工作软件。,迭代验收的好处通过演示可工作的软件来确认项目的进度，具有真实性；能尽早的获得用户对产品的反馈，使产品更加贴近客户需求。,迭代验收的关键要点展示“真实”的产品：Team 应在真实环境中展示可运行的软件，判断是否达到“完成”标准；收集反馈：PO 根据验收情况及客户反馈意见，及时调整产品Backlog。,迭代验收尽早演示可工作的软件，收集反馈意见,Page 46,敏捷管理实践：迭代回顾会议,迭代回顾会议的好处激励团队成员；帮助团队挖掘优秀经验并继承；避免团队犯重复的错误；营造团队自主改进的氛围。,什么是迭代回顾会议在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步；围绕如下三个问题：本次迭代有哪些做得好本次迭代我们在哪些方面还能做得更好我们在下次迭代准备在哪些方面改进？,迭代回顾会议的关键要点会议气氛：Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；关注重点：Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；会议结论要跟踪闭环：可以放入迭代backlog中。,迭代回顾会议是促进团队持续改进的最有效手段,好的,能做得更好的,将来改进的,Page 47,敏捷工程实践：用户故事（user story）,什么是用户故事用户故事是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。,用户故事的好处用户故事站在用户视角便于和客户交流，准确描述客户需求；用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。,用户故事的关键要点I Independent，可独立交付给客户N Negotiable，便于与客户交流V - Valuable ，对客户有价值E - Estimable ，能估计出工作量S - Small ，分解到最底层的用户故事粒度尽量小，至少在一个迭代中能完成T - Testable，可测试,初始需求：1.作为网络规划人员，我想要配置一个媒体网关，因为想要增加网络容量和服务初次分解：1.1作为网络规划人员，我想把媒体网关参数上传到管理系统 1.2作为网络规划人员，我想从管理系统下载媒体网关参数再次分解：1.2.1作为网络规划人员，我想用文件方式从管理系统下载媒体网关参数用例：用户在管理系统上选择以文件方式下载媒体网关参数，执行成功后，检查文件是否正确下载到本地且内容正确1.2.2作为网络规划人员，我想用MML结构方式从管理系统下载媒体网关的参数用例:,故事样例,用户故事便于团队站在用户角度分解细化需求并制定验收标准,Page 48,敏捷工程实践：结对编程,什么是结对编程两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；领航员检视的同时还必须负责考虑下一步的工作方向 ，比如可能出现的问题以及改进等。,结对编程的好处有助于提升代码设计质量；研究表明结对生产率比两个单人总和低 15%，但缺陷数少 15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高（source: The Economist）；结对编程能够大幅促进团队能力提升和知识传播。,结对编程的关键要点程序员应经常性地在“驾驶员”和“领航员”间切换，保持成员间平等协商和相互理解，避免出现一个角色支配另一个角色的现象；开始一个新Story开发的时候即可变换搭档，以增进知识传播；培养团队成员积极、主动、开放、协作的心态能够增进结对编程效果；实施初期需要精心辅导，帮助团队成员克服个性冲突和习惯差异。,结对编程提高代码质量和工作效率,Page 49,敏捷工程实践：测试驱动开发（TDD）,什么是测试驱动开发TDD以测试作为编程的中心，它要求在编写任何代码之前，首先编写定义代码功能的测试用例，编写的代码要通过用例，并不断进行重构优化；TDD要求测试可以完全自动化运行。,测试驱动开发的好处和代码同步增长的自动化测试用例，能为代码构筑安全网，保证代码重构的质量；TDD有助于开发人员优化代码设计，提高代码可测试性。,测试驱动开发的关键要点测试代码和源代码一样都需要简洁，可读性好；测试用例的设计要保证完备，覆盖被测单元的所有功能；每个测试用例尽量保持独立，减少依赖，提高用例的可维护性；当功能单元较大时，为降低难度，可分解为多个更小的功能单元，并逐一用 TDD 实现。,测试驱动开发保证代码整洁可用（Clean code that works）,Page 50,敏捷工程实践：持续集成(CI),什么是持续集成持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。,持续集成的好处大幅缩短反馈周期，实时反映产品真实质量状态；缺陷在引入的当天就被发现并解决,降低缺陷修改成本；将集成工作分散在平时，通过每天生成可部署的软件；，避免产品最终集成时爆发大量问题。,持续集成的关键要点持续集成强调 “快速”和“反馈”，要求完成一次系统集成的时间尽量短，并提供完备且有效的反馈信息；自动化测试用例的完备性和有效性是持续集成质量保障；修复失败的构建是团队最高优先级的任务；开发人员须先在本地构建成功，才可提交代码到配置库 ；持续集成的状态必须实时可视化显示给所有人；大系统持续集成需分层分级，建立各层次统一的测试策略。,持续集成提供产品质量的快速反馈，保证随时拥有可工作的软件,参见附件：持续集成解读.ppt,Page 51,Page 51,敏捷工程实践：Anatomy系统解剖,什么是AnatomyAnatomy（解剖）来源于电信行业，从用户视角全面展示复杂产品系统的功能依赖关系，让整个系统的功能按自底向上逐步有序地开发和集成。,Anatomy的关键要点Anatomy不是系统架构视图，图中的Block是表示系统提供给用户使用的一个功能（capability），是站在纯用户视角，不包含设计信息；Anatomy中的依赖关系是用户使用系统功能的依赖关系，而不是设计或架构上的依赖关系；Anatomy是系统全视图，由最了解系统的工程师绘制出基线，在增量开发时需不断刷新。,Anatomy帮助团队理解系统全局，制定合理的迭代计划,Anatomy的好处Anatomy是迭代计划制定的重要依据，保证系统按照类似生物自然生长的顺序自底向上有序地开发和集成（Organic integration）；Anatomy也可作为可视化工具，通过标识图中每一个功能的状态，使项目整体进展一目了然，并能极大增强团队的信心；有助于团队从增量交付向交付全系统的思维转变；是很好的培训教材，帮助工程师了解全系统。,Anatomy样例,目录,敏捷概述正确理解敏捷我司敏捷开发实施策略PSST发文解读09年敏捷实施指导我司敏捷案例,Page 53,关于敏捷推行的指导意见 华为PSST函（2009）012号 签发人：徐直军 敏捷/迭代开发已经成为业界主流软件开发方法，与瀑布模式相比，其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。为了保证敏捷/迭代开发在我司有组织、有步骤、有策划的开展和推行，现明确要求如下：以业务目标（交付周期、质量）为导向牵引敏捷推行，所有敏捷度量都以交付周期和交付质量为基础，而不能为了敏捷而敏捷。公司敏捷推行分三步走：项目级敏捷、版本级敏捷和产品级敏捷，每一步要控制好入口，降低风险。09年重点全面推进项目级敏捷，版本级敏捷进行试点。2010-2011在版本级敏捷试点基础上进行逐步推广。项目级敏捷要求的实践包括：项目级持续集成、开发测试拉通、迭代、可视化管理、回顾会议、自动化测试、站立会议、用户代表参与现场迭代特性验收；其他敏捷实践项目组根据情况自己选择。所有PL都要成为合格的Scrum Master（关键职责是辅导团队用正确的敏捷方法做事），在PL任职资格中将增加该要求。,Page 54,关于全面推广持续集成的决议华为PSST函（2009）022号签发人:徐直军 持续集成是业界的优秀软件开发实践，对降低软件开发风险、增强项目可视性、提高团队自信心、提升软件开发效率和质量效果明显。为保证持续集成在我司有组织、有步骤、有策划地开展和推行，经PSST讨论，现明确要求如下：09年全面开展项目级和产品级持续集成，通过持续集成行为自检表牵引开发人员树立正确的持续集成理念，同时在行为上落实要求，不断改进持续集成工作。本地构建是确保持续集成成功的关键，开发人员须首先在本地构建（编译链接、单元测试、代码静态检查）成功后，方可提交代码到配置库。完善持续集成工具支撑分层、分级、分布式大规模部署策略，与周边系统有效对接，拉通开发领域相关自动化活动。持续集成给配置管理带来较多改变，配置管理业务和IT与持续集成必须拉通。持续集成要和系统测试拉通，由测试体系建立持续集成的统一端到端测试策略。持续集成大规模推广的专项物料，由测试统一规划和部署，持续集成服务器可采用ATCA。每个产品落实专人负责持续集成工作，进行产品持续集成的策略制定、环境搭建和维护、问题协调解决，支撑产品全面部署。,Page 55,软件代码质量要求及样例华为PSST函（2009）029号 签发人:徐直军 编写简洁、可维护、可靠、可测试、高效和可移植代码是每一位软件开发人员的责任和目标。针对当前突出的软件腐化问题，明确软件代码的质量要求如下：简洁：代码简洁就是易于理解并且易于实现。尽量编写少但功能完备的简洁代码，日后可以随时为额外的功能添加更多的代码。提高简洁的方法有：单一功能、强内聚且低耦合、避免函数过长、避免嵌套过深、避免重复等。可维护：代码可维护性是软件被修改的能力，包括纠错、改进、新需求或功能规格变化的适应能力。面对进度压力开发人员容易忽略代码的可维护性。我们要谨慎的编程，使系统中每个组件尽可能地“保护”自己；同时不要做任何假想，随着代码的增长，没有记录下来的假想会不断地造成缺陷。提高可维护性的方法有：使用好的编码风格、编码清晰、降低代码复杂度、尽可能减少全局变量等。可靠：代码可靠性是软件在给定时间间隔和环境条件下，按设计要求成功运行程序的概率。提高可靠性的方法有：使用安全的函数和数据结构、编译时打开所有的警告开关并清除所有警告、使用静态检查工具分析代码并清除所有警告、检查所有的输入、验证所有的运算、检查所有返回值、避免强制转换、避免内存越界、避免内存泄漏等。可测试：代码可测试性是指软件发现故障并隔离、定位故障的能力，以及在一定的时间和成本前提下，进行测试设计、测试执行的能力。提高可测试性的方法有：尽量减少依赖、保持代码可观测性、限制代码复杂度等。高效：代码性能高效是尽可能少地占用系统资源，包括内存和执行时间。提高性能的方法有：合理利用语言特性和编译选项，例如禁用C+的RTTI，可以减少可执行文件大小；代码内嵌，可以减少方法调用的开销；将不变条件的计算移到循环体外；利用并行和线程来防止串行操作；避免或者移除过多的锁；添加缓存或者缓冲层，以加快较慢的数据访问，或防止漫长的重复计算；创建资源库，以减少分配对象的开销。可移植：可移植性是为了在原来设计的特定环境之外运行，对系统进行修改的能力。提高可移植性的方法有：使用标准库函数，并且把它们和类似ANSIISO C标准中定义的头文件放在一起使用；尽可能使所写的程序适用于更多的编译环境；把不可移植的代码分离出来。,Page 56,PSST敏捷发文要点解读：敏捷实施三步走策略,三步走核心思想：敏捷转型成功的关键是团队意识的转变和能力的提升，通过三步走的策略，实现人员技能、工程能力、流程、工具等方面的积累，在风险可控的情况下逐步达到全面敏捷的目标；项目级敏捷：实施的范