前言
今天的分享的题目是第一性原理和精益敏捷的规模化实施。
我们讲第一性原理，先从它的反面——“货物崇拜”——说起。
货物崇拜发生在西南太平洋的小岛，二战时期美军在这里驻军，美军撤走以后小岛发生一个很奇特的现象，小岛的原住民部落中兴起一个宗教仪式——他们用草木搭起飞机模型，并作为图腾来崇拜。
他们每年定期会在自己的身体上画出USA三个大字母立队行军，拿着木头枪游行，并拜飞机，手里还会拿树叶翻来翻去，大家猜猜他们在干什么？
他们觉得美军不需要打猎、捕鱼却有充分的物资，这些物资都是岛民没有见过的好东西。他们认为美军只是普普通通的人，美军的种种行为是在召唤神灵——也就是被他们称为铁鸟的飞机，铁鸟带来无穷无尽的物资，而这本是祖先赐予他们礼物的，结果却被美军劫持了。
他们觉得自己只要模仿美军的动作就可以召唤神的再次降临，比如翻树叶——其实是在模仿美军翻阅作战文件。
他们模仿这些行为，一直坚持到今天，从来没有改变过，以至于已经成为一个宗教，人类学家称其为货物崇拜教，也就是说对那些飞机以及飞机带来的货物的崇拜。他们希望通过模仿现象和表象，得到想要的结果。
我们在精益敏捷实施里面也经常看到货物崇拜，比如我们产品经理不叫产品经理，叫PO，项目经理不叫PM，而改成Scrum Master，我们的需求不叫需求叫故事。我们也搞各种仪式——比如说站会，搞所谓大规模的敏捷框架，我们希望对于这种形式的模仿可以带来不同的结果。
而我们经常看到形式模仿了，但本质没有改变。我经历过很多成功的团队，也有看到过很多不成功的。托尔斯泰说幸福的家庭都是相似的，不幸的家庭各有各的不幸。
在成功的精益敏捷实施中，我的确看到了共性，它就是聚焦价值交付。不成功的根本原因各不相同，如理解不到位，方法错误，和技术能力不足等。但是，不成功的表现形式也有共性，那就是最终都会表现出某种程度的货物崇拜——只在乎形式，而忘记了实质。
这算是个开头，为第一性原理做一个铺垫。今天我主要还是要分享敏捷的规模化实施，会从以下四个方面分享我们的内容：
1、第一性原理 2、产品开发的第一性原理 3、精益和敏捷的规模化路径 4、以第一性原理检验规模化的效果
一、第一性原理
我们不要货物崇拜，那我们该怎么做呢？我们应该探寻第一性原理，回到事情的本源。我来解释一下什么叫做第一性原理。
第一性原理这个词很早就存在，但是最近特别热，可能是因为特斯拉的创始人 ELON MUSK吧 ，接受采访时，他总会提到第一性原理，认为考虑事情应该注重其第一性原理。以至于现在硅谷投资人也都学会了，经常会问：“这个项目不错，可是第一性原理是什么呢？”
第一性原理就是用物理学的角度看待世界，一层一层拨开事物的表象，看到里面的本质，再从本质一层一层往上走。这洽洽和货物崇拜相反。货物崇拜看到的是表象，第一性原理是要回到事物的本质。
看看 ELON MUSK 怎么讲第一性原理的。
比如他刚做电动车的时候，人们告诉他别做电动车，因为电池成本太高，电动车不可行。Musk是准物理学博士（中途辍学创业，未能取得博士学位），他说我们要回到第一性原理，那么问题是：构成电池的基本原材料是金属元素，这些金属元素加起来成本是多少，多少钱一度电？比如60美元左右一度电。
我们的任务就是无限逼近原材料的成本，因为除了原材料成本之外，其它成本都是人类协作过程之中产生的，就有可能被消除掉，从而逼近原材料成本。这是马斯克眼中的第一性原理——回到事物的物理本质。
再看乔布斯的第一性原理。他说我们做一切事情要围绕产品——公司、管理、技术、销售、创新都要围绕产品做。
- 关于公司，他曾经说，“我创建公司唯一的目的是为了产品，公司只不过是一种手段，可以让真正创造力的人合作打造产品；”
- 关于销售他说：“我坚信我们打造好的产品用户一定喜欢，用户喜欢一定会给钱，所以销售不是问题”。
- 关于创新乔布斯说“我对创新没有兴趣，我只在乎伟大的产品，只要把产品做好了，这件事本质做好了其他会跟着来”。
第一性原理就是要回到事物的本质，从本质出发再一层一层看看我们应该怎么规划其他的方面。产品是商业成功的根本，至少乔布斯是这么认为的，也是这样做的。
二、产品开发的第一性原理
那产品开发的第一性原理应该是什么？我觉得要从理解其根本目标出发，才能回答这个问题。
德鲁克说，任何组织的绩效只能在它的外部反映出来。我们探究产品开发的目标，不能从组织内部找，要从它的外部找，要看用户和价值。管理存在的目的是帮助组织取得成效，他的责任是协调内部资源取得成效。所以说他的第一性原理不在于内部，而是要取得外部的成效，我们称之为：“交付有用的价值”。
我们内部的种种方式，协调资源做计划，改善技术或流程都是为取得外部的成效服务的。对产品开发来说就是要：“顺畅和高质量交付有用的价值”，包括三个关键字。
- 顺畅，就是交付的过程外部价值要顺畅，不管内部怎么去协作，采取什么样的流程，用什么样的技术，构件什么样的基础设施，都是要为价值的顺畅交付服务。
- 当然顺畅还要符合质量的要求。
- 最后交付的价值是要有用的，有用的就是用户在乎的，愿意付钱的，可以为我们带来利益的。如果用4x100米接力赛做比喻，那我们聚焦应该是接力棒的传递而不是运动员是不是时刻在动。产品开发的目的是要把用户的价值最快的传递出去，而不是内部资源是不是时刻忙碌。
三、精益和敏捷的规模化路径
接下来我们要讲讲精益敏捷规模化实施路径，第一性原理为我们的规模化精益敏捷实施的路径提供了方向性的指导。
3.1 康威定律的启示
我们经常看到所谓敏捷的规模化实施方案，会从组织结构的规模化方案开始。这样做好吗？
著名的康威定律告诉我们，组织结构会决定团队沟通的结构，也会决定产品的结构。听起来有点抽象，我们看两个具体的例子。
康威在一篇论文中给了一个例子，当年有一个团队要做两个编译器，一个叫做 COBOL ，一个叫做 ALGOL ， 一共有8个程序员。团队评估认为COBOL 复杂度要比ALGOL复杂，于是给 COBOL 团队分5个人，给 ALGOL 团队分了3个人。从此以后这个世界上COBOL编译分5步，ALGOL的编译分3步。也就是说产品结构拷贝了组织的结构。
再看另外一个例子，我当年做项目经理的时候带过硬件团队，为了激励团队读过一本硬件工程师励志书《新机器灵魂》，它讲的是小型机时代的硬件开发。
当时，一个公司要做小型机,与如日中天的DEC的VAX11竞争。主人公潜入用户的机房，把用户的 VAX11打开，看到其中一块块电路板，于是他放心了。
书中是这样说的：“威斯特打开机器，拉开电路板的一刻，他放心了。他从中看到的是DEC组织结构，而不是一块块电路板，VAX11过于复杂，他对VAX11各部分连接方式不以为然。因为电路沟通方式拷贝的是组织沟通的方式”。这是一个真实的故事，康威原理也适用于硬件开发。
3.2 聚焦用户价值是规划规模化路径的必由之路
康威定律告诉我们，一开始去设计和决定组织结构，那同时也就几乎决定你的产品结构，至少是限制了产品结构。今天市场和环境变化太快，业务本身也需要灵活，产品本身当然也需要灵活性，不能被人为设计的层次化的组织结构所限制。所以我们认为如果上来就去设计规模化的组织结构是不对的，应该避免从组织结构的规模化开始考虑这个问题。
你应该从用户价值出发去考虑，由实际的业务需要驱动，让用户价值交付的需要决定组织的协作方式。在今天这个多变的世界里，用户价值的交付需要有灵活性，组织结构也应该有灵活性，这是对康威原理的一个推论。
康威原理说产品会拷贝组织结构，那我们产品要灵活多变，组织结构也应该是灵活的。所以我们永远应该从用户价值出发，来决定我们怎么去做规模化。
从用户价值出发，我看到两类规模化的需求。
第一是先后各个顺序职能的打通。瀑布开发模式中，开发团队批量的进行需求的设计、开发、测试，这一方式延迟了价值交付和即时有效的反馈。与之对应，敏捷倡导迭代开发方式。希望迭代地交付价值和获取反馈，比如 Scrum框架。但是真实世界要更复杂。
更宏观的看产品交付过程，需求之前还有业务规划、产品定义等，需求之后还有实施和验证等。这样我们发现如果仅仅在实现阶段迭代。整体来看，它还是瀑布，只不过是更大的瀑布，我们称之为Water-Scrum-Fall，局部的迭代，并不能带来真正的快速交付和真实反馈。
打通端到端的价值流，这是规模化要解决的问题之一。这才能产生快速和有效的交付。同时也才能产生有效反馈，基于反馈不断调整保证我们交付的价值有用。
还有另外一种情况，比如对于一个典型设备制造商，就说华为吧，要交付一个移动的解决方案，比如 VOIP 、 VOLTE这样的解决方案可能要涉及到上千人，比如基站、基站控制器、核心网、网管等网络设备，在电信行业把这个单个网络设别成为网元，每个网元背后都是相对独立的开发团队。
一个网元也有几百人在做，功能需求还要被分解到一个个功能模块。这个产品的价值也是分层次的:
- 在解决方案层我们称之为用户原始需求;
- 在网元层称之为功能需求;
- 在模块层称之为可分配需求
需求也是分层次的。
我们不可能把一千个人变成跨功能，跨职能的单个团队。只有各个团队能够协调一致，并保证各个层次工作的对齐，才能快速交付最终对用户有意义的价值。
这就引出了规模化要解决的第二个问题——怎么协调各个层面，最终交付有效的用户价值、用户需求。这也就是，如何协调每个层次、不同团队的工作，对齐各个层次上的工作，保证最终用户价值交付的顺畅流动和交付。
总结下来，规模化的敏捷实施要解决两类为题:
- 第一：打通端到端的价值流，连接价值链上的不同职能；
- 第二：在各个层次上协调各个关联的团队，保证他们工作的对齐。
通过这两点联通前后，对齐左右，目标是顺畅交付对外部也就是对用户有用的业务价值。顺畅意味着快速，也意味着高质量。
3.3 规模化精益、敏捷实施的不同路径及其案例
单个小团队层面和局部环节的实施不能带来真正的价值交付，那这就提出了规模化的需求。面对这样的需求我们来考虑怎么样做，下面我会分享一些例子，其中有华为、平安的，也有创业公司。
这些例子面对的场景和上下文不同，其具体的方案也不同，但总体上可以分为4中模式，它们的共同特点是以团队级实施为基础，再需求更大范围的规模化应用，最终都是为了顺畅交付价值。
我们将介绍4种常见的模式，也就是融合、拓展、连接和层次化。
3.3.1 融合
我们先看一个例子，团队的融合，是两个团队被融合为一个团队。
这是一家做企业网盘的部门。企业网盘类似于百度云盘，相对而言，难度在于需求多样化，比如安全的需求、合规的需求，跟办公系统集成等。
它涉及两类技术：
- 一类是后端的技术，做文件系统、集群控制，以及各类应用的基础服务；
- 一类是前端技术，提供安卓、IOS和Web以及PC的客户端应用。
前后端两类技术并不通用，所以很自然他们分成了前后端两个团队，分别做迭代，分别有一块看板。
这时，如果有一个需求，比如在线视频播放需求。它会被分别分解为前端和后端的子需求，前端和后端团队分别做迭代，两周一个迭代，后端先做，前端再集成。还需要一个单独的缺陷管理系统。
有了BUG先提给前端，前端发现是后端的问题，再转给后端。问题是后端这时正在做下一批需求，相对新需求，我们认为解决Bug的优先级更高。但事实执行中却正好相反，因为新需求有明确的时间要求啊，除非有人追——通常是项目经理来追。
包括刚才说的排计划，也就是协调前后端的迭代计划，也需要项目经理来做。在这里项目经理在这里是非常关键的角色，是一个枢纽，是一个关节点，当然也是一个瓶颈。
这个看板做的好不好？还是可以的，至少工作任务的分解和状态清楚。但它对产品经理友好吗？不太友好，需求会被拆成什么样不知道，也看不到需求端到端的流动，看不到前后端团队的协作，看不到缺陷和需求的关联，最重要的看不到用户需求的交付过程。
所以我们要改造它。改造之前我们讲戴明的一句话，戴明说：“如果不能以一个清晰的过程展示你从事的工作，你不会真正了解你在做什么”。对这个团队来说它并没有用清晰的过程展示前后端怎么协作的，BUG怎么关联的怎么解决的，价值是怎么提出并交付给用户的。所以这个看板对团队能起到的作用就非常受限了。
这个团队当时29个人，还有6个产品经理。我们后来改造了这个看板，前后端要融合在一起，做以用户需求而不是开发任务为主体的看板。
改造后的看板上的主体流动单元不再是开发任务，而是用户的需求。需求首先进入需求池也就是图中的pool，然后是设计中、待澄清等，这时还是蓝色的卡片。到了就绪这个阶段，蓝色的卡片被转换成了白色的卡片，我们称之为故事，是打印出来手填的，相对正式一点。从这一步开始故事替代了原先的用户需求。
接下来看一下这个 实现中的故事（Story），后面数据、集群、应用、Web、PC，这些是什么？是模块名称，既有前端的，也有后端的模块。各个模块下是故事分解出的开发任务，其中蓝色的是开发任务，黄色是自动测试任务，这些任务之间没有时间顺序关系，做完了就放在完成这一列。完成之后是待验证，待验证是需求（也就是story）。
横向被称为泳道，故事和它所属的任务共同放入一个泳道。当一个泳道中所有的任务完整后，故事也完成了，可以进入待验证了。泳道就被清空了，可以进行下一个故事了。
这个团队开会的时候，会过看板上的内容。大家觉得是按从左到右过，还是右到左的顺序更好呢？答案是从右往左，原因是我们的最终目的是完成需求，而非开始需求。
开始是一件非常简单的事情，但团队交付的速度是完成速度决定的，要赶快把这些接近完成的完成。从右往左，优先完成已经开始的需求，有问题及时解决问题，这也体现了用户价值的拉动。
这是一个端到端的看板，最左边的需求池和设计由产品负责，最右边的验收是产品验收。所以它从产品开始到产品结束，是用户价值从提出到交付端到端的过程。同时它也反映了团队协作、需求的分解和合并、缺陷和问题。
做完这个看板以后我问这个负责这个产品的公司副总裁三个问题:
- 能不能清晰全面的反映需求和交付的过程？
- 瓶颈和问题能不能在看板上得到及时的体现？
- 团队可以根据看板的信息协作做决定吗？
他对前两个问题的回答是肯定的，但第三个问题还有些不确定，因为团队的协作需要明确的规则，后来团队又定义了更加明确的协作和需求流转规则，这样更多的协作就可以由团队自主完成，图中是其中的一个例子,它定义了什么样的需求才能叫就绪。
上面的融合是第一个规模化的场景，它让我们看到端到端的价值流动，以及团队协作交付需求的过程，可以更加顺畅的发现解决瓶颈和问题，更加顺畅高质量的交付价值。
3.3.2 拓展
再看第二个叫拓展，这是平安的一个例子。
这个看板跟上面的非常像。这个看板在张江，他们的业务在陆家嘴。业务有一天看到这个看板，看完之觉得非常好。不过说，原来你们把我们叫做需求池，你们知道我们在需求池这个阶段做了多少工作吗？
业务决定也要做一个看板，在他们的看板中，首先就把整个开发看板中的各个阶段压缩了，变成了一个小小的开发阶段。测试强调了用户验收测试（UAT）外，还要加上了生产验证，也就是在生产环境中观察业务的运营，和验证实施的效果。而需求在提出给开发前的工作也被清晰的呈现出来了，比如初始的创意和业务设计，内部的业务评审，业务交互的设计，视觉设计等。
这是一个业务看到的端到端的看板，这个很好。我们有时候没有条件一开始就完全打通整个端到端的价值流，这时可以从局部做起，条件成熟的时候需要向两端拓展，拓展的目的是要从业务的角度更加端到端，让端到端价值的交付过程更加顺畅，这是一个拓展的方式，最终还是为顺畅交付外部的用户价值服务。
3.3.3 连接
再看第三种方式叫连接，这也是平安的例子。
这个团队比较复杂，有四个异地团队构成：业务方在深圳，底层服务在上海，上海开发完了给成都做应用开发，再给深圳做接收测试。本来上海开发团队有一块看板，成都开发团队有一块看板，都是物理形式的。
在这样复杂的组织结构下，我们自然会担心价值交付的速度很慢，因为涉及到这么多团队之间的交互。
作为解决方案，我们要设法把这两块看板连接起来，同时也要业务团队包含进来。我们用电子看板来完成这一任务，但物理看板仍然保留着。
电子看板的流程是从业务侧开始，需求作为业务设计后，由上海团队进行分析，分析之后做API开发，一旦进入API开发阶段，上海开发团队，也会copy一份到自己的物理看板里面。
物理看板的信息更细致，会分解成更细的任务，而电子看板里只有需求，不体现任务，它更关注的是价值流动，而不是具体环节的任务跟踪。等上海团队开发完成，需求放入API开发完成列，这一列也相当于成都团队的需求池，成都团队开发完了再给业务方验证。
电子看板有一个好处，它的度量会变得非常容易得到，也非常及时。
这个叫做累积流图，累积流图只涨不跌。最上面的线业务已经提出需求的个数，最下面一条线是已经交付的需求个数，中间分析完成的，API开发完成的，开始测试的，开始UAT测试，已经交付的等。从左到右画的线一条横线，它的长度是需求从开始到交付的前置时间。比如10月18号这一天提出了25个需求，到12月18号完成了25个需求，说明一个需求从开始到结束要一个月。
通过累积流图，可以看需求在各个阶段之间的分布，在最右面的阶段是UAT用户验收测试，它占据了差不多一半的时间。说明要想缩短需求的交付实践，还是应该及时做验收测试，当然具体原因就需要具体分析了，也有可能是业务并不紧迫，也可能开发给我的东西不可测试。
但是无论如何缩短UAT这个阶段的时间，是我们改进交付时长的着手点。所以把它真正连接起来，打通端到端的价值流，就以后可以去分析改进，产生系统的改进，而不是一个局部的改进。这是规模化的第三个路径——连接。
3.3.4 层次化
再看看华为这个例子，相对要更复杂一些，他们的产品是分层次的，价值也是分层次的。
需求可以分为用户需求、功能性需求和模块需求。用户需求被分解成一个个故事称之为功能需求，用户需求是最小的交付单位，用户故事是一个集成和功能验证单位，最下面还有子模块任务，是不可做系统测试的，它可以分配给某个团队，是分配单位。
这种情况下，我们怎么规模化实施？还是要回到价值顺畅交付上来。当然这里的价值最终应该是用户需求。这里的需求的层次较多，达到了三层，相应的看板也需要分层。
上层是解决方案层看板，其实是做规划用的。这里的泳道中，绿色的是用户需求，蓝色是故事，故事隶属于用户需求。我们在解决方案层要约束并行用户需求的数目，就是并行的用户需求数目不能太多了，因为并行的少就逼迫我们把已经开始的尽快完成掉，让各个团队，各个网元对齐和一致。
泳道数有限的，起到了约束并行用户需求的数目的作用，让故事向用户需求对齐，我们追求的是用户需求的快速完成，而不是仅仅是完成更多的故事，但是需求做不完。更重要的是让故事向用户需求对齐，尽快和顺畅的交付用户需求。
解决方案层的看板只有一个，起到整体规划的作用，处于上层。它的下一层次是项目看板，每个网元都有自己的项目，对一个单独的看板。看板上，蓝色的是故事，黄色的是子模块的任务。同样在项目层面要约束并行故事的个数，让任务向故事对齐，我们追求故事的快速交付。
现在的问题是这两块看板能够联动起来吗？能！因为故事在两个层次都出现了，在项目层面追求任务向故事的对齐，让故事快速完成；在解决方案层追求故事向用户需求的对齐，让用户需求的快速完成。
在这个案例中，需求是层次化的,看板的方案也是层次化的，核心还是价值流动——通过对齐最终实现用户价值的顺畅流动。
四、从第一性原理反馈规模化的效果
怎么更加顺畅高质量交付真正的价值这是我们要考虑的，当然我们还要建立所谓的反馈机制，有了刚才说的各种方法，端到端的价值流拉通以后，就为系统改进价值流动打下了基础。
而精益、敏捷实施的改进效果也应该以价值的流动为基础来衡量。比如需求从提出、确认到交付的前置时间，比如开发完成到测试开始之间的等待时长等。其中前面提到过的累积流图，就是反映价值流动的一个例子。
图中，横线的长度的是时间，纵向是有多少并行的在制品，斜率是速度，累积流通反映的正式价值流动和团队协作的过程，中间有哪些等待、瓶颈或改进的空间，以及过去一段时间的改进趋势等。精益的度量和反馈已经形成了一个以价值流动为核心的度量体系，这里不再一一列举。
总结
我们从第一性原理出发，今天我们讲了规模化实施的四种方案。规模化应该被用户需求，被顺畅和高质量的交付价值驱动出来的。
不能因为组织的规模大就要有规模化的框架，其实很多时候，你会发现你并不需要很复杂的方案。只在有实际业务需要时在考虑规模化方案，永远选择够用，但最简的规模化方案。
针对不同的场景，选择与之匹配的最简方案。比如这是两个看板怎么融合起来，怎么连接上下游，怎么从一个地方开始向上下游拓展，怎么做出一个层次化的方案，但是最终都服务于顺畅的交付。
其实，我们一直在讲看板，但看板只是一个载体，它背后是一个价值交付的团队和单元。
现在规模化敏捷、规模化精益实施有很多流行的框架。最近 Ron Jeffries 写了《软件开发本质论》一书，他评价了大规模敏捷框架的突然流行。他说大公司开始做敏捷了，它们很自然会想大公司需要大规模。Jefferise说我相信他们会取得成功，然而那只会是咨询公司的成功，而不是实施敏捷和精益的公司。大公司需要的并不是大规模，而是需要真正敏捷的方法和技术本身。
我非常同意Jefferise的说法，去模仿照搬一个规模化的框架，正是货物崇拜。我们应该做的是，回到问题的本质，回到我们的目标，再决定怎么才能，顺畅、快速、高质量的交付价值。
Denning有过类似的描述，他总结了微软实现敏捷规模化的16条原则，其中特别强调，我们要追求的是敏捷的规模化，而不是规模化的敏捷。也就是说我们要让敏捷成为公司范围内实施的方法，实现正在的敏捷性，并顺畅交付价值。而不是要搞一个规模化的框架，那反而会制约我们。
规模化的敏捷的需求的确是存在，但它应该不是被组织的规模决定和驱动的，而是需求交付的复杂性，和产品及服务的真实复杂性驱动出来。
我们为了顺畅和高质量的交付有用的价值，是我心目中的产品开发的第一性原理。是不能被忽略的基本出发点，也不能被违反。我们认为有了高质量的交付价值，并打通端到端的交付过程，不断反馈让价值顺畅流动，并以快速的价值反馈和验证，来探索真正的价值，这才是我们要做的东西。
以下是我的书《精益产品开发原则方法和实施》前言写的东西，我称之为精益和敏捷宣言，我用它来结束本文的分享。
敏捷宣言是2001年发布的，当时叫敏捷软件宣言，今天我们看价值的角度需要对它进行拓展，这些年互联网特别是移动互联网的发展日新月异，对产品开发提出了更高的要求。
- 个体和互动重于流程，但是我们要连接和打通组织的各个职能以确保协调一致的行动。
- 我们尊崇可工作的软件，重于面面俱到的文档，但是更重要的是要交付价值，要聚焦端到端价值流动以快速灵活交付真正客户的价值。
- 客户合作重于合同和谈判，，在今天选择权越来越向用户侧转移的时候，我们要与客户建立共同目标，以最大优化业务成果。
- 我们尊崇响应变化，但是响应变化是被动的，今天要有计划和系统主动的试错以支持我们有效的学习和创新
所以今天时代不同了，我们提出比过去高得多的要求。敏捷规模化需求是真实存在的，但是还要要避免不必要的各种规模化的框架，为了规模化而规模化。更不要做所谓的货物崇拜，所以我们要回到问题的第一性原理——顺畅和高质量交付有用的价值。
