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

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

1. 文化建设下好先手棋

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

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

4. 效能度量定准风向标

5. 洞察分析点亮启明灯

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

一.概述

“敏捷就是快速应对变化，解决不确定性问题和维护复杂产品”，没错，这是敏捷最核心的价值体现。在多部门协作、多业务类型等复杂场景下，如何落地敏捷理念、思维、框架、方法、工具和实践，实现组织敏捷、技术敏捷、项目敏捷，进而实现业务敏捷，一直是我们追求的目标。近4年来，市场与平台运营中心-平台研发部基于Scrum框架进行了很多的尝试和实践，有成功的经验，也有失败的教训。本文分别从敏捷文化建设、持续敏捷优化、实践指引、效能度量及洞察分析五个方面，分别介绍我们敏捷转型的一些实践：

（1）敏捷文化建设：欲修其身,先正其心，欲正其心,先诚其意。通过培训、分享、建立敏捷社区、内外部交流、内部考试认证等方式，营造敏捷文化氛围，纠正误区，提升认识，增强信心。

（2）持续优化敏捷实践：道阻且长，行则将至，行而不辍，未来可期。敏捷模式落地，离不开持续的实践及过程中的不断优化，需遵循由简入繁，由易到难的节奏，先僵化再固化最后优化。先从最基础的敏捷实践以及需求流转协作工具开始，在实践的过程中逐步理解敏捷的思维和方法，并结合部门特点，不断优化，引入更高阶的实践以及更高效的工具，并与DevOps的流程和机制结合起来，形成敏捷DevOps流程机制。

（3）实践指引：行之愈笃，则知之愈明，知之愈明，则行之愈笃。实践与认知相辅相成，敏捷转型过程中需要不断总结实践过程中好的经验，标准的、通用的可以沉淀为流程规范，无法作为标准规范的，可以以最佳实践的方式指导后续的实践活动。

（4）效能度量：悬衡而知平,设规而知圆。有效的度量可以及时发现问题，并辅助管理。通过对全链路效能数据的解读和洞察分析，指导和驱动效能改进。

（5）洞察分析：见出以知入，观往以知来。敏捷转型过程中，不能被表面现象所蒙蔽，若要透过现象直达本质，需要对过程、现象以及结果进行深刻的洞察分析，以指导改进和提升。

1.1 对敏捷认知的误区

平台研发部既直接承接业务需求，服务于金融产品层和运营团队，又有很多中台、平台类型的系统，如营销权益、活动平台、mPaaS等，并且也同时是京东金融APP的研发团队，负责APP的原生、H5研发及发版管理，业务系统多，类型复杂，模式多样，研发团队达到几百人，在如此复杂环境下，如何有效协同各方，持续提升研发敏捷性及效能，是PMO团队首要考虑的问题。落地敏捷研发模式是其中一种非常重要的手段和方式。从2018年成立中台，到现在的平台研发部，虽历经多次组织架构变动，但我们一直在践行敏捷研发和敏捷项目管理。在最初的阶段，大家对敏捷的认知存在诸多误区。

误区一：敏捷就是小瀑布

把敏捷迭代当成小的瀑布流，仍然执行着瀑布项目模式。当时很多团队的做法是，每一个迭代做的计划只是一个用户故事的一部分，并不能完全交付使用，产品无法拆解最小MVP版本，产研测认为这个迭代做一个接口，下一个迭代再做页面，那么两个迭代就合成一个功能去做测试，虽然分成迭代去做，但并没有在一个迭代里交付一个完整闭环的可用功能。

误区二：迭代就是敏捷

团队经常认为，固定了周期即是迭代，即是敏捷，经常把产品的实现过程流程化，这个迭代做研发，下个迭代做测试，这并不是敏捷，这只是把瀑布式开发阶段化的表现了一下。

误区三：敏捷无需计划性

认为敏捷就是想到哪里做到那里，不需要计划性。计划性有多重含义，第一，它可以明确短时间内的目标、所要做的任务及方案、达成可交付的产品。第二，可以做验收的标准依据 ，也就是计划内容可以用作目标追寻，方向一致。第三，计划性可以不断检验历史积累的经验是否可用，特别是在评估工作量投入方面、任务统筹方面，不断的检验可以更精准的评估产研的投入。其实敏捷与计划性不冲突，计划对任何敏捷开发项目都是不可缺少的组成部分。

误区四：回顾会无价值

经常排斥回顾会和复盘会，认为这类会议是无效时间投入，有这样的时间还不如多写代码。敏捷开发非常重要的点就是，不断提升团队的作战能力，不总结回顾如何提升产能，产生这样的误区，有两方面原因，第一，回顾会的方式方法不得当，方式方法里面也包含回顾会中是否真正的发现可提升的点。第二，回顾会的改进结论没有真正的落地执行。

