作者：京东科技-市场与平台运营中心-平台研发部 王先科、田野、王锁、刘双、马越、刘思琪

摘要：本文总结了近4年以来部门实施敏捷转型的实践及经验教训，从5个方面进行了阐述：

1. 文化建设下好先手棋

2. 持续敏捷实践祭出连环招

3. 沉淀实践指引把牢定盘星 

4. 效能度量定准风向标

5. 洞察分析点亮启明灯

本篇是系列分享的第二篇（第一篇链接 http://jagile.jd.com/shendeng/article/detail/3445），希望对大家有所帮助。

一.概述

二.文化建设下好先手棋

三.持续敏捷实践祭出连环招

以上内容详见第一篇： http://jagile.jd.com/shendeng/article/detail/3445 

四.沉淀实践指引把牢定盘星

在敏捷转型过程中，不能完全照搬理论，需要结合当前客观环境，并不断总结最适合自身的实践，很多实践未必是标准的流程规范，但有时可能比流程规范更能指导实践。流程规范一般规定了必须要做的事情，或者不能做的事情，带有强制性，而实践指引却是告诉你以何种方式做大概率是最优的，带有建议的性质，流程规范+实践指引共同构成了敏捷落地的基础保障。平台研发部在敏捷实践过程中，总结了一些有用的实践指引，给到项目经理和各研发团队Scrum Master，以更好的落地敏捷研发模式。

4.1 敏捷管理裁剪指引

PMO团队不断积累和总结经验，形成项目管理、敏捷管理的SOP流程，并制定了标准化文档以及对应的裁剪指引，作为项目管理的统一的、最基本的标准。项目管理SOP流程中我们把项目分为两类，第一类是：业务专项，即有明确的目标、时间节奏、资源投入及预期产出，一个或几个阶段就可以输出全部交付物，这类项目既可以按瀑布方式执行，也可以敏捷方式执行或部分模块用敏捷方式执行；第二类是产品迭代项目，此类项目一般在持续运营阶段，或者是探索型迭代产品，这类项目几乎都是在以敏捷迭代方式执行。对于这两种项目我们规定了标准动作及在实践过程中的裁剪指引，项目经理及Scrum Master在敏捷实践中依据团队的实际情况进行裁剪，以下是迭代类项目裁剪指引：

图4-1 产品迭代-敏捷实践工作裁剪指引

4.2 敏捷DevOps实践指引

DevOps是文化理念、实践和工具的组合，用于促进软件开发过程中各角色之间的沟通、协作与整合，以提高组织持续交付高质量软件的能力。敏捷与 DevOps 之间的区别在于，敏捷专注于优化开发生命周期，而 DevOps 将开发和运维统一在 CI/CD 环境中，围绕非敏捷关注的实践而构建。敏捷和 DevOps 都旨在及时交付高质量的软件，当一起使用时，构成敏捷DevOps，结合敏捷思维、敏捷实践以及DevOps相关流程和工具，达到持续在最短周期内交付客户价值的目的，并且将研发流程与DevOps工具链整合，全链路提升交付效能。

平台研发部结合业界DevOps实践及部门特点，沉淀了敏捷DevOps在研发全生命周期各个阶段的活动，包括每个活动的主要内容、负责人、参与人、输入、输出、工具以及过程指导，用以指导各个角色在落地敏捷DevOps理念及流程时作为实践的参考。

图4-2 敏捷DevOps主体流程

4.3 敏捷成熟度评估实践指引

从高效能团队维度，敏捷团队理解自己当前能力，自我确定提升目标、举措、计划，以此持续改善，我们制定了敏捷成熟度评估的实践指引，Scrum Master、PO、项目经理、敏捷教练及三级管理者针对敏捷成熟度从五个维度进行评价，分别为业务敏捷、产品管理、敏捷团队、迭代运作以及工程实践，每个维度又分为若干子项。敏捷团队定期自评，也可以定期或不定期邀请敏捷教练、管理者进行专家评估，确定当前处在成熟度的哪一个级别，成熟度级别共分五级：

• 一级：有意识的（坐）

• 二级：有实践的（爬）

• 三级：熟练的（走）

• 四级：量化可靠的（跑）

• 五级：优化创新的（飞）

每次评估之后，根据各个子项的评价分数，以雷达图的形式进行呈现，并由团队进行洞察分析（详见6.2），由Scrum Master带领团队制定改进措施和计划，项目经理进行跟踪和推进，敏捷教练按需提供支持。

4.4 收益管理实践指引

