很长时间以来，提到敏捷，心里实在有点不是滋味。敏捷，好是真好，说起来，哪儿哪儿都好。可做起来，怎么就是不得劲儿呢。
1
形容词——敏捷
据我在汽车行业里的观察，除了敏捷宣言和Scrum的3355形式具备比较典型的敏捷理论意义外，其余的普遍得不到大家的共识与认可，也鲜见有效落地的项目。
去年写了一篇题为《感觉汽车圈里的这一波敏捷风快过去了》的文章，里面把敏捷视为mindset，观点一直没有太大变化，甚至观念还逐渐有了一些微妙的、更悲观的调整，所以，后面我和别人交流时，粗暴地把敏捷视为了一个“形容词”——敏捷的，即抛开敏捷方法本身。
一时间，我看到敏捷相关的文章就会跳过去，不是我瞧不上敏捷（我还不配），而是单独谈敏捷实在是太空中楼阁，敏捷的道理前两年就已经懂了，互联网的成功案例也实在是难以迁移到汽车行业（重点关注大型主机厂和零部件），现在我们需要的是符合汽车行业与产品的最佳实践，以及既懂汽车又懂软件的人才......
2
再给敏捷一次机会
以前接触的敏捷呢，大抵是以Scrum为代表的小规模敏捷，各路英豪基本都套过壳了、实践过了，很多人说没啥用，当然，也有的人在ppt里写的有用。
实际上，小团队天然就是敏捷的，人少，事少，几个人坐在一起开会、加班就能快速响应，离客户也非常近，敏捷方法可以一定程度规整下，但本身似乎不起决定作用。
可复杂的大团队呢，天然就会慢，天然就复杂，天然就会深度依赖。而现如今的汽车软件供应链就是典型的大团队，着实难以应对。
反复纠缠之下，我是对小团队小规模敏捷没啥耐心了，而正在我与敏捷彻底决裂的最后关口，最近，参与到了一个SAFe转型项目，些许点滴让我意识到，似乎这些因素确实会对大团队汽车软件开发有些益处，这给我带来了兴致。于是，我私自决定，再给敏捷一次机会，但是给SAFe的。
下面我们会初步总结一些亮点。
3
SAFe的几个主要增量与亮点
精益、价值、互动、解耦、小颗粒、迭代、增量……这些理念都是所有敏捷方法论提及的，SAFe也不例外，我们不多讲，我们站在汽车行业的立场，把一些主要增量或者亮点提炼出来。
SAFe有着自己的价值观、原则、方法与实践，进而形成一整套有逻辑层次的框架体系，但出于实用的目的，且只着眼于关键点，我们就不做分类，仅做平级罗列。
协调对齐
信息透明
快速集成
节奏同步
给知识工作者自由度
设计敏捷
敏捷发布火车
PI（Planning Interval）规划会议
4
SAFe导入汽车企业的对应价值
在这一小节，我们开始将上面总结出来的8个点与汽车企业匹配，尝试看其适用性。
4.1 协调对齐
小团队不太存在这种问题，一个5个人的团队，喊一嗓子就知道对方怎么想的、要做什么了。
可当团队扩充到50人、200人、1000人、10000人时呢，就是喊破喉咙也像是在玩传声筒的游戏，到最后都传得七零八落，甚至还是跨国、跨公司，想打个电话都得考虑时差。
这让我想起以前在一家大型外企做项目经理时的经历，公司流程规定，PM必须一周组织一次会议，目的就是对齐信息与协调行动，虽然显得粗笨，但倒是个最常见的解决方法。
汽车企业基本就属于这类跨组织的大团队，对齐团队的想法、观念，观点极为困难，又极为有价值，SAFe把这一点提出来，算是切中了一些要害。
协调对齐会涉及到方方面面，这里重点讲以下几点：
背景信息的对齐。在大型汽车组织里，尤其是开发、测试等细分领域的角色，往往处于领任务的小视角里，不知道为什么做，不知道为什么这个时间做，也不知道做给谁。我们不谈使命、愿景、价值观，至少在不知道任何背景信息的前提下，人的主观能动性会很差。
统一组织沟通语言。初到一家大型外企时，我们通常需要一套术语表来快速入门，这套术语表就是这个组织的沟通语言之一，它的存在就不至于让我们面临我讲的ABC和你讲的ABC是两回事这种情景。再举个软件的例子，软件开发经常会划分各类feature、system、sub-system、module、unit名称，这些名称的对齐与映射就是一个非常提升效率的工作。
深入理解客户。广义来看，客户是全方位的，只要你要交付结果给对方验收，对方就是你的客户。这样的话，汽车体系里会有大量的“客户”存在，把对客户理解的一致拿出来强调也应是题中之义。
持续检验对齐程度。时局动荡不安，公司内部也是风起云涌，对齐仅仅是暂时的，我们需要不断对齐。这让人本能地会想到多开会，但是否有更好的实践，我们暂且不表，继续往下看。
4.2 信息透明
透明并不新鲜，所有的敏捷都在强调透明，但还是觉得这对大规模团队敏捷转型的意义不凡。
看到一个说法是，管理者的权力之一是信息差，所谓信息差就是话语权。话没毛病，毛病是，我们经常会看到一种本该令人匪夷所思却又被教育“年轻人不要太较真"的现象，比如，A团队正在做一件B团队半年前已经证明没意义的事，而C团队正在用另一种思路做同样的事，但是，很有默契的是，ABC这三个团队都悄悄地等待一鸣惊人，见面时还要微笑致意，我啥都没干。
信息不共享，这是一种很可怕的文化，而这种文化在汽车企业里比比皆是。期待能设计一种可视化的工作流程或者工具来一定程度打破这种无用的壁垒。
4.3 快速集成
看到这一条，我甚至有点兴奋。
为什么很多互联网出身的产品经理讲的东西很难引起汽车人的共鸣？就是因为汽车不是一个产品，而是一大堆产品的集合，而这集合又不是简单堆叠，是有机的集成，是磕磕碰碰的集成，是手心手背都是肉的取舍下的集成，是只有集成后才能体现功能与性能的集成。这大大小小的各层级集成占了汽车开发的半壁江山。
此外，我们汽车软件开发经常遇到的一个瓶颈是，没有ECU、没有线束、没有周边件、没有台架、没有整车环境，这所有的东西都代表了一层层集成，所以，集成既是目标，也是实现目标的手段。
因此，加大开发环境的投入，支持快速不断地集成，对于规模化敏捷颇为必要，要避免憋大招。
4.4 节奏同步
最早接触节奏（时间盒）这个概念是在几年前和一个宣称在走敏捷的印度软件团队合作的故事里。
当时，我的项目非常着急，因为要赶客户一个月后的交样，一个关键环节是需要印度软件团队完成某个重要feature的上线，经过千辛万苦，恰好匹配上了印度团队的2周sprint时间盒。
可是，还没等气儿喘匀，软件项目经理就带来个噩耗，原来忙中出错，给印度团队的需求基线传递错误......
再去沟通，告诉我们两周后才接新需求。然后，我们只能坐在那里等着交样延期......尽管后来通过其他方法解决了问题，但当时这个“时间盒”的说法让我觉得既蠢且坏。
后来慢慢知道，印度团队是同步支持全球很多项目的软件开发，坚守时间盒就是保持固定的节奏，节奏的稳定会让很多相关方的规划能够执行。抛开我的单个项目的立场，放在整个组织看，理论上，是能够保持更全面的稳定价值交付的。
在整车软件开发中，节奏的稳定可以让所有有依赖关系的团队能够稳定可预测地协作，这是节奏的意义。
除了单线有节奏，还有多线的同步，这是SAFe在这里的关键点，这让汽车软件多至几十条线的开发能够被统一调度，也有利于我们的跨职能权衡，以及4.3讲的集成，否则，各层级集成就会存在大量的等待。
4.5 给知识工作者自由度
特别是软件开发相关人员，是非常典型的知识工作者，靠脑力活动来实现价值增值。
很多管理者有着非常大的ego，自视甚高，不可否认，管理者有着相对宏观的视角，但是对于如何处理手里的工作，没有人比员工自己更有发言权。
给知识工作者信息、自由度、支持，并释放他们的激情与活力，这应该是一个优秀管理者应该且能够做到的。否则，员工只能把精力花在去证明你是对的上面了。
4.6 设计敏捷
说起这个，我非常快速地想到了防错，这种源自机械结构的设计理念可以很方便用来解释“设计敏捷”的内涵。
对于上图左侧的ABC形状，怎么才能不放错呢？染色？教育？培训？练习？实际上，最有效的方式是放不错，就像右侧那张图。
设计敏捷的内涵也在于此，从架构、软件、工具本身的设计上就具备敏捷的特性，比如，常讲的解耦与自动化。
设计水平的突破将会让效率有数量级的跃迁，这个不多讲，需要沉淀及量变引发质变。
4.7 敏捷发布火车
这个名词是SAFe比较典型的增量之一。
按照SAFe的理念，一辆敏捷发布火车是指由5~12个敏捷团队（PO、Scrum Master、Team）组成的虚拟组织（50~125+人），利用时间盒迭代来保持节奏，并过PI规划会议来实现同步，以及通过敏捷发布火车待办事项来对齐共同目标。
从SAFe的角度，提供了5类角色的定义：
发布火车工程师（Release Train Engineer，RTE）是敏捷发布火车的教练。
产品管理（Product Management，PM）拥有、定义敏捷发布火车待办事项，并确定其优先级。
系统架构师（System Architect，SA）为敏捷发布火车相关团队提供架构指导和技术支持。
系统团队（System Team）提供流程和工具，以便尽早、频繁地集成与评估资产。
业务负责人（Business Owner，BO）是敏捷发布火车的关键利益相关者。
此外，还提供了4类团队定义：
流对齐团队：围绕工作流程进行组织的团队，能够为客户或最终用户直接交付价值。
复杂子系统团队（专项团队）：围绕特定子系统进行组织的团队，这类子系统需要深厚的专业技能和专业知识提供支持。
平台团队：围绕平台开发和支持进行组织的团队，这类平台负责为其他团队提供服务。
赋能团队：这类团队可利用其专业能力协助其他团队，帮助其他团队熟练掌握新技术。
客观来看，这些角色和团队在传统汽车电子企业里本身也几乎都存在，并不具备明显的特殊性。
当然，敏捷发布火车仍然颇有意义，主要价值贡献在于以下3点：
提出了一种相互依赖的多线开发团队融合的形式，比较适合复杂系统化产品的开发。
通过节奏同步保证了可预期的价值交付，并减少了等待浪费。
这种组织模式有助于直接交付价值，较容易实现劲往一处使和缩短交流路径。
4.8 PI规划会议
对比敏捷发布火车，PI是另一个SAFe更核心的增量，以及最具代表性的形式。
PI规划会议是一项有固定节奏的活动，可作为敏捷发布火车的心跳，确保敏捷发布火车每8~12周举办一次为期两天的PI规划会议，会议上可以进行feature优先级定义、故事点估算以及处理接口与依赖等事务。
这种强制的见面会能够提供一个沟通平台，让大家对齐、协调，并快速决策。
不过，几次实际体验下来，效果虽逐渐好转，但还不尽如人意，比我预想的要差一些，多数人还是无法被调动起积极性来，仍然需要持续摸索、调整。
5
写在最后
说句开玩笑的话，SAFe是让我对敏捷的印象有了很大的改观。
我们前面总结的SAFe的8个亮点（协调对齐、信息透明、快速集成、节奏同步、给知识工作者自由度、设计敏捷、敏捷发布火车、PI规划会议）确实能对应上大型汽车组织的通病和痛点。
但实践下来，仍然感受到很大的不适，需要适配。截至目前，个人的观感分两部分：
SAFe值得一试。
仍然需要大量裁剪。
完
