作者：王先科、田野、王锁、刘双、马越、刘思琪
摘要：本文总结了近4年以来部门实施敏捷转型的实践及经验教训，从5个方面进行了阐述：
文化建设下好先手棋
持续敏捷实践祭出连环招
沉淀实践指引把牢定盘星
效能度量定准风向标
洞察分析点亮启明灯
“敏捷就是快速应对变化，解决不确定性问题和维护复杂产品”，没错，这是敏捷最核心的价值体现。在多部门协作、多业务类型等复杂场景下，如何落地敏捷理念、思维、框架、方法、工具和实践，实现组织敏捷、技术敏捷、项目敏捷，进而实现业务敏捷，一直是我们追求的目标。近4年来，市场与平台运营中心-平台研发部基于Scrum框架进行了很多的尝试和实践，有成功的经验，也有失败的教训。本文分别从敏捷文化建设、持续敏捷优化、实践指引、效能度量及洞察分析五个方面，分别介绍我们敏捷转型的一些实践：
（1）敏捷文化建设：欲修其身,先正其心，欲正其心,先诚其意。通过培训、分享、建立敏捷社区、内外部交流、内部考试认证等方式，营造敏捷文化氛围，纠正误区，提升认识，增强信心。
（2）持续优化敏捷实践：道阻且长，行则将至，行而不辍，未来可期。敏捷模式落地，离不开持续的实践及过程中的不断优化，需遵循由简入繁，由易到难的节奏，先僵化再固化最后优化。先从最基础的敏捷实践以及需求流转协作工具开始，在实践的过程中逐步理解敏捷的思维和方法，并结合部门特点，不断优化，引入更高阶的实践以及更高效的工具，并与DevOps的流程和机制结合起来，形成敏捷DevOps流程机制。
（3）实践指引：行之愈笃，则知之愈明，知之愈明，则行之愈笃。实践与认知相辅相成，敏捷转型过程中需要不断总结实践过程中好的经验，标准的、通用的可以沉淀为流程规范，无法作为标准规范的，可以以最佳实践的方式指导后续的实践活动。
（4）效能度量：悬衡而知平,设规而知圆。有效的度量可以及时发现问题，并辅助管理。通过对全链路效能数据的解读和洞察分析，指导和驱动效能改进。
（5）洞察分析：见出以知入，观往以知来。敏捷转型过程中，不能被表面现象所蒙蔽，若要透过现象直达本质，需要对过程、现象以及结果进行深刻的洞察分析，以指导改进和提升。
平台研发部既直接承接业务需求，服务于金融产品层和运营团队，又有很多中台、平台类型的系统，如营销权益、活动平台、mPaaS等，并且也同时是京东金融APP的研发团队，负责APP的原生、H5研发及发版管理，业务系统多，类型复杂，模式多样，研发团队达到几百人，在如此复杂环境下，如何有效协同各方，持续提升研发敏捷性及效能，是PMO团队首要考虑的问题。落地敏捷研发模式是其中一种非常重要的手段和方式。从2018年成立中台，到现在的平台研发部，虽历经多次组织架构变动，但我们一直在践行敏捷研发和敏捷项目管理。在最初的阶段，大家对敏捷的认知存在诸多误区。
误区一：敏捷就是小瀑布
把敏捷迭代当成小的瀑布流，仍然执行着瀑布项目模式。当时很多团队的做法是，每一个迭代做的计划只是一个用户故事的一部分，并不能完全交付使用，产品无法拆解最小MVP版本，产研测认为这个迭代做一个接口，下一个迭代再做页面，那么两个迭代就合成一个功能去做测试，虽然分成迭代去做，但并没有在一个迭代里交付一个完整闭环的可用功能。
误区二：迭代就是敏捷
团队经常认为，固定了周期即是迭代，即是敏捷，经常把产品的实现过程流程化，这个迭代做研发，下个迭代做测试，这并不是敏捷，这只是把瀑布式开发阶段化的表现了一下。
误区三：敏捷无需计划性
认为敏捷就是想到哪里做到那里，不需要计划性。计划性有多重含义，第一，它可以明确短时间内的目标、所要做的任务及方案、达成可交付的产品。第二，可以做验收的标准依据 ，也就是计划内容可以用作目标追寻，方向一致。第三，计划性可以不断检验历史积累的经验是否可用，特别是在评估工作量投入方面、任务统筹方面，不断的检验可以更精准的评估产研的投入。其实敏捷与计划性不冲突，计划对任何敏捷开发项目都是不可缺少的组成部分。
误区四：回顾会无价值
经常排斥回顾会和复盘会，认为这类会议是无效时间投入，有这样的时间还不如多写代码。敏捷开发非常重要的点就是，不断提升团队的作战能力，不总结回顾如何提升产能，产生这样的误区，有两方面原因，第一，回顾会的方式方法不得当，方式方法里面也包含回顾会中是否真正的发现可提升的点。第二，回顾会的改进结论没有真正的落地执行。
误区五：敏捷不需要文档
敏捷宣言的第二条“可工作的软件胜于详尽的文档”，很多人理解为敏捷开发不重视文档，甚至以此为借口逃避写文档。但敏捷强调“价值”、“快速交付价值”、“为客户提供价值”的理念，研发团队要把精力放在能够为客户带来价值的地方，避免在不产生价值或者ROI低的任务上浪费时间。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多团队协作环境下，文档的重要性和必要性不言而喻。
误区六：敏捷就是单纯追求速度
敏捷的快并非研发的快，敏捷更应该被团队记住的是灵活，通过敏捷框架，我们可以应对瞬息变化的环境，而不是我们用了一个框架，原来写2000行代码的程序员就能成为写10000行代码的软件工程师了。另外，通过敏捷，开发效率确实可以提升，但这是建立在各种工具、流程、体系、基本功训练上的。
PMO是一个很特殊的部门，不同行业、不同公司对PMO的定位、期望和实际承担的职责不尽相同，PMO需根据部门特点和领导期望制定适合当前环境的部门定位。我们对自己的定位是聚焦三大方向，利用敏捷的理念和方法，协同各角色持续、顺畅、高质量交付有效价值。
•价值交付方向：通过专业的、全链路项目管理，按时保质交付业务价值，提升业务满意度，通过项目实现组织战略。
•组织效能方向：通过敏捷研发模式落地及多种提效举措，提升研发效率、质量、能力和效果。
•洞察分析方向：通过对效能数据、资源投入、项目收益、敏捷成熟度以及团队协同过程的洞察分析，为部门提供决策依据。
为了支撑以上定位和目标，我们把PMO划分成四大职能，分别为敏捷项目管理中心、效能中心、卓越中心及治理中心。敏捷项目管理中心，通过全生命周期的项目管理，提升战略落地的确定性及效率，交付有效价值；效能中心，通过从组织、技术、工具、项目层面推动效能提升，提升交付的效率、质量、能力、效果以及安全；卓越中心，通过技术文化氛围和技术能力建设，提升组织的可持续发展能力；治理中心沉淀知识、经验、教训、能力、流程规范、最佳实践等组织过程资产，提升团队能力。其中，这四项职责中最核心的支撑力量就是要实现组织敏捷、技术敏捷和项目敏捷，进而实现业务敏捷。
在项目管理全景大图中，敏捷有着至关重要的作用和地位，没有项目和需求的敏捷交付，就谈不上组织战略和业务价值的实现，组织效能也不会持续提升。敏捷研发的流程、机制以及敏捷DevOps工具链建设，需要持续建设和完善，并通过精细化管理和持续改善行动驱动团队敏捷成熟度提升，多管齐下，多措并举，持之以恒方能见到成效。下面将分章节介绍平台研发部如何逐步实现敏捷实践落地和敏捷转型的。
敏捷转型，文化先行。如何从根本解决这些问题，转变团队观念，让更多人接受敏捷并感受到敏捷带来的好处，是我们面临的第一个课题。我们通过以下几个步骤，逐步建设敏捷文化：
•铺垫：最初阶段，PMO团队分析当前项目交付过程中面临的困境，结合内外部实际案例，证明迫切需要引入敏捷研发模式以满足业务快速发展的需要，并获得领导支持。
•洗脑：导入阶段，进行大量的洗脑式培训和宣讲，加强对敏捷知识、原理和基础实践的灌输，让大家接受敏捷，启动敏捷的实践。
•培训：发展阶段，团队Scrum Master一般由项目经理兼任，结合实践过程中反馈的问题，引入外部的敏捷教练和项目管理专家进行分享交流，学习外部优秀的实践，提升项目经理作为Scrum Master角色的能力。
•赋能：全面应用阶段，PMO人力有限，无论是作为项目经理还是作为ScrumMaster，都无法覆盖到所有的项目和需求，以往我们的做法是PMO带一个项目团队，待团队逐步掌握敏捷方法，再去带另外一个，或者同时带领多个团队进行敏捷管理和实践。这样做法存在的问题就是，头疼医头脚疼医脚，无法从根本提升敏捷能力。现在我们的做法是，进行敏捷赋能，由PMO团队规划敏捷培训系列课程，团队中敏捷积极分子参加培训课程，名为”共振计划“，就是将更多的成员培养成Scrum Master，同时加强对敏捷知识、原理和基础实践的灌输，让敏捷变成所有人的工作价值观，提升项目团队自组织、自敏捷能力，这也是作为敏捷文化建设的重要环节。
PMO团队内部进行头脑风暴，梳理作为Scrum Master和敏捷团队成员的痛点和建议的解决方案；其次，我们在项目团队内部寻找多名研发和测试的敏捷积极分子及团队leader，进行了深度访谈，了解他们的困惑、对敏捷的认知以及面临的痛点；然后，我们根据访谈结果，制定调研问卷，在大部门内部进行更广泛的调研。
通过以上三个方面的工作，收集到大量敏捷实施与落地方面的反馈，为我们有针对性提升和优化提供了基础。举个例子，经过多番讨论和调研，发现产研测同学对敏捷只是了解概念，并没有真正的掌握核心价值及执行过程的要点，甚至很多动作跑偏，违背了敏捷的初衷。因此，我们决定大力提升团队成员敏捷项目管理知识，提升敏捷文化，我们举办了名为“共振计划”培训课程，针对非项目经理角色进行敏捷研发和敏捷项目管理系列课程，在项目经理和非项目经理之间产生”同频共振“，使非PMO的项目成员具备PM及SM能力，从而提升整个团队的自敏捷、自组织能力。
”共振计划“是一项项目管理&敏捷管理赋能计划，计划通过针对非项目经理角色（产品、开发、测试）进行项目管理+敏捷管理赋能认证。课程体系设计别从基础能力到专项能力进行分享，每个章节的课程都运用实践作为理论支持，而且每个实践场景都是我们的实际项目经历，这让大家对整个知识体系的掌握更加清晰。下面给大家分享一下两期课程的设置及上课情况，第一期注重加强项目管理能力提升和敏捷基础理念和基本技能辅导，整体分为培训课程+导师制陪伴式项目实践+考试认证三部分，第二期重点加强敏捷高阶能力提升和Scrum Master培养，致力于提升整个组织的自组织、自敏捷能力，整体分为培训课程+各角色分享+线下实践+知识竞赛四部分。
目前已经举办两期的活动，两期学员均在100人以上，经反馈满意度达90%以上，目前很多团队已经可以实现自运转能力，这样的活动我们也将持续开展，后续计划走出平台研发部，引入集团内外部优秀敏捷实践以及更高阶的敏捷技能、方法和工具。
敏捷转型不能闭门造车，别人的实践经验对我们来说是非常好的借鉴。在敏捷转型过程中，通过组织与PMI的分享、与行业大厂的经验交流、引入外部优秀敏捷为组织赋能、走出去参加行业大会、加入敏捷社区等方式，时刻与时代要求与行业先进水平保持同频。另外，通过“共振计划”敏捷赋能培训，我们也选拔并培养了一大批既对敏捷感兴趣，又具有一线实践经验的研发、测试及产品同学，目前我们正在计划通过持续的运营，打造内部的敏捷社区，打造更广泛的影响力。
持之以恒方能行稳致远。谈到敏捷，大多数人认为就是两周迭代、站会、回顾会等。但是在实际上远远不止这些内容。还记得之前在转型的初期，对于相关的实践很难理解，哪怕是在参加了ACP、CSM等培训，或者是经过教练传帮带后也只学其形，未达其意，甚至可能对敏捷的理念产生了质疑，同样对于团队来说，初期非常痛苦，大家根本不知道要做什么，为什么要这么做。但是在经过不断的尝试和实践之后，敏捷为团队带来了翻天覆地的变化，研发效率提升、项目风险管控、应对业务频繁变化等都能够使用最小成本带来更大收益。因此对于敏捷或者Scrum框架来说，我们不仅要学习它的方式和理念，更重要的是进行实践并不断改进，寻找最适合当前环境的落地方式，走出敏捷转型的困境。
回想几年之前，业务处于高速发展期，部门内部系统众多，各小组无统一规范和管理模式，各角色协同配合难度大，需求交付速度慢，变更成本高。以APP发版为例，最初是3周一个开发测试班车，2周后再上线，项目组无法应对产品源源不断的需求，版本上线内容可预测性差，封版集成耗时长，手工脚本打包错误率高。
在此背景下，我们决定进行更加彻底的敏捷转型，采用Scrum框架进行敏捷试点，并引入敏捷DevOps理念，将工具链层打通，选定的是场景适合、团队意愿强烈的移动平台研发部APP发版项目团队，经过近两年的实践及不断优化，京东金融APP发版周期从原来的至少4周变为现在的2周，迭代周期由原来的至少5周变为现在的3周，整体缩短40%，需求按计划交付率提升约10%，版本变更下降10% ，业务满意度不断提升。下面将以京东金融APP如何逐步实现敏捷转型并带动部门整体敏捷落地为例，介绍敏捷是如何在我们部门落地生根的。
首先确立敏捷转型的目标，即实现更快速、更可靠发版，发版节奏和版本容量对齐业界主流APP。确定转型目标后，我们开始着手进行相应的变革动作，首先是要把小瀑布制研发模式转变为基于Scrum框架的模式，同时，确定了敏捷转型小组及职责：
• 组长：二级部门管理者。
• 工具负责人：负责打通行云、PMP、JCI等工具。
• 业务项目经理/产品经理接口人：负责提供产品路线图。
• APP敏捷项目经理：负责敏捷方法落地，推进组织敏捷改革，解决部门间、各角色间协同问题。
• 敏捷教练：负责指导团队敏捷转型，解决流程卡点。
• 开发团队组长：负责承担团队Scrum Master，带领团队落地敏捷各类活动。
项目组制定转型规划，1.0阶段目标是实现4周发版（2周开发测试，2周打包、回归、灰度和发布），主要分为5步：
•准备： 敏捷教练及项目经理充分调研，收集问题和痛点，制定解决方案和详细计划，并向leader汇报，获得充分认可与支持。
•启动： 组织启动会，邀请产研leader、各关键角色参加APP的敏捷转型启动会，拉齐认知，共识目标，统一节奏。
•培训： 对涉及到APP原生的所有一线产品经理、开发以及测试人员进行全员培训。
•组织： 由项目经理或Scrum Master将围绕各业务线的APP原生相关的产品经理、开发、测试，组建成7个敏捷小团队，团队内进行敏捷协作，并由敏捷教练作为顾问。
•工具： 推进工具建设和使用，包括代码发布、分支管理、需求管理、质量管理、迭代管理等。
•落地： 首先保持3周开发测试周期，强化版本目标、计划以及承诺，所有需求录入行云。3个迭代之后，正式过渡到2周开发加测试的迭代周期。
（1）落地过程中，传递新的理念，赋予各个角色新的职责。
（2）制定多种看板，例如在1.0阶段，5周的发版周期【3周开发周期（开发+测试）+11天（集成+打包+回归+灰度+上线）】，另外依据发版周期指导敏捷各类活动，如站会、计划会、迭代演示会等。
（3）根据发版日历，按固定节奏开发测试，在上线窗口期上线业务所需内容。
（4）制定规模化敏捷物理看板（引用SAFe框架理念，红色线条代表故事间的依赖关系）。
（5）引入敏捷DevOps概念，建设DevOps工具。
通过以上实践以及工具的引入，京东金融APP迭代节奏明显加快，从5周班车制变为4周发布火车制：
经过1年的磨合和适应，团队开始逐渐摸索出敏捷的精髓，不但大大提高了信心，同时又能更好的拥抱业务变化，以更小成本应对需求变更。在此基础上，迎来了2.0阶段的发展，此时大家开始考虑如何在原有的敏捷框架下，探索出适合组织的新方法和新实践。敏捷交付的内涵不仅仅是交付速度快，而且要有持续性，同时还需要有稳定的交付质量。敏捷交付2.0的目标设为4项：
•业务目标一：协同一致
•业务目标二：构建质量
•业务目标三：加速业务需求上市时间
•业务目标四：交付业务价值
做法依旧持续执行4周发布火车制度，但持续完善细节并优化流程机制，提高研发效率和质量：
•架构解耦，组件化；
•2周迭代内持续集成；
•细化DoR &DoD；
•强化敏捷PRD ，用户故事&AC；
•强化迭代内变更管理；
•fmPaaS移动研发平台；
•自动化单元测试；
•IDE代码评审插件；
•质量门户建设；
•研发效能度量数据；
根据团队交付形态，变更了版本节奏，升级了迭代日历。
看板也进行了简化。
敏捷机制更加精细化，强调需求拆细、条目化，并按节奏开发，按需发布，同时不断反馈和改进。
经过APP团队不断的迭代尝试，部门将目光放到所有团队，开始扩大战果。在这个过程中，不是简单的完全照搬金融APP的实践，而是在敏捷的思维和Scrum的框架下，结合各团队自己的特点，在实践的基础上，不断修正和优化，同时对敏捷团队的管理和要求也更加精细化。在金融APP敏捷转型成功的鼓舞下，各团队都开始进行敏捷转型，大部分都是基于Scrum框架，并根据各自项目和部门特点持续优化和完善，形成适合自己特点的敏捷实践，在迭代节奏上，绝大部分团队都遵循双周迭代的节奏。
各个团队均强调版本日历的重要性，团队严格遵守迭代日历的约定，形成固定节奏。
（1）通过版本日历可以清楚的知道业务何时进行需求沟通，需求优先级何时进行确认，产品PO何时进行PRD设计，团队何时进行需求评审，以及团队承诺何时交付等。
（2）通过版本日历的约束，纠正了各业务随时随地，杂乱无章的需求沟通，同时结合着《需求准入规范》，设定以价值为导向的原则，让团队做有意义的事情。
（3）部分团队为应对需求插入采用需求置换原则，团队每个迭代的总工时固定的，因此约定业务需求插入执行需求置换，并且只能置换掉并未启动开发的需求，以求降低影响。
（4）团队内部的迭代原则：
•固定评审时间：如每个迭代第二周星期三进行需求评审，产品输出优先级。
•固定排期时间：如研发在周五输出研发排期，测试在次周周一下班前输出排期。
•例外情况处理：对于存有待办的需求可适当延期给排期，但要与业务方同步；研发排期如果开始时间超过了迭代第二周的周三，则无需排期。
回顾会议(retrospective meeting)作为Scrum最有价值的会议之一，在敏捷迭代实践中占据非常重要的位置。平台研发部重视回顾会的作用，关于回顾会，我们遵循以下5个原则：
•对事不对人： 回顾会议不是批评和自我批评，而是识别团队的改进措施；不是追究责任，而是要考虑如何做的更好，如何让我们持续进步。考虑如何充分利用团队的力量来预防错误、及时发现潜在问题。
•人人平等，全员参与： 回顾会议不能一言堂，不能被少数人左右，团队成员是平等的。每个人都应该充分分享自己的观点，在回顾会议上希望是给所有人分享尽可能全面的、不同视角的信息。
•可视化团队绩效： 在回顾会议上可以采用燃尽图、燃起图、折线图等形式展示团队的绩效，例如本次迭代与上次迭代相比，交付速度是否提升了？截止到本次迭代，我们累计实现了哪些改进措施？另外，回顾我们已经落地的措施，可以建立起团队成员对回顾会议价值的认可。
•改进措施要落地： 回顾会议一定要输出下个迭代要落地的改进措施是什么？这样才能不断提升。不要试图解决在回顾会议上识别出的所有的题，要聚焦短板，重点突破，一次识别出1-3项改进措施即可。
•发现优点，建立信心： 在回顾会议上不但要发现改进点，也要发现优点，发现进步和受大家欢迎的成员和做法，让大家建立起对团队、对产品的信心。
通过正确地组织回顾会，让团队认识到问题所在，清楚的知道自己的优劣势，从而进行持续改善。
回顾会作为Scrum模式固定的实践，在每个迭代固定执行，除此之外，我们在近两年，也同时加强了项目复盘，复盘会也成为专项项目和迭代类项目不可或缺的环节。与回顾会不同的是，复盘会一般按月度或季度组织（事故复盘随时进行），除去敏捷团队成员之外，还会有更多的业务、运营及部分leader参加，且比回顾会更有宏观性和整体性。各角色以回顾目标-确认解决-分析影响因素-总结经验教训这样的步骤，针对业务目标、项目收益、资源投入、经验教训、下阶段改进目标等内容进行讨论和反思，拉齐认知，对齐目标。组织好复盘，最重要的不是复盘会议，而是会议之前的准备工作，如下图所示：
通过复盘会的形式，大家停下来回头看，目的是更快的向前走。目前，平台研发部各项目团队及敏捷团队均建立了定期的复盘机制。
经过2年的不断尝试，团队不仅加深了敏捷理论，同时也落地了更加精细化的管理方法：
•DevOps敏捷成熟度评估：定期进行团队敏捷成熟度评估，主要是从3个角色，5大能力的维度进行评估，并总结经验持续改进（详见4.2）。
•团队责任心培养：从分配任务升级为自认领，敏捷所提倡的也是团队能够自认领，每一个人都是任务的Owner。
•需求拆解指引：规范大需求拆解，使需求具备业务最小MVP版本交付的状态（详见4.4）。
•任务拆解原则：充分使用行云，在任务拆解时，遵守以每条任务8H最佳，16H其次，最大不超过24H的原则。
京东金融APP落地敏捷研发模式的过程中，移动平台研发部研发和测试团队给与了项目组坚定的支持和充分的试错空间，在确保APP安全合规发版的前提下，实现了快速、稳定以及顺畅的需求交付，体现了敏捷带来的价值。通过金融APP项目团队的成功的实践，提升了大家的信心，进而带动整个部门敏捷研发模式顺利落地，并通过精细化管理和持续改善行动驱动团队敏捷成熟度的不断提升，成为快速实现业务价值及支持业务低成本快速试错的基础和保障。
在敏捷转型过程中，不能完全照搬理论，需要结合当前客观环境，并不断总结最适合自身的实践，很多实践未必是标准的流程规范，但有时可能比流程规范更能指导实践。流程规范一般规定了必须要做的事情，或者不能做的事情，带有强制性，而实践指引却是告诉你以何种方式做大概率是最优的，带有建议的性质，流程规范+实践指引共同构成了敏捷落地的基础保障。平台研发部在敏捷实践过程中，总结了一些有用的实践指引，给到项目经理和各研发团队Scrum Master，以更好的落地敏捷研发模式。
PMO团队不断积累和总结经验，形成项目管理、敏捷管理的SOP流程，并制定了标准化文档以及对应的裁剪指引，作为项目管理的统一的、最基本的标准。项目管理SOP流程中我们把项目分为两类，第一类是：业务专项，即有明确的目标、时间节奏、资源投入及预期产出，一个或几个阶段就可以输出全部交付物，这类项目既可以按瀑布方式执行，也可以敏捷方式执行或部分模块用敏捷方式执行；第二类是产品迭代项目，此类项目一般在持续运营阶段，或者是探索型迭代产品，这类项目几乎都是在以敏捷迭代方式执行。对于这两种项目我们规定了标准动作及在实践过程中的裁剪指引，项目经理及Scrum Master在敏捷实践中依据团队的实际情况进行裁剪，以下是迭代类项目裁剪指引：
DevOps是文化理念、实践和工具的组合，用于促进软件开发过程中各角色之间的沟通、协作与整合，以提高组织持续交付高质量软件的能力。敏捷与 DevOps 之间的区别在于，敏捷专注于优化开发生命周期，而 DevOps 将开发和运维统一在 CI/CD 环境中，围绕非敏捷关注的实践而构建。敏捷和 DevOps 都旨在及时交付高质量的软件，当一起使用时，构成敏捷DevOps，结合敏捷思维、敏捷实践以及DevOps相关流程和工具，达到持续在最短周期内交付客户价值的目的，并且将研发流程与DevOps工具链整合，全链路提升交付效能。
平台研发部结合业界DevOps实践及部门特点，沉淀了敏捷DevOps在研发全生命周期各个阶段的活动，包括每个活动的主要内容、负责人、参与人、输入、输出、工具以及过程指导，用以指导各个角色在落地敏捷DevOps理念及流程时作为实践的参考。
从高效能团队维度，敏捷团队理解自己当前能力，自我确定提升目标、举措、计划，以此持续改善，我们制定了敏捷成熟度评估的实践指引，Scrum Master、PO、项目经理、敏捷教练及三级管理者针对敏捷成熟度从五个维度进行评价，分别为业务敏捷、产品管理、敏捷团队、迭代运作以及工程实践，每个维度又分为若干子项。敏捷团队定期自评，也可以定期或不定期邀请敏捷教练、管理者进行专家评估，确定当前处在成熟度的哪一个级别，成熟度级别共分五级：
•一级：有意识的（坐）
•二级：有实践的（爬）
•三级：熟练的（走）
•四级：量化可靠的（跑）
•五级：优化创新的（飞）
每次评估之后，根据各个子项的评价分数，以雷达图的形式进行呈现，并由团队进行洞察分析（详见6.2），由Scrum Master带领团队制定改进措施和计划，项目经理进行跟踪和推进，敏捷教练按需提供支持。
在精细化经营的大背景下，业务和产研都更加重视项目和需求的投入与产出比，需要进行体系化的收益管理，逐步实现业务需求收益的可评估、可量化、可衡量。通过统一项目收益管理的范围与机制，提升项目收益管理规范性，让产研资源聚焦于高产出业务。为此，我们制定了收益管理的实践指引。收益管理涉及的两类角色：
（1）需求方
需求负责人负责设定收益指标，即负责参照收益指标库制定合理的、可量化的、可验证的项目/需求收益指标并在交付项目后按要求反馈项目收益实现情况，在行云提交验证结果，并提供支撑材料。
（2）执行方（产研测）
•产品负责人：评估收益指标技术角度合理性，专项类的收益指标需经过C-3/C-2复核（参考立项流程，立项邮件涵盖收益指标）。
•项目经理：
专项项目-负责发起立项，组织立项材料编写；跟踪项目收益达成情况，提醒验收人及时完成业务验证，推动项目收益目标达成，组织评估收益合理性与可验证性。
迭代类项目-负责组织需求评审会，迭代开始前收益收集，跟踪收益达成情况，提醒验收人及时完成业务验证，推动需求收益目标达成，组织评估收益合理性与可验证性。
•团队成员：如实评估与填报工时。
专项项目按照整个项目的维度进行收益管理，迭代类项目按照单个需求的维度进行收益管理，我们对销售类指标（如直接效益类指标、用户类指标、页面类指标）要求是必须填写收益，效率提升类的高度建议有收益指标，对体验提升&系统技术类不做明确要求，如有可提供收益指标。迭代类项目收益管理流程如下：
专项类项目收益管理流程如下：
利用行云，实现全流程的线上化收益管理。
为进一步践行敏捷理念与研发模式，需要细化需求颗粒度，需求颗粒度足够细致，质量才能足够高，小批量、快速、频繁、高质量交付业务可用的需求是我们追求的目标，为此，我们结合实践总结形成了需求拆解实践指引。具体的做法是，首先通过识别+引导的方式，了解业务目标和运营计划，站在需求提出方的角度识别业务诉求，引导需求提出方说出业务诉求背后的目的/目标/意义，即识别出说的，引导出没说的，形成最原始的业务诉求，通过产品分析，形成产品需求，再进一步分解成可交付评审的功能点，最后才是我们常说的Story。需求拆解需满足以下几个原则：
•独立性：功能是独立实现的，低耦合的。
•可交付：功能是可以交付使用的或验证的，不是幻想的功能。
•可商讨：功能是有细节的，可以讨论更具体的内容。
•有价值：强调价值。
•可估计：主要强调每个Story可以估算工作量。
此外，需求拆解还有一个重要的原则，就是大小合适，从我们实践的经验来看，比较理想的情况是把需求拆分成多个用户故事（Story），可以在1~2周完成开发+测试+上线的颗粒度。但有些需求确实很大，从业务交付的角度来说，很难拆分，如果产品或研发人为把需求拆分为多个小需求，但这些小需求不是闭环的小功能，不能独立交付业务或者用户使用，这样的拆分有没有意义，有没有必要？我们的回答是：要分不同情况分别看。单独上线不能独立使用的功能，对业务来说好像没什么意义，并且可能会增加测试回归、研发上线的工作量，但也会带来其它收益：
•保持迭代的节奏，每两周内都有交付物（虽然该交付物未必真正可用），提升产研同学的信心。
•提高协同性。这种阶段性输出，方便需求提出方掌握研发进度和汇报进度，提升信任感。
•减少了变更的成本。若在此过程中业务需求有变更，这种阶段性输出物（或功能模块）由于已经被测试验证过，是可以继续复用的；另外一方面，需求提出方在试用阶段性输出物时，可以体验到部分功能或流程（虽然不完整，或者流程没有闭环），若发现有问题，可以提前变更，减少变更成本。
总结以上，这种需求的强制拆分在一定程度上也是有意义的。需求拆解实践指引提供了一种参考和视角，至于在真正的实践中需不需要强制拆分，产研可以根据实际情况进行评估和判断。
管理大师彼得.德鲁克说过：“没有度量就无法管理”。两年来，我们搭建并持续完善了适合团队特点的效能度量体系，经历了由简入繁、再基于实践过程进行化繁为简的过程，由关注数据到关注问题，由效能度量到效能提升的过程，并逐步实现了全民关注效能提升的技术文化氛围。
•从PMO组织项目管理工作层面来看，效能度量是一种全局监控的工具，通过度量为起点，通过度量数据反馈的问题和待改进点，提升组织效率、质量和能力。
•从单个敏捷团队来看，度量的数据结果可以提供相对直接和客观的团队进步成果，增加团队自我认同感和持续提升的动力。
•从Scrum框架来看，度量可以对团队的迭代回顾提供客观的数据帮助，并对调整提供有针对性的指向、以及对调整后结果进行有效性的评估。
对于刚开始启动效能度量的团队来说，管理角色看到指标总是很兴奋，全都想要、哪个都不想放弃。对于有这样的想法其实很正常，因为这毕竟是先进公司的优秀实践，但是如何选用合理的指标呢？可以试试从这个角度去评估：
•既行的敏捷管理和DevOps流程
•既有的线上化管理系统
•团队有共识的存在的问题
•当前组织内管理层的期望
下面，将从以上几个角度，举例说明具体的思路。
•既行的敏捷管理和DevOps流程：这一项既是一个评估考虑点，更是一个组织做度量的前提。组织/团队先要有一套运行相对成熟的流程机制，大家遵守同一套游戏规则，才有去度量的意义。说回来，怎么去结合当前运行的流程去选用度量指标，举个实际的例子，如果当下Scrum框架落地范围已经切实覆盖了产品经理角色（由于组织架构的原因，很多团队Scrum的落地都仅在研发测试团队），在交付效率方面，可以选用“产研交付周期”指标。相反如果产品经理角色表面上认可实行Scrum框架，但实际上内心和行为并不十分配合，这个阶段就不建议开始“产研交付周期”“需求分析周期”的度量，因为这些指标对于眼前的团队改进大概率起不到实际作用。
•既有的线上化管理系统：万事开头难，度量也一样。选好了适用的指标，发现当下用的管理工具/线上化系统并不完全支持，获取数据花费大量的人工成本。这种情况下，建议结合指标的必要性和获取数据的难易性再进行综合评估。对于团队自己努努力、动动手、费些时间的指标，建议坚持获取（也可以成为线上管理系统迭代优化的输入），对于强依赖外部团队而获取的指标，建议期初先放一放。
•团队有共识的存在的问题：这个很好理解，例如测试角色认为研发提测质量不好，那用数据说话，就去看一看代码bug相关的统计、例如千行代码bug率、reopen率等等。
•当前组织内管理层的期望：这个也很好理解，领导层的期望无非是“多、快、好、省”，但需要结合当下的问题和痛点，确定管理层最急切的期望。对于大多数互联网IT团队来说，第一期望通常是对业务侧的感受来说；快！那就笃定的选择：产研交付周期。
简单来说可以分为3个步骤：确定度量周期 → 分析解读度量报告 → 优化工作方法及基础设施
•选择适用的度量周期。度量周期的选择也需要结合迭代周期，一般选用2周迭代的团队，度量周期可以定为月度（注意，而不是2周）。度量周期和迭代节奏本身并没有强绑定的关系，度量周期太短，会导致数据局部性表现和影响的凸显，也无法有效反馈团队的成果（因为人并不是机器，不是简单的换个档就能立马加速）。任何改进都需要有一定的耐心、给与团队和决策的信任。
•进行度量报告的透明、与团队成员一起进行分析解读。注意这里的关键词是“一起”。分析并不是报告输出者一个人的事情，解读也不是脱离团队的空想。分析者应当给出团队直接的数据信息、环比的变化、带来负向变化的直接原因（例如某几个需求周期超长导致团队平均周期延长），将这些信息共享给团队，与当事人一起分析原因和后续改进计划或减缓措施。
•基于识别的改进点，通常逃不出这两个方向：流程/工作方法的改进、基础设施的改善。并不是所有的优化点都要真的一一去落地实现，需要考虑投入收益，长期计划和短期行动，尤其是基础设施方面，如果花很大力气去解决个例问题是不经济的。总而言之，凡事不走极端，需要综合全面的考虑。
基于以上的思路，平台研发部在效能度量方面持续实践，总结为“525研发效能度量实践”，概括来讲：
•五大度量指标群：交付效率、交付质量、交付能力、交付安全、交付效果。每一个度量指标群下包括多个具体的度量指标，选取最核心的指标，按照一定的权重和算法，组成整体的效能健康度模型。
•两级度量体系：C2级别的月度及年度效能度量报告、C3/C4级别的双周洞察分析会议。
•五个效能提升实践：单位化核心指标、进行洞察分析、设立提效官、提供分析思路框架、组织团队分享。
5.4.1 五大度量指标群
（1）核心度量指标
基于行业的实践以及与集团内BGBU兄弟部门的沟通交流，我们选取了以下几个核心的度量指标，分别从效率、质量、能力、效果以及安全五个方面，对产研效能进行量化评估。
•交付效率：指标包括产研交付周期、双周交付率、人均周/月吞吐量、需求吞吐量/率。从衡量交付效率的多个指标中，选取以上几个，分别从需求提出者视角(产研交付周期、双周交付率)、需求实现者视角(人均吞吐量)，以及部门整体视角(需求吞吐率/量)衡量交付的效率情况。
•交付质量：指标包括线上缺陷率、千行代码bug率、缺陷关闭率、平均缺陷关闭时长。从衡量交付质量的多个指标中选取以上以上几个，分别从线上缺陷密度（线上缺陷率）、提测质量（千行代码bug率），以及缺陷解决程度（缺陷关闭率）、缺陷解决和验证的效率（缺陷关闭时长）衡量交付的质量情况。
•交付能力：指标包括发布次数、发布频率。发布频率是衡量部门交付能力的核心指标，它反映了价值的流动速度。更快和更可靠的发布，意味着更强的持续交付能力，产研可以更频繁地将更小批量的需求投入生产，业务方可以更快速体验到产品新功能。
•交付效果：主要指标是ROI达成率，反馈收益的达成比例。
•交付安全：合规及安全漏洞及修复数量。该指标用以度量近期在安全、合规方面的量化数据及趋势。
（2）效能健康度
效能度量的指标众多，但每一个指标仅代表某一个方面，无法代表部门整体的效能情况。为此，我们把多个核心指标整合到一起，按照一定的算法和权重，组成效能健康度指标，用以直观呈现部门整体的效能（主要是效率和质量）概况及趋势。现在该指标作为一个实验性指标，正在征集反馈并不断优化中。如下图所示：
5.4.2 两级度量分析体系
在刚开始进行效能度量时，由于人力和指标/数据自动化、以及指标复杂度的问题，我们仅进行C-2大部门维度的度量，后来随着指标的精简和数据线上化，我们开始赋能每个产品线团队的项目经理角色效能数据度量和分析的方法，用了大概3个月左右的时间，各个C-3维度的产品线团队开始定期进行月度开展度量工作。一方面，基于各自团队的特性新增了一些附属指标并进行差异化评估，另一方面，各团队又进一步下钻到项目角度、C-4角度等进行详细分析。后来，各C-3设立提效官（接口人），负责本部门双周维度的度量数据计算及洞察分析（详见下文效能提效官），C-3部门的效能度量分析工作逐步由项目经理转变为部门提效官。
5.4.3 五大效能提升实践
（1）单位化核心指标
所谓的单位化核心指标，就是让指标平均到项目、平均到个人，再缩短改指标的单位时间。举个很好理解的例子，各个团队都知道需求吞吐量是个衡量团队交付能力的重要指标，但由于每个团队的人员规模不同，导致团队横向比较时没有任何可比性；又因为每个月份可能工作日数量不同（例如遇上十一假期等情况），也会导致团队自身时间维度上展现的趋势没有持续可比较性。基于以上，我们制定出了 【人均周吞吐量】 指标，不管是横向、还是时间纵向，都可以相对稳定的具有比较和分析意义。
（2）洞察分析
•C-2级别洞察分析
根据交付效率、交付质量及交付能力的数据，首先进行数据解读，然后进行关联分析、趋势分析和因果分析，提出待改进点。如下图所示：
•C-3/4级别洞察分析
基于C-3/4与C-2数据的对比，进一步进行下钻分析，找出具体的问题所在。举一个例子，在C-2级别的度量报告里，对【产品处理阶段】时长进行了度量，并且细分到待处理时长和处理时长，用以评估平台类产品经理对业务需求的支持效率和资源等待情况。下方是2021年某个团队做的下钻分析，一方面从项目角度入手，识别出拉长周期（或者说在平均周期以上）的项目，对这些项目在该度量周期内的事情进行分析，另一方面，从周期较长的Top5为切入点、再下钻到这些需求的各个阶段时长，进行详细分析。各C-3/4部门根据自身部门特点，在C-2北极星指标基础上，可以定制自己的度量指标以及度量报告模板。
（3）设立效能提效官
基于项目经理角色开展各团队的效能洞察分析的动作和成果，各个部门/团队都逐渐重视和正视效能度量的意义和价值，为了去辐射和传达提升效能的实践经验和动作导向，我们又在每个团队中发起了“效能提效官”的报名，由此每个团队都提报了1~2位提效官，用以自驱主动、更加贴切详细的分析其团队内部的效能数据，让效能提升不再是“项目经理”的目标，而是实实在在团队的目标。因此，不管是团队做得好的、还是待改进的问题，第一负责人都是团队自己，而各个项目经理的工作重点逐渐转变为：
•定义标准，总结通用问题和解决方案，沉淀最佳实践。
•以顾问角色，指导各团队提效官。
•检查度量数据的真实性和客观性，对于不合理的动作进行纠偏。
（4）提供分析思路框架
效能提效官有了、度量数据报告也有了、提升目标也设立了，但纠结怎么结构化的去识别瓶颈和指定解决方案，开始成为各个团队的通用问题。大家在不遗余力的找出“问题需求”之后，往往陷入了如何去制定有效改进措施的自我困惑中，一方面要实际有效、另一方面也要避免“矫枉过正”的做法出现。以“产研交付周期”举例，我们以优秀实践经验而明确的导向出发，为各团队效能提效官提供了以下分析思路框架，旨在引导团队：1）拆小需求 2）做好计划。
（5）组织优秀团队分享
“最具说服力的不是报告上数字的提升，而且兄弟团队的接地气的分享”。基于效能度量报告，定期优秀团队和个人进行分享，在共性问题上听到其他团队的解决小妙招时，往往能让大家更有感触，原来同样的问题，还能这么解决，同样的困难、同样的阻力，再坚持一下就真的可以击破！
效能度量不是最终目的，效能提升才是。我们需要通过效能度量实现问题分析、优化改进及效果检验的闭环。在上面的效能度量章节，我们介绍了 “两级效能度量分析体系”，C-2级别的洞察分析属于宏观分析和趋势分析，侧重整体趋势和通用问题，C-3/4级别的洞察分析属于中观和微观分析，侧重分析实际的案例和具体的问题，以此作为提升的方向。详细内容可参见5.4.3。
在上面的章节，我们介绍了敏捷成熟度评估实践指引，团队定期进行敏捷成熟度的评估，并把各项打分结果以雷达图的形式展现，同时可以进行数据的环比分析。如下图所示：
每次评估之后，根据各个子项的评价分数及团队的反馈，由Scrum Master带领团队制定改进提升措施和计划，团队实施，项目经理进行跟踪和推进，敏捷教练按需提供支持。对于通用问题，可以考虑是否通过流程规范、工具或者管理的手段解决。
PMO会定期针对收益验证的情况进行数据统计和洞察分析（收益验证详情参见4.4），出具分析报告，并推动各部门针对收益管理各个环节反馈的问题进行改进，提升收益达成率，助力业务实现更高价值。
回顾和复盘在上面已经详细介绍（详情见3.3.2和3.3.3），它们既是敏捷活动和项目活动的重要一环，也是洞察分析的重要源头和输入，通过建立并固化定期的回顾和复盘机制，洞察问题，分析解决方案，并推动持续改进。
以上是我们的一些实践，可能未必标准，或者未必与理论完全一致，甚至可能是错误的，但只有不断实践才能不断改进，我们仍然需要在敏捷转型的路上披荆斩棘，通过更加精细化的管理、更深入的敏捷实践以及持续改善的行动驱动团队敏捷成熟度不断提升，不求立竿见影，但需潜移默化，润物无声。