近日，Agilean 首席咨询顾问、敏捷创新管理专家吴穹博士，在 2020 China DevOpsDays 大咖说活动中，接受了张乐、许峰两位主持人的深度访谈。吴穹博士就敏捷、精益思想和框架，金融行业敏捷和数字化，人员建设和管理，研发效能度量，以及 Agilean 推出的 ADAPT 规模化敏捷框架等方面的问题，进行了详细解读。本文即该次访谈精华内容的摘录和编辑。

0

金句摘录

01/11 我不觉得任何软件开发应该用瀑布模式去做，敏捷最核心的要素就是迭代。

02/11 敏捷是一个模式，但速度可以不一样，实践也可以不一样。

03/11 金融行业已来到一个时点，去全面推行敏捷的研发、科技或创新管理方式。

04/11 作为科技团队，你自己都不数字化，怎么帮别人数字化？

05/11 在中国公司，PO 和 Scrum Master 这两个角色很难落地。

06/11 ADAPT 框架不是西方的，文化上更兼容，拿来即用，可复制性更强。

07/11 矩阵型架构有一定管理成本，却是一个长短期比较均衡的策略。

08/11 人员能力是一个 Given，一个我们必须接受的条件。

09/11 规模化和工程效率不矛盾，解决「甜点」短板的效率会更大。

10/11 提效真正的重点，根本不是让你代码编的更快，而是让你等得更少。

11/11 短期内现在大多数中国企业的问题是管理不足，不是管理过度。

1. 谈 Thinking

思想、理论、框架有啥区别

思想无界，但落地框架分行业

我想首先厘清概念，跨行业的我们一般称之为思想，也就是 Thinking，比如 Agile Thinking， Lean Thinking，在这个层面，可以认为它是相对抽象的，类似于正确做事的方式。例如在 DevOps 中，也会把精益思想（Lean Thinking）作为一个很关键的思考方法。

因此，我们认为思想是可以做到跨行业的，甚至跨国家的。

来到方法论、框架、实践层面，就与环境、目标有关系了，比如互联网公司和金融公司，方法论和具体的实践会有差异，当实践进行的愈发深入细致，你就会更清晰的感受到这种差异的存在。

国情和环境也会造成这种差别。也许有人会说，先照搬、先去学是没有问题的，但到最后要落地时，你一定会发现，西方的一些做法，到中国是需要重新适配的，甚至需要创造出新的框架、新的实践。这是环境差异，所以不同的行业会有差异性，不同的组织，不同的国家，不同的文化也会有这种情况。

因此，敏捷没有绝对不能做的行业

很多人都会有一种疑问，敏捷在某个行业能不能做？能不能适配？有没有敏捷实践可以分享？回到Thinking（思想）层面，其实所有行业都是要快速出原形、快速上线，快速迭代，快速反馈。

严格来讲，我不觉得任何软件开发应该用瀑布模式去做。当然据说有人考过古，说原来做瀑布那个人所说的瀑布，跟你们后来说的那个瀑布是完全不一样的。我们认为敏捷最核心的要素就是迭代，所有的软件都应该两周四周交付一次。在组织合理的前提下，要做的就是迭代去加速反馈。

这一点，对所有的软件，各行各业都是适用的，只不过你的实践，你遇到的困难会不一样。初心是要迭代，你怎样做到迭代，要去思考困难在哪儿，谁不让你迭代、怎么说服……这些是你要去解决的问题，可能有合同问题、有文档问题、有内部管理问题，最后就是考虑是不是能说服管理层了。但是我觉得大的道理其实是一样的，做软件都是这样。

2. 谈行业

金融行业科技团队是时候转向全面敏捷了

中国金融行业：高度严谨、大量创新、非常复杂

从规模化敏捷的角度来讲，中国金融行业很多框架都是从电信行业中蜕变而来。10年前，超过 5000 人研发规模的企业，大多数是电信企业，这就是为什么我们现在认为很多规模化框架都有很强的电信味道。

电信行业是一个高度标准化的行业，即必须先把标准谈清楚，然后才能互联互通。所以，电信行业的需求不确定性是相对少的。因为基本按标准做，无非是做的快慢，成本高低，但要做的事相对清楚。

