理解规模化敏捷框架 (SAFe)：一种全面的方法
在企业内部建立高效的职能型 Scrum 团队本身就充满挑战，许多团队在此过程中遭遇挫败。然而，当多个高度依赖的团队在同一个产品或价值流中协同工作时，就需要更强大的方法来保证协调一致。
这时，就需要利用一个覆盖多个 Scrum 团队的扩展框架。 这样的框架能够为团队提供流程和规范，确保它们之间同步协作、保持一致，并避免在过程中迷失方向。
常见的现象是，团队最终会形成“筒仓效应”，这意味着独立的 Scrum 团队专注于局部目标，却对整体项目的共同目标缺乏认识。 而规模化敏捷框架（SAFe）正是在这种情况下发挥作用的。
什么是 SAFe？
来源： SAFe 是一种将敏捷原则和流程应用于传统层级组织的方法。它不重新创建既有的层级结构，而是在原有系统的基础上，以一种大多数现有利益相关者都能理解的方式，引入一套新的体系。
SAFe 的核心价值体现在以下几个方面：
协同一致
- 所有 Scrum 团队都必须清晰理解愿景、战略以及最终目标。
- 将团队的战略统一起来，引导他们朝着共同的方向努力。
- 使用团队易于理解的统一语言进行沟通。
- 持续检查团队是否对目标和愿景有透彻的理解。
- 团队应以客户为中心，了解客户是谁以及他们的需求，并根据这些调整战略。
透明公开
- 营造一个开放信任的环境，让每个人都能发挥最大潜能。
- 公开交流观点和事实，坦诚直接，不要对团队隐瞒重要信息。
- 快速从失败中学习，将错误转化为经验。 如果事情没有按预期发展，尽快发现并总结教训，然后调整战略。
- 将正在进行的工作可视化，以便每个人都能更好地理解。
- 确保信息随时可访问。
尊重个体
- 强调人的价值，而不是将人视为资源。
- 尊重员工及其观点的多样性，鼓励真诚的反馈。
- 通过指导和培训来帮助员工成长。
- 认识到客户是工作成果的消费者。
- 在团队内部和团队之间建立持久的合作关系。
持续改进
- 创建一个鼓励团队解决问题的环境。
- 反思过去一周的表现，找出可以改进的地方。
- 将事实作为改进工作的最重要依据。
- 为创新提供时间和空间，鼓励团队尝试不同的方法，即使这些方法不是最安全的。
SAFe 为规模化敏捷系统引入了协作和沟通层，但它并不会取代现有的 Scrum 团队的 Sprint 活动。
SAFe 的一个关键组成部分是敏捷发布系列 (ART)。 它是一个由多个 Scrum 团队（通常不超过 12 个）组成的长期、稳定的团队，定期发布新的增量功能。 他们在工作流程中开发、交付和支持一个或多个解决方案。
来源： SAFe 中的角色
SAFe 的运作依赖于承担不同职责的人员。坚持对角色的期望是框架实施成功与否的关键。因此，了解这些角色是什么以及它们的目的是什么至关重要。
1. 敏捷团队
敏捷团队是跨职能的，这意味着他们可以覆盖团队内部正在执行的整个工作范围。他们也是定义、构建、测试、部署和发布价值增量的自组织实体。
每个敏捷团队都具备在商定的范围内执行工作的能力，并通过每次迭代以可预测的方式增加价值交付。可预测性至关重要，因为它使得团队能够专注于在特定时间内实现特定目标。沟通和交付是团队需要不断提升的核心价值。
敏捷团队是项目增量 (PI) 规划会议的核心参与者，负责在 Sprint 中创建用户故事并进行规划。最终，他们致力于实现自己的 PI 目标。
Scrum Master 负责指导敏捷团队并主持团队会议，消除障碍，保护团队免受外部干扰。他们作为 ART 的一部分参加 Scrum 会议。
产品负责人 (PO) 是团队中的另一位关键成员。PO 代表客户的声音，对用户故事及其优先级有直接的影响。PO 与其他 PO 进行沟通，以定义团队待办事项中的用户故事并确定优先级。
2. 产品管理
产品管理层位于 Scrum 团队之上，负责团队之间的协调工作。 他们的职责包括：
- 确保开发团队构建可行且可持续的产品和解决方案，从而实现业务目标。
- 了解客户需求，确保产品符合客户的期望。
- 保证待办事项清单中有足够的用户故事。
- 支持通过程序板并进入程序待办事项的工作流程。
- 通过确定团队所创建的功能的优先级来确定下一个计划增量的范围。产品管理最终负责定义下一个 PI。
3. 系统架构师/工程
工程团队负责分析并开发待办事项用户故事中商定的内容。他们是团队中的专业人员，其职责包括：
- 创建并维护架构跑道，确保新功能能够利用技术推动因素。
- 积极参与项目增量规划，并在每个程序增量结束时进行系统演示。
- 与敏捷团队合作实施新的架构推动因素，以便团队构建新功能。
- 协助敏捷团队定义高级设计方案和决策，并提出敏捷团队内部概念验证活动的替代方案和最佳实践。
- 他们创建了架构跑道，即各个团队定义功能可用的技术推动因素的定义。
4. 企业主/利益相关者
这些团队虽然不在 Scrum 团队内部，但在 SAFe 框架执行的每个阶段都发挥着重要作用。
PI 规划前：
- 为待办事项细化活动提供输入。
- 根据需要参与 PI 规划前的活动。
- 确保业务目标得到包括发布列车工程师 (RTE)、产品管理和系统架构师在内的主要利益相关者的理解和同意。
在 PI 规划期间：
- 为即将到来的 PI 提供业务背景和愿景。
- 参与计划草案评审，并为团队的 PI 目标分配商业价值。
- 参与管理评审，协助解决可能阻碍最终计划通过的问题。
PI 规划后：
- 积极参与，确保业务和发展方向一致，尤其是在优先级和范围发生变化时。
- 帮助验证 Program Epics 的最小可行产品 (MVP) 的定义，并根据 MVP 的交付情况指导“转向或坚持”的决策。
- 参加系统演示，查看进度并提供反馈。
- 根据需要参加敏捷团队的 Sprint 计划和 Sprint 回顾活动。
- 参与发布管理，重点关注范围、质量、部署选项、发布和市场考量。
5. 发布列车工程师 (RTE)
RTE 负责协调 ART 内的人员和团队的活动，类似于整个项目中 Scrum Master 的角色。其主要职责包括：
- 管理和优化 ART 的价值流。
- 制定并发布 Sprint 和项目增量 (PI) 的年度日历。
- 担任 PI 规划会议的主持人。
- 组织团队并协助他们创建已确定的 PI 目标的摘要，并将团队的目标转化为整体 PI 计划目标。
- 将团队聚集在一起，沟通并解决彼此之间的风险和依赖关系。
- 将产品管理、产品负责人和其他外部利益相关者联系起来，确保各方对共同的战略保持一致。
- 协调检查和调整研讨会，不断改进现有流程和活动。
- 评估整个团队采用敏捷方法的成熟度水平，并确定未来的改进方向。
6. 领导
领导层负责制定计划的策略，并为团队提供开展工作所需的工具和支持。 最终，他们定义了其他所有工作所依据的体系。 因此，拥有一支能够为团队提供正确目标和价值观的定义管理团队至关重要。他们的主要职责包括：
- 以身作则。
- 拥有成长的心态。
- 强调 SAFe 的价值观和原则。
- 培养人才。
- 引领变革。
- 营造心理安全感。
项目增量 (PI) 规划
PI 规划是一个为期两到三天的活动，旨在了解并承诺下一个计划增量的工作。 例如，这可能代表下个季度的规划。
产品管理层负责确定 PI 规划期间所确定的功能的优先级。敏捷团队则负责容量规划、用户故事创建、评估以及对 PI 目标的承诺。
PI 规划对于 SAFe 至关重要。 如果没有进行 PI 规划，就意味着实际上并没有真正实施 SAFe。
PI 流程
来源： PI 规划从桌面上的输入开始。 每个工作流都会收集他们的需求和想法，了解他们下一步希望为产品构建什么。 然后，他们将这些作为输入传递给 PI：
- 接下来要实现的十大功能。
- 为史诗或功能准备的 ART 待办事项。
- 产品负责人的愿景。
接下来，不同工作流之间开始讨论。每个工作流都会阐述自身的愿景和特性，强调下一步要实施的关键内容，以及在实施过程中取得成功所需的要素。 这可能涉及以下方面：
- 需要其他工作流提供的支持，以便继续使用这些功能。
- 对其他工作流的依赖以及优先排序的需求。
- 系统当前存在的问题，需要优先修复才能继续推进。
- 团队人员配置面临的挑战，团队可能缺少执行功能所需的关键角色。
- 预算限制可能会阻碍工作流在给定时间内实现愿景。
- 团队可能识别出的任何其他风险、问题、假设或依赖关系，这些都需要在 SAFe 团队其他成员之间进行更广泛的讨论，以确保目标一致。
PI 演练
PI 规划通常分为几天，通常是两到三天。议程可如下所示：
第一天
- 讨论构成整体计划愿景和战略的业务声明以及即将到来的关键目标。领导层负责这一部分，并与团队进行明确的沟通。
- 将工作流的所有功能摆上台面，并根据共同愿景确定其优先级。
- 进入架构愿景并定义开发需求的主要目标。 强调技术挑战，并就解决团队之间的障碍达成一致。
第二天
- 向团队详细解释规划流程，并概述 PI 结束后的预期成果。
- 在计划期间首次进行团队分组讨论。 团队的目标是制定计划草案，并识别障碍和风险。
- 分组讨论结束后，各团队应在其他团队面前展示并审查制定的计划草案。
- 接下来由管理层审查计划，并为下一步的解决问题提供指导。 根据挑战、风险和障碍对计划进行调整。
第三天
- 以与前一天管理会议一致的计划调整开始新的一天。
- 团队制定最终计划并完善风险和障碍。 企业主将商业价值分配给团队目标。
- 接下来，各团队在全场观众面前展示最终方案。
- 讨论剩余的项目级风险，并应用 ROAM（已解决、拥有、接受、缓解）风险信息。
- 团队投票表达他们对计划增量规划结果的信心。
- 如果得票率过低或总体信心仍然较低，则会进行额外的规划。
- 在 PI 承诺之后，RTE 计划对团队进行回顾，讨论计划的进展情况以及下一轮需要改进的内容。 领导层在最终指示的同时说明接下来将要发生的事情。
PI 结果
PI 规划的最终结果是在下一个 PI 周期内按照 Sprint 完成的功能列表。 所有已知的依赖项都有明确的计划来解决和解锁功能的进展。
团队将专注于他们的目标和范围。 如果存在未包含在列表中的其他目标，则将其视为未承诺的目标。 如果时间和资源允许，这些问题仍然可以得到解决。
团队将记录和跟踪项目的所有风险，并制定如何处理这些风险的准确计划。
团队还将记录回顾会议中提出的每一个回顾想法，并将其标记为下一次 PI 规划会议的学习课程。
在团队方面，具体的期望包括：
- 团队致力于实现具有商业价值的目标。
- 团队将计算每个 Sprint 的容量，以更好地评估路线图内容的可行性。
- 他们还会考虑每个 Sprint 的实际负载。
- 根据所提供的能力，这些用户故事将被放入每个工作流的特定 Sprint 中。
- 团队投票表示对 PI 计划和即将交付的内容的信心。
结论
尽管以上所有内容看似复杂，但将大型组织转型为 SAFe 确实是一项极具挑战性的任务。 在某些情况下，这可能看起来难以完成。 即使应用了一些基本原则，通常也需要多次迭代才能完成转型，从而有信心地说你已经采用了 SAFe。
很多时候，进步会与一些老式的层级原则和规则发生冲突，无论如何努力，这些旧观念都难以消除。 你可以制定详细的 PI 规划和某种程度的成果，甚至可以自信地命名它们。但是，如果工作流团队没有按照正确的敏捷方法运作，这到底有什么意义呢？
这里不存在中间道路。 要么完全投入，拥有所有正确的流程、人员和心态，要么就会因为一个或多个方面不符合要求而失败。
当然，在考虑实施 SAFe 之前，必须明确你已经掌握了敏捷团队的原则和工作方式。 这不仅要从领导层的角度来看，还要让团队投票并表达他们真实的意见，结果可能会出乎你的意料。
接下来，可以研究一些优秀的敏捷认证学习资源。
本文是否有帮助？
感谢您的反馈意见！