在精细化经营的大背景下，业务和产研都更加重视项目和需求的投入与产出比，需要进行体系化的收益管理，逐步实现业务需求收益的可评估、可量化、可衡量。通过统一项目收益管理的范围与机制，提升项目收益管理规范性，让产研资源聚焦于高产出业务。为此，我们制定了收益管理的实践指引。收益管理涉及的两类角色：

（1）需求方

需求负责人负责设定收益指标，即负责参照收益指标库制定合理的、可量化的、可验证的项目/需求收益指标并在交付项目后按要求反馈项目收益实现情况，在行云提交验证结果，并提供支撑材料。

（2）执行方（产研测）

• 产品负责人：评估收益指标技术角度合理性，专项类的收益指标需经过C-3/C-2复核（参考立项流程，立项邮件涵盖收益指标）。

• 项目经理：

专项项目-负责发起立项，组织立项材料编写；跟踪项目收益达成情况，提醒验收人及时完成业务验证，推动项目收益目标达成，组织评估收益合理性与可验证性。

迭代类项目-负责组织需求评审会，迭代开始前收益收集，跟踪收益达成情况，提醒验收人及时完成业务验证，推动需求收益目标达成，组织评估收益合理性与可验证性。

• 团队成员：如实评估与填报工时。

专项项目按照整个项目的维度进行收益管理，迭代类项目按照单个需求的维度进行收益管理，我们对销售类指标（如直接效益类指标、用户类指标、页面类指标）要求是必须填写收益，效率提升类的高度建议有收益指标，对体验提升&系统技术类不做明确要求，如有可提供收益指标。迭代类项目收益管理流程如下：

图 4-3 迭代类项目收益管理流程

专项类项目收益管理流程如下：

图 4-4 专项项目收益管理流程

利用行云，实现全流程的线上化收益管理。

图4-5 行云收益管理线上化流程

4.5 需求拆解实践指引

为进一步践行敏捷理念与研发模式，需要细化需求颗粒度，需求颗粒度足够细致，质量才能足够高，小批量、快速、频繁、高质量交付业务可用的需求是我们追求的目标，为此，我们结合实践总结形成了需求拆解实践指引。具体的做法是，首先通过识别+引导的方式，了解业务目标和运营计划，站在需求提出方的角度识别业务诉求，引导需求提出方说出业务诉求背后的目的/目标/意义，即识别出说的，引导出没说的，形成最原始的业务诉求，通过产品分析，形成产品需求，再进一步分解成可交付评审的功能点，最后才是我们常说的Story。需求拆解需满足以下几个原则：

• 独立性：功能是独立实现的，低耦合的。

• 可交付：功能是可以交付使用的或验证的，不是幻想的功能。

• 可商讨：功能是有细节的，可以讨论更具体的内容。

• 有价值：强调价值。

• 可估计：主要强调每个Story可以估算工作量。

此外，需求拆解还有一个重要的原则，就是大小合适，从我们实践的经验来看，比较理想的情况是把需求拆分成多个用户故事（Story），可以在1~2周完成开发+测试+上线的颗粒度。但有些需求确实很大，从业务交付的角度来说，很难拆分，如果产品或研发人为把需求拆分为多个小需求，但这些小需求不是闭环的小功能，不能独立交付业务或者用户使用，这样的拆分有没有意义，有没有必要？我们的回答是：要分不同情况分别看。单独上线不能独立使用的功能，对业务来说好像没什么意义，并且可能会增加测试回归、研发上线的工作量，但也会带来其它收益：

• 保持迭代的节奏，每两周内都有交付物（虽然该交付物未必真正可用），提升产研同学的信心。

• 提高协同性。这种阶段性输出，方便需求提出方掌握研发进度和汇报进度，提升信任感。

• 减少了变更的成本。若在此过程中业务需求有变更，这种阶段性输出物（或功能模块）由于已经被测试验证过，是可以继续复用的；另外一方面，需求提出方在试用阶段性输出物时，可以体验到部分功能或流程（虽然不完整，或者流程没有闭环），若发现有问题，可以提前变更，减少变更成本。

总结以上，这种需求的强制拆分在一定程度上也是有意义的。需求拆解实践指引提供了一种参考和视角，至于在真正的实践中需不需要强制拆分，产研可以根据实际情况进行评估和判断。

五.效能度量定准风向标

管理大师彼得.德鲁克说过：“没有度量就无法管理”。两年来，我们搭建并持续完善了适合团队特点的效能度量体系，经历了由简入繁、再基于实践过程进行化繁为简的过程，由关注数据到关注问题，由效能度量到效能提升的过程，并逐步实现了全民关注效能提升的技术文化氛围。