金融行业虽然有些基础功能一样，但金融是个存在大量创新的行业，探索性需求非常多。在中国，互联网行业的发达与金融监管不对称，简单来说，对金融行业进行强监管，对于互联网公司做金融，由于相较金融行业发展时间较短，相关的监管仍处在一条探索的道路上。

不对称监管的现状，造成了金融行业（特别是银行）一面被逼着创新，一面又要探索很多新业务。所以金融组织需求的变化不确定性、探索性非常强，这是金融行业与电信行业非常不同的一点。

其次，金融领域相对互联网行业的复杂性也非常高。Agilean 过去十几年间，在帮助大量金融企业进行敏捷和数字化转型时，观察到的一个共性问题是，IT 的人听不懂业务在说什么，同时业务也听不懂 IT 在说什么。这与互联网行业不同，比如在一个电商产品架构师说一段需求，电商业务人员基本能明白是什么；但一个金融专家与 IT 沟通例如反洗钱规定，或是某种特殊的资产债券股票、量化交易，二者基本就是两种语言在沟通了。因此，这增大了金融组织内部的沟通成本，怎么沟通需求，在金融行业是一个很大的问题。

怎么让金融企业业务和科技团队更好的融合，这是一个全新的挑战。由于金融是一个高度监管行业，很多互联网实践，比如 DevOps 中我们经常说的灰度测试，灰度的最主要目标是加速反馈，这种有损发布及其造成的质量成本，在互联网行业是可以接受的，但在金融行业，这种实践很多时候是不能、不敢接受的。

高度的严谨性是金融行业的特色，就需要寻找其他方法去加速反馈。虽然思想是一致的，但在具体实践上，会产生一些适配的要求，例如金融行业常用的白名单，开一个区、一个储蓄所去做实验，这就是一种可接受的灰度。因此在金融行业，就需要因地制宜的去探索，什么样的实践既符合这些思想，又能够满足监管要求，这也是我们每天在咨询过程当中，要去跟客户一起探索的这个工作内容。

10 年前 VS 现在：从「能敏捷吗」到「敏捷怎么做」

十年前，金融行业对数字化敏捷方向还存有怀疑，现在大家对这个行业潮流不再怀疑了，这是行业的一个进步。前面10年甚至5年前，大家问的问题就是，银行能敏捷吗？而现在，更多的挑战是能不能做成、怎么做更好。

现在，行业应该转向全面敏捷，我们叫单模多速，即敏捷是一个模式，但速度可以不一样，实践也可以不一样。比如，Agilean 在很多银行导入的是，渠道侧的团队两周一个版本，核心侧的团队四周一个版本，你的测试、质量事件可能不一样，测试强度、灰度能力也可能不一样。但整体来讲，大家的需求体系、迭代方式、管理节奏、系统版本的管理，这些都是一致的。

上图：Agilean 推出的 RISE 版本迭代日历，这是一种稳定高效的版本迭代节奏，目前已在很多国内企业科技团队运行。

点击下图 ⬇️，了解 RISE 版本迭代日历。

个人观点，金融行业已来到一个时点，去全面推行敏捷的研发管理、科技管理或者创新管理方式。数字化已经是未来一个非常清晰且不可阻挡的趋势，我们现在看到的所有数字化的书籍、观点，都把敏捷组织 DevOps 作为数字化组织的基础之一。

我们最近跟很多客户在交流时，都会提到一个「灯下黑」的问题，也就是说作为科技团队，你自己都不数字化，你怎么帮别人数字化？

所以从整个趋势上，数字化、敏捷组织、敏捷方法、DevOps，精益思想，这些整体在金融行业的接受度越来越高了，已经成为越来越主流的发展趋势。

当然，这也带来了另一个挑战：我们应思考用先进带动后进的方式，让相对比较走得快的组织有更好的效果，当有足够的经验案例，后来者也就会更快的追赶上了。

谈框架

为何要推出规模化敏捷框架 ADAPT ？

ADAPT 补充了 Spotify Model 缺失的落地细节

ADAPT 是 Agilean 发布的一套适合中国企业的规模化敏捷框架，其脱胎于 Spotify 的部落制。目前，ADAPT 已演进至V 2.0 版本。