误区五：敏捷不需要文档

敏捷宣言的第二条“可工作的软件胜于详尽的文档”，很多人理解为敏捷开发不重视文档，甚至以此为借口逃避写文档。但敏捷强调“价值”、“快速交付价值”、“为客户提供价值”的理念，研发团队要把精力放在能够为客户带来价值的地方，避免在不产生价值或者ROI低的任务上浪费时间。规范化和常规化的内容形成文档可以大大减少沟通成本。尤其在多团队协作环境下，文档的重要性和必要性不言而喻。

误区六：敏捷就是单纯追求速度

敏捷的快并非研发的快，敏捷更应该被团队记住的是灵活，通过敏捷框架，我们可以应对瞬息变化的环境，而不是我们用了一个框架，原来写2000行代码的程序员就能成为写10000行代码的软件工程师了。另外，通过敏捷，开发效率确实可以提升，但这是建立在各种工具、流程、体系、基本功训练上的。

1.2 PMO与敏捷模式推广 

PMO是一个很特殊的部门，不同行业、不同公司对PMO的定位、期望和实际承担的职责不尽相同，PMO需根据部门特点和领导期望制定适合当前环境的部门定位。我们对自己的定位是聚焦三大方向，利用敏捷的理念和方法，协同各角色持续、顺畅、高质量交付有效价值。

• 价值交付方向：通过专业的、全链路项目管理，按时保质交付业务价值，提升业务满意度，通过项目实现组织战略。

• 组织效能方向：通过敏捷研发模式落地及多种提效举措，提升研发效率、质量、能力和效果。

• 洞察分析方向：通过对效能数据、资源投入、项目收益、敏捷成熟度以及团队协同过程的洞察分析，为部门提供决策依据。

为了支撑以上定位和目标，我们把PMO划分成四大职能，分别为敏捷项目管理中心、效能中心、卓越中心及治理中心。敏捷项目管理中心，通过全生命周期的项目管理，提升战略落地的确定性及效率，交付有效价值；效能中心，通过从组织、技术、工具、项目层面推动效能提升，提升交付的效率、质量、能力、效果以及安全；卓越中心，通过技术文化氛围和技术能力建设，提升组织的可持续发展能力；治理中心沉淀知识、经验、教训、能力、流程规范、最佳实践等组织过程资产，提升团队能力。其中，这四项职责中最核心的支撑力量就是要实现组织敏捷、技术敏捷和项目敏捷，进而实现业务敏捷。

图1-1 平台研发部项目管理全景图

在项目管理全景大图中，敏捷有着至关重要的作用和地位，没有项目和需求的敏捷交付，就谈不上组织战略和业务价值的实现，组织效能也不会持续提升。敏捷研发的流程、机制以及敏捷DevOps工具链建设，需要持续建设和完善，并通过精细化管理和持续改善行动驱动团队敏捷成熟度提升，多管齐下，多措并举，持之以恒方能见到成效。下面将分章节介绍平台研发部如何逐步实现敏捷实践落地和敏捷转型的。

二.文化建设下好先手棋

敏捷转型，文化先行。如何从根本解决这些问题，转变团队观念，让更多人接受敏捷并感受到敏捷带来的好处，是我们面临的第一个课题。我们通过以下几个步骤，逐步建设敏捷文化：

• 铺垫：最初阶段，PMO团队分析当前项目交付过程中面临的困境，结合内外部实际案例，证明迫切需要引入敏捷研发模式以满足业务快速发展的需要，并获得领导支持。

• 洗脑：导入阶段，进行大量的洗脑式培训和宣讲，加强对敏捷知识、原理和基础实践的灌输，让大家接受敏捷，启动敏捷的实践。

• 培训：发展阶段，团队Scrum Master一般由项目经理兼任，结合实践过程中反馈的问题，引入外部的敏捷教练和项目管理专家进行分享交流，学习外部优秀的实践，提升项目经理作为Scrum Master角色的能力。

• 赋能：全面应用阶段，PMO人力有限，无论是作为项目经理还是作为ScrumMaster，都无法覆盖到所有的项目和需求，以往我们的做法是PMO带一个项目团队，待团队逐步掌握敏捷方法，再去带另外一个，或者同时带领多个团队进行敏捷管理和实践。这样做法存在的问题就是，头疼医头脚疼医脚，无法从根本提升敏捷能力。现在我们的做法是，进行敏捷赋能，由PMO团队规划敏捷培训系列课程，团队中敏捷积极分子参加培训课程，名为”共振计划“，就是将更多的成员培养成Scrum Master，同时加强对敏捷知识、原理和基础实践的灌输，让敏捷变成所有人的工作价值观，提升项目团队自组织、自敏捷能力，这也是作为敏捷文化建设的重要环节。

