大咖布道丨证券行业规模化敏捷和核心能力演进

摘要：本文以证券行业的某头部企业的重点产品为例，探讨基于行业特征，同时脱离现成框架的规模化敏捷实施的实践总结。



说到规模化敏捷，大家通常马上会想到市场上的各种主流框架。诚然，现成的框架能与企业现状较好结合的时候，基于框架的实施是省时省力的。



然而，实践中我们经常会遇到的情形是，企业的情况千变万化，往往跟框架的假定相去甚远，有时候应用现有框架代价巨大，甚至产生削足适履的效果。本文以证券行业的某头部企业的重点产品为例，探讨基于行业特征，同时脱离现成框架的规模化敏捷实施的实践总结。



01我们眼中的规模化敏捷



如何在产品研发中凝聚力量以快速捕捉市场机会、使之转化为业务收益，并持续地做到这一点，是很多大型组织需要解决的问题。具体而言，复杂产品开发中，



- 如何让共同的目标凝聚多个敏捷团队？



- 多个敏捷团队如何协作？



- 如何快速地、持续不断地推出新的产品功能？



- 如何控制协作的复杂度以降低管理成本，并减少系统瓶颈？



- 如何保持透明性，使产品研发的过程可见，使风险和障碍容易显现，并被移除？



- 如何不断演进自己以适应环境的变化？



在我们看来，规模化敏捷的本质是应用精益、敏捷的思想和实践来寻求这些问题的解决方案。



02从五个核心能力看规模化敏捷实践



规模化敏捷可能有无数的剖析视角。我们认为，从具体实践落地的角度，规模化敏捷最依赖于五种核心能力：



目标对齐，节奏，同步，依赖解耦，持续改进



我们可以基于这些核心能力衍生、演进实践，使组织能够勠力同心、快速应变。本节将以某重点产品为例，介绍基于这五种核心能力实践中如何帮助产品开发。





图 1 规模化敏捷的五种核心能力



下图展示了所述产品上下文。自外而内的两层椭圆中，外层表示产品所属投资组合，内层表示本文本产品范围。产品内部包含多个相对独立的应用，每个应用设有Scrum Master (SM)和Product Owner （PO），图中的两个应用作为示意。各应用均基于Scrum方式搭建团队，每个应用包括若干专职、固定的Scrum小组。



值得注意的是：本产品内所包括的应用往往同时被投资组合中的其他产品所依赖，这形成了复杂的相互依赖关系，形成了产品开发活动的一个关键制约因素。



注：下文所提到的“Scrum Master”（SM）、“Product Owner”(PO) 均为各应用级别角色，他们通常负责多个Scrum团队。





图 2 产品范围及主要活动



（产品协作会：各应用PO主导、协作定义优先级



计划协作会：各应用SM主导、下一迭代排期，兼上一迭代回顾



接口对齐点，在迭代开始之前确定相依赖产品之间的接口）



2.1目标对齐



你大概听过这个故事：



工地上三个石匠在忙碌。路人问，你们在做什么？第一个石匠说，我在砌墙。第二个说，我在挣钱养家。第三个说，我在建一座大教堂。



人们常常赞叹第三个石匠的格局，但第一个石匠可能过于被“顺便”轻视了。的确，我们心中应该有我们在修建的大教堂，那是使命所在。然而，眼前要砌的这堵墙是否该是当前关注的焦点？



从目标对齐的角度而言，我们需要基于长期业务目标，但更要能够：



• 将作为远景的大目标分解为短期的小目标，

• 使相关人和团队的“小目标”指向一致，

• 使相关团队在实现小目标的过程中步调一致。



长期的大目标给我们方向，短期的小目标让我们聚焦。大、小目标的对齐让我们能够勠力协作，然后才能持续快速交付。



产品的目标对齐由以下三个关键活动驱动。





图 3 三个关键活动驱动产品目标对齐



产品协作会及其先导活动



基于业务价值并考虑相互依赖关系，产品各PO共创进行需求拆分和优先级排序(必要时业务裁决)。产品协作会输出下一迭代所需排期的需求列表。



产品协作会是一个线下与线上结合的活动，绝大部分实质性工作发生在会议之前。PO们在会议之前需要深入分析需求，并与相关方充分沟通；会议更多是一个查漏补缺的检查点。





表1 产品协作会



（注：每个迭代两周时间；W: 当前迭代第一周；W+1: 当前迭代第二周；W-1: 迭代开始前的一周…其他类推。）



计划协作会及其先导活动



基于产品协作会产出，产品各应用的SM协作排期。（如前所述，“SM”是一个应用的Scrum Master，背后可能有多个Scrum小组。）



协作排期本质上是从传统Scrum计划会议抽取出了产品级的计划工作（之后Scrum小组会在迭代计划会中各自进行详细计划）。



与产品协作会类似，绝大部分实质性排期工作同样发生在会议之前的线下沟通中。





表2 计划协作会



接口对齐点