5.1 为什么需要度量

• 从PMO组织项目管理工作层面来看，效能度量是一种全局监控的工具，通过度量为起点，通过度量数据反馈的问题和待改进点，提升组织效率、质量和能力。

• 从单个敏捷团队来看，度量的数据结果可以提供相对直接和客观的团队进步成果，增加团队自我认同感和持续提升的动力。

• 从Scrum框架来看，度量可以对团队的迭代回顾提供客观的数据帮助，并对调整提供有针对性的指向、以及对调整后结果进行有效性的评估。

5.2 需要哪些度量指标

对于刚开始启动效能度量的团队来说，管理角色看到指标总是很兴奋，全都想要、哪个都不想放弃。对于有这样的想法其实很正常，因为这毕竟是先进公司的优秀实践，但是如何选用合理的指标呢？可以试试从这个角度去评估：

• 既行的敏捷管理和DevOps流程

• 既有的线上化管理系统

• 团队有共识的存在的问题

• 当前组织内管理层的期望

下面，将从以上几个角度，举例说明具体的思路。

• 既行的敏捷管理和DevOps流程：这一项既是一个评估考虑点，更是一个组织做度量的前提。组织/团队先要有一套运行相对成熟的流程机制，大家遵守同一套游戏规则，才有去度量的意义。说回来，怎么去结合当前运行的流程去选用度量指标，举个实际的例子，如果当下Scrum框架落地范围已经切实覆盖了产品经理角色（由于组织架构的原因，很多团队Scrum的落地都仅在研发测试团队），在交付效率方面，可以选用“产研交付周期”指标。相反如果产品经理角色表面上认可实行Scrum框架，但实际上内心和行为并不十分配合，这个阶段就不建议开始“产研交付周期”“需求分析周期”的度量，因为这些指标对于眼前的团队改进大概率起不到实际作用。

• 既有的线上化管理系统：万事开头难，度量也一样。选好了适用的指标，发现当下用的管理工具/线上化系统并不完全支持，获取数据花费大量的人工成本。这种情况下，建议结合指标的必要性和获取数据的难易性再进行综合评估。对于团队自己努努力、动动手、费些时间的指标，建议坚持获取（也可以成为线上管理系统迭代优化的输入），对于强依赖外部团队而获取的指标，建议期初先放一放。

• 团队有共识的存在的问题：这个很好理解，例如测试角色认为研发提测质量不好，那用数据说话，就去看一看代码bug相关的统计、例如千行代码bug率、reopen率等等。

• 当前组织内管理层的期望：这个也很好理解，领导层的期望无非是“多、快、好、省”，但需要结合当下的问题和痛点，确定管理层最急切的期望。对于大多数互联网IT团队来说，第一期望通常是对业务侧的感受来说；快！那就笃定的选择：产研交付周期。

5.3 如何循序渐进的实施度量工作

简单来说可以分为3个步骤：确定度量周期 → 分析解读度量报告 → 优化工作方法及基础设施

• 选择适用的度量周期。度量周期的选择也需要结合迭代周期，一般选用2周迭代的团队，度量周期可以定为月度（注意，而不是2周）。度量周期和迭代节奏本身并没有强绑定的关系，度量周期太短，会导致数据局部性表现和影响的凸显，也无法有效反馈团队的成果（因为人并不是机器，不是简单的换个档就能立马加速）。任何改进都需要有一定的耐心、给与团队和决策的信任。

• 进行度量报告的透明、与团队成员一起进行分析解读。注意这里的关键词是“一起”。分析并不是报告输出者一个人的事情，解读也不是脱离团队的空想。分析者应当给出团队直接的数据信息、环比的变化、带来负向变化的直接原因（例如某几个需求周期超长导致团队平均周期延长），将这些信息共享给团队，与当事人一起分析原因和后续改进计划或减缓措施。

• 基于识别的改进点，通常逃不出这两个方向：流程/工作方法的改进、基础设施的改善。并不是所有的优化点都要真的一一去落地实现，需要考虑投入收益，长期计划和短期行动，尤其是基础设施方面，如果花很大力气去解决个例问题是不经济的。总而言之，凡事不走极端，需要综合全面的考虑。

5.4 平台研发部度量实践

基于以上的思路，平台研发部在效能度量方面持续实践，总结为“525研发效能度量实践”，概括来讲：

