华为敏捷软件开发.ppt

HUAWEI TECHNOLOGIES CO.,LTD.,Page,*,单击此处编辑母版标题样式,Huawei Confidential,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,HUAWEI TECHNOLOGIES CO.,LTD.,Huawei Confidential,Security Level:,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,HUAWEI TECHNOLOGIES CO.,LTD.,Page,*,单击此处编辑母版标题样式,Huawei Confidential,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,HUAWEI TECHNOLOGIES CO.,LTD.,Huawei Confidential,Security Level:,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,Thank you,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,英文目录标题,:35-40pt,颜色,:R153 G0 B0,内部使用字体,:,FrutigerNext LT Medium,外部使用字体,:Arial,中文目录标题,:35-40pt,颜色,:R153 G0 B0,字体,:,黑体,英文目录正文,:28-30pt,子目录,(2-5,级,):20-30pt,颜色,:,黑色,内部使用字体,:,FrutigerNext LT Regular,外部使用字体,:Arial,中文目录正文,:28-30pt,子目录,(2-5,级,):20-30pt,颜色,:,黑色,字体,:,细黑体,HUAWEI TECHNOLOGIES CO.,LTD.,Huawei Confidential,Security Level:Internal Public,*,HUAWEI TECHNOLOGIES CO.,LTD.,Page,*,单击此处编辑母版标题样式,Huawei Confidential,英文标题,:32-35pt,颜色,:R153 G0 B0,内部使用字体,:,FrutigerNext LT Medium,外部使用字体,:Arial,中文标题,:30-32pt,颜色,:R153 G0 B0,字体,:,黑体,英文正文,:20-22pt,子目录,(2-5,级,):18pt,颜色,:,黑色,内部使用字体,:,FrutigerNext LT Regular,外部使用字体,:Arial,中文正文,:18-20pt,子目录,(2-5,级,):18pt,颜色,:,黑色,字体,:,细黑体,配色参考方案：,建议同一页面内不超过四种颜色，以下是,13,组配色方案，同一页面内只选择一组使用。（仅供参考）,客户或者合作伙伴的标志放在右上角,.,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,HUAWEI TECHNOLOGIES CO.,LTD.,Huawei Confidential,Security Level:Internal Public,英文标题,:40-47pt,副标题,:26-30pt,字体颜色,:,反白,内部使用字体,:,FrutigerNext LT Medium,外部使用字体,:Arial,中文标题,:35-47pt,字体,:,黑体,副标题,:24-28pt,字体颜色,:,反白,字体,:,细黑体,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,Thank you,HUAWEI TECHNOLOGIES CO.,LTD.,Page,*,单击此处编辑母版标题样式,Huawei Confidential,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,HUAWEI TECHNOLOGIES CO.,LTD.,Huawei Confidential,Security Level:,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,华为敏捷软件开发,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,研究报告,“团队”在“敏捷宣言”中的体现,个体和交互,胜过,过程和工具,可以工作的,软件,胜过,面面俱到的文档,客户合作,胜过,合同谈判,响应变化,胜过,遵循计划,效率,流行度,文档,录制的视频,录制,的音频,2,人,邮件沟通,2,人,白板沟通,2,人,电话沟通,不支持问答形式,支持问答形式,研究表明面对面的沟通最有效,业界调查：一个,50,人开发团队，每人平均,30%,时间用于编码，,70%,的时间用于与其他成员交流。,研究表明,1981,年来自不同公司的优秀程序员生产率之比是,7:1,，而,2007,年最新的研究数据，则是,40:1,。,人是软件开发的决定因素,需求变更降低比例,补充场景数,TR4,前发现缺陷比例,版本周期缩短（周数）,无线,49.36%,88,55.90%,2.82,核心网,45%,190,45.18%,3.5,网络,31%,330,42.5%,2.6,业软,30%,300,48.15%,2.1,公司平均,38.84%,908,47.93%,2.76,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,个方面引入的优先级不一样，初期以实践为主,Wave3,(,企业级）,Wave2,(,产品级,),Wave1,(,项目级,),2,1,2,1,3,3,4,Stage5,2,2,Alignment,1,1,1,2,Culture,1,3,Governance,2,2,Performance,2,1,2,Process,1,1,2,2,Organization,3,2,1,1,Practices,Stage4,Stage3,Stage2,Stage1,Numbers represent typical relative importance at each stage.,实践,绩效,组织,过程,文化,管控,技术和,业务对齐,敏捷转型,框架,目录,敏捷概述,正确理解敏捷,统一认识敏捷,敏捷理念解读,敏捷实践解读,我司敏捷开发实施策略,我司敏捷案例,Page,19,深入理解敏捷理念,深入理解“适应变化”,认请“客户是逐步发现真正需求”,小批量是快速交付的关键,通过迭代计划不断调整以适应需求变化,应持续保持良好的软件架构,利用多层次反馈不断调整以逼近目标,深入理解“激发团队”,认清团队的基本事实,敏捷方式下管理者的转变,敏捷方式下团队成员的转变,深入理解“聚焦客户价值”,标识和消除软件开发中的浪费,交付刚刚好的系统,随时构建质量，不容忍缺陷,及时消除技术债务，持续保持快速响应,Page,20,浪费类别,浪费举例,1,部分完成的工作,部分完成但没有最终落地的工作（没有转化成代码的设计文档；未及时合入的代码导致引发后续更多同步工作量）。,2,未应用特性,开发完成但没有被客户应用的特性（交换机,2000,多个功能客户只用了,1%,）。,3,再次学习,人员频繁流动导致经验不能积累，反复重新学习；在多个环节移交时，接收信息者也需要重新学习；拥有某领域的专家，但在开发过程中需要此领域经验时，他却没参与，而是团队重新摸索。,4,移交,知识信息的传递总是伴随信息丢失，隐形知识尤其困难，分工过细往往导致过多不必要的移交（如详细设计和实现分离，造成大量设计信息丢失）。,5,任务切换,研究表明多任务工作会导致效率下降,20%-40%,（员工多头工作或杂事繁多）。,6,延迟,因任务或资源相互依赖而导致工作停滞（集成时被关键模块阻塞，等待测试环境就绪）。,7,缺陷,解决缺陷活动本身就是浪费，而且缺陷越遗留到后端浪费越大。,聚焦客户价值，标识和消除软件开发中的浪费,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 Master,Team,完整团队实践,团队,用户故事,结对编程,TDD,（测试驱动开发）,持续集成,Anatomy,系统解剖,工作件,敏捷软件开发是以短周期迭代为核心，包含团队、工作件、管理和技术优秀实践的集合,迭代开发,Page,34,敏捷软件开发典型场景,PO,和开发团队对产品业务目标形成共识,PO,建立和维护产品需求列表（需求会不断新增和改变）,并进行优先级排序,PO,每轮迭代前，,Review,需求列表，并筛选高优先级需求进入本轮迭代开发,开发团队细化本轮迭代需求，并按照需求的优先级，依次在本轮迭代完成,开发团队每日站立会议、特性开发、持续集成，使开发进度真正透明,PO,对每轮迭代（,2,4,周）交付的可工作软件进行现场验收和反馈,回到第,3,步，开始下一轮迭代,迭,代,每日工作,站立,会议,特性开发,特性测试,持续集成,交付,可以工作,的软件,迭代计划,回顾,确定一个迭代,的工作内容,产品和利益相关人,、,Page,35,什么是迭代式开发,迭代开发将整个软件生命周期分成多个小的迭代（一般,2-4,周），每一次迭代都由需求分析、设计、实现和测试在内的多个活动组成，,每一次迭代都可以生成一个稳定和被验证过的软件版本。,迭代式开发的好处,通过将高技术风险的需求在早期迭代里实现，有助于尽早暴露问题和及时消除风险,通过提供功能渐增的产品，,持续,从客户获得反馈，根据反馈及时调整，使最终产品更加符合客户的需要,通过小批量减少排队，提供更灵活、快速的交付能力,平滑人力资源的使用，避免出现瓶颈,迭代式开发的关键要点,每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。,每次迭代要邀请用户代表（外部或内部）验收，提供需求是否满足的反馈,迭代推荐采用固定的周期（,2-4,周），迭代内工作不能完成，应当缩减交付范围而不是延长周期,敏捷软件开发核心,迭代开发,迭代,1,迭代,2,迭代,3,反馈,反馈,迭代开发是有节奏地小步快跑，但建立在坚实的质量基础上,Page,36,敏捷,团队,包括,3个核心角色,:,PO,(,Product Owner),、,Scrum Master,(Scrum,教练,),和,Team,(,开发产品,),敏捷团队的三个核心角色,Marketing,用户,用服,管理,.etc,利益相关人,SM,SM,SM,SM,：,Scrum Master,PO,：,Product Owner,Page,37,敏捷团队的角色职责,角色名称,角色定义,角色职责,注意事项,Product Owner,（产品负责人）,确保,Team,做正确的事,代表利益相关人（如用户、,Marketing,、用服、管理者等），对产品投资回报负责,确定产品发布计划,定义产品需求并确定优先级,验收迭代结果，并根据验收结果和需求变化刷新需求清单和优先级,除了客户需求之外，内部任务如重构、持续集成环境搭建等也由,PO,纳入统一管理,Scrum Master,（,Scrum,教练）,确保,Team,正确地做事,辅导团队正确应用敏捷实践,引导团队建立并遵守规则,保护团队不受打扰,推动解决团队遇到的障碍,激励团队,不命令和控制,Team,Team,（开发团队）,负责产品需求实现,负责估计工作量并根据自身能力找出最佳方案去完成任务且保证交付质量,向,PO,和利益相关人演示工作成果（可运行的软件）,团队自我管理、持续改进,一般由,5-9,名跨功能领域人员组成,坐在一起工作,有共同的目标，共担责任,团队成员严格遵守团队规则,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,作为网络规划人员