基于计划协作会产出，各产品架构定义相互依赖的接口；迭代开始之前（W-1周）确定相互依赖的各应用接口。这个活动是迭代计划会的一个跟进，也是迭代中联调工作的序章。





表3 接口对齐点



可以看到，此产品的对齐机制结合了少量例行活动和大量线下沟通：产品协作会与计划协作会类似，会议作为对齐点，但实质性工作大部分都发生在线下；接口对齐点更是仅仅作为一个检查点存在。这与各通用的敏捷框架有明显区别，比如SAFe、LeSS都在不同程度上强调大规模集体计划活动。



之所以有这样的不同，背后原因有二：第一，该产品所属投资组合是多个相关联产品的集群，多个价值流交错；产品所依赖的很多应用同时服务于投资组合内的其他产品，这与SAFe或LeSS典型场景中的唯一解决方案显著不同。第二，产品开发中广泛使用的合作方（外包）员工目前还不能深入参与到早期需求活动中。



在这种复杂场景下，大规模集体计划很难保证效率。相形之下，本产品所采用的对齐方式以去中心化的、渐进式的计划方式为基础，以集中的检查点为制约，对类似情形有参考价值。



2.2 节奏与同步



如果你参加过拔河比赛，你可能知道，站在旁边喊号的人很大程度上决定了比赛胜负。喊号实际上是对节奏的控制。在比赛中利用稳定节奏制造冲击波，是获胜的一个诀窍。



规模化软件开发对节奏的依赖也如拔河。各相关产品基于固定的迭代节奏互相配合，重要活动可预期、可管理，才能在团队之间形成合力并免于混乱无序。



同步发生在节奏之中，包括正式和非正式活动，基于信息共享促成合作，在目标对齐的前提下使人们有机会在整体上权衡取舍。



本文所述产品所在投资组合范围内的应用共同使用两周为单位的同一个迭代节奏。对高度关联的产品而言，这样统一拉齐的节奏有利于目标对齐。



截止我们写作本文时，迭代节奏以及其中的主要活动如下图所示。



• “跨产品优先级共创”比开发迭代提前2个周期。其主要活动是前文已述的“产品协作会”，作为研发的触发器。

• “需求梳理与跨迭代排期”为开发迭代提供直接输入，包括需求沟通活动、接口同步活动以及需求的分析与设计。这些活动比开发迭代提前1个周期。

• “开发迭代”是主要的价值产生阶段。开发迭代内部有联调控制点，表示跨系统联调的控制开始时间；还有提测控制点表示提交系统测试的控制开始时间，不同小组略有区别。





图 4 迭代节奏与其中的同步活动



同一节奏为多产品目标对齐和研发协作提供了可靠的心跳，是稳定交付的基础。



受限于目前的人员状况，当前节奏设计仍然略偏复杂：该产品的相当部分开发及测试工作由合作方完成，合作方员工的高流动性导致难以形成积累，这导致更多管控需要和相应流程环节——这里有待继续探索简化机制。



2.3 依赖解耦



规模化场景中，各团队之间的依赖关系往往是效率杀手。“依赖解耦”就是应用各种方式减少、控制依赖，使团队的工作能够尽可能独立。有观点甚至认为规模化敏捷的本质是“去规模化”，也就是通过研发组织之间的解耦来降低组织协作的复杂性。完全的组织解耦未必可行也未必最优，解耦的最佳投入产出点需要通过探索来逐渐逼近。本产品采用的典型尝试包括长期的基础业务能力解耦和短期的旅客机制。



基础业务能力建设



基础业务能力体现为多应用共享的公共服务。抽取基础业务能力是降低系统复杂度的一种尝试，这里的关键是尽量避免公共服务成为业务开发的依赖。



IT部门的天职是迅速、高质量地响应业务需求。然而由于资源有限，短期和长期的响应能力是一对矛盾。着眼短期，我们需要以全部人力尽可能快地响应业务请求；而长远看来，我们需要为基础业务能力建设留出人力，因为成熟的基础业务能力支撑可使应用功能开发事半功倍。（注意：这个实践的尝试需要慎重，基础业务能力如果无法做到较高的独立性，很可能会产生适得其反的效果。）



我们在本产品开发中采用了一种渐进建设基础业务能力的思路。



如下图：作为远景，期望中的基础业务能力与应用产品开发应该是解耦的，基础业务能力开发应具有适当的前瞻性和成熟度，聚焦公共服务，支撑应用开发。



不过，当前基础业务能力范围还包括为“应用特定服务”部分，其内容与特定应用仍有紧密耦合。



为保障业务响应速度，“应用特定服务”部分要紧跟应用开发的节奏；同时，相关开发人员需要与基础业务能力部分（尤其是架构师）保持紧密合作，并受业务能力的基础设施和规则制约，以备相关功能平台化。



长期看来，随着基础业务能力的完善，“应用特定服务”部分的软件功能应向上下两个方向分化 – 部分沉淀为基础业务能力的通用服务，部分上升合入业务需求开发。