• 五大度量指标群：交付效率、交付质量、交付能力、交付安全、交付效果。每一个度量指标群下包括多个具体的度量指标，选取最核心的指标，按照一定的权重和算法，组成整体的效能健康度模型。

• 两级度量体系：C2级别的月度及年度效能度量报告、C3/C4级别的双周洞察分析会议。

• 五个效能提升实践：单位化核心指标、进行洞察分析、设立提效官、提供分析思路框架、组织团队分享。

5.4.1 五大度量指标群

（1）核心度量指标 

基于行业的实践以及与集团内BGBU兄弟部门的沟通交流，我们选取了以下几个核心的度量指标，分别从效率、质量、能力、效果以及安全五个方面，对产研效能进行量化评估。

• 交付效率：指标包括产研交付周期、双周交付率、人均周/月吞吐量、需求吞吐量/率。从衡量交付效率的多个指标中，选取以上几个，分别从需求提出者视角(产研交付周期、双周交付率)、需求实现者视角(人均吞吐量)，以及部门整体视角(需求吞吐率/量)衡量交付的效率情况。

• 交付质量：指标包括线上缺陷率、千行代码bug率、缺陷关闭率、平均缺陷关闭时长。从衡量交付质量的多个指标中选取以上以上几个，分别从线上缺陷密度（线上缺陷率）、提测质量（千行代码bug率），以及缺陷解决程度（缺陷关闭率）、缺陷解决和验证的效率（缺陷关闭时长）衡量交付的质量情况。

• 交付能力：指标包括发布次数、发布频率。发布频率是衡量部门交付能力的核心指标，它反映了价值的流动速度。更快和更可靠的发布，意味着更强的持续交付能力，产研可以更频繁地将更小批量的需求投入生产，业务方可以更快速体验到产品新功能。

• 交付效果：主要指标是ROI达成率，反馈收益的达成比例。

• 交付安全：合规及安全漏洞及修复数量。该指标用以度量近期在安全、合规方面的量化数据及趋势。

（2）效能健康度 

效能度量的指标众多，但每一个指标仅代表某一个方面，无法代表部门整体的效能情况。为此，我们把多个核心指标整合到一起，按照一定的算法和权重，组成效能健康度指标，用以直观呈现部门整体的效能（主要是效率和质量）概况及趋势。现在该指标作为一个实验性指标，正在征集反馈并不断优化中。如下图所示：

图5-1 效能健康度

5.4.2 两级度量分析体系

在刚开始进行效能度量时，由于人力和指标/数据自动化、以及指标复杂度的问题，我们仅进行C-2大部门维度的度量，后来随着指标的精简和数据线上化，我们开始赋能每个产品线团队的项目经理角色效能数据度量和分析的方法，用了大概3个月左右的时间，各个C-3维度的产品线团队开始定期进行月度开展度量工作。一方面，基于各自团队的特性新增了一些附属指标并进行差异化评估，另一方面，各团队又进一步下钻到项目角度、C-4角度等进行详细分析。后来，各C-3设立提效官（接口人），负责本部门双周维度的度量数据计算及洞察分析（详见下文效能提效官），C-3部门的效能度量分析工作逐步由项目经理转变为部门提效官。

5.4.3 五大效能提升实践

（1）单位化核心指标

所谓的单位化核心指标，就是让指标平均到项目、平均到个人，再缩短改指标的单位时间。举个很好理解的例子，各个团队都知道需求吞吐量是个衡量团队交付能力的重要指标，但由于每个团队的人员规模不同，导致团队横向比较时没有任何可比性；又因为每个月份可能工作日数量不同（例如遇上十一假期等情况），也会导致团队自身时间维度上展现的趋势没有持续可比较性。基于以上，我们制定出了【人均周吞吐量】指标，不管是横向、还是时间纵向，都可以相对稳定的具有比较和分析意义。

（2）洞察分析

• C-2级别洞察分析

根据交付效率、交付质量及交付能力的数据，首先进行数据解读，然后进行关联分析、趋势分析和因果分析，提出待改进点。如下图所示：

图5-2 C-2级别数据解读

图5-3 C-2级别洞察分析

• C-3/4级别洞察分析

基于C-3/4与C-2数据的对比，进一步进行下钻分析，找出具体的问题所在。举一个例子，在C-2级别的度量报告里，对【产品处理阶段】时长进行了度量，并且细分到待处理时长和处理时长，用以评估平台类产品经理对业务需求的支持效率和资源等待情况。下方是2021年某个团队做的下钻分析，一方面从项目角度入手，识别出拉长周期（或者说在平均周期以上）的项目，对这些项目在该度量周期内的事情进行分析，另一方面，从周期较长的Top5为切入点、再下钻到这些需求的各个阶段时长，进行详细分析。各C-3/4部门根据自身部门特点，在C-2北极星指标基础上，可以定制自己的度量指标以及度量报告模板。