点击下图，查看 ADAPT 框架介绍 ⬇️

从规模化敏捷框架来讲，ADAPT 脱胎于 Spotify 部落制，是在大量国内金融组织，特别是银行落地的过程中，基于很多实践总结演进形成的。

图 / ADAPT V2.0 章程图

敏捷是一个分权自治的思路。人类历史上有一个邓巴数原则，意思是人的大脑容量适配的组织合理规模大概就是150人左右。从社会心理学的角度，150 人以内，大家会把这个组织当成一个整体，会愿意为组织牺牲个人，从某种意义上讲，这也就是以公为私的意思。但是在超过这个规模后，就会进入大锅饭了，你的贡献、你跟这个组织的关系已经太渺小了。

部落化的主要原则，与阿米巴思路是一样的。只不过对于知识工作者，由于知识工作的特点是分工协作，需要多个人才能完整的交付价值。因此，我们用虚拟团队来拉通原来部落制的组织结构，让大家坐在一起，组成一个虚拟的、比较灵活的、交互的组织。

Spotify Model 实际上并没有太多的细节，特别是落地的细节。我们可以保持这个大的 Thinking，填充进我们需要的细节，让它变成一个适合中国国情的、适合中国金融企业的这样一个更具可操作性的方法框架，这就是差异问题的答案，也是 ADAPT 框架诞生的原因。

对百人千人规模团队，ADAPT 框架拿来即用

ADAPT 跟 SAFe 的定位还是一样的，都是协作框架。现在的 ADAPT 2.0 ，更多的是解决 50~150 人规模的部落，应该怎么协作的问题；即将推出的 ADAPT 3.0 会开始提供面向千人级别部落，解决部落和部落间协作，以及需要做什么事情的问题。总而言之， 在金融行业，ADAPT 主要是帮组织搭建一种业务敏捷或者金融创新的模式（业务+科技的组织）。

熊节老师说过一句话，大概的意思就是说：你们也别骂瀑布，因为你们做的也不是瀑布。现在大多数的组织其在做危机管理，或者说没有管理。每天出事了，然后就招个会，再出个制度，然后大家再要求一下。

所以，我们在做的是让大家去要「书同文、车同轨」。就是把一整套协作体系先给企业，再去探讨交流。ADAPT 不是一套纯理论体系，而是结合大量中国企业十几年的敏捷和数字化实践经验，逐渐总结而成，它天生是有大量成功落地案例的，能让企业能站在巨人的肩膀上。我们在和客户一起成长、共同学习。所以，ADAPT 对百人千人规模的团队，基本上拿过来就可以照着做了。而且 ADAPT 不是西方的，文化上更兼容，可复制性、可落地性还是比较强的。

SAFe、LeSS 在金融行业落地，是否会遇到问题？

从我目前了解到的情况，SAFe 和 LeSS，在金融行业应该还没有成功案例。SAFe，LeSS 都有很强的电信背景的。SAFe太复杂，术语太多。SAFe 的术语体系，什么 Agile Release Train（ART 敏捷发布火车），RTE（发布火车工程师），有点像一个专门的学科，在做企业导入时成本太高了。

但即使这样，SAFe 相对 LeSS，已经是跳出电信圈一些了，现在国内我们能看到的，SAFe 应用在航空和汽车行业比较多，LeSS 可能就在诺基亚，基本上还没有出圈，所以 LeSS 的应用范围更小一些。

实践方法先标准化，然后规模化

ADAPT 另一个与 Spotify Model 不同的地方在于，Spotify Model 强调每个小队的自治性，每个小队可以用不同的实践方法，可以用看板的方法，可以用 Scrum 板方法，也可以用自己想到的任何方法。但是在ADAPT框架里，定义的相对标准化，使得在组织级运作上能够有一致性。

该差异的出现，与 ADAPT 框架诞生的金融行业特点有关。金融行业虽然也应用了微服务架构，但相对来讲金融行业软件的模块耦合性比较强，因此对跨部落跨小队协作的要求比较高。如果各个小队完全独立，那么在整体的管控和数字化的研发管理上，无法做到度量单元、任务单元上的一致，度量体系也无法搭建。标准化是规模化的基础。