2.1 内部培训赋能

PMO团队内部进行头脑风暴，梳理作为Scrum Master和敏捷团队成员的痛点和建议的解决方案；其次，我们在项目团队内部寻找多名研发和测试的敏捷积极分子及团队leader，进行了深度访谈，了解他们的困惑、对敏捷的认知以及面临的痛点；然后，我们根据访谈结果，制定调研问卷，在大部门内部进行更广泛的调研。通过以上三个方面的工作，收集到大量敏捷实施与落地方面的反馈，为我们有针对性提升和优化提供了基础。举个例子，经过多番讨论和调研，发现产研测同学对敏捷只是了解概念，并没有真正的掌握核心价值及执行过程的要点，甚至很多动作跑偏，违背了敏捷的初衷。因此，我们决定大力提升团队成员敏捷项目管理知识，提升敏捷文化，我们举办了名为“共振计划”培训课程，针对非项目经理角色进行敏捷研发和敏捷项目管理系列课程，在项目经理和非项目经理之间产生”同频共振“，使非PMO的项目成员具备PM及SM能力，从而提升整个团队的自敏捷、自组织能力。

”共振计划“是一项项目管理&敏捷管理赋能计划，计划通过针对非项目经理角色（产品、开发、测试）进行项目管理+敏捷管理赋能认证。课程体系设计别从基础能力到专项能力进行分享，每个章节的课程都运用实践作为理论支持，而且每个实践场景都是我们的实际项目经历，这让大家对整个知识体系的掌握更加清晰。下面给大家分享一下两期课程的设置及上课情况，第一期注重加强项目管理能力提升和敏捷基础理念和基本技能辅导，整体分为培训课程+导师制陪伴式项目实践+考试认证三部分，第二期重点加强敏捷高阶能力提升和Scrum Master培养，致力于提升整个组织的自组织、自敏捷能力，整体分为培训课程+各角色分享+线下实践+知识竞赛四部分。

图2-1 共振计划一期课程体系

图2-2 共振计划二期课程体系

图2-3 共振计划课堂

目前已经举办两期的活动，两期学员均在100人以上，经反馈满意度达90%以上，目前很多团队已经可以实现自运转能力，这样的活动我们也将持续开展，后续计划走出平台研发部，引入集团内外部优秀敏捷实践以及更高阶的敏捷技能、方法和工具。 

2.2 外部分享交流

敏捷转型不能闭门造车，别人的实践经验对我们来说是非常好的借鉴。在敏捷转型过程中，通过组织与PMI的分享、与行业大厂的经验交流、引入外部优秀敏捷为组织赋能、走出去参加行业大会、加入敏捷社区等方式，时刻与时代要求与行业先进水平保持同频。另外，通过“共振计划”敏捷赋能培训，我们也选拔并培养了一大批既对敏捷感兴趣，又具有一线实践经验的研发、测试及产品同学，目前我们正在计划通过持续的运营，打造内部的敏捷社区，打造更广泛的影响力。

图2-4 与业界交流敏捷落地经验

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

持之以恒方能行稳致远。谈到敏捷，大多数人认为就是两周迭代、站会、回顾会等。但是在实际上远远不止这些内容。还记得之前在转型的初期，对于相关的实践很难理解，哪怕是在参加了ACP、CSM等培训，或者是经过教练传帮带后也只学其形，未达其意，甚至可能对敏捷的理念产生了质疑，同样对于团队来说，初期非常痛苦，大家根本不知道要做什么，为什么要这么做。但是在经过不断的尝试和实践之后，敏捷为团队带来了翻天覆地的变化，研发效率提升、项目风险管控、应对业务频繁变化等都能够使用最小成本带来更大收益。因此对于敏捷或者Scrum框架来说，我们不仅要学习它的方式和理念，更重要的是进行实践并不断改进，寻找最适合当前环境的落地方式，走出敏捷转型的困境。

