有关SAFe实质概要介绍
面向企业的Scrum-SAFe
常规的敏捷框架适用于中小型项目团队，而且不具有扩展性。基于常规的敏捷框架，SAFe定义了一个可扩展的敏捷框架模型，它适用于大型团队的合作开发，可以提高团队之间的协作性，降低团队管理的复杂性。
若企业已从Portfolio（投资组合）、team（团队）、计划（Program）三个层面清晰定义了敏捷的框架，你可以按照以下的方式来定义和细化你的敏捷架构。
首先，SAFe架构Portfolio层，由PPM来负责定义和驱动投资策略如何形成和资金的组合形式，然后将其体现成为叙事诗(Epics)。一个Epics可以是一列单独的敏捷火车（Agile Release Train）来执行，也可以是几个火车的组合。Epics 是直接面向客户的，设计架构级别的业务解决方案。
接着，在第二层计划层由产品经理（Product Manager）负责把等待安排的计划（Backlog）进行排序，并且把投资策略转化成具体的新功能（Feature），同时和业务负责人一起设计出项目的愿景和路线。
最后，在第三层团队由产品负责人（Product Owner）和团队成员根据上面的定义细化出用户故事（User Story）和验收标准，开发团队可以从候选的用户故事里面优先选择可以提前开始的内容，其余的留到故事池里面等待后续的选择。
由此可见，SAFe 从三个层面保证了团队和企业的投资组合的最终愿景一致。同时，在实施过程中，需要一系列的里程碑事件来保证最终的实现和高层愿景设计的持续一致。而里程碑事件的制定主要通过计划发布（Release planning）和系统的展示（System Demo）来保证。
SAFe 的几个关键的角色：
SAFe 执行过程中，我们必须掌握几个关键角色：
Scrum 火车 工程师 (Release Train Engineer, 简称 RTE)
Scrum 主 管 (Scrum Master, 简称 SM)
如图 2 所示，基于 SAFe 的一个企业级的投资策略往往由多列敏捷发布火车（Agile Release Trains）来组成。
RTE 是一列敏捷火车（Train）总的 Scrum 主管，其中每列敏捷火车有一个 RTE 。请注意一列敏捷火车是由多个团队组成的。RTE 负责一列敏捷火车的总体执行，包括在执行过程中移除阻止火车前进的障碍，以及管理各个团队之间的集成（Integration）。
而 Scrum 主管 (Scrum Master) 是团队级别上 Scrum 的负责人，确保 scrum 的正确使用并使得 Scrum 的收益最大化。
图 2.大规模的敏捷的火车
SAFe 在计划管理面有一个时间控制，就是递增的 Sprint 计划（Program Increments，简称 PI）, 用来对一列敏捷火车的提交和发布时间进行总体规划。而在团队管理层主要是通过 Sprint 来做为一个时间箱标准，一般一个 Sprint 为 2 到 4 周。
SAFe 的计划和发布
让我们来认识下 SAFe 下和计划和发布相关的几个重要概念，这是实现和运用大规模的敏捷框架的最重要的部分。
递增的 Sprint 计划 （Program Increment, 简称 PI）
在首个 Sprint 开始之前，需要召开一个递增的 Sprint 计划。用来计划和确定一列敏捷发布火车的时间维度，通过定量的时间递增（Sprint）来保证编码实现和我们计划任务（Mission）的持续一致。如图 3 所示，一个 PI 周期可以是 8 到 12 周的长度，包含一个位于最末端的 IP (Innovation and Planning) Sprint。
PI 将在固定的时间箱内计划出一个可量化、可实现和最终可测量验收的计划路线图。
每个 Sprint 都需要经历同样的工作： 设计，编码和用户故事的测试。
任意一个 Sprint 都必须产出是对计划任务有价值的内容，在较短的时间箱（2 周）内防止实现和计划任务的偏离。一旦发现偏离，可以及时纠正。
所有的敏捷火车都共享同一个发布项目时间表，比如在 2016 年的 2 月份的发布是从 2015 年 11 月 15 日到 2016 年 2 月 19 日，那么所有的敏捷火车都遵守这个项目发布时间表。
在每列敏捷火车中，代码编写、提交和测试是基于单个 Sprint 时间范围内有节奏的进行，但是各个发布火车代码的最终发布和部署是根据实际情况来决定的。也就是说，并不是每个火车一定在 PI Sprint 后才可以发布。比如说，一列敏捷火车的代码在第二个 Sprint 可以完成，那么它就可以在第二个 Sprint 来发布。当然在部署到最终产品环境之前，一定要完成对所有的用户故事的验证测试。
图 3.SAFe 的递增的 Sprint 计划
创新和计划（Innovation and Planning， 简称 IP）
IP Spring 是位于整个增量计划周期里的最后一个阶段，也是两周的时长。
通常在第一周，我们会对整个新功能进行系统级别的验证和回归测试，估算下一次增量计划的缓冲时间，总结我们在实施项目过程中哪些是做的好的地方，可以继续；哪些地方需要改进，总结经验和教训。最后，我们可以对下一次的增量发布进行提前计划。
在 IP Spring 的第二周，可以在这个阶段对即将发布的代码进行规划，包括各个相关团队做发布包等的筹备。但是也有例外的情况，如果项目的时间比较紧张，开始和测试不能在 IP Sprint 完成，那么 IP sprint 的第一个周也可能用作一个回归测试。
发布计划（Release Planning）
在我们进入首个 Sprint 阶段之前，需要举行一个发布计划会议。
发布计划需要遵循下面的的几点：
一般来时，推荐进行时长两天的面对面的计划会议。
在上一个 PI 的基础上，计划下一个发布计划的 PI。
始终保持开发工作和业务需求以及计划一致，从而保证每个 Sprint 的产出对用户或者业务而言是有价值的。
对将要实现的新功能进行排序，筛选出优先级前十的功能和特征。
辨识出每个 sprint 的 sprint 目标、存在的风险，并且把各个团队之间的依赖和阻碍记录到计划展示板（Program Board）中。
确保大家对新功能的优先排序保持理解一致。
图 4. 计划展示板
敏捷的团队需要做哪些工作
在每个 Sprint 的开始阶段，需要进行 Sprint 计划会议。通过会议，确定在本 Sprint 需要完成哪些用户故事，保持开发人员，测试人员和相关人员的理解是一致的。以及用户故事提交顺序安排。如图 5 所示，对相临近的 Sprint 可以进行同样的计划和安排。不需要把所有 Sprint 都提前进行计划，可以遵循近详细，远粗略的原则。
另外，在实践中我们引入一个探针（Spike）的概念。如果在某个 Sprint 开始时，我们无法精确估算将要完成的工作量，那么我可以加一个探针来探测我们大约需要的工作量和时间。探针的使用一般在整个 PI 周期的第一个 Sprint 里使用。前提是可能需求不够清晰，也可能是我们对自己要进行的开发辅助工作量不好衡量。例如，我们在 Sprint 1 需要完成用户故事 A，但是在完成用户故事 A 前，需要做大量相关代码的重构工作，但是在用户故事里面这个工作没有体现，而且我们对代码重构的工作量也不能准确估算，这个时候我们可以引入探针。
每天一个 Scrum 会议， 简短的更新进度和问题。
在 Sprint 结束前，对所完成用户的故事进行展示。并且，开展一个回顾会议 (Respective)。
图 5. 团队计划
敏捷发布火车需要做哪些工作
每列敏捷的发布火车都需要做下面一些事情：
在正式的 Sprint 开始之前，需要召开发布计划会议（Release Planning）。在一个 PI 完成后，而下一个 PI 开始前，这个会议在上一个 PI 的 IP Sprint 期间召开。
由 RTE 来主持一个 Scrum 会议，会议的频率根据项目的具体情况而定。 会议参与人包括本次发布火车上各个团队的主要负责人、产品经理、产品负责人等必要的人员。会议的内容包含各个团队工作进度的更新、目前存在的主要问题等。如果问题是跨团队的，需要一起讨论解决方案
实践经验总结
本人进行的实践项目是一个面向 IBM 内部销售代表使用的 WEB 电子上午网站，需要支持客户在使用中提出的业务功能改进方案。业务功能的支持团队是由位于中国和美国的六个团队组成的 ， 我们采用了 SAFe 的框架来实施敏捷。请注意在此提供的经验总结仅供参考， 而不是必要的法则。那么，让我来开始分享下我们的经验吧。
必要的敏捷火车 scrum 会议
由 RTE 主持的 Scrum 会议上，RTE 维护出一个包含所有团队工作进度的列表。 让处于同一列敏捷火车的团队成员知道除了自己之外，其它团队的进度。如果发现某个团队的一些用户故事不能及时部署到对应的测试环境，RTE 需要调查原因，移除障碍，从而保证整列敏捷火车高速前进。如图 6 所示，在工作列表的纵列是本列敏捷火车的相关团队，横列是各个团队在不同测试环境下的工作进度。紫色的部分列出了没有完成的用户故事在某个 Sprint 下。浅蓝色代表用户故事已经提交到两个测试环境，但是测试还没有结束。浅黄色背景代表在用户验收环境的验收测试已经完成，可以部署到产品环境了。
工作进度列表对各个团队的工作状态显示的一目了然，最主要的是可以保证整个敏捷测试的策略是清晰的。例如，哪些部分现在可以测试了，哪些部分受到阻碍以及哪些部分有依赖，不能进行端到端的测试等。
工作进度列表是实时更新的，更新的频率取决于敏捷发布火车会议的频率。
图 6. 团队进度列表
知识全面的敏捷测试人员
在单个 Sprint 期间，敏捷测试包括用户故事的测试和端到端的测试。我们的项目涉及到六个开发团队。所以一个端到端测试，需要经历四五十个测试步骤。而我们的团队是分布到美国和中国的不同时区，所以在顺利的情况下，完成一个端到端的测试也需要至少两天的时间。那么在敏捷的框架下，我们的测试箱是有限的。如何在有限时间内完成如此步骤繁杂的测试呢？需要我们的测试人员对业务知识的了解是是全面的，拥有各个团队的相关业务知识背景和访问权限。
通常情况下，我们前端的测试人员会在中国时间内完成其它团队的测试，从而确保一个端到端的测试用例在一个工作日内完成。除非发现异常情况，那样我们必须等待美国其它团队的测试人员重新确认测试结果。
实时更新的用户故事
产品负责人把新功能分划成具体的用户故事过程中，用户故事不是一成不变的。随着需求的逐步确认和沟通，用户故事的内容和验收标准需要实时更新。请注意，通过问题队列来跟踪需求是不好的敏捷实践。它会导致敏捷火车上的相关人员对用户故事有不用的理解。
产品负责人有责任实时更新用户故事和验收标准。
结束语
通过上述对 SAFe 基本特征的介绍，以及项目实践经验的分享，读者可以对 SAFe 的概念和实施方式有一个基本的了解，在将来项目实施大规模的敏捷框架时，可以借鉴相关的实践经验。
本文摘自IBM的网站