图 5 应用功能与基础业务能力开发的平衡



旅客机制



敏捷团队应该基于价值组织。而同时，敏捷团队也应该保持稳定。然而，这两个原则有时是冲突的。当有冲突的时候怎么办？这里我们借鉴了LeSS中的旅客概念（是借鉴而非借用 - LeSS中的旅客更倾向于目标团队赋能，而在我们这里旅客的首要目的是需求交付）。



如果某个迭代，基础业务能力有较多的某特定应用开发工作，则基础业务能力团队研发工程师可作为“旅客”临时加入应用，按照应用优先级工作。这种做法的作用有：



一，降低团队之间的耦合程度，从而降低协调复杂度（跨团队沟通转化为团队内沟通）。



二，平衡基础业务能力开发与应用需求开发。在这二者之间，可上可下的旅客制提供了灵活性。



三，促进基础业务能力与业务应用合作紧密度，使基础业务能力开发保持业务敏感。



当然，旅客机制只是一种可能的尝试，远不是银弹。在这种多价值流交错的情况下，我们需要在“消除依赖”和“管理依赖”之间寻找一种平衡。



2.4 持续改进



工作方式演进



基于对精益敏捷理念的把握和实践中得到的反馈，产品研发实践在一直不断地调整、适配。



在不同范围内，持续改进机制的主要承载活动包括：



（1）Scrum小组的迭代回顾会



这是源于经典Scrum框架的基本检视调整活动。



（2）应用内的SoS例会



应用内的SoS例会有两个作用：一是日常工作的同步，二是对开发过程中问题的及时回顾和改进。这种及时回顾产生的改进事项会记录在Wiki中，并在下一次会议中检查结果。各个回顾活动强调自下而上的问题发现，领导层致力于帮助团队解决问题。



（3）产品范围的迭代协作会



前文“目标对齐”部分已介绍此活动，这里不再赘述。



从规模化敏捷实践中获得的收益



（1）规模化场景中特别需要避免各团队各自为战。本产品的对齐机制设计基于多应用的优先级共创，各应用协作产生每个迭代所需完成的功能列表、所需支撑的业务目标，使得各个应用有同认可的目标，这成为应用间协作的坚实基础。



（2）多应用统一的节奏为产品开发中的各个事件提供了可靠的过程框架。同一节奏方便了去中心化的同步活动，并以例行的（中心化的）检查点及配套工具（Wiki，Jira）增强透明性，确保去中心化活动的质量。这在简化沟通、协作的同时，有效地暴露进而消除了迭代执行中的障碍。



（3）需求与实现的双重迭代周期（辅以清晰的流程、角色、职责）使需求的梳理活动严谨有序，产品规划与需求实现有规律地交叠推进。



03 当前面临的主要挑战和仍在进行中的探索



多价值流交错情形之下，规模化的演进方向



前文已述，本产品所属投资组合面临的是多产品并存且相互依赖，多价值流交错的复杂场景。在此情形下，现成的规模化框架并不能提供系统的解决方案，必须探索自己的方式。我们正在进行的探索基于对如下几个关键点的考量：



第一，多产品目标对齐。在投资组合范围内，把多个产品所形成的网络看做一个价值流网络整体，这个网络有共享的业务目标。我们正在努力的一个方向是：以多应用的优先级共创为基础，以路线图支持长期组织战略（长期目标对齐），以使多个应用能够集中力量，在同一发布中分兵协作，共同支持跨产品的业务需求（短期目标对齐）。



第二，去中心化协作。价值流网络越庞大复杂，大型的集体活动和决策就越昂贵，我们就越需要依赖于去中心化的协作方式。这与员工赋能相辅相成，我们依赖于优秀的员工高度自主地、高质量地完成他们各自的产出，更依赖他们与合作伙伴的紧密协作、相互支持。



第三，透明。去中心化的场景下，我们更需要有效的度量设计，形成过程和度量的整体视图，从而能够暴露需要关注的需求开发问题，以及系统性问题。这样，我们才有机会在去中心化的同时，为需求开发过程去除障碍，并避免混乱无序。



“大需求”的支持：一个具体的挑战



影响投资组合范围内多个产品的“大需求”尚未完全纳入对齐机制和迭代节奏：目前，大需求往往基于固定交付时间点独立排期、一次性验收，在迭代节奏之外运作。



对此，我们正在试图将大需求按照“MVP+增量”的方式进行拆解，并基于此强化投资组合范围内的对齐机制，使大需求开发纳入同一迭代节奏，并相应地通过可视化看板提供整体视图。





图 6 大需求的MVP拆分方式示意



最后



本案例规模化敏捷探索已经进入深水区。在致力于探索这些深层次问题的解决之道的同时，我们希望在本产品开发中所做的这些探索能够对你有参考价值，同时也欢迎跟我们一起探讨规模化敏捷开发的实践。



欢迎到论坛交流讨论。



点击关注，第一时间了解华为云新鲜技术~