相信大家一定被上文SAFe的复杂“震慑”到了，尤其是那张大图。
但不管体系设计多么复杂，基本的元素还是“事”和“人”，今天我们来看看SAFe里有哪些“大事儿”要发生。
前文介绍了SAFe整体框架分为这么几层：基础层，团队层，项目群层，价值流层（可选），投资组合层。让我们一个一个来看。
基础层
基础层虽然没有具体的实践，但是其中包含了一些支撑SAFe体系的“底层逻辑”，我们挑重点简单展开一下。
SAFe的底层理念很简单：作为团队的推进者，精益-敏捷开发方法的采纳、成功运用和持续改进的最终责任是由企业的管理层、领导人和高管们来承担的，只有他们可以改变和持续改进大家所使用的系统。
基础层需要老板们做的事情，就是理解精益-敏捷思想，不断做出改善行动。
SAFe的核心价值观：协调一致、内建质量、透明、项目群执行。
值得一提的是，SAFe都把“协调一致，项目群执行”放到核心价值观里了，我不知道项目经理和PMO们在焦虑什么？或者有什么必要去讨论敏捷模式与PMO能不能共存？这不是大家最擅长的嘛！
注：这个话题我们后续专题讨论，你应该还记得我们是个PMO的专栏对吧？^_^
另外，基础层提到要组织和运营实践社区。呃，又是社区......记得LeSS也模模糊糊提过对吧？SAFe篇幅更多，一定很重要。先记下来。
实施SAFe步骤1-2-3：1. 培训实施人员和精益-敏捷变革驱动者（忽悠老板的人）2. 培训企业高管、经理和主管（忽悠老板）3. 培训团队，启动敏捷发布火车（忽悠团队）
嗯？有内味儿了......健身、游泳有需要么？
团队层
迭代周期
SAFe的基础是敏捷团队，所以团队层最基础的活动是迭代。SAFe不管敏捷团队使用的是Scrum还是看板，明确了迭代周期为2周。
注：看板的方式本质上是没有迭代周期概念的，但仍建议设置一个固定周期作为工作输出和检视的点。这一点单独运作看板团队同样适用。
关于迭代周期，多啰嗦几句。
在笔者的工作经历中，动不动就有同学过来说：“大（鼻子）老师，我们能把迭代周期稍微调一下么？”“恐怕不行......”“敏捷这么死板么？”“......”
笔者前面《玩转Scrum》的文章中提过，Scrum没有规定迭代周期，只是建议2~4周。LeSS同样如此。但SAFe为什么明确了呢？这真的不是僵化！
在笔者推广敏捷的经历中，在团队数量比较少的时候，其实对于团队迭代周期的控制是相对较松的，我们试过1周，也试过3周，我也鼓励团队去尝试不同的迭代周期，从而找到最适合自己团队的节奏。
但团队大了，一定要做控制。迭代周期是心跳，不能轻易改变。
记得LeSS和SAFe的原则都提过通过“系统的视角”来看问题么？也就是说，某一个流程和方案，对于局部可能不是最优，但对整体是最优的，这时候我们可能会牺牲局部的体验。
这点笔者非常有共鸣，因为流程的根本意义是为了更大范围的协作。
我非常理解这些团队的诉求：有些团队业务刚刚起步，希望更短平快的优化自己的产品，自然希望迭代周期短一点，迅速试错；有些业务已经比较成熟，相对功能比较复杂，就希望迭代周期稍微长一点......
但，我为什么卡这么死，就是因为团队规模大了，需要适配的场景太多，众口难调。而2周是笔者多年实践经验下来认为是最优的一个方案，既不会太长，也不会太短，基本能够满足绝大多数团队的要求。这一点与SAFe的观点不谋而合。
对于不适的团队怎么办？没办法，去适应。
对于想用1周的团队，迭代和发布从来都不是耦合的，你可以一个迭代发布两次；对于想用3周的团队，合理拆分需求，如果实在拆不了，先上能上的功能，不是可以更早的给用户带来价值么？
计划迭代
在规划迭代会议期间，SAFe提及了敏捷团队需要讨论实施方案、技术问题、非功能性需求和依赖关系（依赖关系是笔者想特意强调的）。这是相较于LeSS不同的地方。
另外，需要特别提及的是，SAFe强调了故事点必须标准化，并推荐使用“理想人天”。嗯，这也与笔者推荐的单个敏捷团队的评估故事方法相似。
其目的是在大规模团队中统一语汇，更好的做更高层次的评估。当然，毫无疑问，也需要避免高层对相关估算先入为主认为是“板上钉钉”的，一旦有调整就“雷霆万钧”。P.S.: 现在倒是有点理解为什么SAFe那么强调培训了......
内建质量
除了迭代的常规事项之外，毫无疑问，在团队层SAFe也非常强调内建质量的相关活动。因为“你不能规模化糟糕的代码”，大规模团队是“糟糕代码”的“放大器”。
所以，持续集成，测试驱动开发，重构，结对编程等工程实践都要考虑加以运用；包括频繁的系统级集成测试（含硬件，固件，软件等），设计验证等与固件或硬件等后期变更成本较高的研发活动也是需要考虑的范畴。
其他迭代活动与单个敏捷团队活动相同，不做赘述。
一句话，在团队层中，SAfe强调所有敏捷团队应该是共同计划、共同集成和演示、共同学习。保持迭代节奏同步。
项目群层
虽然SAFe中使用“项目群层”这个术语，但实际上它不像传统的“项目群”那样被赋予明确的开始结束时间和临时分配的资源。
在项目群层几乎所有的活动都是围绕“敏捷发布火车”展开的。与之相比，敏捷发布火车均有更长的生命周期、组织结构和更持久的自我管理和使命。
敏捷发布火车（Agile Release Train）
敏捷发布火车是SAFe体系中最重要的价值交付体。每一列火车都是一个长期存在的、自组织的敏捷团队集合，它是一个虚拟的组织（通常包含5~12个敏捷团队，50~125人），这些团队一起做计划、给出承诺并执行工作。
敏捷发布火车的隐喻还是非常形象的：
火车按照可靠的时间表离开和到达车站，这样给项目提供了固定的开发节奏，标准的敏捷发布火车速度和可预测的计划。火车不等人。
所有的“货物”，包括原型、模型、软件、硬件和文档等，都包含在火车上。
无论人员的人事汇报结构如何，火车上的大部分人员都是全职的。如果你想参加相应的工作，就需要加入到火车上。
敏捷发布火车的创建是围绕企业主要的价值流来进行的，创建后的敏捷发布火车独立运作，并通过构建解决方案向最终用户提供收益，从而实现团队交付价值的承诺。
ART有点类似LeSS Huge中“Product Area”的概念。
PI（Program Increment）
PI可以会聚多个团队，多个迭代，让企业精力集中在一个时间盒（默认10周，即5个Sprint，含一个IP[创新与计划迭代]）内进行价值交付。
如果说敏捷发布火车是SAFe交付价值流的表现形式，比如我们开通了京沪高铁，那么PI则是具体用于交付价值的时间盒，好比我们送的是乘客还是货物是由PI决定的。
我的理解，也可以把PI看做是一个迭代（或者Sprint），配合一些支持大型敏捷团队必须的活动即可。
顺着这个思路，我们对应着单个迭代看一下PI的相关活动。
Sprint Planning 对应PI计划会议；Sprint Demo 对应PI的系统演示；每日站会对应PI的Scrum of Scrums和PO同步会议，只是建议频率相对低一点，不是每日；回顾是通过检视和调整来实现的，通常会包含系统演示。
同样，在单个敏捷团队中的待办事项列表梳理对应的是准备PI计划会议，而且是在PI中敏捷团队待办事项列表梳理的前置；因为PI涉及的团队及发布内容较多，增加了一个专门的发布管理会议，也是非常合乎逻辑的延展。
只要深入理解了单个敏捷团队各个活动背后的逻辑，其实SAFe也没多什么新东西，Right?
当然，因为敏捷团队的数量增多，任何一个活动与单个敏捷团队的活动开展都有些区别，笔者在这里无意于把PI的每个活动特别详细的展开介绍，只是跟大家“划划重点”。
PI计划会议：如下图，需要输出PI的目标，以及每个团队多个Sprint的计划（5个Sprint），红线意味着重要依赖。
Scrum of Scrums：通常每周或者按需要召开，持续协调处理敏捷发布火车上的依赖关系。
PO同步会议：每周或者按需要召开，根据PI目标讲敏捷交付火车的进展情况进行可视化呈现，讨论特性开发中的问题或机会并评估任何的范围调整。
以上两个活动，跟单个敏捷团队站会功能何其相似？
系统演示：同样每两周举行一次。每个迭代至少集成一次。
准备PI计划会议：除了待办事项的准备就绪，通常还需要与管理层达成一致：这么多团队的人力要真金白银的砸下去了。以及推进时间需要的后勤保障的准备就绪等。
架构跑道
架构跑道是SAFe中实现敏捷架构概念的一种方式。
敏捷开发避免了瀑布模型的思维方式和大量前期设计，取而代之的“涌现式设计”的方式。这种新的实践方法在一定程度上工作的很好，在大型团队和规模化团队也逐渐暴露了以下问题：
过度的设计返工和延迟，出现了流动瓶颈问题
使用不同的架构组件支持相同的能力，增加了维护成本
团队之间的协作和同步减少了
速度降低了，系统很难进行集成和验证
系统的质量退化（非功能性需求）；系统组件重用度低，实现中出现冗余
其实也非常好理解，在大型团队的工作环境中，对所有团队而言，让他们自己预测发生在其所处环境之外的变化是不可能的，同样让单个团队理解整个系统来避免冗余产生和设计实现的冲突也是不现实的。
基于这种原因，团队需要进行意图架构，并把意图架构和涌现式设计结合起来。
当建立创新性平台或者进行全新开发时，系统或解决方案架构师/工程师将承担初试定义和构建架构跑道的责任；但这些系统架构的成功随着时间的推移，自然而然地被逐渐消耗殆尽。所以，架构师/工程师和敏捷团队应该持续评估和同PI一同实现架构的迭代。
跨层级面板
跨层级面板的出现也非常自然。既然PI或者敏捷发布发布火车是一个涉及到那么多人，那么长时间的一个开发活动，相关的一些支持工作也不容忽视。比如，如何更好的让大家清楚目前PI和敏捷发布火车运行的怎么样，怎么进一步提升敏捷发布火车本身的效率（高铁速度怎么进一步提升）等等......要回答这些问题，跨层级面板就显得非常重要了。
所以SAFE在其主要层级之外，也包含了跨层级面板这一内容，主要包括：
DevOps：一些基础设施支持和系统团队（如工作环境，发布工具支持的团队等），确保敏捷发布这趟高铁线路和车况安全稳定。
发布管理：有助于解决方案设计的计划、管理和治理。一趟ART上有5~12个团队了，需要专门进行治理。
共享服务和用户体验：通用能力的支持。这些能力的抽象，有利于减少投入和提升支持效率。
愿景、线路图、里程牌和发布：用于明确我们未来要去哪里，实现路径，当前已经到达的状态。有点类似传统项目执行看板。
度量：一系列量化的方式来看我们的执行过程效率如何，趋势怎样，改进的措施是否奏效等。类比于单个团队工作的度量指标对于单个团队的作用。
价值流层
一句话概括，价值流层是为了那些大型和复杂方案的系统构建者专门设置的，这些方案实现需要多个ART以及供应商的共同努力。在SAFe中，价值流层是可选的。
因为有可能涉及多趟ART及与硬件、固件研发团队乃至外部供应商团队的协作，所以价值流层聚焦于解决超大型系统的问题，没有这么复杂的系统自然可以略过。
大鼻子解读：价值流层就是对于有可能与软件敏捷研发团队特性不同（包括交付物、工作节奏、企业文化等）的团队之间的协作适配。所以，更重视解决方案这个层面的整合与管理。
PI计划前、后会议
其实是项目群层PI计划会议的输入和输出后的行动，SAFe把它放在了价值流层（如果没有价值流层，自然就是在项目群层进行了）。
PI计划前、后会议有助于大型价值流中的多个敏捷发布火车和供应商，一起协作创建下一个PI计划。PI计划前会议，用于协调ART计划会议中需要的输入目标、关键里程碑、解决方案上下文以及业务上下文。PI计划后会议结束时，应该对一系列的价值流PI目标和下次解决方案演示会议上展示的内容达成共识。
输入：价值流路线图、愿景、解决方案意图、价值流待办事项列表中高优先级的能力。
与会者包括：客户、价值流利益相关者，以及所有ART和供应商的代表。
输出：一系列汇总的服务于价值流的目标；一个价值流计划公告板；一次投票表决（表达对计划的信心）。
价值流增量和解决方案演示
这个层级的Demo即价值流增量和解决方案层面的演示。高层管理者和利益相关者在更广泛的解决方案环境中评审进展状况。它也可以用来通告是否继续、调整，甚至取消原有方案，或者改变价值流的预算。
投资组合层
是SAFe框架中的最高层级，它提供了围绕一个或者多个价值流构成的精益-敏捷企业的基本框架，基于每一个价值流所开发的系统或解决方案都需要 满足企业的战略意图。
SAFe投资组合层包含了为实现企业战略目标而开发的系统和解决方案所需要的人员和流程。投资组合最基本的元素是一个或者多个价值流，每一个价值流为实现交付价值的方案提供了必需的人力或者其他资源所需的资金。
提炼一下，笔者认为，宏观上说，在投资组合层所做的事情就是如何将企业战略拆分落地成一个个价值流，提供最优的价值流组合方案和提供相关的预算保障。自然也需要从宏观的角度来监控价值流输出情况和效果。
从这一点上来看，SAFe这一层与传统企业或者传统项目群投资组合管理所做的事情基本一样，只是用敏捷-精益的方式去实现而已。
针对这一层，SAFe提供了适用于各种业务形态（小型，大型，超大型业务）企业的解决方案。
通过提炼企业战略主题，形成业务史诗；将业务史诗进一步拆分成价值流/价值流组合（视业务负责程度）并给予一定的企业预算分配。通过价值流交付的固定周期（PI的节奏）获得反馈，从而管理和实现公司维度价值流交付的最大化输出，达成企业战略意图。
所以这一层的“大事儿”就是以下几项：
链接企业目标
投资组合层与企业目标有双向的联系。一方面，战略主题提供明确的、条目化的业务目标，这些业务目标将投资组合与企业持续演进的业务战略目标进行连接。另一方面，投资组合层将投资组合现状持续不断地反馈回企业。
大鼻子解读：通过敏捷的方式，迅速获得反馈并及时调整。
项目群投资组合管理
是由项目群投资组合管理部门（PPM）来负责的。通常，由项目群管理办公室（PMO）协助企业高管和业务管理人员，展开以上工作并共同承担指导项目群执行和治理的责任。
大鼻子解读：这与传统企业和项目群管理方式类似，只是SAFe的项目群是以敏捷的方式展开而已。星星还是那颗星星，PMO还是那个PMO......
管理投资组合史诗的流动
其实就是确保价值以最优的方式流动，而不是阻塞。需要确保相关信息对于所有的利益相关者可见，并提供了在制品限制（预算），以确保按实际价值流的容量来供给需求。
大鼻子解读：第一部分是规划，第二部分是支撑，这一趴就是如何落地。
SAFe足够宏大，但抽丝剥茧，我们也一点一点把它啃下来了，不是么？
消化一下，下面我们来“拜见”SAFe“大人”！^_^
