SAFe: Scaled Agile Framework
SAFe的全称是Scaled Agile Framework enterprise
上图黄色柱形中的每一个小圈代表的是一个scrum迭代，共有五个迭代。两个小圈中间的省略号。。。的意思是有很多团队在跑迭代。SAFe有两层，Team层和program层（很多团队之间的依赖比较大，人数为50 - 125）。Team 层包含有scrum master, PO, 开发测试人员。Program 层也称作火车层，跟team层一一对应。
RTE：release train engineer 发布火车工程师，类似于chief scrum master的角色
Product manager: 可以理解为管理所有PO
System architecture: 系统工程架构师
Business owners: 老板/客户业务方的老板/研发的老板，会给PR的价值打分数
版本火车：在发布周期很短的情况下，不按照以前的项目方式（如果在截止日期前没做完，则延期），而火车的发车时间是固定的，如每月发一版。但是每个月发布的内容是不固定的，这么处理的目的就是为了建立快速发布的能力；真正达到敏捷，敏捷的范围scope是可以变的，如果这个版本没赶上，下个版本再发，客户那边也比较容易接受
版本火车+feature 开关：如果有代码没写完，有开关
PI planning: 通常是会有上百个人开两天会，有非常详细的会议议程。首先Business Owner会就将来的战略/目标进行发言，接着架构师就公司的架构技术进行发言。接下来会进行scrum分解来计划这五个迭代要做什么；在开会之前，PO和product manager要商量哪些特征feature要做的,怎么拆分成更小的故事story；第一天会议结束后，会就风险/问题/依赖关系进行分心并讨论计划是否要变；第二天在继续做分解讨论，最后进行信心投票；business owner会进行价值value 打分；做完之后大家按照计划来执行。在执行过程中，在团队层（Team level）面，会有每日站会；火车层（Program level）也会有相应的会议，要注意两者之间要进行互通/同步
在全部五个迭代中，前四个迭代有冤圆圈表示，最后一个没有圆圈，而是写着IP （也即innovation and planning创新计划）迭代；五个迭代中通常留出最后一个做创新/回顾，但是不做新的需求；在开始计划的时候，前四个迭代真正完成所有需求
Enabler: 技术方面的故事
红色折线：架构跑道；技术类的基础工作，需要技术/架构团队经常做系统/架构优化，支持实现新的feature或者换届由新的业务造成的系统压力
DevOps: 开发和运维，怎样更好地进行合作，打破中间的裂缝
分而治之的思想: 分成多个 sub-epic
SAFe是企业层面的Scrum
若企业已从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 时间范围内有节奏的进行，但是各个发布火车代码的最终发布和部署是根据实际情况来决定的。也就是说，并不是每个火车一定在 IP 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 的概念和实施方式有一个基本的了解，在将来项目实施大规模的敏捷框架时，可以借鉴相关的实践经验。
敏捷原则
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何能提高成效，并依此调整自身的举止表现。
Scrue 框架(敏捷)
接着，Ella对整个Scrum框架进行了讲解。PO从干系人那边得到需求作为输入，跟开发团队保持紧密沟通，清楚想做的特征在技术上能否实现，风险怎样。得到输入后，需要将其转化为需求列表product backlog（需求列表是动态的，PO可以随时更新；按照优先级排序；渐进明细，高需求的颗粒度较小。基本只要几天的工作量，排在下面的就是简单描述，需求还不是很明确）。Development team是开发团队。一个大圈（通常1-4周），最开始定义好一个圈是几周。迭代第一天会有sprint planning，PO跟团队解释前面几条具体要做什么。结束后，输出，团队在固定的sprint里面能做完几条需求。Scrum master的角色有点类似于项目经理，但还是有区别；scrum master会进行协调组织，每天会有15分钟的站会，会后更新燃尽图，识别问题风险；sprint最后有两个会，sprint review 迭代评审会，叫PO过来给他演示进行验收；sprint retrospective 迭代回顾会：流程/工具/合作/沟通/人/，哪些做得不错，哪些需要改进；有些改进项可能会进入sprint backlog。