1获取资料请关注微信公众号:365学库华为敏捷软件开发•PSST质量与成本管理部/系统工程部2获取资料请关注微信公众号:365学库Page2关于管理者和软件开发相关人员掌握敏捷知识的要求为落实敏捷软件开发的顺利推行,使广大软件开发管理者和开发人员深刻领会敏捷核心理念,熟练掌握敏捷实践方法,从而达到增强应对需求变化的能力、提高产品质量、提升开发效率和缩短交付周期等方面的目标。为此,特提出如下要求:1.PM及以上管理者要深刻领会敏捷核心理念、理解敏捷推行策略、了解各种敏捷实践。2.软件开发相关人员(含PL、软件开发人员、软件测试人员、软件架构人员、系统分析人员、与软件相关的资料人员和研发质量人员)要深刻理解敏捷理念、掌握敏捷实践、了解敏捷推行策略。通过敏捷相关知识的考试是软件开发相关人员任职资格的基本要求。3.考试试题分为管理者版本和员工版本,分别针对管理者和员工应知应会的知识进行考试。4.敏捷学习参考材料包括:《华为敏捷开发解读》及相关附件。3获取资料请关注微信公众号:365学库目录敏捷概述正确理解敏捷敏捷开发实施策略敏捷案例4获取资料请关注微信公众号:365学库Page4业界敏捷浪潮ISO9000(09版)标准将在原来八大原则的基础上新增敏捷原则2000年美国军方软件开发标准(DOD5000.2)推荐迭代为软件开发优选模式世界影响最大的美国波多里奇国家质量奖将敏捷作为核心的十一大原则之一5获取资料请关注微信公众号:365学库Page5软件作坊软件过程控制重型过程2001~今敏捷正在流行软件规模小,以作坊式开发为主;硬件飞速发展,软件规模和复杂度激增,引发软件危机;引入成熟生产制造管理方法,以“过程为中心”分阶段来控制软件开发(瀑布模型),一定程度上缓解了软件危机;软件失败的经验促使过程被不断增加约束和限制,软件开发过程日益“重型化”,开发效率降低、响应速度变慢;随着信息时代到来,需求变化更快,交付周期成为企业核心竞争力,轻量级的,更能适应变化的敏捷软件开发方法被普遍认可并迅速流行。软件危机20世纪60年代80年代90年代软件开发顺应时代变化,从重型过程转向轻量型敏捷70年代敏捷诞生的历史背景6获取资料请关注微信公众号:365学库Page6敏捷宣言揭示更好的软件开发方法敏捷宣言(2001年)是敏捷起源的基础,由上述4个简单的价值观组成,敏捷宣言的签署推动了敏捷运动敏捷宣言本质是揭示一种更好的软件开发方式,启迪人们重新思考软件开发中的价值和如何更好的工作敏捷宣言7获取资料请关注微信公众号:365学库Page7•软件更像一个活着的植物,软件开发是自底向上逐步有序的生长过程,类似于植物自然生长•敏捷开发遵循软件客观规律,不断的进行迭代增量开发,最终交付符合客户价值的产品传统开发敏捷开发敏捷更符合软件开发规律8获取资料请关注微信公众号:365学库Page8敏捷对生产率、质量、满意度、成本有明显改进82%的项目生产率有提高78%的项目质量有提高78%的项目客户满意度有提高37%的项目成本有降低*以上数据来自DDJ2008由ScottAmbler发起的网上调查结果9获取资料请关注微信公众号:365学库目录敏捷概述正确理解敏捷统一敏捷认识敏捷理念解读敏捷实践解读敏捷开发实施策略敏捷案例10获取资料请关注微信公众号:365学库Page10对敏捷的常见误解误解一:敏捷开发意味着可以不需要文档、设计和计划误解二:敏捷只是一些优秀实践,或者是优秀实践的结合误解三:敏捷只适用于小项目开发误解四:敏捷只会对研发产生改变误解五:管理者不需要亲自了解敏捷,只需要管理上支持就可以了误解六:引入敏捷只需要按照既定的步骤去做就可以了误解七:敏捷是CMM的替代品,是另一种流程误解八:敏捷只注重特性的快速交付,在敏捷下架构不重要了11获取资料请关注微信公众号:365学库Page11统一认识:敏捷=理念+优秀实践+具体应用理念(敏捷核心思想)敏捷包括3个层次优秀实践(敏捷的经验积累)具体应用(能够结合自身灵活应用才是真正敏捷)理念优秀实践具体应用12获取资料请关注微信公众号:365学库Page12理念:聚焦客户价值(Value),消除浪费软件业:45%的软件特性客户没有使用Source:StandishGroup来自5万个软件开发项目的调查Source:中国电信总工韦乐平在《华为公司工程与技术大会》上的讲话Source:《如何提升软件开发效率》08年统计电信业:“电信级”带来的浪费“价值”在“敏捷宣言”中的体现产品商业成功为目标,聚焦客户价值、围绕价值流消除浪费研发版本废弃特性07.1-08.6年某产品线所有产品中重要特性无应用的比例达22%(需求变更和分析不足占63%)重要特性无应用原因占比需求分析不全面不深入,25%大T需求变更,38%过渡技术,但一线强烈要求,4%竞标特性,8%方案缺陷客户无法实施,25%个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划13获取资料请关注微信公众号:365学库Page13理念:激发团队(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.7614获取资料请关注微信公众号:365学库Page14理念:不断调整以适应(Adapting)变化麦当劳是简单可预测生产过程《人月神话》:软件开发是人类最复杂工作之一,软件具有四个属性:复杂性、一致性、可变性和不可见性。软件开发是不可重复、探索性的、演进的,适应性过程。随软件规模增长,需求变化呈非线性增长软件开发是复杂不可预测的经验控制过程“适应变化”在“敏捷宣言”中的体现不断的根据经验调整,最终交付达到业务目标的产品软件开发规律再审视个体和交互胜过过程和工具可以工作的软件胜过面面俱到的文档客户合作胜过合同谈判响应变化胜过遵循计划15获取资料请关注微信公众号:365学库Page15优秀实践:业界敏捷优秀实践概览结对编程测试驱动开发客户参与验收计划游戏代码集体所有每日站立会议产品backlog(带优先级的需求清单)燃烧图迭代计划会议回顾会议ScrumMasterProductOwnerAnatomy(系统解剖)OneTrackSystemakut(缺陷管理和决策)重构完整团队稳定开发节奏Lagomising(需求决策)隐喻电信业偏重大规模产品实践、Scrum偏重项目管理,XP偏重编程实践电信业ScrumXP持续集成迭代交付16获取资料请关注微信公众号:365学库Page16具体应用:因地制宜选择适合的敏捷实践团队在透彻理解敏捷理念的基础上,可以灵活选择最适合自己的实践,避免教条化开发团队一站立会议排序的工作列表持续集成持续集成重构持续集成结对编程迭代开发++迭代开发+++++…+…+…开发团队三敏捷理念开发团队二敏捷理念敏捷理念17获取资料请关注微信公众号:365学库Page17敏捷转型是系统性工程敏捷转型7个方面优先级Source:CutterAgileTransformation(JimHighsmith大师)敏捷转型是系统工程,覆盖7个方面:实践、绩效考核、组织、过程、文化、管控、技术和业务对齐敏捷在敏捷转型不同阶段,敏捷转型框架的7个方面引入的优先级不一样,初期以实践为主Wave3(企业级)Wave2(产品级)Wave1(项目级)2121334Stage522Alignment1112Culture13Governance22Performance212Process1122Organization3211PracticesStage4Stage3Stage2Stage1Numbersrepresenttypicalrelativeimportanceateachstage.实践绩效组织过程文化管控技术和业务对齐敏捷转型框架18获取资料请关注微信公众号:365学库目录敏捷概述正确理解敏捷统一认识敏捷敏捷理念解读敏捷实践解读敏捷开发实施策略敏捷案例19获取资料请关注微信公众号:365学库Page19深入理解敏捷理念深入理解“适应变化”认请“客户是逐步发现真正需求”小批量是快速交付的关键通过迭代计划不断调整以适应需求变化应持续保持良好的软件架构利用多层次反馈不断调整以逼近目标深入理解“激发团队”认清团队的基本事实敏捷方式下管理者的转变敏捷方式下团队成员的转变深入理解“聚焦客户价值”标识和消除软件开发中的浪费交付刚刚好的系统随时构建质量,不容忍缺陷及时消除技术债务,持续保持快速响应20获取资料请关注微信公众号:365学库Page20浪费类别浪费举例1部分完成的工作部分完成但没有最终落地的工作(没有转化成代码的设计文档;未及时合入的代码导致引发后续更多同步工作量)。2未应用特性开发完成但没有被客户应用的特性(交换机2000多个功能客户只用了1%)。3再次学习人员频繁流动导致经验不能积累,反复重新学习;在多个环节移交时,接收信息者也需要重新学习;拥有某领域的专家,但在开发过程中需要此领域经验时,他却没参与,而是团队重新摸索。4移交知识信息的传递总是伴随信息丢失,隐形知识尤其困难,分工过细往往导致过多不必要的移交(如详细设计和实现分离,造成大量设计信息丢失)。5任务切换研究表明多任务工作会导致效率下降20%-40%(员工多头工作或杂事繁多)。6延迟因任务或资源相互依赖而导致工作停滞(集成时被关键模块阻塞,等待测试环境就绪)。7缺陷解决缺陷活动本身就是浪费,而且缺陷越遗留到后端浪费越大。聚焦客户价值,标识和消除软件开发中的浪费Source:《精益软件开发》21获取资料请关注微信公众号:365学库Page21•当质量、进度、资源冲突时,能改变的只有项目范围,即选择“交付刚刚好的系统”–产品交付前,客户往往期望多而全的功能,产品交付后,客户把稳定的质量放在首位,尤其在电信领域,客户对产品质量要求是Alwayswork,不是Sometimes。–与其为了满足多而全的功能导致交付延迟,质量不稳定,不如按时交付刚刚好的系统,保证其高质量运行。–交付刚刚好的系统,基于对客户需求的深入理解,并花时间了解细节,简化(simplify)需求(降低复杂性)而不是简单地拒绝需求(delete)。–做到“交付刚刚好的系统”,同时需要管理者有足够的勇气和果断决策聚焦客户价值,交付刚刚好的系统在项目明显超负荷时,管理者简单地期望靠团队workharder来解决,最终导致:质量下降项目延期客户不满意团队疲劳埋下长期隐患22获取资料请关注微信公众号:365学库Page22缺陷遗留带来高额成本:对单独质量保证活动(如后端测试)的依赖,容易形成缺陷可以遗留到下个阶段的心理,导致缺陷发现成本升高(系统测试阶段缺陷定位和解决成本是开发阶段的10倍)•例1:E公司开发阶段和测试阶段发现缺陷的比例为7:3,而我司大量缺陷集中在后端发现,带来高额成本。•例2:我司顾问指出:华为测试和开发“相