回想几年之前，业务处于高速发展期，部门内部系统众多，各小组无统一规范和管理模式，各角色协同配合难度大，需求交付速度慢，变更成本高。以APP发版为例，最初是3周一个开发测试班车，2周后再上线，项目组无法应对产品源源不断的需求，版本上线内容可预测性差，封版集成耗时长，手工脚本打包错误率高。在此背景下，我们决定进行更加彻底的敏捷转型，采用Scrum框架进行敏捷试点，并引入敏捷DevOps理念，将工具链层打通，选定的是场景适合、团队意愿强烈的移动平台研发部APP发版项目团队，经过近两年的实践及不断优化，京东金融APP发版周期从原来的至少4周变为现在的2周，迭代周期由原来的至少5周变为现在的3周，整体缩短40%，需求按计划交付率提升约10%，版本变更下降10%，业务满意度不断提升。下面将以京东金融APP如何逐步实现敏捷转型并带动部门整体敏捷落地为例，介绍敏捷是如何在我们部门落地生根的。

3.1 导入阶段-敏捷交付1.0

首先确立敏捷转型的目标，即实现更快速、更可靠发版，发版节奏和版本容量对齐业界主流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）落地过程中，传递新的理念，赋予各个角色新的职责。

图3-1 角色职责变化

（2）制定多种看板，例如在1.0阶段，5周的发版周期【3周开发周期（开发+测试）+11天（集成+打包+回归+灰度+上线）】，另外依据发版周期指导敏捷各类活动，如站会、计划会、迭代演示会等。

图3-2 1.0阶段的发布计划

（3）根据发版日历，按固定节奏开发测试，在上线窗口期上线业务所需内容。

图3-3 按节奏开发，按需发布

（4）制定规模化敏捷物理看板（引用SAFe框架理念，红色线条代表故事间的依赖关系）。

图3-4 1.0阶段物理看板

（5）引入敏捷DevOps概念，建设DevOps工具。

图3-5 DevOps流程和工具

通过以上实践以及工具的引入，京东金融APP迭代节奏明显加快，从5周班车制变为4周发布火车制：

图3-6 1.0阶段京东金融APP发布火车

3.2 发展阶段-敏捷交付2.0

经过1年的磨合和适应，团队开始逐渐摸索出敏捷的精髓，不但大大提高了信心，同时又能更好的拥抱业务变化，以更小成本应对需求变更。在此基础上，迎来了2.0阶段的发展，此时大家开始考虑如何在原有的敏捷框架下，探索出适合组织的新方法和新实践。敏捷交付的内涵不仅仅是交付速度快，而且要有持续性，同时还需要有稳定的交付质量。敏捷交付2.0的目标设为4项：

• 业务目标一：协同一致

• 业务目标二：构建质量

• 业务目标三：加速业务需求上市时间

• 业务目标四：交付业务价值

做法依旧持续执行4周发布火车制度，但持续完善细节并优化流程机制，提高研发效率和质量：

• 架构解耦，组件化；

• 2周迭代内持续集成；

• 细化DoR &DoD；

• 强化敏捷PRD ，用户故事&AC；

• 强化迭代内变更管理；

• fmPaaS移动研发平台；

• 自动化单元测试；

• IDE代码评审插件；
• 质量门户建设；
• 研发效能度量数据；

根据团队交付形态，变更了版本节奏，升级了迭代日历。

图3-7 2.0阶段的版本节奏

图3-8 2.0阶段的版本日历

看板也进行了简化。

图3-9 2.0阶段的物理看板

敏捷机制更加精细化，强调需求拆细、条目化，并按节奏开发，按需发布，同时不断反馈和改进。

图3-10 条目化需求，按节奏开发，按需发布

3.3 全面应用阶段-敏捷交付3.0

经过APP团队不断的迭代尝试，部门将目光放到所有团队，开始扩大战果。在这个过程中，不是简单的完全照搬金融APP的实践，而是在敏捷的思维和Scrum的框架下，结合各团队自己的特点，在实践的基础上，不断修正和优化，同时对敏捷团队的管理和要求也更加精细化。在金融APP敏捷转型成功的鼓舞下，各团队都开始进行敏捷转型，大部分都是基于Scrum框架，并根据各自项目和部门特点持续优化和完善，形成适合自己特点的敏捷实践，在迭代节奏上，绝大部分团队都遵循双周迭代的节奏。

图3-11 基于Scrum的框架的实践

3.3.1 优化版本日历 

各个团队均强调版本日历的重要性，团队严格遵守迭代日历的约定，形成固定节奏。

（1）通过版本日历可以清楚的知道业务何时进行需求沟通，需求优先级何时进行确认，产品PO何时进行PRD设计，团队何时进行需求评审，以及团队承诺何时交付等。

（2）通过版本日历的约束，纠正了各业务随时随地，杂乱无章的需求沟通，同时结合着《需求准入规范》，设定以价值为导向的原则，让团队做有意义的事情。

