SAFe（Scaled Agile Framework，规模化敏捷框架）
常规的敏捷框架适用于中小型项目团队，而且不具有扩展性。基于常规的敏捷框架，SAFe 定义了一个可扩展的敏捷框架模型，它适用于大型团队的合作开发，可以帮助提高团队之间的协作性，降低团队管理的复杂性。
精益企业的规模化敏捷框架（SAFe）是一个可扩展/可配置的框架，可帮助企业在最短的可持续交付周期内以最优化质量和最大化价值交付世界上最重要的系统。它可以帮助多个敏捷团队甚至更大规模的集团组织进行协调同步，协作和交付。
SAFe将敏捷的力量，精益产品开发，系统化思维相结合。其广泛的知识体系基于精益敏捷原则和价值观，它们更好地指导了业务所需的角色，职责，工件和活动。
配置
SAFe支持各种开发环境，具有四种开箱即用配置，具体配置项目如下：
必不可少的最简SAFe
基于投资组合SAFe
基于大型解决方案SAFe
全局完整的SAFe
团队组织和计划实施，两个层面共同构成了一个名为Agile Release Train（ART 敏捷发布火车）的结构。ART是针对于多个团队，利益相关方和项目资源的持续化解决方案任务列表。
目前，你只需要把它当做传统SCRUM里面的Product BackLog来理解即可，即我们实施解决方案，需要完成哪些研发，设计，测试任务。
ART通过共同愿景，路线图和积压计划表，使管理层，团队和利益相关方与共同使命保持一致；
ART提供了可持续发展价值所需的上层功能（用户功能）和底层推动支持（技术基础设施）；
ART工作推进中，团队迭代是同步的，使用相同的持续时间，相同的开始和结束日期；
每个ART周期在两周左右，每个周期都提供有价值且经过测试的系统级增量；
程序增量（PI）为规划，执行，检查和调整工作提供了更长，更固定，更有节奏的时间周期；
ART使用大规模的面对面程序增量研发计划，来确保团队协作、进度基线对齐和快速适应变更；
ART建立并维护一个持续的交付渠道，以便于定期开发和释放有价值的增量。这使团队可以随时根据市场需求发布自己想要的解决方案；
ART为系统架构设计和使用体验（UX）设计提供了通用且一致的方法；
ART融合DevOps持续交付。DevOps是一种思维方式，文化和技术实践，提供了计划，开发，测试，部署，发布和维护解决方案。同时提供了所有人之间沟通，集成，自动化和密切合作的可能性；
角色
通过必要的协调和治理，以下角色有助于使多个团队与共同使命和组织愿景保持一致：
系统架构师/工程师
是一个应用系统化思维的个人或小型跨学科团队。充当此角色的人员定义了系统的整体架构，确定了新的非功能需求（NFR），确定了关键元素和子系统，并确定了它们之间的接口和协作规范。
产品经理
提供客户的内部声音，与产品所有者和客户合作，以沟通了解他们的需求，从而定义系统功能并参与验证。产品经理负责管理产品的积压计划表，并使用经济学方法确定功能和其推动因素的优先级。
首席Scrum Master
无实权领袖，也叫发布快线工程师（RTE）。此角色的主要工作是使用诸如计划看板，检查调整（I＆A）事件，PI计划等机制来帮助改善团队工作计划中的价值流动，使其更加流畅。
商业负责人
代表利益相关方的小组，他们对治理，合规和投资等业务和技术负责，为ART开发的解决方案买单。他们是重要的利益相关者，评估项目适用性并积极参与ART活动。
客户
是价值的最终裁定者，是敏捷开发流程和价值流的重要组成部分。他们在SFAe中负有特定的责任和角色定位。
上面提及的三个要素有助于协调ART的推进，它们分别是：PI规划，系统演示和I＆A事件。接下来我会将简要介绍所有要素。
SAFe的十大关键要素
哪怕是一个最简的SAFe也确定了10个关键要素，这些要素适用于所有SAFe配置。这对于成功的精益和敏捷开发是必不可少的。如果企业在建立新解决方案时融入这些元素，那么他们将很好地获得SAFe的全部优势。
1. 精益敏捷原则
其中包含了九个小的基本原则，这些原则合集为SAFe实践提供了信息。如果这些实践不能直接适用于当下特定的环境，那么基本原则就会为他们指出连续的明确的发展路径，确保他们在尽可能短的时间内开始尝试这些实践。
2. 完备的敏捷和培训团队
被完备组建的敏捷与培训团队，都需要产生一个可行的，经过测试的解决方案增量。团队内实施跨职能，自组织和自管理，ART允许价值更快地流动，同时最小化成本。产品经理，系统架构师/工程师和RTE提供权限并简化开发过程。产品所有者和Scrum Masters帮助开发团队实现其目标。客户在整个开发过程中发挥着关键作用。
3. 节奏和同步
节奏是一种固定的，周期性模式的事件，就像是项目进展中的心跳一样重要。它确保定期举行各种团队会议，制定计划和大型解决方案活动，使其成为团队中默认的常规（例如每日站立，PI计划，系统演示，I＆A事件，解决方案演示）。同步则允许从多个方面理解并解决问题。 例如，它将一个系统中的不同资产结合在一起，以评估解决方案的可行性。
4. 程序增量（PI）计划
PI的基石，SAFe中没有比PI规划更强大的事件。此活动是ART的心跳活动，本计划的制定，共识与实施，使ART的所有团在未来愿景上保持一致。
5. DevOps和可交付性
SAFe接近于DevOps的“CALMeR —— culture, automation, Lean-flow, measurement, recovery”方法，这使企业能够缩小开发和运营的差距。可交付性侧重于企业根据市场需求更频繁地为客户提供价值的能力。DevOps和可交付性共同作用，使组织能够通过频繁发布和快速验证来实现更好的经济效益。
6. 系统演示
ART进展的主要衡量标准，是系统演示中解决方案提供的客观证据。每两周，敏捷发布列车（ART）上的所有团队都要整合工作，并会向利益相关方进行演示，然后利益相关方提供反馈，帮助团队保持正确的前进防线并及时纠正偏差。
7. 检查和调整（I＆A）
每个程序增量迭代（PI）都要周期性举办的重要活动。I＆A是为了定期反映问题，收集数据，解决问题、汇集团队和利益相关方一起评估解决方案。这是一个定期机会，有助于提高下一个PI的速度，质量和可靠性。
8. 创新和规划（IP）迭代
每次程序增量迭代中，为了多方目的，计划至少一次创新和规划迭代（PI）。它可以看作为了实现PI目标的估算缓冲区，并为创新，团队继续教育，PI规划和I＆A活动提供时间。这就像是坦克中的额外燃料：如果没有它，我们的敏捷发布火车可能会开始在“极端的暴政”迭代失衡
9. 架构跑道
架构跑道由现有的代码，组件和技术基建储备组成。这些代码，组件和技术基建储备必须支持高优先级，近期的任务安排，确保不会出现过度的延迟交付和中途返工。这样就能加速价值交付流程。
10. 精益敏捷领导力
为了确保SAFe实施的有效性，企业的管理人员和管理人员必须对敏捷精益的采用与成功承担领导责任。因此，领导者必须接受培训，并成为更精干的思考者和团队培训者。只有当领导者积极参与并负责实施时，SAFe转型才能成功。
下面的因素可能会影响你是否确定在企业中实施 SAFe
如果你已经在团队级别成功应用和尝试过敏捷，现在有意在更大的层面，跨团队来考虑组织层的计划和投资组合实行。
如果你有多个团队在各自独立应用敏捷，一旦遇到障碍，延期或失败，就会影响其他团队，甚至整个公司目标的实现。
如果你渴望跨组织的扩张敏捷实践，但不确定需要什么新的角色、哪些存在的角色 ( 例如：管理 ) 需要改变以及如何改变。
如果你试图在整个组织中实施敏捷实践，但你还在与跨业务部门达成一致策略的问题和文档层面到程序到团队层面一致对齐的问题上苦苦挣扎。
如果你的组织需要提升产品开发和交付周期，你已经听说过像 John Deere 这样的公司熟练的用 SAFe 扩展敏捷实践获取的成功，你想自己尝试下敏捷的带来的好处。
首先，SAFe 框架在投资组合层由投资组合管理委员会（Program portfolio Manager）来负责定义和驱动投资策略如何形成和资金的组合形式，然后将其体现成为叙事诗（Epics）。一个 Epic 可以是一列单独的敏捷火车（Agile Release Train）来执行， 也可以是几个火车的组合。Epic 是直接面向客户的、设计架构级别的业务解决方案。
接着，在第二层计划层由产品经理（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 的收益最大化。
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 时间范围内有节奏的进行，但是各个发布火车代码的最终发布和部署是根据实际情况来决定的。也就是说，并不是每个火车一定在 IP Sprint 后才可以发布。比如说，一列敏捷火车的代码在第二个 Sprint 可以完成，那么它就可以在第二个 Sprint 来发布。当然在部署到最终产品环境之前，一定要完成对所有的用户故事的验证测试。
创新和计划（Innovation and Planning， 简称 IP）
IP Spring 是位于整个增量计划周期里的最后一个阶段，也是两周的时长。
通常在第一周，我们会对整个新功能进行系统级别的验证和回归测试，估算下一次增量计划的缓冲时间，总结我们在实施项目过程中哪些是做的好的地方，可以继续；哪些地方需要改进，总结经验和教训。最后，我们可以对下一次的增量发布进行提前计划。
在 IP Spring 的第二周，可以在这个阶段对即将发布的代码进行规划，包括各个相关团队做发布包等的筹备。但是也有例外的情况，如果项目的时间比较紧张，开始和测试不能在 IP Sprint 完成，那么 IP sprint 的第一个周也可能用作一个回归测试。
发布计划（Release Planning）
在我们进入首个 Sprint 阶段之前，需要举行一个发布计划会议。
发布计划需要遵循下面的的几点：
一般来时，推荐进行时长两天的面对面的计划会议。
在上一个 PI 的基础上，计划下一个发布计划的 PI。
始终保持开发工作和业务需求以及计划一致，从而保证每个 Sprint 的产出对用户或者业务而言是有价值的。
对将要实现的新功能进行排序，筛选出优先级前十的功能和特征。
辨识出每个 sprint 的 sprint 目标、存在的风险，并且把各个团队之间的依赖和阻碍记录到计划展示板（Program Board）中。
确保大家对新功能的优先排序保持理解一致。
敏捷的团队需要做哪些工作
在每个 Sprint 的开始阶段，需要进行 Sprint 计划会议。通过会议，确定在本 Sprint 需要完成哪些用户故事，保持开发人员，测试人员和相关人员的理解是一致的。以及用户故事提交顺序安排。如图 5 所示，对相临近的 Sprint 可以进行同样的计划和安排。不需要把所有 Sprint 都提前进行计划，可以遵循近详细，远粗略的原则。
另外，在实践中我们引入一个探针（Spike）的概念。如果在某个 Sprint 开始时，我们无法精确估算将要完成的工作量，那么我可以加一个探针来探测我们大约需要的工作量和时间。探针的使用一般在整个 PI 周期的第一个 Sprint 里使用。前提是可能需求不够清晰，也可能是我们对自己要进行的开发辅助工作量不好衡量。例如，我们在 Sprint 1 需要完成用户故事 A，但是在完成用户故事 A 前，需要做大量相关代码的重构工作，但是在用户故事里面这个工作没有体现，而且我们对代码重构的工作量也不能准确估算，这个时候我们可以引入探针。
每天一个 Scrum 会议， 简短的更新进度和问题。
在 Sprint 结束前，对所完成用户的故事进行展示。并且，开展一个回顾会议 (Respective)。
敏捷发布火车需要做哪些工作
每列敏捷的发布火车都需要做下面一些事情：
在正式的 Sprint 开始之前，需要召开发布计划会议（Release Planning）。在一个 PI 完成后，而下一个 PI 开始前，这个会议在上一个 PI 的 IP Sprint 期间召开。
由 RTE 来主持一个 Scrum 会议，会议的频率根据项目的具体情况而定。 会议参与人包括本次发布火车上各个团队的主要负责人、产品经理、产品负责人等必要的人员。会议的内容包含各个团队工作进度的更新、目前存在的主要问题等。如果问题是跨团队的，需要一起讨论解决方案
实践经验总结
本人进行的实践项目是一个面向 IBM 内部销售代表使用的 WEB 电子上午网站，需要支持客户在使用中提出的业务功能改进方案。业务功能的支持团队是由位于中国和美国的六个团队组成的 ， 我们采用了 SAFe 的框架来实施敏捷。请注意在此提供的经验总结仅供参考， 而不是必要的法则。那么，让我来开始分享下我们的经验吧。
必要的敏捷火车 scrum 会议
由 RTE 主持的 Scrum 会议上，RTE 维护出一个包含所有团队工作进度的列表。 让处于同一列敏捷火车的团队成员知道除了自己之外，其它团队的进度。如果发现某个团队的一些用户故事不能及时部署到对应的测试环境，RTE 需要调查原因，移除障碍，从而保证整列敏捷火车高速前进。如图 6 所示，在工作列表的纵列是本列敏捷火车的相关团队，横列是各个团队在不同测试环境下的工作进度。紫色的部分列出了没有完成的用户故事在某个 Sprint 下。浅蓝色代表用户故事已经提交到两个测试环境，但是测试还没有结束。浅黄色背景代表在用户验收环境的验收测试已经完成，可以部署到产品环境了。
工作进度列表对各个团队的工作状态显示的一目了然，最主要的是可以保证整个敏捷测试的策略是清晰的。例如，哪些部分现在可以测试了，哪些部分受到阻碍以及哪些部分有依赖，不能进行端到端的测试等。
工作进度列表是实时更新的，更新的频率取决于敏捷发布火车会议的频率。
知识全面的敏捷测试人员
在单个 Sprint 期间，敏捷测试包括用户故事的测试和端到端的测试。我们的项目涉及到六个开发团队。所以一个端到端测试，需要经历四五十个测试步骤。而我们的团队是分布到美国和中国的不同时区，所以在顺利的情况下，完成一个端到端的测试也需要至少两天的时间。那么在敏捷的框架下，我们的测试箱是有限的。如何在有限时间内完成如此步骤繁杂的测试呢？需要我们的测试人员对业务知识的了解是是全面的，拥有各个团队的相关业务知识背景和访问权限。
通常情况下，我们前端的测试人员会在中国时间内完成其它团队的测试，从而确保一个端到端的测试用例在一个工作日内完成。除非发现异常情况，那样我们必须等待美国其它团队的测试人员重新确认测试结果。
实时更新的用户故事
产品负责人把新功能分划成具体的用户故事过程中，用户故事不是一尘不变的。随着需求的逐步确认和沟通，用户故事的内容和验收标准需要实时更新。请注意，通过问题队列来跟踪需求是不好的敏捷实践。它会导致敏捷火车上的相关人员对用户故事有不用的理解。
产品负责人有责任实时更新用户故事和验收标准。
来源：developerWorks Rational 专区，