通常，我们先梳理需求体系、任务体系，再跟企业就此达成统一，进而搭建在工具上。总而言之，ADAPT 框架就很多细节内容标准化的原因，就是基于金融行业跨部落跨团队协作非常重要的考虑。

谈人员

规模化与工程效率不矛盾，关注「甜点」短板

ADAPT 引入的新角色，落地时如何划分职责？

ADAPT 框架在底层替换了 SCRUM 框架。在 SCRUM 中，有 ScrumMaster 和 PO 两个角色，PO 对产品和交付负责，而 Scrum Master 不对交付负责的，是一个方法论专家。

但在中国公司，PO 和 Scrum Master 这两个角色很难落地。为什么呢？

• 一是，在每个小队配备一个不对交付服务负责的方法论专家不现实；

• 二是，中国公司里，PO 通常被拆分为业务负责人和产品经理两个角色，业务负责人一般是部长级别，不太可能参与小队级别会议和日常工作。

为了适应中国国情，ADAPT 拆分为一个授权结构，即把业务负责人抽出去，与部长对齐；把产品经理下沉到小队或部落级别，使产品经理可以参与到小队的日常活动。

图 / ADAPT 「5+3」角色体系

因此，ADAPT框架中各角色的分工变得更合理、更容易理解、更加可执行。产品经理负责需求，小队长负责交付，业务负责人负责整体业务交付，部落长管理多个小队长，负责部落级产品交付。架构师从技术维度整体把控，测试工程师从测试的角度管控整个产品质量。

这是 Agilean 在引入敏捷10多年来，真正可操作的一些经验沉淀。

部落虚拟化：可分可合，随时调整，不改变汇报线

我们跟麦肯锡做法有一块不太一样，麦肯锡倾向把部落做成实体架构，我们倾向于把部落做成虚拟架构，当然我们也还在探索的过程中。

虚拟架构的好处是什么呢？

虚拟架构不动原来的汇报线，职能线是一个长时间的组织实体，比如架构部、测试部、开发部等，这些部门相当于一个个有专业性的「兵种」。

部落和小队相当于「战区」，「战区」可以根据情况随时调整，所以部落做成虚拟架构好处就是可分可合。

当然，没有绝对好的组织架构，每种架构都有利有弊。部落制会短期受益，但长期可能会损伤组织竞争力，一些中台建设、工程能力建设可能会由于短期利益而作出牺牲；矩阵型架构有一定管理成本，却是一个长短期比较均衡的策略，既可以为了快速见效授权给部落，也可以把权力收回进行一些长期建设。大型组织架构也需要经常横纵变化、不断调整，避免组织架构的固化和僵化。

人员能力是 Given ，一个必须接受的条件

在规模化敏捷的维度上有两种观点：

一种，规模化敏捷的框架是用来弥补 IT 人员能力不足的；另一种，如果本质问题是团队和个人能力的问题，框架反而去掩盖了人员能力的这种缺陷。

由此产生了几个问题：规模化框架能不能解决团队和个人的问题？如何看待中国 IT 从业人员的能力？IT 人员能力问题是不是说阻碍敏捷或规模化敏捷发展的基本问题？

严格来说，人员能力是一个Given，一个我们必须接受的条件。因为这是不可能短期改变的，或者说，人员是现状。精益的改进原则永远是精益求精，从现状出发，改进、提升人员能力是永远必要的，但也确实是个慢功夫。

规模化和工程效率不矛盾，并不是非 A 即 B 。规模化敏捷肯定是需要的，提升工程能力肯定也是需要的，只是在组织中哪个更痛的问题。

我一直在说：小组是天生敏捷，10 个人的时候，流程交互就不是问题，那工程能力差就是主要问题，就要提升工程能力；当达到 1 万人的组织，工程能力基本上不会是短板。因为，你不太可能大规模的提升几万人的工程能力，这个时候「甜点」就是流程和协作这些方面，解决「甜点」短板的效率会更大。

谈度量

「多快好赞」，减少等待浪费

问题：从哪些维度去度量团队交付效率？