图5-4 C-3/4下钻分析示例

（3）设立效能提效官

基于项目经理角色开展各团队的效能洞察分析的动作和成果，各个部门/团队都逐渐重视和正视效能度量的意义和价值，为了去辐射和传达提升效能的实践经验和动作导向，我们又在每个团队中发起了“效能提效官”的报名，由此每个团队都提报了1~2位提效官，用以自驱主动、更加贴切详细的分析其团队内部的效能数据，让效能提升不再是“项目经理”的目标，而是实实在在团队的目标。因此，不管是团队做得好的、还是待改进的问题，第一负责人都是团队自己，而各个项目经理的工作重点逐渐转变为：

• 定义标准，总结通用问题和解决方案，沉淀最佳实践。

• 以顾问角色，指导各团队提效官。

• 检查度量数据的真实性和客观性，对于不合理的动作进行纠偏。

（4）提供分析思路框架

效能提效官有了、度量数据报告也有了、提升目标也设立了，但纠结怎么结构化的去识别瓶颈和指定解决方案，开始成为各个团队的通用问题。大家在不遗余力的找出“问题需求”之后，往往陷入了如何去制定有效改进措施的自我困惑中，一方面要实际有效、另一方面也要避免“矫枉过正”的做法出现。以“产研交付周期”举例，我们以优秀实践经验而明确的导向出发，为各团队效能提效官提供了以下分析思路框架，旨在引导团队：1）拆小需求 2）做好计划。

图5-5 分析思路示例

（5）组织优秀团队分享

“最具说服力的不是报告上数字的提升，而且兄弟团队的接地气的分享”。基于效能度量报告，定期优秀团队和个人进行分享，在共性问题上听到其他团队的解决小妙招时，往往能让大家更有感触，原来同样的问题，还能这么解决，同样的困难、同样的阻力，再坚持一下就真的可以击破！

六. 洞察分析点亮启明灯

6.1 效能度量数据洞察分析

效能度量不是最终目的，效能提升才是。我们需要通过效能度量实现问题分析、优化改进及效果检验的闭环。在上面的效能度量章节，我们介绍了 “两级效能度量分析体系”，C-2级别的洞察分析属于宏观分析和趋势分析，侧重整体趋势和通用问题，C-3/4级别的洞察分析属于中观和微观分析，侧重分析实际的案例和具体的问题，以此作为提升的方向。详细内容可参见5.4.3。

6.2 敏捷成熟度洞察分析

在上面的章节，我们介绍了敏捷成熟度评估实践指引，团队定期进行敏捷成熟度的评估，并把各项打分结果以雷达图的形式展现，同时可以进行数据的环比分析。如下图所示：

图6-1 评价结果雷达图

每次评估之后，根据各个子项的评价分数及团队的反馈，由Scrum Master带领团队制定改进提升措施和计划，团队实施，项目经理进行跟踪和推进，敏捷教练按需提供支持。对于通用问题，可以考虑是否通过流程规范、工具或者管理的手段解决。

6.3 收益分析

PMO会定期针对收益验证的情况进行数据统计和洞察分析（收益验证详情参见4.4），出具分析报告，并推动各部门针对收益管理各个环节反馈的问题进行改进，提升收益达成率，助力业务实现更高价值。

6.4 回顾与复盘

回顾和复盘在上面已经详细介绍（详情见3.3.2和3.3.3），它们既是敏捷活动和项目活动的重要一环，也是洞察分析的重要源头和输入，通过建立并固化定期的回顾和复盘机制，洞察问题，分析解决方案，并推动持续改进。

以上是我们的一些实践，可能未必标准，或者未必与理论完全一致，甚至可能是错误的，但只有不断实践才能不断改进，我们仍然需要在敏捷转型的路上披荆斩棘，通过更加精细化的管理、更深入的敏捷实践以及持续改善的行动驱动团队敏捷成熟度不断提升，不求立竿见影，但需潜移默化，润物无声。

感谢平台研发部各研发测试团队、业务、产品、运营小伙伴们以及集团内兄弟部门的专家们，所有的沉淀都是基于大家持之以恒的实践，同时也感谢部门内项目经理李晓雪、钱之苓、王玥、徐雪娇、宁嘉晨贡献的案例和素材。