（3）部分团队为应对需求插入采用需求置换原则，团队每个迭代的总工时固定的，因此约定业务需求插入执行需求置换，并且只能置换掉并未启动开发的需求，以求降低影响。

（4）团队内部的迭代原则：

• 固定评审时间：如每个迭代第二周星期三进行需求评审，产品输出优先级。

• 固定排期时间：如研发在周五输出研发排期，测试在次周周一下班前输出排期。

• 例外情况处理：对于存有待办的需求可适当延期给排期，但要与业务方同步；研发排期如果开始时间超过了迭代第二周的周三，则无需排期。

图3-12 3.0阶段的平台系统版本日历示例

3.3.2 重视回顾会

回顾会议(retrospective meeting)作为Scrum最有价值的会议之一，在敏捷迭代实践中占据非常重要的位置。平台研发部重视回顾会的作用，关于回顾会，我们遵循以下5个原则：

• 对事不对人：回顾会议不是批评和自我批评，而是识别团队的改进措施；不是追究责任，而是要考虑如何做的更好，如何让我们持续进步。考虑如何充分利用团队的力量来预防错误、及时发现潜在问题。

• 人人平等，全员参与：回顾会议不能一言堂，不能被少数人左右，团队成员是平等的。每个人都应该充分分享自己的观点，在回顾会议上希望是给所有人分享尽可能全面的、不同视角的信息。

• 可视化团队绩效：在回顾会议上可以采用燃尽图、燃起图、折线图等形式展示团队的绩效，例如本次迭代与上次迭代相比，交付速度是否提升了？截止到本次迭代，我们累计实现了哪些改进措施？另外，回顾我们已经落地的措施，可以建立起团队成员对回顾会议价值的认可。

• 改进措施要落地：回顾会议一定要输出下个迭代要落地的改进措施是什么？这样才能不断提升。不要试图解决在回顾会议上识别出的所有的题，要聚焦短板，重点突破，一次识别出1-3项改进措施即可。

• 发现优点，建立信心：在回顾会议上不但要发现改进点，也要发现优点，发现进步和受大家欢迎的成员和做法，让大家建立起对团队、对产品的信心。

通过正确地组织回顾会，让团队认识到问题所在，清楚的知道自己的优劣势，从而进行持续改善。

3.3.3 加强复盘

回顾会作为Scrum模式固定的实践，在每个迭代固定执行，除此之外，我们在近两年，也同时加强了项目复盘，复盘会也成为专项项目和迭代类项目不可或缺的环节。与回顾会不同的是，复盘会一般按月度或季度组织（事故复盘随时进行），除去敏捷团队成员之外，还会有更多的业务、运营及部分leader参加，且比回顾会更有宏观性和整体性。各角色以回顾目标-确认解决-分析影响因素-总结经验教训这样的步骤，针对业务目标、项目收益、资源投入、经验教训、下阶段改进目标等内容进行讨论和反思，拉齐认知，对齐目标。组织好复盘，最重要的不是复盘会议，而是会议之前的准备工作，如下图所示：

图3-13 复盘会议要点

通过复盘会的形式，大家停下来回头看，目的是更快的向前走。目前，平台研发部各项目团队及敏捷团队均建立了定期的复盘机制。

3.3.4 流程及工具辅助实践

经过2年的不断尝试，团队不仅加深了敏捷理论，同时也落地了更加精细化的管理方法：

• DevOps敏捷成熟度评估：定期进行团队敏捷成熟度评估，主要是从3个角色，5大能力的维度进行评估，并总结经验持续改进（详见4.2）。

• 团队责任心培养：从分配任务升级为自认领，敏捷所提倡的也是团队能够自认领，每一个人都是任务的Owner。

• 需求拆解指引：规范大需求拆解，使需求具备业务最小MVP版本交付的状态（详见4.4）。
• 任务拆解原则：充分使用行云，在任务拆解时，遵守以每条任务8H最佳，16H其次，最大不超过24H的原则。

京东金融APP落地敏捷研发模式的过程中，移动平台研发部研发和测试团队给与了项目组坚定的支持和充分的试错空间，在确保APP安全合规发版的前提下，实现了快速、稳定以及顺畅的需求交付，体现了敏捷带来的价值。通过金融APP项目团队的成功的实践，提升了大家的信心，进而带动整个部门敏捷研发模式顺利落地，并通过精细化管理和持续改善行动驱动团队敏捷成熟度的不断提升，成为快速实现业务价值及支持业务低成本快速试错的基础和保障。

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

五. 效能度量定准风向标

六. 洞察分析点亮启明灯

以上三个章节详见第二篇：http://jagile.jd.com/shendeng/article/detail/3483