本文较为复杂，主要是阐述如何实现精益和敏捷的规模化（以及强调，什么情况下才需要敏捷的规模化）
一、第一性原理：顺畅和高质量交付有用的价值
成功的精益敏捷实施中，其共性是：聚焦价值交付。即回归产品开发的第一性原理：“顺畅和高质量交付有用的价值”。因此，产品开发的目的是要把用户的价值最快的传递出去，而不是内部资源是不是时刻忙碌。
二、康威定律：组织结构会决定团队沟通的结构
康威定律告诉我们，一开始去设计和决定组织结构，那同时也就几乎决定你的产品结构，至少是限制了产品结构。。
康威原理的一个推论：应该从用户价值出发去考虑，让用户价值交付的需要决定组织的协作方式。在今天这个多变的世界里，用户价值的交付需要有灵活性，组织结构也应该有灵活性。永远应该从用户价值出发，来决定怎么去做规模化。
三、当需求规模足够大后，可以分层
分层为：用户需求、功能性需求和模块需求。
用户需求被分解成一个个故事称之为功能需求，用户需求是最小的交付单位，用户故事是一个集成和功能验证单位，最下面还有子模块任务，是不可做系统测试的，它可以分配给某个团队，是分配单位。
四、敏捷的规模化实施要解决两类问题
第一：打通端到端的价值流，连接价值链上的不同职能；
第二：在各个层次上协调各个关联的团队，保证他们工作的对齐。
五、敏捷的规模化主要有四种路径
为：融合、拓展、连接和层次化。
路径一、融合
例子：做企业网盘开发，原来是分为前后端团队。
改造：前后端融合在一起，做以用户需求而不是开发任务为主体的看板。改造后的看板上的主体流动单元不再是开发任务，而是用户的需求。改造后的看板上的主体流动单元不再是开发任务，而是用户的需求。往后是用实现中的故事替代用户需求，故事又再分解出模块（包含前后端），模块下是从故事分解出来的各个开发任务，在任务开发、测试、验证完成后，就汇总进入验收、交付。需要注意，要定义什么样的需求（故事）才能叫就绪，即定义明确的协作和需求流转规则，以便团队间自主做出协作的决定。
看板的制作时从左往右，但看板上内容的处理，是优先从右往左，原因是最终目的是完成需求及价值交付，而非开始需求，距离需求及价值交付越近则优先级越高。所以，bug要优先于功能开发处理，因为bug位于看板的更右边。
端到端的看板，最左边的需求池和设计由产品负责，最右边的验收是产品验收。所以它从产品开始到产品结束，是用户价值从提出到交付端到端的过程。同时它也反映了团队协作、需求的分解和合并、缺陷和问题。
路径二、拓展
往上、下游拓展实现规模化，譬如拓展到业务视角，从业务的角度得到的看板，将包括初始的创意、业务设计、内部的业务评审、业务交互的设计、视觉设计，以及用户验收测试（UAT）、生产验证，开发看板此时被压缩为一个小小的“开发阶段”，这样的业务视角看板会更加端到端，也会让价值交付更加顺畅。
路径三、连接
需求的流动过程中涉及多个团队的前后协同，每个团队都有自己的物理看板，这时可通过电子看板连接多个物理看板。物理看板的信息更细致，会分解成更细的任务，而电子看板里只有需求，不体现任务，它更关注的是价值流动，而不是具体环节的任务跟踪。
路径四、层次化
以华为的千人规模团队为例。
上层是解决方案层看板，仅有一个，是做整体规划用的。在解决方案层要约束并行用户需求的数目，逼迫各个团队的对齐；每个用户需求下面是故事，故事要体现在解决方案层看板上。在解决方案层追求故事向用户需求的对齐，让用户需求的快速完成。
下一层次是项目看板。项目看板上，首先要约束故事的个数，每个故事包含多个子模块。在项目层面追求任务向故事的对齐，让故事快速完成。
“故事”在解决方案层面看板与项目看板两个层面都出现了，他们联动也是通过“故事”实现。
六、对价值流动架构的持续改进
最后，还要建立价值流动的衡量、反馈机制，从而能系统性的改进价值流动效果。
规模化应该被用户需求，被顺畅和高质量的交付价值驱动出来的。组织的规模大并不意味着就得有规模化的框架；只在有实际业务需要时再考虑规模化方案，永远选择够用，但最简的规模化方案。
七、剩下的主要问题
累积流图还没太理解，累积流图如何实现价值流动效果的计量、反馈的？
网友评论