随着敏捷开发的流行，近年来各种大型、规模化敏捷框架、敏捷组织设计、业务敏捷也称为大老师们口中的热词，也带来了很多讨论甚至质疑。本文根据笔者Jacky Shen在2019上海和北京敏捷之旅发表演讲所整理。
笔者认为，敏捷的核心是“小而美”，追求“大而全”非常危险而且也达不到敏捷的目标，即“早+准”，在不确定环境中快速反馈来命中商业愿景，提升竞争力。
本文分为以下三个部分：
- 从敏捷到”大型敏捷”
- 骨感现实中的复杂性
- 变革管理及一些原则
一、从敏捷到规模化”大型敏捷”
1.1 回顾敏捷Agile这个词
2001年17位软件行业先驱在美国雪鸟镇聚会，石破天惊地提出了《敏捷开发宣言》，当时的主要关注点包括：
- 追求响应力与灵活性，即适应性over预测性 （不是单纯地求快，也不是要压榨产能）
- 以人为本（一群“艺术”家），而非用流程来管控（流水线工人）
- 提升客户和团队满意度
然而现实中，人们对”敏捷”还有其他期望：
- “抄竞品抄得快” — （敏捷不见得能帮你少花时间，只让你知道该干嘛）
- “明年少招点人” — （敏捷不见得提高产能，只是增加了可管理性）
- “按时上线” — （敏捷不见得确保时间，只是摧毁不切实际的幻想）
笔者认为，我们平时书本和课程谈的各种敏捷方法论、框架实践集，都在描述一种“理想的未来状态”，但是很难说如何在特定组织中能够达到那种状态，所以与敏捷转型（变革管理）是两码事。
1.2 大型敏捷、规模化的意图
- 某个项目或产品确实需要多于9人（多团队）以上共同完成开发（也有人叫多团队敏捷）
- 不仅仅是开发部门，而是全IT流程参与，包括需求部门、测试部门、运维部门等（敏捷开发本来就是提倡这样）
- 不仅仅是IT敏捷，让公司业务、市场部门也参与，更加灵活地响应市场变化，提升业绩 （也有人叫业务敏捷）
- 不仅仅是单个项目or产品团队，希望其他项目组、部门、业务线全都用起来敏捷模式 （也有人叫组织级敏捷）
然而，大部分公司称不上大型开发：因为通常某个产品组也就10来个人，比较独立。但：
- 产品开发组之间可能存在技术依赖或使用了共享的模块
- 不同编程语言、技术栈、中间件、遗留系统、烂代码、耦合、依赖、存储过程、古老的编程语言
- （由于采购不同供应商导致）技术栈过于分散，人员相互学习交叉工作存在学习投入不足，或者身份差异不允许交叉学习
1.3 大型敏捷框架概览
目前市面上常见大型敏捷框架和方法论一般来说会提到：LeSS, SAFe, DAD, Nexus, Spotify, Scrum@Scale等。我们来看一个有代表性的，适合重型企业的大型敏捷框架 LAFABLE，是Mike Cohn提出的，最新为5.0版本。
怎么样，看到什么问题了吗？
矩阵式的结构中，更多的团队待办列表造成局部优化，似乎产出很高，但是丢了全局优先级视角，很可能延迟了反馈和客户价值，SOS也变成了项目经理的汇报会。诸多新角色，造成更多组织官僚，说白了，监工的中间商比干活儿的人还多，这能敏捷起来吗？
这个框架正如被某些咨询公司推崇的SAFe框架一样（巧合的是，它也推出了5.0）。SAFe的开发价值流（定义、构建、测试、发布）及其ART ，就是多个瀑布式的项目。组织结构的现状里面，一定已经存在类似的结构，相关但不一定在同地的多个部门或团队为同一个产品领域而工作。即ART设计并没引发什么变化，而敏捷的关键在于解耦后重组资源，这才是难点，激进的Craig Larman甚至说“close some sites”（关掉一些城市的办公室）。
SAFe还是以交付视角为主，产品负责人和客户代表被放在了边缘的一角里面，这样是无法牵动业务一起转型的。SAFe的人力绩效那部分建议中，持续反馈是的说法是可以，但源自Attlansian的高底薪是不合经济规律的，高底薪只有行业头部公司才给的出，而且在经济下行周期也难以维系。
1.4 “SAFe is just another RUP” — Ken Schwaber
笔者曾经觉得大而全的SAFe框架，能让一些既得利益者能看到好处然后支持变革，是好事。然而，因为资源利益交换摆不上台面的，所以框架能说出来利益对齐都不是真利益。企业级变革都是老板工程，帝王之术自古有之。可能就是换几个诸侯的事情，别说底下没执行力，老板搞不定诸侯们就是改朝换代。
企业级的、原则指导性的框架，如果进化速度过快可能是因为没想明白，或者故意堆砌热词。企业级转型没个2-3年是不会有很大变化的。
该框架底层是Scrum实践为主，其他没看到任何“个体与交互、适应性”的内容，框架的中层及以上就是瀑布大版本规划（10周），更像一个大项目。核心反馈机制弱。没考虑上线以后的维护机制，缺乏人的互动，没有持续需求分析也没有持续改进机制，追求“高大全”，违背敏捷原则#10也违背精益思想。
更别提100人规模的PI Planning大会会议效率低，参与和理解的效果差。（如果只是在启动时开一次可以接受）
相反，敏捷结构追求的是“小团队、自组织、跨职能”，从客户和产品视角拆分、解耦backlog，打破职能孤岛，计划上留有buffer和planB应对变化，机制上允许甩掉包袱，强调透明性及DoD，尽早尽少地做事是关键，追求可持续的快速反馈。
在美国国防部2019年11月一份报告中指出，非常反对使用诸如SAFe这类“死板、预定义的框架”，因为造成在（某飞行器项目）“研发中过晚地发现多种依赖”，而我们知道，依赖是巨大的风险。
自SAFe打着“规模化敏捷”旗号诞生起，一方面迎合了一些商业利益，各种恰烂饭的“大老师”鼓吹“大敏捷”，使客户组织愈加不敏捷。另一方面，质疑声一直不断。不论是知名敏捷人士，还是发起敏捷宣言的17个人都公开发文反对SAFe。包括Martin Fowler、Dave Snowden、Steve Denning、Marty Cagan、Ken Schwaber、Mike Cohn、Mike Beedle、Ron Jeffries、Dave Thomas等。Martin Fowler甚至公开说：“SAFe=shitty agile for enterprise” (屎一样的企业级敏捷)！
另一个小道消息讲，由于Dean在早期出版的敏捷类书籍中引用了大量他人和社区贡献的文章，但不进行明显的引用说明（欧美很看重这种credit），使得其他敏捷人士心里也不是很愉快，不愿意与Dean来往。
1.5 为什么规模化扩展不是个好主意
- 产品和创意由小团队协作出来
- 沟通路径和开销大
- 全生命周期的总成本（TCO），例如依赖、集成等风险容易后移，导致变更成本高
- 局部优化易于全局优化
- 传统组织设计带来了不必要复杂性的幻觉
- 流程补丁打补丁，但极少去掉补丁
- 更多层级使团队远离客户
- 人数过多阻碍了实验性过程之快速反馈
1.6 扩展效率 vs.扩展适应力
左图是传统的层级结构，强调自上而下的命令与控制，讲究去扩展执行效率和资源利用率。右边是数字化和敏捷转型大潮中，为了适应变化的环境，《赋能》书中及Scrum of Scrum描述的更多是去中心化、跨职能、自组织的团队。国内有一个企业案例，就是青岛海尔的“人单合一”组织形式，国外著名的Spotify案例，都是讲究去扩展适应力。
二、骨感现实中的复杂性
失控不可怕，因为混乱是通向新秩序的阶梯；
看似有序和坚固，才是脆弱和混乱的温床。
2.1 上层管理者关注资源分配
越往上的企业管理者，终极关注点必然是“生存永续”。
笔者曾给某跨国企业进行敏捷转型咨询辅导，总部在国外，国内多个城市的研发中心。进去时发现，一个功能特性因为历史原因，被切分的很碎，不同地点的不同团队相互依赖和等待严重。这样的大型组织很难获得快速反馈。
我们帮助管理者描绘了资源/组件分布的现状，使总部的高层领导看清了局面。一段时间后，高层领导下决心关闭了某个城市的办公室（对那里员工来说，被裁员并不开心），重新进行了资源分配和整合，这次组织变革有力推动了整体的敏捷性提升。
2.2 跨地域团队的争宠
要理解跨地域交付团队管理者的“欺上瞒下”，背后是一番好意在为自己团队争得更多发展机会。
纵观历史，总部的“帝王之术”其实是另一个维度的“敏捷性”。古代统治者就是要多生孩子，优胜劣汰，东边不亮西边亮的意思。这种业务敏捷确实是全局优化，但敏捷性不是通过主动加速反馈获得的，也不是通过模块化组合获得的。而对于单个“孩子”来说，难免会局部优化，看紧自己的一亩三分地。
但如果各区域分家独立运作、解耦，争宠情况就可以得到改善。类似“藩王”，这要看上层的智慧和授权了。
2.3 财大气粗（需求方向的决策权）
决策权混乱是敏捷转型难以深入的一个常见原因，用Scrum的话来说，谁做PO呢？通常取决于谁出钱，谁控制时间表。
那么研发费用谁出？以下以银行为例讨论：
一类是业务部门不直接承担研发费用，技术部门的成本由银行列支
另一类是业务部门承担研发费用，技术部门的项目都由业务部门计价后发起，或者研发完成后对成本内部计价分摊到业务部门。
但是，业务部门不代表企业的整体利益（以银行业为例）
- 一是国家对银行的技术有严格监管，如服务连续性、信息安全、基础设施建设等等，专业性极强，很难把这些职责交给业务部门去承担；
- 二是银行的业务部门众多，难免受制于本部门的考核指标、短期利益，提出的很多需求连客户都代表不了，更无法代表银行的整体利益；
- 三是业务部门由一个个具体的人构成，难免受制于个人的能力和格局，提出的低价值甚至无价值需求比比皆是。
2.4 其他现象
- 紧急、常规版本怎么设置？开发过程怎么管，要不要版本经理？
- 但不是说给原来的职位角色都安上一个“敏捷”的帽子
- 度量报告及对外宣传怎么写？
- 隶属多供应商的外包人员怎么管理？
- 外包合同怎么签？
- 绩效怎么打？
2.5 大型（多团队）开发动态浮现出的靠谱实践
笔者在诺基亚西门子通信工作期间，亲历LeSS框架的生长过程，单个产品线的单个版本涉及数百人协作。这些不是顶层设计出来的，而是慢慢浮现生长的，例如：
- SCM 分支策略：同时存在多达10几个客户/版本分支而非特性分支，某一个变更需要明确哪些分支才能修改
- 线上缺陷的路由者：需要有人进行初步筛选分配到合适的产品线或团队
- 共享模块的负责人/PR Reviewer: 保证多团队修改的代码质量、内部开源模式
- 多级CI：缩短验证和反馈时间
- 虚拟架构团队或Cross-functional team：最好的架构出自于自组织团队
- 组织级障碍清单Impediment Backlog：汇总组织级障碍，拉通解决共同问题，深化变革（不要妄想套用一个静态的组织结构图）
- 内部敏捷社区：分享、传播、成长
- 大型遗留系统必须逐步补自动化测试和重构改造
- 绩效考评中更多增加团队的权重
2.6 越简单，越有效
敏捷原则#10：简明扼要，去掉不必要的工作，是敏捷的本质。
《道德经》曰：“大成若缺”。（数学家）哥德尔的不完备性定理：“无矛盾”和“完备”是不能同时满足的，既完美又统一是不存在的！
再看看SAFe之类大型敏捷，总是想“高大全”，把事情越搞越复杂，经不起实战检验，适得其反。能落地的一定是简单易懂，如果读者的产品确实涉及多团队协作，笔者个人比较推崇LeSS框架。
三、变革管理及一些原则
3.1 变革管理 vs.敏捷方法论
这是两个维度的事情。大家要的不仅是框架，还有咨询和转型路线图（How to do）
- 组织结构应该是动态的，守破离，不是卖一张Spotify结构图的事情
- 现状-中短期目标状态（如Scrum）-中期目标状态（多团队敏捷）-长期目标（基于原则生长，因地制宜）
- 转型路线图在其他类咨询内也能找到（如：人力资源转型、IPD导入）且差不多的
- 通常先培训和评估，然后小范围试点，接下来分批铺开
- 任何变革的关键是上层支持，获得权力来移除障碍，也涉及绩效考核的调整
- 所以变革转型路线图并非敏捷框架图的一部分，而只是咨询解决方案的一部分
3.2 从转型推进者的角度思考
- 打包服务方案让人安心
- 需要的不仅仅是敏捷框架，而是敏捷成熟度模型和路线图
- kotter 8步法
- 第一步紧迫感最重要，评估现状类似X光扫描，挖掘动力
- 拿到尚方宝剑
- 透明化工作和问题，并进行优先级排序
- 考虑奶酪分配
- 考虑如何表明（度量）进展和成效
3.3 妥协程度
作为方法论，既然定义的是一个未来理想状态，那就不要太妥协，因为标准（框架和实践）定为100分，现实中能做到60分就不错了。但如果标准（框架和实践）一开始就妥协为60分，现实中能做到20分就不错了。
另一方面，标准要高不能妥协，但实施路线图可以妥协和分阶段。咨询和转型范围不只是一个小系统，而是“整体”，整体意味着80%达标。一般用成熟度模型评估现状，应该包括：教学大纲和考卷两部分，每一级应能独立存在，有可见效果，才能锁定收益。
3.4 商业（研发）组织的共性问题
无论什么敏捷实践或框架，无非是通过建设四大能力域来解决组织的三大问题:
- 三大问题
- 决策
- 协作
- 能力
- 四大能力域
- 需求管理
- 项目管理
- 版本管理
- 质量管理
但敏捷实践的做法与CMMI/瀑布/PMP却是截然不同的，不要被夸夸奇谈的大老师蒙蔽了。尤其那些好处CMMI、敏捷、DevOps通吃的，下次遇到他就说“talk is cheap, show me the code”，写几把代码看看再说。
3.5 基于敏捷原则的Scaling
- 从一开始就要改变结构 （如定义Scrum角色，开发测试人员坐在一个团队中等）
- 组织结构以产品（客户价值）为中心进行调整
- 业务要买账，有动力深度采用
- 预算和绩效考核调整方向为鼓励相互支持与合作
- 解耦成小单元，加速信息流动和决策
- 规模化的关键就是“去规模化”
- LeSS is More, 组织设计也像我们做的产品一样以少为多，简单是敏捷的本质
- 扁平化组织结构，减少信息流动的中间商
- 闭环思维，快速反馈
- 流程有增也要有减
- 培养人
- 管理者先自我觉察，再以身作则，然后授权放手
- 持续集成CI，必须有！（而持续交付/DevOps却可以晚一点引入）
- 尽量小地引入变化（如仅少数团队从Scrum和一些XP实践开始）
- 先用Vertical方式来扩展，PO越少排序越容易。这种扩展方式从干系人角度看还是一个团队，如LeSS引入的Requirement Area
- （而Horizontal方式会引入更大的复杂度与成本。这种扩展方式从干系人角度看是多个团队，如SAFe引入的Program Level ）
- 以更灵活的方式签署外包合同
3.6 区分组织面对的是复杂问题还是繁杂问题？
参考Cynefin框架，很多问题实际上70年代的精益所要解决的问题，而还未到敏捷的范畴：
- 譬如加速财务流程，且要考虑低级错误、人为因素、场外因素
- 譬如团队要解决的只是基本项目管理和交付技能问题，连“瀑布”水平都还远未到达
敏捷的本意是从繁冗的流程与工具中解脱出来，以人为本。可以说是从正规军到特种兵的转变，但是现实中一些团队，不在于规模大小，还处在凭本能做事的起义军水平。在这种情况下，可能先要建立基本的能力和流程，或许瀑布什么的也不错呢。
| 起义军 | 正规军 | 特种兵 |
|---|---|---|
| 本能驱动开发 | 流程驱动开发 | 互动驱动开发 |
3.7 关键：Product Owner/业务需求方是火车头
将熊熊一窝。PO/需求方是决定方向的掌舵人，方向和决策有误，不会有好的成果，所有支持的人员和实践都是空谈
- 传统业务组织的需求方强势却说不清楚，IT团队理解分析能力不足却试图一次弄清楚，沟通链条长，再加上多部门决策不明，忽视产品经理/产品负责人培养产品的ownership（所有权与担当）缺失
- 各部门缺乏一致的战略目标和产品定义，所以只能依靠项目经理协调和推动，但是各方或许都藏着留一手
3.8 关键：需求澄清是头号问题，然后是工程能力
现实中，大部分团队还是要解决的是业务说明白，程序听明白的情况，需求澄清、缩短沟通链条的问题就已经不错了，即40年前精益思想所要解决的问题。
- 需求分析的方法沿用传统的SRS有耗时过长，阅读困难，覆盖不全等问题。从源头降低了整体工程的效率。
- 采用PRD的方法，去掉各种必要信息，只有原型加简单描述，把问题传递给下游，导致开发过程中反复确认，降低效率。
- 需求分析的读者有若干种，但是去只通过一种文档试图让所有人获取自己想要的信息。
- 缺少图形化的表达，通过大量文字，掩盖重要信息，增加理解困难。根源原因是大家惧怕画图。然而一图胜千言。
而TDD/重构等敏捷实践是非常好的，然而在上述主要矛盾解决之前，工程实践并未让人直接感受到收益，也难怪推行不畅了
3.9 关键：敏捷合同（外包开发供应商合作）
- 多供应商服务于多部门合作，需要由PO来牵头主导统一管理
- 敏捷合同形式：
- 包项目 Fixed Scope, Fixed Price
- 包人头，（带有奖惩的）T&M
- (例如以UCP计)单位工作固定价格
- 包人头，（带有预算上限的）T&M
- 共享损益的目标成本合同
3.10 关键：教练式领导力、文化、软技能
转型的边界就是管理者的理念、认识模式、习惯模式等等。面对新时代新形势，管理者的认知必须升级，教练式领导力可以了解一下。
专业教练通常会利用三个对齐：认知、利益、情感来帮助团队和组织心往一处想。别光谈利益，也别不谈利益。
管理者请永远记得”培养人”，这是长远的效益。
四、参考资料
- 常见大型敏捷框架和方法论比较： https://www.slideshare.net/BerndSchiffer/comparing-ways-to-scale-agile-at-agile-product-and-project-manager-meetup
- LAFABLE框架： http://www.lafable.com/，中文版：https://www.jackyshen.com/lafable-cn/
- 美国国防部2018-2019关于某空军项目失败的调查报告，由USAF首席软件官Nicolas Chaillian签发：https://software.af.mil/dsop/documents/
- 敏捷宣言17君子和其他敏捷知名人士公开反对SAFe文章合集：https://mp.weixin.qq.com/s/V-PojzupohQvI7NnAfhUHw，以及https://www.linkedin.com/pulse/safe-lean-agile-modern-management-theory-luca-minudel/
- 招商银行的技术业务关系思考，by 夏雷 https://mp.weixin.qq.com/s/9g8WOmNNXQiexTOGJHHMag
- 演讲《开思基于LeSS框架的敏捷组织规模化设计与思考》，by 曾庄俊、申健
- 系统性团队教练。曌乾组织教练、ICF国际专业教练、系统性团队教练。
- 《真正提升软件团队能力的方法，唯有极限编程》, by 熊节 https://mp.weixin.qq.com/s/2iC-MkFnTmymqoVhPExgqw
- 《你的Scrum够精益吗？》，by 申健 https://www.jackyshen.com/2017/08/02/is-your-Scrum-lean-enough/
- 需求分析工具箱 by 王洪亮 https://mp.weixin.qq.com/s/b7BboFQt9nNMO7vTGfTYdg
- TDD练功房 by 熊节 https://mp.weixin.qq.com/s/2w4tvsr5sK8_3Z6eeppWBQ
- 中国软件匠艺小组 by 李小波 https://codingstyle.cn
- 《甲乙方敏捷合同怎么签》，https://www.uperform.cn/agile-contract/
- 《敏捷合同》by Bas Vodde & Craig Larman, LeSS框架创始人, https://www.uperform.cn/introduction-to-agile-contracts-1/
- CCSTC商业应用学习发展项目，by 周冰
- 《技术团队管理者的软技能》，by 申健 https://www.jackyshen.com/2016/05/04/soft-skills-of-technical-leaders-and-managers
- 《Clean Agile》by Uncle Bob，敏捷宣言发起人之一，中文版《敏捷整洁之道》于2020年出版。
- 《做一些不必规模化的事情》by Paul Graham，Y Combinator孵化器创始人、《黑客与画家》作者，http://paulgraham.com/ds.html
- 《为什么用了Scrum但你的组织却还不敏捷？》Michael James，敏捷教练，《Scrum Master Checklist》作者，https://v.qq.com/x/page/t3024y3caup.html
- 《大规模Scrum》， by Bas Vodde & Craig Larman, LeSS框架创始人，《敏捷合同》作者
- 《赋能》（Team of teams），by Stanley McChrystal
- 敏捷精益平衡轮（成熟度模型）：https://www.uperform.cn/lean-agile-balanced-wheel/