实际上，这个问题严格来讲是没有解的。比如说找个两个画家，看谁画的好，这个很难评判。我认为无法度量一个团队到底效率好不好，但肯定会有一些度量体系去为管理者提供参考。就像现在谷歌的管理方式里是「前 5%，后 5%」，能看出团队里面最好的什么样，最差的什么样，但不要指望它可以精确。我们说起度量，需要的是准确，而不是精确。

图 / ADAPT 「多快好赞」度量体系

度量指标上，首先是时间，就是 Lead Time。这个指标在 DevOps 体系里面也非常推崇，Lead Time 决定反馈速度，你做得再多，你的 Lead Time 不够短，演进的速度就是慢，改进的速度也就慢。

而后在同等的规模下，还需要看吞吐量，干得快不能以干得少为代价。比如法拉利加油的例子，法拉利加油是快，但是 4 小时就加一辆车，那这个速度是很难接受的。在保证吞吐量合理的前提下追求快，保证质量的前提下追求快。两个控制变量分别是吞吐量和质量，首先保证控制变量不下降，然后在这个前提下去做快。

快了之后，根据经济的原理，Lead Time 短了，WIP 在制品就少，并行的工作就少。而并行少了，其实吞吐量还会上升。所以过去我们给很多企业导入敏捷之后的效果，基本上能看到 Lead Time 可以缩短 50% 左右。

图 / 知微的分段 Lead Time 趋势图功能

现在大多数企业实际上是高并行低效率（低流动效率）。所以我们说 Lead Time 缩短 50%，吞吐量上升 50%~100%，还是比较合理的。当然有些组织，Lead Time 不错，吞吐量也不错，但就是质量太差，这就是囫囵吞枣。

对于这种情况，可以帮助组织放慢速度，重点改质量，因为低质量的软件交付等于零。每个组织做敏捷最后的目标是不一样的，根据现状找到问题是什么，然后针对问题，打法和套路也是不一样的。所以，我一直认为敏捷是一套实践体系，我们用 ADAPT 来把它装到框架里面，或者说为金融企业做了一些定制，用的时候还是要裁剪、进行适配。

研发组织应如何进行度量，或者说如何设计研发绩效体系。吴穹博士有一篇文章专门谈了这个话题，即 DEF 研发绩效体系。

点击下图 ⬇️ 了解 DEF 研发绩效体系详情

实现客户价值，客户满意度当然是最重要的，但是相对也是比较难衡量，所以我们把它作为一个结果指标。响应时间、吞吐量、缺陷率、系统可用率，这是一些我们认为比较关键的指标。作为敏捷团队来讲，我们建议就是把这些指标作为核心的 KPI 或者 OKR 指标。还可以有一些观察指标，但是不要过分的再细的管理。现在有很多团队会对开发或测试做一些岗位指标体系，这其实会导致局部优化，这个指标体系在一个组织里面很关键，一旦这个目标设错了，可能对全局的伤害非常大。

Lead Time 降低 50% 是如何做到的？

上面我们提到了一组效能提升的数字， Lead Time 降低 50%，吞吐量翻倍。很多人可能会好奇比如 Lead Time 这个 50% 的优化幅度是如何做到的？毕竟，工程师的能力成长是有周期的，不可能短时间内出现大幅度的大个人产能提升。

这个问题的关键在于，Lead Time 压缩 50% 的情况，更多是浪费和返工的去除，以及其中并行度的下降。在精益中，David Anderson 看板理论里有一个非常重要的指标叫流动效率，也就是增值时间除以总时间。根据我们之前的统计，软件开发领域大多数的流动效率在 5%~10% 之间。

在流动效率很低的研发过程中，必须引入需求优先机制，即优先级选择。以上图看板为例，「开发」列前为「选择」队列（红框），将积压需求停留在研发系统之外，避免进一步加剧流程中的阻塞，确保研发流程得以快速优化。

——摘自吴穹博士《精益研发效能提升框架 FLEET》，点击下图 ⬇️ 阅读全文。

所以实际上你可能 90% 的时间是在等。提效真正的重点，根本不是让你代码编的更快，而是让你等得更少。我们通过协作，通过团队的有效沟通，把等待时间减掉了，你的速度就快了。在你真正的那 5% 的有效时间里，可能还有 3% 是在讨论需求，现在一个开发，一天一两百行代码就已经不错了，一两百行代码敲出来，其实花不了多久。所以说敲的快不是优化重点，减少等待才是真正的重点。

