短期胜利有助于建立必要的动力。

——Kotter

准备ART启动

这是SAFe^®实施路线图系列的第七篇。点击这里查看整个路线图。

SAFe实施路线图系列中前几篇文章讨论了实施过程中的前六个“关键步骤”：

达到引爆点
培训精益-敏捷变革代理人
培训高管、经理和领导者
创建精益敏捷卓越中心
识别价值流和ART
制定实施计划

到目前为止，企业已经确定了它们的价值流，并制定了实施计划。它还将对第一个ART进行宽泛的定义。这是一个关键时刻，因为计划现在正走向实施。从变革管理的角度来看，第一个ART是非常重要的，具有潜在的深远影响。这将是对工作方式的第一次实质性变革，并将产生最初的短期胜利，从而帮助企业建立动力。本文介绍ART启动前的必要准备活动。

详细内容

现在是执行成功启动ART的必要活动的时候了。在受SAFe培训的项目群利益相关者和精益敏捷卓越中心（LACE）成员的支持下，SPC通常会牵头实施最初的ART。

无论由谁来领导，在准备启动过程中，较大的活动包括：

定义ART
设置项目群日程表的启动日期和节奏
培训ART领导者和利益相关者
建立敏捷团队
培训产品经理（Product Manager）和产品负责人（Product Owner）
培训Scrum Master
培训系统架构师（System Architect）或系统工程师（System Engineer）
评估并改进启动准备
准备项目群待办事项列表（program backlog）

这些活动中的每一项都将在下面的章节中进行介绍。

定义ART

在制定实施计划中，定义了利益相关者用于确定第一个价值流和ART的过程。在该规划阶段，只要有相对足够的细节来确定它是一个潜在的ART，就可以定义一个ART。然而，ART的参数和边界是留给那些更了解局部背景（local context）的人的，如图1所示[1]。

图1.敏捷发布列车画布

画布的主要好处是帮助团队确定主要的ART角色。ART只有在正确的人被赋予正确的职责时，ART才能发挥作用。毕竟，ART组织是一个系统。为了使系统正常运行，必须实现解决方案定义、构建、验证和部署等所有必要的职责。在画布上填写关键角色可以促进这些讨论，并突出新的职责。

要了解谁是业务所有者（Business Owner），必须特别注意。显然，他们包括内部和外部客户和/或他们的产品管理代理（Product Management proxies）。然而，应用系统视图（Applying a systems view）意味着通常也应该包括其他人，例如，开发/技术副总裁、数据中心经理、企业和安全架构师以及市场和销售主管。只有正确的业务所有者才能共同协调不同的组织职责和观点。

设置启动日期和项目群日程表

有了 ART 的定义，下一步就是为第一次项目群增量（PI）计划事件设定日期。这将创建强制功能，即一个日期确定（date-certain）的启动截止日期，它将创建一个起点，并定义规划时间线。

第一步是建立项目群的节奏，包括PI和迭代长度。SAFe大图（SAFe Big Picture）显示了一个为期10周的PI，其中包括四个常规迭代和一个创新与计划（IP）迭代。PI节奏没有固定的规则，也没有为IP迭代保留多少时间。一个PI的建议持续时间在8到12周之间，偏向于较短的持续时间（例如10周）。一旦选择了节奏，就应该保持稳定，而不是从一个PI到另一个PI任意改变。这使得ART有一个可预测的节奏和速度。固定的节奏还可以在人们的日历上安排一整年的项目群事件。PI日程表通常包括以下活动：

PI计划
系统演示
ART Sync，或单个Scrum of Scrum和PO Sync会议
检查与调整（I＆A）研讨会

这种提前公告可以减少差旅和设施成本，并有助于确保大多数利益相关者能够参与。一旦确定了项目群日程表，就可以安排团队事件了，每个团队可以确定其日常会议、迭代计划、演示和回顾的时间和地点。列车上的所有团队应该使用相同的迭代开始和结束日期，这有利于整个ART的同步。

培训ART领导者和利益相关者

根据推广的范围和时间，可能会有一些ART领导者（发布列车工程师、产品经理、系统架构师）和利益相关者（业务负责人、经理、内部供应商、运营人员等）没有参加过Leading SAFe培训课程。他们很可能对SAFe不熟悉，不清楚期望值，也可能不理解他们参与的必要性和好处。他们必须了解并支持该模型以及他们角色的职责，这一点很重要。在这种情况下，SPC通常会安排一个“Leading SAFe”课程，以培训这些利益相关者并鼓励他们参与。随后通常是为期一天的实施研讨会，在该研讨会上，新近接受培训的利益相关者和SPC可以制定启动计划的具体内容。毕竟，这是他们的ART；只有他们才能规划出最好的结果。从本质上讲，这是将变革的主要职责从变革推动者移交给新成立的ART的利益相关者。

