ADAPT-中国金融企业规模化敏捷框架
作者：Agilean
ADAPT-中国金融组织的规模化敏捷框架
进入VUCA时代，越来越多的金融组织开始数字化转型。这个过程中，首先要进行敏捷型组织建设，在科技侧建立与业务对齐的敏捷产品部落。Agilean 在十余年来帮助金融组织进行数字化落地和敏捷转型的过程中，意识到SAFe、LeSS、Scrum等框架在金融组织落地时，都面对着不同的阻力和困惑，因此，Agilean将多年实战经验融汇出ADAPT框架，即Agile Development Agenda for Product Tribe（产品部落敏捷研发章程），与大家分享。
金融组织敏捷转型往往从对科技侧的部落化改造开始，即将科技部门划分成若干个可以对齐业务的部落。平安银行从2017年起打造「敏捷银行」，开始时便在 Agilean 的协助下，将信用卡科技团队划分成了十个部落（如下图）。
ADAPT框架诞生的初衷，是为这类部落提供指引，确保其建立后能顺畅运行。我们先来看看这些部落的特点，从而更好地理解ADAPT框架的应用场景：
业务需求复杂度较高。产品经理需要兼具金融知识和互联网运营能力，并对科技有一定程度的理解，才能促成科技驱动业务的融合创新，这对岗位角色也提出了新的要求。
由50-150人组成的研发组织，就可以交付相对完整的业务功能。组织规模比电信行业小，需求任务分解层级也相对简单。
系统间高度耦合，业务功能往往要多系统协作才能完成，跨团队之间需要紧密协作。
对外部环境保持快速响应，大多数需求要在2-4周完成上线。由于低质量发布可能造成资金损失，质量也非常关键，必须考虑交付速度与质量之间的平衡。
系统发布大多数只涉及软件，生产系统上只有一个最新版本。因此，不用同时维护多个生产版本，版本管理的复杂性要求较低。
基于十余年来对金融组织敏捷化的理解，Agilean 特意打造了适合金融组织特点的ADAPT框架，包含以下要素，后文将逐一说明。
鉴于国内金融组织的业务特点，我们推荐采用需求-系统任务-个人任务的需求管理体系：
需求：提供完整业务价值，能够细化到一次发布完整上线的程度。
系统任务：需求被拆分到不同系统，每个任务必须对应到一个系统，建议每个系统任务不超过10人天开发工作量。
个人任务：将系统任务分解到个人，如前端开发任务、后端开发任务，建议每个个人任务不超过3人天开发工作量。
设计三层需求任务分解体系，是为了解决金融组织下面这些常见问题：
需求范围不断蔓延，需求颗粒度过大，需求时效难以统计
金融组织往往采用严格的需求审批制度，从而确保需求合理合规。这种做法的副作用是审批流程很长、时效性差，容易导致业务部门一次性提个大需求，甚至不关闭已完成需求，以便未来可以不经过审批，随时扩充需求范围。有的需求上线慢是因为做的慢，有的需求慢却是因为需求范围不断蔓延，两者混在一起，造成需求时效统计混乱。为了进行有效统计，反映现状并指引日后改进提升，我们要求需求在一个时间点发布上线，如果需要多次上线，就进行需求拆分。
研发团队快速扩张，忙闲不均，难以衡量绩效
研发团队效能评估是一个让研发和财务负责人都非常头疼的话题。如何证明现在的研发工作需要这么多研发人员来完成，又如何证明这些研发人员的效率合理？为解决这个问题，有的组织引入了功能点估算法，让第三方（功能点专家或测试团队）对研发团队的工作来进行功能点计数，从而证明研发团队的效能合理或在不断提高。就像替两只小熊分饼时引入了狐狸，这个游戏里的赢家，就是所谓的功能点专家们。目前，行业里已经有了一些向好趋势出现，比如招行、平安，开始把科技投入占企业利润/收入的比重确定下来，保证对科技的适当投入，不再纠结于具体的效能问题。
研发投入的效果很难精确度量，但不代表投入的合理性不可管理。ADAPT框架中纳入了复杂学、统计学的思考方式。业务需求被拆分成系统任务，每个任务大概10人天的工作量。在大型组织里，不用保证每个系统任务的颗粒度绝对均匀精确（成本高且难以实现），只要系统任务足够多，在这个级别上进行统计分析，管理者就可以获取足够的数据信息，从而采取相应的管理改进手段。
假设组织里有1000位开发人员，一年工作220天，总计22万人天工作量。每个系统任务定义为10人天工作量，整个组织一年大概完成2.2万个系统任务。如果组织有200个系统，平均到每个系统就是110个任务/年，到每个人是22个系统任务/年。这种计算方式有些简单，现实中，管理者可以通过观察系统任务在系统上的分布情况、人力在系统上的分布情况、各系统任务完成的前置时间、系统任务积压等数据，来了解组织运作情况，识别问题与瓶颈。
图 / 某行用知微统计小队按需求工时分布情况
个人任务颗粒度过大，进度风险不透明
在辅导金融组织敏捷转型的过程中，我们发现许多敏捷小队存在个人任务颗粒度过大的问题。有的个人任务在看板上一、两周停滞不前，到了迭代后期发现任务无法完成，或者加班加点追赶进度，或者牺牲质量匆匆完成，或者重新规划挪到下一迭代，给其它关联任务造成影响。
所以，我们要求个人任务不超过3人天，基本上每周可以完成两个个人任务。这样小队能较早发现进度问题，及时移除潜在风险。有的组织要求个人任务控制在1人天，这样做是可以的，但不建议细化到小时级别，因为会造成管理成本过高。
ADAPT需求分解体系适用于百人或千人级别的金融组织，强调在部落、小队、个人三个级别建立产能管理和时效管理体系，在部落级别关注需求、在小队级别关注系统任务、在个人级别关注个人任务。
现实中应用ADAPT框架的时候，建议使用者根据自己组织的习惯，对需求、系统任务、个人任务三个术语重新命名，从而降低ADAPT框架的导入成本。
为什么没有提用户故事？
细心的读者可能已发现，我们有意避开了敏捷需求体系中的一个常用术语：用户故事，因为这个术语已经被业界误用，很容易造成沟通混淆。教科书上用户故事的标准写法是：“作为……（用户角色），我想要……（完成活动），以便于……（实现价值）”，它是业务价值单元的载体。敏捷在早期应用于小团队的时候，用户故事可以既交付业务价值，又被一个小队完成。随着进入大型组织，用户故事概念里的业务价值要求往往被抛弃，只保留了由一个小队交付的要求。因此，当前在许多大型组织里，用户故事实际上是ADAPT中的系统任务。如果一定要与上面的需求体系对应，从强调业务价值交付的角度说，用户故事其实是 ADAPT中的需求。但经过慎重考虑，我们决定还是放弃用户故事这个术语，避免引起混淆。
如果实践者在组织中细细观察，会发现在岗位职责方面，很多敏捷框架有其不接地气之处。在Scrum或LeSS里，PO的地位不上不下，Scrum Master 只是敏捷鼓吹手，不对交付结果负责，这与国内组织文化很不匹配。SAFe里的RTE，由于其强烈的行业背景特征，也让很多人在执行时不知所云。我们推出ADAPT角色定义的初衷，就是希望把多年实战经验与国内金融组织的特点相结合，形成一套容易落地的岗位职责体系。
ADAPT框架包含5个部落级角色（部落长、业务负责人、测试分会长、架构师、版本经理），以及3个小队级角色（产品经理、小队长、研发小队成员）。部落可以是个虚拟组织，在不改变企业现有组织架构的情况下搭建而成，所以，这里定义的也可以是部落运行中的虚拟角色。
业务负责人：部落的业务带头人，负责产品整体范围和优先级决策。通常一块业务有一个负责人，对业务结果负责。当需求优先级发生冲突时，给出最终决策。
部落长：部落的交付负责人，负责部落交付和资源配置，也对部落最终绩效负责。部落长负责整合部落内的各种资源，保证快速高质量完成交付，也为跨部落资源协调提供帮助。
产品经理：部落产品创新的核心力量。金融领域的产品经理要能融合金融知识、互联网运营思维和科技能力，综合要求较高，通常需要内部进行培养。产品经理负责产品规划，对短期业绩诉求和长期产品发展进行平衡管理，将业务创意转换成研发团队可以理解并实现的需求，并对研发交付的需求进行验收。产品经理和开发人员的配比应该在 1:6 到 1:10 之间，目前该角色在组织里多是配比不足的，这也成为了交付速度和质量的瓶颈。
测试分会长：测试资源的管理者，质量防线的设计师，负责守护部落交付质量。我们建议将测试人员分解，和开发人员一起混编成研发小队，而非将所有测试人员集中，形成测试人员资源池。测试分会长（部落内为分会，跨部落为行会）通过流程要求影响小队长和小队成员，从而在源头保证质量。TA还可以通过各种培训分享活动，提升整个部落的质量能力。可以考虑在部落级别保持一只专项测试小队，负责测试框架、自动化、测试环境维护、性能测试等专项工作。为了提升控制力，测试分会长应该是所有测试人员的汇报领导，对测试人员的考核具有最终决定权，这样既能提高该角色的影响力，也提供了一条快速通道，让研发小队里的测试人员能够自己升级质量风险。
架构师：系统架构的守护者，负责部落系统的长期质量守护，对系统发展和技术路线进行长期规划，明确各系统职责，并在各系统负责人的设计决定无法达成一致时进行仲裁。各系统的分管架构师负责该系统的整体质量，审核系统的核心设计，并对关键代码进行代码评审。
小队长、研发小队成员：研发小队由产品经理、开发人员、测试人员混编而成，一般不超过12人。产品经理负责澄清需求，并在业务负责人的授权范围之内，决策业务优先级。小队长负责组织小队成员交付需求，管理研发的容量、进度、质量。在SCRUM框架里，小队不设置负责人，由团队自组织运作，这超越了大多数组织的成熟度水平，在复杂金融企业里尤其难以实现。
版本经理：部落交付的最后一棒，负责系统版本交付。在金融组织里，生产环境多由专门的运维团队管理，有专门的发布要求。版本经理负责规范化系统版本的制备过程，与运维团队对接，对系统版本部署到生产环境的全过程进行监控。
敏捷教练到哪去了？
对于进行数字化转型的金融组织来说，「敏捷」应该成为每个角色都能理解的内容，部落级敏捷教练应该由以上角色兼任，将其融入日常的工作管理之中，而非一个单独的角色。企业可以设置专门的组织级或领域级敏捷教练，辅导敏捷实践逐步深入开展。在转型初期，可以通过引入外部顾问，快速进行内部敏捷人才培养和赋能。
导入敏捷工作方式前，很多金融组织重视版本管理。在导入敏捷后（如常用的敏捷开发框架Scrum），反而变得只强调迭代管理，忽视了对版本进行管理，这加剧了质量风险。我们认为，大中型金融组织必须版本管理与迭代管理并重。这里先理清下版本和迭代的基本概念：
上图分成三列，左侧是ADAPT需求任务分解体系（需求、系统任务、个人任务），中间是部落组织的两个稳定静态单元（系统、小队），右侧是三个动态批量管理单元（产品版本、系统版本、迭代）。系统版本对某系统在一个时间点上线的所有系统任务进行批量管理，迭代对某小队在一段时间内要完成的系统任务进行批量管理。
图 / 对部落负责的系统中系统任务的统计管理
上面两个动态管理单元，虽然管理的都是系统任务的批量，但管理目的和作用各有不同。迭代严格串行，有固定的起始和终止时间，对小队的研发容量进行管理。例如，一个迭代为期10个工作日，团队8个开发人员，那么一个迭代最多放80个人天的系统任务，即8-12个系统任务。这类经验数据能帮助小队避免过度承诺，从而引发进度和质量风险，也可以帮助管理者识别闲置的小队。另外，迭代燃尽图也能帮助管理者监控每个小队的研发进展，提前预警进度和质量风险。
图 / 某银行使用知微管理小队研发容量
系统版本为微服务、遗留系统、内部开源等跨小队协同场景提供了一个质量管理视角，满足了金融组织对质量的要求。系统架构师可以利用系统版本挂载的系统任务来了解系统在该版本要完成的功能，及时参与设计评审和代码评审，提前把控版本质量。版本经理可以利用系统版本时间来监控各系统版本研发进度，根据节奏控制版本需求冻结和代码冻结时间，了解版本回归测试情况，把控版本交付质量。
产品部落活动按照需求、系统任务，系统版本三个层次展开：
需求层：包含需求优选、需求细化、需求排期、需求澄清、需求验收、部落月度回顾共6个活动，涉及产品需求列表、优选需求列表、就绪需求列表3个工件。
系统任务层：包含系统任务梳理、小队迭代计划、小队每日站会、小队迭代回顾共4个活动，涉及系统任务列表、迭代系统任务列表2个工件。
系统版本层：包含版本年度整体规划、版本规划调整、版本合入检查、版本封版、版本回归、版本发布共6个活动，涉及系统版本列表和潜在版本交付列表2个工件。
ADAPT框架打破了需求全量承诺的传统习惯，即业务在提出需求的时候，就要求研发给出预期上线时间。我们建议业务提出的需求，先进入产品需求列表，经过需求优选活动后进入优选需求列表。在需求细化活动完成后，进行需求排期，初步给出上线计划时间。
ADAPT框架除放弃需求全量承诺外，也要求业务控制倒排期需求（业务直接规定上线时间）的总体数量。因为倒排期对当前交付节奏是种冲击，好比在现有的高铁网络里面，直接要求加开一班北京到深圳的特别列车，这种事情不可以随意发生，如果发生将引发成本和风险问题。
需求优选活动可以定期举行，也可以随时发生。定期的需求优选活动可以由产品经理、小队负责人预先准备，明确可能出现容量冲突的需求，请业务负责人和研发负责人在需求优选会议上共同决策。更理想的方式，是需求优选活动按需举行，发生冲突就实时升级给业务负责人进行决策。需求优选的意义在于保护产品经理的产能，提升需求质量。根据 Agilean 的实战经验，在整个需求生命周期里，需求在细化排期阶段会耗费更多的时间。因此，让产品经理聚焦于优选之后的需求，可以大幅度提升交付时效，需求质量提升也会提升整体交付质量。
需求细化活动由产品经理、架构师、小队负责人共同完成，产品经理将需求细化到小队负责人可以理解的程度，并拆分出系统任务。
需求排期活动由产品经理和小队负责人完成，将分解出来的系统任务落实到系统版本和研发迭代。一个需求的所有系统任务都纳入了系统版本，这个需求才能算是排期完成。在研发迭代启动后，产品经理向开发人员按需澄清需求，并及时进行需求验收。
在研发迭代正式开始之前，小队负责人要提前梳理系统任务，确定进入迭代的系统任务列表，之后通过每日站会推动任务快速流动至交付、集成、验收，避免迭代内形成小瀑布。需要强调的是，在这个过程中质量活动应该前移，通过代码评审、桌面检查、需求演示等活动，保证质量内建。
在每个小队日常工作中，同时有三条线在进行：产品经理和小队负责人在准备下一迭代的需求和系统任务，研发小队在开发本迭代的系统任务，版本经理和测试人员在发布上一迭代的系统版本。
通常，金融组织会提前做好年度版本计划，在实施过程中根据情况，按需调整版本规划。为了保证质量，可以安排系统负责人对系统合入的所有代码进行合入检查。在适当时点，版本经理可以先锁定系统版本，不再合入新的系统任务，避免质量风险，并在版本回归测试前，冻结代码分支，防止代码误合入。
以上这些行为活动，可以由每个部落甚至每个小队，自己决定流程的重度。轻量流程适用于高成熟度组织和高质量系统，而低成熟度组织则适合采用相对较重的流程管理。
ADAPT框架采用双层看板管理体系，在部落级别建立部落需求看板，在小队级别建立系统任务看板。一般的部落需求看板，应该包括以下状态列：
产品需求：所有新提出的需求都进入这一列，对应上文工件中的产品需求列表。
优选需求：存放优选出的需求，对应上文工件中的优选需求列表。
需求细化：存放细化中的需求。产品经理将要开始工作的需求拉入此列，在完成需求细化并拆分出系统任务后，将需求移入下一列「就绪需求」。
就绪需求：存放待排期需求，对应上文工件中的就绪需求列表。产品经理负责推动需求排期活动，当需求的所有系统任务都纳入系统版本后，就绪需求移入下一列「排期需求」。
排期需求：存放已经进入排期的需求。如果相应的系统任务开始研发，产品经理应该把对应需求移入下一列「需求研发中」。
需求研发中：存放处于研发过程中的需求，需求看板上应该实时汇集展示系统任务的研发进展。
待验收：存放待验收的需求。每个需求应有其主办小队，主办小队负责人在完成集成测试后，将需求拖入此列，等待产品经理验收。
需求验收：存放验收中的需求，产品经理开始验收时，将需求拖入此列。
上线需求：存放已经上线的需求。
系统任务看板主要包括的阶段是：待办、纳版、优先、编码自测、代码评审、桌面检查、功能测试、系统联调、研发完成。系统任务应该平顺流过各个状态，没有堆积和阻塞。通过观察这个系统任务看板，管理者可以发现小队是否陷入了小瀑布开发模式，及时清除瓶颈。
待办：所有从需求拆分出的系统任务都先放入这一列。
纳版：小队根据需求优先级将系统任务同时纳入系统版本和对应的研发迭代，只有一个需求的所有系统任务都完成纳版动作，该需求才能进入需求研发中。
优先：表示小队后续将优先开发这个系统任务。迭代中的系统任务按照优先级逐次开发，以保证随时应对迭代范围变化。
编码自测：开发人员对系统任务进行开发。开发完成后先进行自测，后端开发人员应使用带挡板的接口测试。
代码评审：自测后的系统任务，需要由同组成员或架构师进行代码评审。
桌面检查：开发人员在开发环境或测试环境向测试人员演示已经完成自测和评审的系统任务，桌面检查通过后，系统任务才能进行功能测试。
功能测试、系统联调：进行单系统功能测试和跨系统联调测试。
部落双层看板凝结了质量内建和流式开发的思想，金融组织在实施ADAPT框架时，可以根据实际情况适度调整定制。
明确上述ADAPT框架元素后，我们就可以确立部落-小队的效能度量体系，并将其划分至相应角色。度量包括「多、快、好、赞」四个方面：“快”代表响应力，“多”代表交付数量（也就是通常说的产能），“好”代表交付质量，“赞”代表周边满意度。
部落层级的“快”，主要考察需求从提出到就绪的时长，以及从就绪到上线的时长，前一段由产品经理推动，后一段由研发负责人推动。在“多”的方面，主要关注部落在单位时间内完成的需求数量。在“好”的方面，主要关注人均生产缺陷数，以及部落负责系统的系统可用率。在”赞”的方面，主要关注业务满意度，以及对应业务部门的指标达成情况。
在小队层面，“快”主要反映于系统任务的交付时效，“多”取决于系统任务的交付数量，“好”取决于人均生产缺陷数和负责系统的可用率，“赞”取决于产品经理和相关小队的评价。
如果按角色进行划分，产品经理的“快”主要指需求澄清速度，“多”需要与需求质量进行平衡。“好”可以由开发和测试进行打分，来评价需求质量，也可以和“赞”合并。
部落研发负责人、测试负责人、架构师都可以用部落的指标体系来考核自己，只要相应调整权重就好。比如，测试负责人可以增大质量权重，架构师因为需要考虑如何不断优化系统，降低交付成本，可以增大交付数量权重。小队负责人、研发小队成员可以用小队完成的任务指标来考虑自己，系统负责人可以用负责系统的系统任务来考核自己。版本经理应该致力于加速版本发布时间，减少发版过程中引入的问题。
ADAPT 框架凝结了 Agilean 多年的金融组织敏捷化经验，力求通过规范需求体系、定义职能角色、精益流式研发、版本迭代双维管理、度量体系数字化等手段，实现以产品为中心的业务价值快速交付：
需求任务分层管理：需求、系统任务、个人任务多层次管理，确保分拆后颗粒度大小合适、验收标准明确，在不同层次实现产能和时效管理，快速发现问题，提升效率，加速响应。
可落地的职能角色定义：业务负责人、部落长、测试分会长、架构师、版本经理、产品经理、小队长，研发小队成员，各司其职，通过明确的职能定义来推动组织能力提升。
版本迭代双维管理：将版本与迭代解耦，双维管理视角。迭代关注小队的容量管理和系统任务交付，版本关注质量风险和管理交付节奏，在快速交付速度和保证质量之间求得平衡。
需求澄清前置：根据金融组织需求复杂度高的特点，要求进入研发的需求都经过评审和澄清，并把该工作提前一个迭代进行，有利于保证研发效能和提升交付质量。
精益流式研发：确保小批量快速交付，避免瀑布的开发方式。研发与业务紧密端到端协作，通过可视化和限制在制品（同时研发中的需求和系统任务数量）等手段，加速流动，快速交付用户价值。
质量内建，无缝对接DevOps：通过开发测试混编，强化开发团队的质量职责，采用开发自测、代码评审、桌面检查等质量内建实践。同时，ADAPT框架也可以无缝对接DevOps技术实践。
数字化研发管理：在ADAPT框架设计之初，就充分考虑了如何实现多层次多角度的度量和反馈，真正实现科技组织的数字化管理。
篇幅有限，本文仅对 ADAPT 进行了概貌介绍，相关细节、案例、工具应用等话题，未来将逐步推出。如对 ADAPT 有疑问，欢迎在文后评论。我们也将根据读者反馈，组织答疑和分享等线上活动。
以上为 ADAPT 产品部落敏捷研发章程细节图。想申请高清彩印版图片的组织，可点击阅读原文填写表单，我们将为最需要的同学，免费赠送 「ADAPT 全景图+要点图」的高清彩印版。
本文作者
↓↓↓ 点击"阅读原文"，申请ADAPT高清彩印图