详解IBM的大规模敏捷框架SAFe

大规模敏捷框架

♪

PM吃瓜

在企业层面实现敏捷的一致性。

常规的敏捷框架适用于中小型项目团队，而且不具有扩展性。基于常规的敏捷框架，SAFe定义了一个可扩展的敏捷框架模型，它适用于大型多个团队的合作开发，可以提高团队之间的协作性，降低团队管理的复杂性。

面向企业的Scrum-SAFe。多个团队共同使用SAFe，避免多个团队独自使用敏捷，一旦失败影响其他团队。

三个层面的敏捷

第一投资组合层：由投资组合管理委员会来负责定义和驱动投资策略如何形成和资金的组合形式，然后将其体现成为叙事诗（Epics）。一个 Epic 可以是一列单独的敏捷火车（Agile Release Train）来执行， 也可以是几个火车的组合。Epic 是直接面向客户的、设计架构级别的业务解决方案。

第二层计划层：由产品经理（Product Manager）负责把等待安排的计划（Backlog）进行排序，并且把投资策略转化成具体的新功能（Feature），同时和业务负责人一起设计出项目的愿景和路线。

在第三层团队层：由产品负责人（Product Owner）和团队成员根据上面的定义细化出用户故事（User Story）和验收标准，开发团队可以从候选的用户故事里面优先选择可以提前开始的内容，其余的留到故事池里面等待后续的选择。

名词解释

1.Agile release train ART，敏捷发布火车

2.Scrum Train Engineer RTE , scrum 火车工程师, 敏捷火车的主管；RTE 负责一列敏捷火车的总体执行

3.Scrum master SM, scrum 主管、 Scrum 主管 (Scrum Master) 是团队级别上 Scrum 的负责人，确保 scrum的正确使用并使得 Scrum 的收益最大化。

4.Scaled Agile Framework SAFe, 大规模敏捷框架， SAFe 的一个企业级的投资策略往往由多列敏捷发布火车（Agile Release Trains）来组成。

5.Epics： 叙事史诗

6.Program Increment PI , 递增的sprint 计划，用来做时间控制

7.Innovation and Planning IP, 创新和计划

IP Sprint 是位于整个增量计划周期里的最后一个阶段，也是两周的时长。 通常在第一周，我们会对整个新功能进行系统级别的验证和回归测试，估算下一次增量计划的缓冲时间，总结我们在实施项目过程中哪些是做的好的地方，可以继续；哪些地方需要改进，总结经验和教训。最后，我们可以对下一次的增量发布进行提前计划。 在 IP Spring的第二周，可以在这个阶段对即将发布的代码进行规划，包括各个相关团队做发布包等的筹备。

8.Program 计划

9.Team 团队

10.Portfolio 投资组合

11.Program portfolio Manager 投资组合管理委员会

12.Product manager 产品经理

13.Backlog 待办事项

14.Feature 新功能

15.User story 用户故事

16.Product owner 产品负责人

17.Release planning 发布计划

18.System demo 系统展示

19.Program Board 计划展示板

20. Spike A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

原则

• 请注意一列敏捷火车是由多个团队组成的。
• 在我们进入首个 Sprint 阶段之前，需要举行一个发布计划会议。 在一个 PI 完成后，而下一个 PI 开始前，这个会议在上一个 PI 的 IP Sprint 期间召开。
• 不需要把所有 Sprint 都提前进行计划，可以遵循近详细，远粗略的原则。
• 实时更新用户故事，随着需求的逐步确认和沟通，用户故事的内容和验收标准需要实时更新。
• 每个 Sprint 都需要经历同样的工作：设计，编码和用户故事的测试。
• 任意一个 Sprint 都必须产出是对计划任务有价值的内容，在较短的时间箱（2 周）内防止实现和计划任务的偏离。一旦发现偏离，可以及时纠正。

时间控制

• 递增的 Sprint 计划（Program Increments，简称 PI）, 用来对一列敏捷火车的提交和发布时间进行总体规划。PI 将在固定的时间箱内计划出一个可量化、可实现和最终可测量验收的计划路线图。
  • 一个 PI 周期可以是 8 到 12 周的长度，包含一个位于最末端的 IP (Innovation and Planning) Sprint。

• 在团队管理层主要是通过 Sprint 来做为一个时间箱标准，一般一个 Sprint 为 2 到 4 周。
  • 在每个 Sprint 的开始阶段，需要进行 Sprint 计划会议。通过会议，确定在本 Sprint 需要完成哪些用户故事，保持开发人员，测试人员和相关人员的理解是一致的。
  • 我们无法精确估算将要完成的工作量，可以建立一个Spike，理解为：以回答问题或收集信息为目的的任务，而不是生产非专业产品的任务

集成

在单个 Sprint 期间，敏捷测试包括用户故事的测试和端到端的测试， 如何在有限时间内完成如此步骤繁杂的测试呢？需要我们的测试人员对业务知识的了解是是全面的，拥有各个团队的相关业务知识背景和访问权限。

发布计划

发布计划需要遵循下面的的几点：

1. 一般来时，推荐进行时长两天的面对面的计划会议。
2. 在上一个 PI 的基础上，计划下一个发布计划的 PI。
3. 始终保持开发工作和业务需求以及计划一致，从而保证每个 Sprint 的产出对用户或者业务而言是有价值的。
4. 对将要实现的新功能进行排序，筛选出优先级前十的功能和特征。
5. 辨识出每个 sprint 的 sprint 目标、存在的风险，并且把各个团队之间的依赖和阻碍记录到计划展示板（Program Board）中。
6. 确保大家对新功能的优先排序保持理解一致。