精益中为什么说管理是一种浪费？

访谈中，一位观众提到，精益思想说管理本身就是一种浪费，规模化敏捷管理机制本身也是要被优化的对象。这应该如何理解？

首先，精益中有一个 Necessary Waste 。精益中对浪费的区分，一种是必要的浪费，一种是不必要的浪费。比如我们经常说测试也是一种浪费，被列为必要的浪费。

其实可以认为管理也是必要的浪费，你可以认为它不增加价值，但从复杂系统的理论来讲，个体是一个系统，一个小队组成了一个更大的系统，多个小队组成了一个更大的部落，每一个层级都有它自己的目的。但肯定是上层越薄越好，越下沉越好，就是说上层尽量不干扰下层，下层尽量自治。

我小的时候数学老师有一句话，书要先读厚再读薄，先读厚，把该懂的东西都懂了，然后大道至简，你会发现所有的东西其实道理都差不多，最后可能就读薄了。

其实管理也一样，短期内现在大多数中国企业的问题是管理不足，不是管理过度。我之前写过一篇文章，有人说从某些方面要管理不足，有些方面要管理过度。我认为管理过度也是一种管理能力的不足，自治并不代表没有管理，自治是在很强的管理之后，逐步再授权。这是一种理想状态，但至少短期不会朝这个方向来走。所以从某种角度讲，短期大多数企业还是要通过加强管理，减少浪费，去提升整个的质量和效果。

谈落地

千人团队半年规模化敏捷转型实例

从危机驱动到有序协同

我们有一个城商行千人团队半年时间整体进行了规模化敏捷转型的案例，我想简单介绍下这个团队的开展情况。

首先要得到高层的支持，领导层有很强的决心去推动，这是一个前提条件。在这个前提下，这个团队的规模化敏捷转型大概分了两个大的阶段，前后各三个月。第一个阶段是整理和试点阶段，主要工作是梳理整体框架，搭建一些基础体系。然后把部落分出来，并挑了 6 个小队去试点。第二个阶段是基于第一阶段的试点成果，在全行进行推广。

根据我们的经验，几百人到上千人规模这种导入，一般都需要6个月的周期。但敏捷是一个没有终点的旅程，并非6个月之后，就大功告成、完全没有问题了。这6个月只是把基础打好，后续要优化的东西还会非常多。

需要澄清的是，这6个月不会涉及工程实践，更关注在流程再造、协作、度量体系等方面。工程实践，包括持续集成、自动部署等需要更长的时间去建设。

这个过程中会兼顾解决业务的既有痛点，银行这种大型组织面临最大的问题就是协同问题，所以一开始优先解决，将组织从危机驱动型转换为有序协同型。从每天无序救火，逐渐变得有序协作和规律起来，整个组织、领导层和一线管理者都会看到整个交付效率的提升。

另一个痛点是很多客户没有度量，没有数据看到整个组织效率效果。这些痛点都是在第一阶段要优先解决的。

预告：转型亲历者的第一人称分享

我们正在沟通，会邀请该案例组织的科技管理部门领导，在 12 月 6 日上海 DevOps Day 大会上，与我们共同分享这次转型的经历。他们当时非常有勇气去推动这个变革，整个部落化的推进下了非常大的决心。

我们希望给大家分享，当时划分部落的时候是怎么做的、面临着哪些问题，我们是如何把相关体系，包括需求体系，以及使用了我们自研的知微工具体系，来支持全行的研发数字化管理，以及未来可能会导入到业务去做的业务侧数字化创新。

我们现在把知微当成一个中台来看，它可以是一个 DevOps 中台、数字化营销中台、人力资源中台，等等。现在大家说 DevOps，但我自己的说法叫创新。DevOps 不是起点，尤其在金融行业，创新才是起点。

预告

12 月 6 日，吴穹博士在 DevOps Day 的分享会是一个非常具体的案例。同时，我们也会在 DevOps Day 上，正式发布 ADAPT 规模化敏捷框架 V2.0版本，届时，欢迎大家到现场与我们进行沟通。