组织敏捷团队

在实施研讨会期间，将出现关于如何根据系统架构和解决方案的目的来组织敏捷团队的问题。与组织ART本身类似（见制定实施计划），有两种主要的敏捷团队组织模式：

功能团队专注于用户功能，并针对快速交付价值进行了优化。这是首选的方法，因为每个团队都能够提供端到端用户价值。它们还有利于“T型”[2]个人技能的成长。
组件团队针对系统健壮性、组件复用和架构完整性进行了优化。建议将它们的使用限制在有重要的组件重用机会、技术高度专业化和关键的非功能需求（NFRs）时。组件成熟后，具有一些轻量级治理的功能团队可以承担组件的未来开发。原有的组件团队就可以重新组织起来，进行其他功能或组件的工作。

大多数ART都是由功能团队和组件团队混合组成的（参见指南文章）。但是，ART一般应避免围绕技术系统基础架构（架构层、编程语言、中间件、用户界面）组织团队，因为这样会产生很多依赖关系，阻碍新功能的流转，并脆弱的设计。

组建敏捷团队

下一步是组建将要上火车的敏捷团队。一个创新的解决方案是让ART上的人能够以最小的约束将自己组织成敏捷团队（参见Em-Campbell Pretty关于自组织的博客[3]）。在其他情况下，管理层根据他们的目标、对个人才能和愿望的了解、时机和其他因素进行初步选择。在大多数情况下，需要管理层和团队之间做反复的交流。团队对局部背景（local context）比较了解，知道他们喜欢如何工作。管理者会根据当前的个人、组织和产品发展战略添加观点。

在进行PI计划之前，所有从业人员必须成为跨职能敏捷团队的一部分，Scrum Master和Product Owner的初始角色也必须建立。

图2所示的团队花名册模板是一个简单的工具，它可以帮助使每个团队的组织带来清晰度和可见性。

图2.敏捷团队花名册模板

填写花名册这个简单的行为可以提供相当多的信息，因为它开始使敏捷开发的抽象概念更为具体化。毕竟，敏捷团队的结构是相当明确的；有关谁在团队中，以及专业角色性质的问题，可以导致有趣的讨论。即使一个看似简单的将个人奉献给敏捷团队的举动，也可以令人大开眼界。但没有回头路可走。包括一人一队（one person–one team）在内的敏捷成熟的成功模式非常清晰。

地理位置一栏也很有意思，因为它定义了每个团队的搭配和分布级别。固定搭配当然更好。但是，可能会出现一个或多个人无法与其他人员同地办公的情况。随着时间的推移，这种情况可能会发生变化，但至少每个人都知道当前团队成员的居住地，因此他们可以开始考虑每日站立（DSU，Daily Stand-up）时间和其他团队活动。许多转型团队还包括ART中每个成员的直接主管的姓名和联系信息，以确保在宣布变更之前与这些经理进行主动沟通和协调（他们也应该被邀请参加Leading SAFe！）。

培训产品负责人和产品经理

产品经理和产品负责人共同引导列车。他们分别拥有特性（features）和故事（stories）的内容权限。这两个角色对ART的成功至关重要，履行这些角色的人必须接受良好的培训，以确保最佳的合作，学习新的工作方式，并了解如何更好地履行他们的具体职责。此外，这些角色将主要负责建立最初的项目群待办事项列表，这是PI计划的一个关键工件（artifact）。

Scaled Agile, Inc.为期两天的SAFe产品负责人/产品经理课程就是专门为此目的而设计的。该课程教导产品负责人和产品（和解决方案）经理如何在SAFe企业中推动价值的交付。学员将了解SAFe的精益-敏捷思想和原则，并对角色特定的实践进行了深入探索。与会者将学习如何编写史诗（Epics），特性（Features）和用户故事（User Stories），如何建立团队和项目群看板系统来管理工作流，以及如何使用（加权最短工作优先（WSJF））来管理待办事项列表并确定优先级。

培训Scrum Master

高效的ART在很大程度上依赖于Scrum Master的服务型领导，以及他们指导敏捷团队成员和提高团队绩效的能力。这是一个特殊的角色，它不仅包括传统的Scrum领导职责，还包括对构成ART的更大的敏捷团队的责任。在SAFe中，Scrum Master还在PI计划中扮演着关键角色，并通过Scrum of Scrums会议帮助协调价值交付。显然，如果他们在第一次PI开始之前接受适当的培训，那将是非常有帮助的。

Scaled Agile, Inc.为期两天的SAFe Scrum Master课程教授Scrum基础知识，同时也探讨了Scrum在SAFe背景下的作用。它为Scrum Master准备了如何促进团队迭代，如何成功地计划和执行PI，如何参与ART事件，以及如何使用看板来衡量和改善系统中的工作流程。本课程对新手和有经验的Scrum Master都是有益的。

培训系统架构师/系统工程师

系统架构师/工程师通过提供、沟通和发展解决方案的更广泛的技术和架构视图来支持解决方案的开发。通过这样做，他们使敏捷团队能够做出有效的、分散的决策，加速创造业务价值，同时确保解决方案的架构保持稳健和可持续。履行这些职责的人不仅是经验丰富的技术专家，而且必须是在整个组织中参与工作的高效的精益敏捷领导者。该职位与产品管理部门合作，承担、定义和负责待办事项列表中的使能特性（enabler features），以维持必要的架构跑道，保证业务价值的持续创造。

Scaled Agile, Inc.为期三天的SAFe系统和解决方案架构师课程向高级技术贡献者（senior technical contributors）传授架构在精益-敏捷企业中的作用。学员将探索精益-敏捷架构和按需发布的基本原则，学习领导和支持解决方案列车和敏捷发布列车，将驱动持续流动（driving continuous flow）的原则扩展到大型系统的系统，并探索如何在整个投资组合中实现跨价值流体系的改进。

评估并改进启动准备

对人员进行新角色和新职责的培训是ART准备就绪的关键部分，但这只是成功启动ART的要素之一。它还需要其他活动。然而，由于SAFe是基于经验性的计划-执行-检查-调整（PDCA，Plan-Do-Check-Adjust）模式，因此不存在完美的启动准备状态。即使试图达到这样的状态也是痴人说梦，因为第一个PI的经验将为未来的活动提供参考。更重要的是，前期试图过于完美，会耽误学习，从而延迟其收益的转化和实现。

尽管如此，一定程度的准备工作将有助于确保第一次规划活动更加成功。图3和图4提供了一些ART准备情况评估和活动的检查表。

图3. ART准备工作检查表：所需的条目

图四：ART准备工作检查表：有用的条目

大多数人都会同意图3中的大多数条目是成功启动所必需的。图4中的条目当然是理想的，但根据你的情况，也可以在最初的几个PI中轻松解决。

准备项目群待办事项列表

如前所述，将启动日期用作强制功能会增加确定PI的范围和愿景的紧迫性。毕竟，如果没有坚定的使命感，没有人愿意参加PI规划。虽然在活动之前假设应该是这样，但经验往往表明情况并非如此。更有可能的是，对于新系统应该做什么，会有多种意见，在启动日期之前，可能需要一些时间来融合这些观点。

PI的范围（或“构建的内容”）主要是由项目群待办事项列表（Program Backlog）定义的，它包含了一系列即将到来的特性（features）、非功能性需求（NFR）和定义系统未来行为的架构工作。为此，SPC和LACE利益相关者通常会促进ART利益相关者一起准备一个共同的待办事项列表。这通常是在一系列的待办事项列表改进研讨会和其他活动中完成的，如图5所示。

图5.准备项目群待办事项列表和相关活动

我们很容易在待办事项列表准备工作上进行过度投资，所以不要让这一点拖累了整个过程，因为与团队一起规划的行为会解决很多问题。他们通常知道什么是最好的。经验表明，列出具有初步验收标准的特性（features）列表就足够了。许多人倾向于过度规划，提前创建用户故事。但当愿景发生变化时，这往往会造成浪费和失望。这也肯定会挫伤团队的积极性，因为创建故事是他们对PI规划的重要贡献。

下一步

到目前为止，这是一段相当漫长的旅程。以下是目前已经完成的工作。

达到引爆点
受过训练的精益敏捷变革代理人
训练有素的高管，经理和领导者
确定的价值流和ART
制定实施计划
为首次ART发布做好准备

终于可以离开车站，启动这趟列车了! 更多关于启动活动的内容，请阅读本系列下一篇文章“培训团队并启动ART”。

准备启动ART