541
《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》SAFe团队层
SAFe?团队层
3.1 团队层介绍
我们、工作、知识是一个整体。
——本书作者
摘要
SAFe团队层是项目群层的组成部分，但有时会分开讨论。所有的SAFe团队都是敏捷发布火车（ART）的一部分——ART是项目群层的核心组成部分。团队层为敏捷团队的活动提供了组织、工件、角色和流程模型。由每个敏捷团队自己负责定义、构建和测试来自团队待办事项列表中的用户故事，这些工作在一系列固定周期的迭代内进行，通过使用共同的迭代节奏，并与其他团队同步和对齐，从而保证整个系统开发的迭代执行。所有团队都使用ScrumXP或团队看板，开发和交付高质量的系统，并每两周进行一次系统演示，从而确保在ART上的所有团队可以共同创建出一个经过集成和测试的系统，利益相关者可以通过快速反馈进行评估和响应。系统演示提供了一个常规的 “拉动事件”，用于在特定节点拉取不同团队的成果，让困难的集成和测试工作尽量提前。这种方法与“阶段–门限”模型有所不同，“阶段–门限”模型通常在项目生命周期的后期才进行集成和测试工作。
详述
团队层描述了敏捷团队如何驱动敏捷发布火车。敏捷团队采用SAFe ScrumXP或团队看板，同时应用内建质量的实践，确保最终产品质量。每个团队有5～9名团队成员（ScrumXP），并包括所有必要的角色，确保在每一次迭代中构建一个高质量且有价值的发布增量。ScrumXP角色包括Scrum Master、 产品负责人、全职工作的团队成员，以及其他能为团队创造价值的资源。看板团队的角色没有严格的定义，许多SAFe看板团队也使用ScrumXP的角色。每个团队都会得到项目群层中成员的支持，这些成员包括：发布火车工程师、产品经理、系统架构师/工程师、系统团队、共享服务、DevOps和其他必要的角色。因此，团队应该完全有能力在每次迭代中定义、开发、测试和交付可以工作并经过测试的系统。
项目群增量和迭代
所有团队遵循相同的迭代起止日期和时间周期，也就是有相同的迭代和项目群增量（PI）边界，以便与ART上的其他团队保持同步和集成。每个PI都起始于团队的PI计划，他们构建团队的PI目标，再汇总成项目群的PI目标，这些目标有助于指导团队的迭代执行。
团队会按照事先确定的迭代目标，计划和执行迭代，每个迭代的时间盒为两周。每个迭代提供有价值的新功能增量，迭代过程按照以下模式循环进行：迭代计划、承诺交付一些功能 、通过构建和测试用户故事执行迭代、演示新功能、执行迭代回顾，在下一个迭代再重复进行这些活动。在每次迭代结束时，团队也需要支持系统演示，它是ART的关键集成点。在一个包含多个ART的大型价值流中，团队还需要支持解决方案的演示，整个解决方案由多个ART全面集成和测试，进行整体演示。
创新与计划（IP）迭代为团队提供了一个探索和创新的机会，有专门的时间用于计划、回顾并通过正式和非正式渠道进行学习。如果发布处于PI的边界上，团队需要做最终的系统审核、验证和文档工作。为了能提供一个缓冲，团队不会在IP迭代中计划用户故事的实现，所以对于每个PI而言，资源利用率不会达到100%。这样做增加了流动、吞吐量和交付的可靠性。
PI的时间盒可以用于将大型的、系统级的功能聚合为有价值且可评估的项目群增量。这些功能可以在PI的边界上进行发布，也可以更加频繁的发布。项目群应该有节奏地开发，并支持任何时间的发布。
每个PI的迭代数量
SAFe把开发周期分为PI内的一系列迭代。在SAFe全景图中描述了如何通过PI计划会议启动一个PI，接下来是4个实施迭代，最后是1个创新与计划迭代。这种模式具有启发性，不过有些武断，其实在一个PI中有多少个迭代是没有固定规则的。经验表明，PI持续时间一般是在8～12周的效果最好，并且倾向于最短的持续时间。
用户故事和团队待办事项列表
团队使用用户故事来交付价值，产品负责人负责用户故事的创建和接收。用户故事承载客户的需求，通过价值流进入到实现阶段。团队待办事项列表由用户故事和使能故事组成，其中大部分故事是在PI计划中，当产品经理向团队展示愿景、路线图和项目群待办事项列表时进行确定的。在团队层基本的需求管理流程是：用户故事的识别、排序、排期、细化、实施、测试和接收。
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.2 敏捷团队
敏捷团队所向无敌。
——SAFe 语录
摘要
正如敏捷宣言（2001年）中所描述的那样，敏捷运动是软件和系统开发方式的一个重要转折点。SAFe正是基于这种变革而构建起来的，它通过授权敏捷团队作为构建单元来创造和交付价值。
敏捷团队是由获得授权并富有激情的成员组成的。如果没有这种有效的敏捷团队，组织就无法将敏捷进行规模化，也无法实现企业级精益–敏捷开发的大型业务收益。精益–敏捷领导者的主要职责在于构建和指导这些敏捷团队。
SAFe 敏捷团队是一个跨职能小组，他们有能力和权力来定义、构建和测试解决方案价值，所有的这些活动都在一个短迭代的时间盒内完成。团队应包含必要的成员来成功地交付价值，适当的时候由项目群层或者价值流层的专家提供支持。这也遵循SAFe的原则#9——去中心化的决策，通过授权团队对需求和设计进行决策，从而让每个团队对自己的工作负责。
在SAFe中，敏捷团队并非独立的单元，而是作为敏捷发布火车的一部分，敏捷发布火车上的团队相互协作，他们负有交付大型价值的责任。所有的团队都在火车上，没有团队就无法组成火车。团队在火车上运作，基于共同愿景与其他团队相互协作，并参与敏捷发布火车的关键仪式。团队与火车是不可分割的，它们作为一个整体的价值远大于每个部分简单相加的总和。
详述
敏捷团队是由专职成员组成的一个小团队（在Scrum中是5～9人），他们具有一些必备技能，可以在短时间盒内定义（细化和设计他们的组件/特性）、构建（实现这些组件/特性）以及测试（运行测试用例并验证组件/特性）价值增量。
在敏捷发布火车中，敏捷团队获得授权、自我组织、自我管理并对满足客户需求和期望的交付结果负责。这些团队开发软件、硬件、固件，或者都有所涉及，但通常情况下，团队具备交付特性所必要的属性。
企业将工作交予团队和火车，而不是把人员分配到工作任务上，从而有助于创建团队，以及规模化团队，而且这些团队都是长期存在的，并且专注于持续提升交付解决方案的能力。在这种情况下，SAFe 与传统方式有所不同，传统方式中是由经理来指导个人活动的；而在SAFe中是由团队来决定构建什么，以及如何构建他们的特性和组件。精益–敏捷领导者为团队提供愿景、领导力和自主权，从而培养和促进高绩效团队。这将不再需要给团队的每个成员分配工作任务，而把去中心化的决策方式交到了团队成员的层级。
角色和责任
SAFe摒弃了职能式的、基于筒仓的，以及阶段–门限的开发模型。在那些模型中，用户价值是在漫长的软件生命周期最后阶段，依赖于各个独立职能部门的输入而进行交付的。敏捷团队执行或参与所有这些职能，在每个迭代中都会进行价值的交付：
团队负责管理自己的工作。
团队估算工作的大小和复杂度。
团队在架构指导下根据所关注领域决定技术设计。
团队承诺在迭代或项目群增量时间盒中完成的工作。
团队负责价值和构建，从而持续提升交付成果的质量。
团队承诺不断地提升工作方式。
紧密合作
团队只有通过不断沟通和合作，以及快速、有效和授权的决策能力，才能完成他们所承担的责任。如果有可能的话，团队最好能够在同一地点，每小时、每天、每周都进行沟通。标准的团队会议要依赖于所选择的框架，但可能包括每日站立会议、迭代计划、团队演示，以及每个迭代最后的回顾。每个团队成员都完全专注于单一的团队，在每周的工作时间内紧密合作。团队成员和其他团队持续并积极合作，对依赖进行管理并解决障碍。
团队成员之间的关系完全基于彼此的信任，而共同的任务、共同的迭代目标和团队的PI目标有助于促进信任的达成。团队的合作通过持续的反馈环不断提高，这样的反馈模式也构建了团队的持续学习环。每一次真实的价值交付，都能增进信任，降低不确定性和风险，并有助于提升团队的自信。敏捷团队的激励因素来自于共同的愿景和向客户交付价值的承诺。
团队可以选择敏捷方法
SAFe 团队所使用的敏捷实践，主要基于Scrum和团队看板。大部分 SAFe 团队应用Scrum作为基本的项目管理和交付框架。Scrum产品负责人参与并支持去中心化的决策制订，而这对于团队的授权是至关重要的。Scrum Master 支持团队达成交付目标，并帮助构建一个高绩效和自我管理的团队。
其实Scrum也并不是唯一可用的实践。团队通过采用注重用户体验（UX）的工程实践和内建质量的多种实践，来推动有纪律的开发和质量。这些实践包括集体所有权、结对工作、编码标准、测试先行和持续集成，通过在开发过程中直接嵌入质量和运行效率而使事情变得更加精益。敏捷架构有助于完成高质量的解决方案开发。
然而，由于SAFe是基于流的系统，大部分团队也在应用看板进行工作的可视化，建立WIP限制，并使用累积流图来显示瓶颈和关键机会来提升吞吐量。有些团队（尤其是维护团队、DevOps和系统团队）经常将看板作为自己的基本实践，Scrum中的计划和承诺活动在这些团队中可能无法有效应用，因为工作内容以活动为主并且是按需发生的，优先级的变化也更加频繁。
敏捷团队在火车上
SAFe敏捷团队并不是独立运行的，他们在敏捷发布火车上互相协作来构建可工作解决方案的有价值的增量。不管团队是否应用Scrum、看板或两者的结合，所有团队都在一个共同的框架下运作，这个框架管理并指导整个火车的运行。这些团队共同制订计划、共同执行集成和演示、共同学习，如图3.2-1所示。
图3.2-1 敏捷团队共同计划、共同集成和演示、共同学习
共同计划
所有团队共同参加PI计划会议（如果可能的话，所有的团队成员最好都要参加）。在计划会议上，大家一起计划和承诺一系列的PI目标。大家都有一个共同的愿景和路线图，共同协作以达成目标。在计划和执行中，有清晰的工作授权。产品负责人是大型产品管理团队的一部分（看板团队有时对此角色使用不同的名称）。每个团队的待办事项列表都是从项目群待办事项列表中衍生而来的。
此外，作为敏捷发布火车的一部分，为了与经济框架保持一致，所有敏捷团队都使用相同的方法进行估算。这提供了一种有意义的方式，有助于决策者根据经济情况决策并指导行动。虽然工作方式随着使用的方法不同而不同，但结果往往是相同的，后续在“Scrum”和“团队看板”的相关章节（3.4～3.6节）中会有进一步讨论。
共同集成和演示
交付高质量的复杂系统需要团队之间的紧密配合与相互协助。为此，团队按照相同的敏捷发布火车节奏工作，在每个迭代开始时共同提出和沟通迭代目标。在敏捷发布火车同步时，各个团队也会互相更新状态，通过与其他团队的成员进行交互，从而积极地管理相互之间的依赖关系。
当然，这里所说的目标不是简单地让团队向着目标进行“冲刺”，而是指让系统向着有质量和有价值的增量进行“冲刺”。为此，团队在内部和这个火车上，都应用了内建质量并在迭代内进行持续集成，同时所有团队共同协作，从而可以在每个迭代完成时进行系统演示。
共同学习
所有SAFe的团队成员都参与持续改进（参见1.4节中的第4个支柱）。除了团队级别的回顾会议和随时发生的流程提升之外，团队也会参与更大的检视和调整会议，通过这种方式识别优先级，按优先级对改进故事进行排序，并将其放入后续的PI计划会议中进行处理。用这种方式，团队完成了一个迭代，敏捷发布火车完成了一个PI，就可以让“环路闭合”。当然，学习并非仅在回顾会议中进行，学习也是在实践社区中不断发生的，实践社区的建立可以帮助个人和团队不断提升本职能和跨职能的技能。
参考资料
[1] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
[2] Lencioni, Patrick. The Five Dysfunctions of a Team: A Leadership Fable. Jossey-Bass, 2002.
[3] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009.
[4] Manifesto for Agile Software Development. https://agilemanifesto.org/.
3.3 产品负责人
业务人员和开发人员必须相互合作，项目中的每一天都不例外。
——敏捷宣言
摘要
产品负责人（Product Owner，PO）是团队的一员，负责定义用户故事和确定团队待办事项列表的优先级，从而衔接项目群优先级事项的执行，并维护团队所负责的特性和组件在概念和技术上的完整性。产品负责人是质量保证的关键人物，并且是团队中唯一有权力接收已完成用户故事的人。对于正在向敏捷方式转型的企业来说，产品负责人是一个新的并且非常重要的角色。产品负责人通常是全职的，一个产品负责人通常可以支持一个团队（最多两个团队）。
该角色是开发团队与外界的重要接口，例如与产品经理（负责项目群待办事项列表）合作，为PI计划会议做准备。
详述
产品负责人是敏捷团队的成员之一，他是团队与客户之间的接口，负责与产品管理人员以及其他利益相关者（包括其他产品负责人）协作来确定团队待办事项列表中用户故事的优先级，以便解决方案能够有效处理项目群优先级事项（特性/使能），同时保持技术的完整性。理想情况下，产品负责人与团队的其他人在同一地点办公，产品负责人与团队拥有同一个经理、拥有同样的激励机制和文化。但是产品负责人也会参加产品经理的会议讨论有关计划、待办事项列表和愿景的梳理等。
责任
SAFe产品负责人的主要责任如下。
筹备和参加PI计划会议
作为产品管理团队的一员，产品负责人积极参与项目群待办事项列表细化和准备PI计划会议的工作，同时也积极参与PI计划。在PI计划之前，产品负责人更新团队待办事项列表，审查和参与制订愿景、路线图和进行内容展示。
在PI计划期间，产品负责人参与用户故事定义，为团队澄清产品需求，以便团队进行用户故事估算和用户故事排序，并为项目群增量起草团队目标。
迭代执行
待办事项列表梳理——产品负责人的主要职责是从系统架构师/工程师和其他利益相关者那里获得输入信息，并构建、裁剪和维护团队待办事项列表。待办事项列表主要是由用户故事组成，但也包括缺陷和使能。待办事项列表基于用户价值、时间和其他团队依赖关系进行优先级排序，团队依赖关系在PI计划会议上确定并在PI执行期间进行优化。
迭代计划——作为筹备迭代计划工作的一部分，产品负责人审查和重新排定待办事项列表（参见3.5节中的“迭代计划”的内容），有时还需要与其他产品负责人协调相互的依赖关系。在迭代计划会议上，产品负责人负责澄清用户故事细节和用户故事优先级，并负责接收最终迭代计划。
准时制（Just-in-Time，JIT）的用户故事细化——待办事项列表中的大部分条目都会细化成用户故事进行实施。这可能会发生在迭代之前、迭代计划过程中或迭代执行过程中。虽然任何团队成员都可以写用户故事和接收标准，但产品负责人对保持整个流程的顺畅性负有主要责任。通常比较好的做法是，在团队待办事项列表中的用户故事可供两个迭代执行。如果故事过多，则会导致产生队列等待；如果故事过少，则会抑制流动的进行。
支持ATDD——产品负责人参加用户故事接收标准的制订和起草，并提供示例以支持ATDD（Acceptance Test-Driven-Development，接收测试驱动开发）规范制订。可参考8.2节的内容。
故事接收——产品负责人是唯一可以接收用户故事完成的团队成员。接收用户故事包括验证用户故事符合接收标准，通过了适当和长期的接收测试，或者通过其他方式能够验证用户故事满足完成的定义。通过故事接收，产品负责人履行了质量保证的职能，主要侧重功能是否适合使用。
理解使能工作——虽然产品负责人无需推动技术决策，但是他们需要理解后续使能工作的范围，并与系统和解决方案架构师/工程师协同工作来帮助做决策，并为那些实现新商业功能的关键技术基础设施排定顺序。这通常需要进行人力物力安排，可参考4.8节中的描述。
参加团队演示和回顾——作为团队不可或缺的成员和团队需求负责人，产品负责人在团队演示、评审和接收用户故事，以及迭代回顾（参见3.12节）中发挥着重要作用。在回顾活动中，团队成员聚集在一起，改进流程。产品负责人也积极参与敏捷发布火车的“检视和调整”工作坊。
项目群执行
迭代和团队都服务于一个更大的目标——频繁、可靠和持续地发布以便实现解决方案的增值。在每个PI的过程中，产品负责人与其他团队的产品负责人协调各团队的功能相关性，通常产品负责人需要每周参加产品负责人协调会议来保障这一点。详细信息请参阅4.10节。
产品负责人在为项目群和价值流利益相关者进行演示的过程中也起到关键作用。
检视和调整
团队可以在PI的检视和调整工作坊上来处理那些较大的障碍。在工作坊中，各团队产品负责人协同工作来定义和实施改进故事，以提高项目群的速度和质量。
PI系统演示在检视和调整工作坊中进行，产品负责人在为项目群利益相关者进行PI系统演示时发挥重要作用。
产品负责人也参与PI系统演示的准备，以确保能够为利益相关者展现解决方案的最关键环节。
内容授权
对于大规模项目，一个人不可能身兼数职——既处理产品和市场策略也服务于某一个敏捷团队。因为在项目群中，产品经理和产品负责人分担“内容权力”，所以职责划分是非常重要的。通常的职责划分如图3.3-1所示。
产品经理 产品负责人 团队
面对市场/客户。识别市场需求。与市场/业务人员在一起办公。
负责愿景、路线图、项目群待办事项列表、定价以及ROI。
通过对特性和使能排定优先级来实现PI目标并发布内容。
建立特性的接收标准。 协调解决方案、技术和团队交互。与团队一起办公。
参与制订愿景和项目群待办事项列表。负责团队待办事项列表及实施。
定义迭代和故事。接收迭代增量。
通过合理排序故事实现迭代目标和迭代内容。
建立故事接收标准，接收故事并发布到产品基线。 面对客户/利益相关者。
负责故事估算并实现其价值。
参与意图式架构制订。负责浮现式设计。
协助细化待办事项列表和创建故事。
与其他团队进行集成。
图3.3-1 发布内容治理
产品经理、产品负责人和敏捷团队的人员配比
项目取得成功的一个重要因素是企业内各个岗位的人员配比。不合适的岗位人员配比会严重影响执行速度。因此，产品经理、产品负责人以及敏捷团队的人数必须是大体平衡的，以便正确地驾驶敏捷发布火车，否则整个系统将花费大量的时间在等待定义、澄清和接收等工作中。SAFe框架建议的人员配比如图3.3-2所示。
每个产品经理通常可以支持最多4个产品负责人，每个产品负责人最多可以负责1～2个敏捷团队的待办事项列表。
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 11.
[2] Larman, Craig, and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010, chapter 3.
3.4 Scrum Master
好的领导者首先必须是个好仆人。
—— 罗伯特·K·格林里夫
摘要
大多数SAFe团队采用的是ScrumXP，这是一种用于有效地进行敏捷项目管理和产品交付的轻量级的团队框架。Scrum Master的角色由团队中的一员承担，主要职责是帮助自组织、自我管理的团队实现其目标。Scrum Master通过教学和指导SAFe，实施并支持SAFe的原则和实践，识别和消除不利因素的影响，引导流动。
SAFe团队从Scrum、看板、XP和其他精益敏捷方法中挑选最佳实践来调整他们的过程。虽然Scrum Master这个角色主要基于标准的Scrum模型，但是大多数团队——甚至是那些基于事务或工作流的团队（主要应用看板）——也有效地采用了Scrum Master这个角色来帮助团队达成目标，并协调与其他团队的沟通活动。
详述
Scrum Master对于敏捷团队来说是一个专门的角色，他会花大量的时间帮助团队成员进行沟通、协调、合作；一般来说，Scrum Master会协助团队达成他们的交付目标。Scrum Master是基于团队的管理代理人和仆人式领导，他通过有效的敏捷实践，帮助团队实现自组织、自我管理和交付工作。Scrum Master支持和实施Scrum流程的规则以及团队认可的其他规则。Scrum Master也帮助团队在敏捷发布火车上与其他团队进行协调配合，在必要的时候向管理层沟通当前的状态。
在团队中的责任
优秀的SAFe Scrum Master是基于团队的仆人式领导：
展现精益–敏捷的领导力——展现出具有精益–敏捷思维的领导者行为。帮助团队拥抱SAFe的核心价值观，采纳和应用SAFe原则，并实施SAFe实践。
支持规则——虽然Scrum的规则是轻量级的，但依然是规则，Scrum Master负责遵循实行这些规则，包括Scrum规则、在制品限制，以及团队认可的其他规则。
引导团队向着目标前进——Scrum Master接受培训并成为团队引导者，不断地挑战旧有的软件开发范式，同时保持团队专注于迭代目标。Scrum Master在质量、可预测性、流动和速度等方面帮助团队。以当前产品增量目标为基准，帮助团队关注于日常工作和迭代目标。
领导团队进行持续改进——帮助团队进行改进，并对自己的行为负责。引导团队进行回顾。教给团队如何解决问题，并帮助团队成为自身问题的解决者。
引导会议——引导所有的团队会议，包括每日站会、迭代计划、团队演示和迭代回顾。
支持产品负责人——在团队中产品负责人有专门的职责。Scrum Master支持产品负责人的工作，促进健康的团队内部优先级和范围的动态调整。
消除障碍——很多阻碍问题都超出团队授权，或是需要来自其他团队的协助。Scrum Master需要积极解决这些问题，以便团队能够保持专注于迭代目标的达成。
宣传推广SAFe质量实践——SAFe提供了指导，帮助团队持续改进交付物的质量，达成完成定义（DoD）。Scrum Master帮助团队培养技术自律和匠艺精神文化，这是卓越敏捷团队的标志，Scrum Master还培育和支持相关实践的社区。
建立高效团队——致力于不断提高团队的动力和绩效。帮助团队管理人际冲突、挑战和成长机会。必要时可以把人员问题上升到管理层，但这仅限于通过内部解决无法达成目标时才进行。Scrum Master 还可以通过人事变动帮助团队和个人开展工作。
保护和沟通——与管理层和外部利益相关者进行沟通。保护团队不受那些不可控插队工作的影响。
在敏捷发布火车上的责任
Scrum Master帮助协调团队之间的合作，以便团队真正地成为“在火车上的团队”。
与其他团队进行协调——一般而言，Scrum Master作为代表，参加Scrum of Scrums会议，把会议上的信息传达回团队（细节信息参见4.10节）。经常和系统团队、用户体验、DevOps、共享服务，以及发布管理团队进行协调。需要注意的一点是，团队间协调的责任不能完全委托给Scrum Master，每一个团队成员在这方面都负有责任。
引导敏捷发布火车仪式的准备和就绪——帮助团队准备敏捷发布火车活动，包括PI计划会议，系统演示，以及检视和调整工作坊。
协助估算——指导团队建立标准化的估算方法，帮助团队和敏捷发布火车进行大型特性及能力的估算。
角色来源
Scrum Master可以是全职或兼职的，这取决于团队规模、环境和其他职责。然而对企业来说，接受每个敏捷团队有一个全职Scrum Master是一件有挑战的事情。毕竟，如果企业组建了100个新的敏捷团队，将100个开发团队成员全职地放在这个新职责上，而不再做开发或测试工作，这看起来不太经济，而且行政上的可操作性也不高。就更不要说给每个团队配备一个全职或者兼职的顾问，来帮助团队学习和掌握新的思想了。可能在团队有机会证明这个角色的价值之前，这种变革就已经胎死腹中了。
因此，SAFe提供了务实的方法和假定，通常情况下，Scrum Master是由敏捷团队的成员、项目经理、团队领导或者其他角色兼职担任。然而在SAFe推行的初始阶段，这个角色的活动会很密集，这时候组织会发现让外部顾问指导团队，使团队在Scrum和SAFe执行中熟练起来很有益处。通常来说，外部的Scrum Master教练和咨询师能够同时指导多个团队。
参考资料
[1] www.scrumalliance.org.
[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.5 ScrumXP
“……一套整体的，或者说是‘橄榄球’的方法——团队在来回传球的过程中作为一个整体而行动，也许能更好地服务于当今的竞争需求。”
——野中郁次郎和竹内弘高，《新型的新产品开发游戏》
摘要
多数SAFe团队采用Scrum作为他们基本的团队级别项目管理框架。Scrum是一个轻量的、有纪律的、高效的过程，适合于跨职能、自组织团队在SAFe环境下使用。Scrum规定了三个角色：Scrum Master、产品负责人和开发团队成员（参考资料[3]）。Scrum Master是仆人式领导，他帮助团队遵守Scrum规则，并且清除团队内外的阻碍。产品负责人负责定义需求，他是团队待办事项列表的负责人（在Scrum中称为产品待办事项列表，在SAFe中称为团队待办事项列表）。通过将精益质量管理实践延伸到软件开发，并结合来自于极限编程（XP）的工程实践，SAFe的ScrumXP团队为SAFe提供了基础的敏捷单元。
但是，SAFe的ScrumXP团队当然并不是孤立的，每个团队都是更大的敏捷发布火车的一部分，团队之间相互协作构建大型的系统，从而努力达成目标。为此，为了确保整个系统的迭代和增量式演进，所有的敏捷团队都会共同计划、共同集成和演示、共同学习。
详述
ScrumXP敏捷团队是一个包括5～9人的自组织、自管理的跨职能团队，并且尽可能工作在一起。这样的规模和结构优化了团队沟通、互动和交付价值的能力。自组织意味着团队中没有团队主管或经理角色来给团队分配任务、估算工作量、为特定的目标做承诺，或是制订明确的解决方案。团队在获知迭代的意图之后，独立地决定在意图范围内哪些是他们可以实际承诺的，以及他们将如何构建这个价值增量。
团队是跨职能的，因此具备用于交付增量的所有角色和技能。团队自组织和跨职能的性质，以及持续地沟通、有建设性的冲突、充满活力的互动，这些都可以为团队成员创造一个高效的团队氛围和更愉快的工作环境。
Scrum定义了两个特殊的角色：产品负责人和Scrum Master，他们是SAFe ScrumXP 团队的成员，各自被赋予特定且具体的职责。每个角色在本书中都有一个同名的章节做详细阐述。下文是对其各自职责的一个概括。
产品负责人（PO）
每个ScrumXP团队有一个产品负责人负责团队待办事项列表。产品负责人与团队其他成员的互动是重要的、日常性的，并且高度聚焦于工作的事项。因此，最有效的模式是每个团队拥有一个专职的产品负责人，或者最多两个团队拥有一个产品负责人。这有助于产品负责人在迭代执行过程中对团队进行有效的支持，包括回答问题，在开发中提供更多的功能细节，评审、接收并将已完成的故事发布到产品基线。
Scrum Master（SM）
Scrum Master是团队的引导者和敏捷教练，其主要职责包括：确保团队遵循开发流程，向团队提供Scrum、XP和SAFe实践的培训，以及提供持续改进的环境。Scrum Master也负责领导团队移除阻碍。Scrum Master可以是全职的，或是由团队成员兼职。此外，一些专职的Scrum Master可以支持2～3个Scrum团队。
Scrum流程
Scrum流程本身是一个轻量级的项目管理框架，能够促进快速、迭代式高级解决方案能力的构建，并且有利于持续改进以支持更高效的产能和更好的交付。其流程围绕着迭代进行（注：Scrum采用术语“冲刺”（sprint），SAFe采用更通用的术语“迭代”（iteration），迭代是一个短周期时间盒，在SAFe中是两周，在此期间团队定义、开发、测试和接收结果。以下是Scrum流程的进一步描述。
迭代计划
迭代开始于迭代计划，该计划也是一个遵循时间盒（不超过4小时）的会议，产品负责人可以展示迭代相关的故事。团队评审故事，定义接收标准，必要时将大故事拆分成更小的故事，估算故事点数，最后根据已知的团队速度（每个迭代交付的故事点数）承诺可以完成的故事。许多团队进一步将故事拆分成任务，以小时为单位来估算任务，以此完善对工作的理解。最终，团队承诺一系列的迭代目标。
其实早在迭代开始之前，Scrum团队就通过梳理团队待办事项列表为新迭代准备内容，以确保团队对于将在新迭代中交付的工作有一个预先的了解。
可视化工作
在执行过程中，团队以每隔几天就可以交付一两个故事的速度进行开发和测试。这种串行的工作方式限制了在制品数量，并帮助避免了迭代瀑布化。团队采用大型可视化信息雷达（big visual information radiators，BVIR）掌握并跟踪迭代执行过程。在整个迭代过程中，团队的故事板用于可视化故事及其进度。在故事板中团队往往把每一列作为一个实现的步骤，随时间从左至右移动故事，如图3.5-1所示。
图3.5-1 团队故事板示例
有些团队在部分步骤中应用在制品限制，从而在迭代中创造“拉动”过程，持续平衡工作以提高产能。事实上，很多团队把Scrum和看板的最佳实践结合起来，以促进工作的流动性。在这种情况下，简单的故事板演变成了结构化的看板板（Kanban board）。更多信息可以参见3.6节的内容。
协调每日站会
团队每天都举行一个正式的仪式——每日站会（Daily Stand up Meeting，DSU），用于了解团队目前的状况，提出问题，以及向其他团队成员寻求帮助。在会议中，每个团队成员描述昨天做了什么，今天将要做什么，以及遇到的任何阻碍。由于这是一个每天进行的协调会，因此Scrum Master应该保持会议简短且聚焦，每日站会不应超过15分钟，而且是在故事板前站立完成的。
团队沟通并不仅限于每日站会，团队成员在整个迭代过程中保持互动。沟通的便利性是ScrumXP推荐团队成员尽可能在一起工作的主要原因。
价值演示和过程改进
在每个迭代的结尾，团队要进行一次团队演示和迭代回顾。在演示过程中，团队展示迭代中每一个完成的故事，其总和就是此次迭代团队的价值增量。这不是一个正式的状况报告，而是一次有形的迭代成果的评审。接下来，团队进行一个简短的回顾，反思在迭代过程中，哪些地方做得好，以及当前有什么阻碍。然后，团队生成一些改进故事，放入下一个迭代执行。
内建质量
正如一条SAFe的宗旨所说，“你不能规模化糟糕的代码。”因此，SAFe的一个核心价值观是“内建质量”。内建质量需要从代码和组件层面抓起，由此生成解决方案；否则，要想确保从组件集成到系统和解决方案过程中的质量，就是一件非常困难的事情，有时候甚至是完全做不到的。
为了确保团队在代码和组件方面的内建质量，SAFe指出了5种来自于极限编程（XP）中的工程和质量实践，用以扩充Scrum项目管理实践。它们是：持续集成、测试先行、重构、结对工作和集体代码所有权。除了这5个实践之外，一些团队还会采用更多的极限编程实践，如结对编程、隐喻（参考资料[2]）。
ScrumXP团队“在火车上”
如果一个大型系统包括了不同的技术平台，涵盖硬件、软件以及系统工程等多种领域，在这种情况下，即使团队是跨职能的，让一个7、8个人的团队交付最终用户价值也往往是不现实的，我们需要多个团队一起协作。为此，SAFe敏捷团队运作在敏捷发布火车之上，敏捷发布火车可以帮助对齐任务目标，提供协作环境，使团队可以相互协作以具备构建更大型解决方案的能力。作为敏捷发布火车的一部分，ScrumXP团队共同计划、共同集成和演示、共同学习，如图3.5-2所示。
有关团队如何参与“共担职责的项目群”的更多细节，参见3.2节的内容。
ScrumXP 团队领导力
管理者通常不是跨职能团队的一部分。然而，最初的团队组建往往会围绕着特性、组件和子系统来进行，而敏捷发布火车的设计和架构，往往是管理者的职责，同时要以团队的输入为基础。因此，团队管理人员的日常管理职责存在一个质的转变，即从指导团队具体技术实现的专家管理者，转变为使能员工、发展员工的精益–敏捷领导者。
图3.5-2 SAFe敏捷团队共同计划，共同集成和演示，共同学习
参考资料
[1] Kniberg, Henrik. Scrum and XP from the Trenches. lulu.com, 2015.
[2] Beck, Kent and Cynthia Andres. Extreme Programming Explained: Embrace Change, 2nd edition. Addison-Wesley, 2004.
[3] Sutherland, Jeff and Ken Schwaber. https://www.scrumguides.org.
3.6 团队看板
造成库存挤压的唯一原因，是因为使用了过量的人力。
——艾利·高德拉特
也有可能是因为职责划分太过专门化了？
——本书作者
摘要
尽管出于不同的目的，看板系统广泛应用于SAFe的投资组合、价值流、项目群和团队等各个层级。本节将阐述团队看板，一种可以帮助团队通过可视化工作流来促进价值流动、建立在制品限制、度量生产能力和持续改进流程的方法。
SAFe团队可以自行选择敏捷方法，多数团队会选择Scrum方法，它是一种轻量级、有效和普遍适用的管理方法。开发团队也会采用极限编程，从而专注在软件工程和代码质量上。有些团队，特别是系统团队、DevOps团队，以及维护团队，会选择看板来作为他们主要的敏捷方法。在有些场景下可能会导致团队选择使用看板方法，比如快速响应、救火式的工作特点、快速变化的优先级、“在下个迭代里确切计划要做哪些工作”是没有意义的行为等。本节将描述如何使看板系统较好地适用于SAFe敏捷团队，与此同时，这些SAFe团队是“在火车上的”，并且需要遵循特定的火车规则。
详述
通常，看板被描述为一个拉动系统，当团队有能力胜任某项工作时，是通过“拉动”而不是“推动”的方式来完成这项任务的。本节将讨论团队看板，一种可以帮助团队通过可视化工作流，从而促进价值流动、建立在制品限制、度量生产能力，以及持续改进流程的方法。
看板系统是建立在工作流状态基础之上的，大多数状态是有在制品（WIP）限制的，即一个新的工作项只有在该状态的WIP小于限制的时候，才能够加入到该状态的队列里。有一些状态是没有WIP限制的，例如开始和结束状态。
WIP限制由团队自己定义和调整，从而快速适应复杂系统开发中流动的变化。在SAFe里，团队看板应用于敏捷发布火车的节奏与同步中。这确保了团队间的对齐，依赖管理，以及快速地、基于集成的学习环，也为推进更大型的解决方案提供了客观证据。
看板描述
看板（Kanban，意为“可视化的信号”）的本质是一个用于可视化和管理工作的方法。虽然对于如何将看板用于软件开发有很多种理解，但一般来讲用于开发的看板系统包括以下几个主要方面：
系统包含一系列需要经历的工作状态的定义；
所有的工作都是可视化的，每个任务的进度都会被跟踪；
团队对于每个工作状态的在制品（WIP）限制数达成一致，并在必要时更改WIP以优化工作流；
团队制订工作管理政策；
度量流动。工作项从进入系统开始被跟踪，直至离开；这样就可以持续地指示在制品数量以及当前的前置时间（Lead Time，一个工作项通过系统所需的平均时间）；
通过分配服务等级进行排序，而服务等级是由延迟成本决定的。
可视化流动和限制WIP
启用看板之初，团队通常会创建一个大致的工作流程，并设定初始的WIP限制。图3.6-1展示了一个团队的初始看板例子，他们目前的工作流程是：分析–评审–构建–集成–测试。
在图3.6-1中，该团队还决定创建两个缓冲区（“准备就绪”）来更好地管理流动的变
化。一个是在“评审” 状态之前，这可能需要团队外的领域专家（产品经理或者其他专家），而这些专家的工作时间有限或者不均衡。另外一个缓冲区是在 “集成和测试” 状态之前，在这个团队的例子里，需要使用共享的测试设备和资源。因为集成和测试是由同一群人在同一个环境上完成的，所以这两个步骤被视为同一个状态。考虑到成本因素，团队允许对
“评审”与“集成和测试”两个状态设置更高的WIP。
图3.6-1 团队初始看板示例
团队看板的改进是迭代式进行的。在定义初始流程和WIP，并且执行一段时间之后，团队的瓶颈将会显现出来。如果没有的话，团队可以梳理工作的流程，或进一步降低WIP，直至某些状态出现明显的空闲或者过载，这会有助于团队向更优化的流进行调整。通过验证假设，以调整WIP，从而使工作流程步骤得以合并、拆分，或者重新定义。
度量流动
为了更好地理解和改进流动与流程，看板团队采用客观的度量，包括平均前置时间、WIP、吞吐量。其中常用的一种度量方式是累积流图（Cumulative Flow Diagram，CFD），如图3.6-2所示。
图3.6-2 累积流图展示了前置时间和WIP按天的变化
每一个工作项都是有时间戳的，包括其进入工作流的时间（从团队待办事项列表拉入开始实施状态）及完成时间。“到达曲线”表示拉入工作流的工作项数量，“离开曲线”表示完成并被接收的工作项数量。两条曲线在X轴的差值是平均前置时间——也就是一项工作通过系统所花费的时间。在Y轴的差值是WIP——也就是在任何时间点上，系统中所有工作项的数量。吞吐量——指在给定时间段内完成的工作项数量，它也是一个非常关键的指标。SAFe中看板团队以迭代为工作节奏，因此会度量每个迭代的故事吞吐量。
累积流图为团队提供数据，以计算他们迭代的吞吐量。
为此，团队用平均WIP除以平均前置时间，得到平均每天可以处理的故事数量，然后再乘以14。其结果就是每个迭代以故事数量计算的平均吞吐量，这有助于制订计划。（这对于计算团队速度也是很重要的，相关内容将在本节后面描述。）
累积流图也将明显的流动变化进行了可视化。这可能是团队没有意识到的系统内部阻碍，或者是外部力量干扰了流动。累积流图是一个客观的度量工具，可以帮助看板团队持续改进。
通过服务等级改进流动
此外，团队需要有能力管理依赖、确保与里程碑保持一致。看板使用服务等级机制帮助团队优化工作项的执行。服务等级提供了一种方法，基于延迟成本区分工作项。对于每一类服务等级都有一个特定的执行策略。例如：
1.标准——大部分工作项都属于这个服务等级：没有特定的日期依赖的新功能开发。对于标准类别的任务，它的延迟成本是线性的，它的价值只有在完成交付的时候才会达成，但对它没有固定完成日期的要求。
2.固定日期——有固定日期的工作项意味着里程碑和预先设定日期的依赖关系。其延迟成本是非线性的。需要及时“拉动”这些工作任务进入开发状态，以期按时交付。有些工作项需要额外的分析，以便调整期望的前置时间。有些工作项在落后于计划进度时需要将其类别改为“加速”。
3.加速——“加速”类别工作项有着难以接受的延迟成本，因而需要立即引起团队关注；它可以在违反当前WIP限制的情况下被“拉动”进入开发状态。通常在系统里同一时间内只允许有一个“加速”类别的工作项，并且团队可以设定“蜂拥”策略，以便该工作项迅速通过系统。
如果团队发现很多工作项都需要加速，那么系统极有可能是超负荷负载的。有可能是需求超过处理能力，也有可能是输入流程缺乏纪律。这时需要对工作流程重新进行调整。
如图3.6-3所示，通常情况下服务等级被可视化为“泳道”。
此外，团队可以把不同类别的工作项对应到特定颜色上（参见4.11节），如“新功能”“研究探针”（Spike）“建模”等，这有助于团队进一步理解正在执行的工作项。
密切关注工作流的结构可以给看板团队提供改进的机会。例如，累积流图中发生的变化可能揭示了平均WIP在增加（这将导致前置时间拉长）。这也许是某种更深层次问题的一个表象，现在团队有能力做出识别。定期省思和调整流程是获取高度可视化益处的必要措施。
图3.6-3 看板上的服务等级
SAFe 看板团队“在火车上”
SAFe 看板团队在更大的框架下运作，这需要多个敏捷团队甚至跨多个敏捷发布火车来构建一个解决方案。为了实现这一目标，团队除了需要遵守常规看板原则之外，还需要遵守特定的SAFe规则。这些规则包括：团队之间共同制订计划，共同集成和演示，共同学习，如3.2节描述的那样。共同制订计划是一个值得进一步讨论的话题，如下文所述。
估算工作内容
通常，看板团队在估算或者任务分配上花费的时间没有Scrum团队那么多。团队查看要做的工作项，把较大工作项进行必要的拆分，然后致力于完成拆分出来的故事，通常不会在意故事的大小。然而，SAFe团队需要具备对PI计划的需求进行估算的能力，以及参与对较大工作项做经济估算。同时，为了能够做预测，需要对团队的速度、其他团队的速度，以及敏捷发布火车的速度有一致的理解。
为估算建立一个共同的起点
最初，一个新的看板团队并不清楚其吞吐量，因为吞吐量是基于历史数据计算出来的。启动之初，SAFe 看板团队必须有一种方法来估算工作，这往往从第一个PI计划会议开始。这在一定程度上与Scrum团队一致，看板团队的初始能力估计是从标准化估算开始（参见3.9节的描述）。然后，看板团队把估算过的故事加入到迭代中，如Scrum团队所做的一样。团队的初始能力是他们所假设的速度，至少在第一个PI时是这样的。
计算“导出”速度
从启动开始，看板团队可以使用累积流图来计算每次迭代的故事吞吐量（或者也可以先简单地相加再计算平均值）。由此看板团队通过用吞吐量乘以故事平均大小（通常是3~5点）来计算“导出”速度。这样，SAFe Scrum团队和SAFe 看板团队都可以参与到大的经济框架中来，从而为投资组合运行提供基本的经济环境。
估算大的工作项
在投资组合和价值流层级，通常需要估算更大的工作项（诸如史诗或能力）来确定它们的潜在经济可行性。此外，对敏捷发布火车和价值流路线图的开发需要同时具备估算知识（工作项的大小），以及敏捷发布火车的速度（ART的吞吐量）。为了做到这点，看板团队会把大的举措分解为故事并进行估算，与Scrum团队所采取的方式类似。这提供了更细颗粒度的解决方案来帮助估算大规模工作任务。故事用标准化的故事点数进行估算，这为企业提供了从各个团队聚合估算的能力，而且在整个过程中避免了过度的争论。
参考资料
[1] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.
[2] Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Programmers, 2012.
3.7 团队待办事项列表
待办事项列表的定义：
1. 隐藏在舒适表面下的大型列表
2. 未完成的任务或未处理资料的聚集
上述第一种待办事项列表的燃尽速度缓慢，而第二种待办事项列表的燃尽速度迅速。
摘要
团队待办事项列表代表了一个团队为提升系统需要做的所有事情的集合，它包含了用户故事和使能故事，其中大部分都来自于项目群待办事项列表，有些则是来自团队自己的具体场景。团队待办事项列表由产品负责人负责，虽然产品负责人是待办事项列表的“责任人”，但这并不意味着只有产品负责人可以创建用户故事，而是需要产品负责人对工作进行优先级排序。
由于用户故事和使能故事都是待办事项列表的一部分，所以通过有效配置资源以确保投资可以在需求冲突中得到平衡，这一点显得尤为重要。资源的配置需要把敏捷发布火车看成一个整体，并根据火车的需要进行协调。
详述
虽然“待办事项列表”看起来是一个简单的概念，然而在其背后却有许多微妙的影响。
待办事项列表需要包含所有要做的事情，如果工作项处于列表中，那么就需要被完成；如果工作项不在列表中，那么就不会被完成。
待办事项列表是一个“希望实现工作项”的列表，而不是一个承诺。工作项可被估算（推荐）也可以不用估算，但无论哪种情况都不会包括承诺该项工作的具体完成时间。
待办事项列表有唯一的责任人——团队的产品负责人。这样可以保护团队免受多方面利益相关者的干扰，因为每一个利益相关者的关注重点都有所不同。
所有的团队成员都可以将自己认为重要的用户故事放入待办事项列表。
待办事项列表包含用户故事、使能故事和“改进故事”，其中“改进故事”是从团队迭代回顾会议的结果中识别出来的改进内容。
团队待办事项列表是一个简单而统一的形式，但也隐藏了敏捷在规模化过程中的复杂性。图3.7-1说明了团队待办事项列表的三个主要来源。
图3.7-1 团队待办事项列表的分解图
项目群待办事项列表中包括将要实现的特性，通常会计划在敏捷发布火车中进行交付。在PI计划会上，计划在项目群增量（PI）中交付的特性会被分解成故事，并且暂时分配进入团队待办事项列表以便在下一个迭代进行实现。此外，也会计划一些将来需要开展的工作，在这种情况下，团队待办事项列表也可以包含一些尚未拆分成故事的特性。有时需要由多个团队共同交付一个特性，在这种情况下，就需要为相关团队创建相应的工作，然后对其进行估算，并在团队待办事项列表中进行维护。
团队也需要根据自己的实际情况开展工作。除了需要实现那些来自于特性的故事之外，团队也会有一些自己创建的故事，比如新功能、重构、缺陷、研究探针，以及技术债等。这些由团队自己创建的故事也需要加以识别，可以写成使能故事，进行估算，并排序放入待办事项列表中。
敏捷发布火车上的团队并不是孤立存在的，不同团队的待办事项列表中的用户故事可能会相互关联，从而满足利益相关者的目标。这些故事可能会包含对特性、能力甚至史诗故事的研究和估算探针，同时也会反映团队之间的依赖关系，以及对外部的承诺。
通过容量分配优化价值交付和系统健康
与敏捷发布火车一样，每个团队都会面临待办事项列表中内部和外部工作项的平衡问题，内部工作项包括维护、重构、技术债等；外部工作项是指立即能交付价值的新用户故事。“永远保持新功能的开发”在一定程度上比较有效，甚至可以立即满足市场需要，但是这种效果将是短暂的，因为可能会由于沉重的技术债务而影响交付速度。为了避免速度的降低，以及推迟由于技术过时导致的大量系统更换，团队需要持续关注解决方案的技术演进，及时修复缺陷和改进提升，从而保证现有客户的满意度。
产品负责人对于工作项的排序是一件复杂和极具挑战的事，他需要在3种不同类型的工作中进行价值比较：1）缺陷；2）重构、重新设计和技术升级；3）新的用户故事。而且这些工作项按需发生，持续增加。大多数情况下，工作项来自项目群待办事项列表，然后通过容量分配有助于团队形成一种机制，用于明确在给定时间周期内开展哪些类型的活动，如图3.7-2所示。
图3.7-2 团队待办事项列表的容量分配
一旦团队做出决定，他们就可以从每个“切片”中选择最高优先级的工作项，放入迭代中进行实现。对于那些在项目群中已经承诺的故事，在PI计划的时候就已经进行了优先级的排定；但是对于团队自己添加的本地故事，产品负责人需要按照价值/规模大小，或者采用WSJF（加权最短作业优先）进行优先级排序。此外，为了平衡长期的产品健康和价值交付，分配到各个工作项类型的百分比可能会有所不同（例如，在每个PI中都会有所不同）。
待办事项列表梳理
在本节的讨论中，可以看出待办事项列表中的有些故事已经比较完善，并准备就绪可以进行下一步的实现了，这样的故事不会带来太大的风险和意外。因为，整个团队都参与了讨论，大家采取了基于流的方法，通常是每个迭代（或者每周）至少有一个团队对将要实现的故事（有时也会讨论特性）开展一个工作坊，进行讨论、估算，并且建立初步的接收标准。
对于这个会议，业界没有标准的术语，在SAFe 中称为待办事项列表梳理会，但是需要指出的一点是，待办事项列表梳理是一项持续的工作，而不仅仅是一次会议就能解决全部问题的。应用接收测试驱动开发（ATDD）的团队，通常会在前期投入更多的时间用于开发特定的接收测试，有时也会开展一些相关会议，称为规格说明工作坊（specification workshop）。此外，由于多个团队都在做待办事项列表的梳理，可能会出现新的问题、依赖关系和故事。在这种方式中，待办事项列表梳理的流程会有助于把当前计划中存在的问题暴露出来，并升级到敏捷发布火车的同步会议中进行更进一步的讨论。
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.8 迭代
我平生从来没有做过一次偶然的发明。我的一切发明都是经过深思熟虑，严格试验的结果。
——托马斯·爱迪生
摘要
迭代是敏捷开发的基本组成单元，每个迭代都是一个固定的时间盒，团队在这个固定时间内构建一个商业价值或产品功能的增量。SAFe的迭代长度是2周，这为团队提供了一个开发产品特性和组件的基本开发节奏。在这个短周期之内，团队需要完成迭代待办事项列表中用户故事的开发，与其他团队的输出结果进行集成，以及准备整个系统的演示等一系列工作。迭代是连续的，一个接着一个进行，以稳定的速度提供持续的商业价值交付。
迭代的节奏是SAFe提到的第一个节奏，SAFe项目群增量的时间盒更长，由一组和谐的短迭代组成。PI时间盒为敏捷发布火车上所有的团队提供了一个外部节奏，团队在这个时间盒里共同计划、共同集成和演示、共同学习成长。
详述
由于快速学习是SAFe学习环的关键目标，所以敏捷团队需要尽可能快地执行PDCA （Plan-Do-Check-Adjust）循环，包括计划、执行、检查、调整四个步骤，如图3.8-1所示。
每个PDCA循环就是一个迭代，每个迭代以固定的、可预测的开发节奏产生新的价值增量，同时也优化以前迭代产生的价值增量。在两周时间内，每个团队通过计划、构建、测试、集成和演示等一系列工作完成系统增量的输出。在短暂的迭代时间内，团队、产品负责人、产品经理（PM）和其他利益相关者能够通过可工作的系统完成技术和业务假设条件的验证。每个迭代都会触发一次“集成点”，就是所谓的“拉动事件”，通过团队成员的一致努力把系统的不同方面进行集成，集成包括功能、质量、校准和可用性等。
计划迭代
迭代计划会议是PDCA循环中的“计划”步骤。所有团队成员在会议中对团队目标达成一致，此目标在团队PI目标中描述，在团队和系统演示中展示最终结果。
尽管团队使用ScrumXP或看板会带来一些计划活动上的不同，但是在计划会议中，团队会检查待办事项列表来设定迭代目标，并从系统角度明确需要在迭代结束时进行集成和演示的详细内容。
执行迭代
迭代执行对应PDCA循环中的“执行”步骤，它描述了开展工作的过程。团队在迭代执行中，开发和测试新功能，以增量的方式交付用户故事，当用户故事完成后尽快向产品负责人进行演示，并且通过演示来显示团队的工作进展情况。
在执行阶段还包含一个更小的PDCA循环，即每日站会。团队成员每天都面对面地评估迭代目标的进展情况，更新自己的工作进度。每日站会就是一个以天为单位的PDCA循环，它允许团队每天计划、检查，以及调整他们的迭代计划。
团队演示
团队演示对应PDCA循环中的“检查”步骤。在演示会议上，团队向产品负责人演示经过充分测试的价值增量，并且获得产品负责人的反馈。团队也会根据演示的结果来调整下一个迭代的团队待办事项列表。在演示会上某些用户故事会被产品负责人接收，另外一些会根据迭代中所收集到的反馈进行改进。
团队演示后，团队成员紧接着会参与整个系统的演示。在敏捷发布火车中，系统演示是一个必需的、正式的“集成点”，也是一个“拉动事件”，它会对多个团队的成果进行集成，确保在项目群层级进行尽早的集成和验证。在迭代中，每个团队都可以站在系统的角度，对自己的工作进行持续集成和评估，从而满足整个系统的要求。
改进流程
迭代回顾会“检查”整个迭代的工作，对应PDCA循环中的“调整”步骤。在迭代回顾会议中，团队成员一起评估开发流程和上一个迭代中改进故事的执行情况，识别问题及其发生的根本原因，当然也会回顾工作中做得好的地方，团队把识别出的改进故事放到待办事项列表中，放入下一个迭代中实现。迭代回顾是团队进行持续改进（SAFe精益–敏捷思想的支柱之一）的关键方式之一。不论是立刻进行，还是在检视和调整工作坊时进行，迭代回顾都可以驱动项目群层的流程改进。
在下个迭代计划会议开始前，待办事项列表会根据演示会议和回顾会议的决策重新进行调整。产品负责人根据需要，对新的和原有的待办事项进行重构或重新排序。
参考资料
[1] Cockburn, Alistair. “Using Both Incremental and Iterative Development.” STSC CrossTalk 21 (2008): 27 – 30.
[2] Maurya, Ash. Running Lean: Iterate from Plan A to a Plan That Works. O’Reilly Media, 2012.
3.9 迭代计划
坚守对决定的承诺，但保持灵活的操作方法。
——汤姆·罗宾斯
摘要
基于团队的迭代计划是去中心化的控制，以及授权快速、局部决策的主要机制之一。在Scrum中，团队进行计划，从产品待办事项列表中选取故事，并承诺在接下来的迭代中进行实现。
这个基本流程对SAFe来说也是最为基础的，而且适用于更广泛的敏捷发布火车层面，因为SAFe团队是敏捷发布火车不可分割的组成部分。所以，在PI计划会议中团队的待办事项已经确定或部分确定。此外，团队不仅可以从之前的迭代中获得反馈，而且也能从系统演示和其他团队那里获得反馈。虽然，按照事情发展的自然规律和事实变更的模式来说，迭代计划应该涉及更大的范围。但是，此处的迭代计划流程与Scrum中的方式大致相同，都需要敏捷团队在时间盒会议中对下一个迭代进行计划。迭代计划会议的输出如下：
1.迭代待办事项列表，包括本迭代承诺的故事，以及故事的接收标准
2.迭代目标陈述，通常是描述本迭代中业务目标的一两句话
3.团队对于达成目标所需要做的工作的承诺
详述
迭代计划的目的是组织工作并为迭代定义切合实际的范围。每个敏捷团队为下一个迭代（依据迭代待办事项列表）确定需要完成的故事，并将这些故事汇总成一组迭代目标。迭代待办事项列表和目标是基于团队能力来设定的，同时也考虑了每个故事的复杂性、规模大小，以及与其他故事和其他团队的依赖关系。
在迭代计划的结尾，团队对迭代目标做出承诺，并对故事做必要的调整，从而可以实现更大的目标。在这个过程中，管理层不会干扰或调整迭代范围，以便使团队能够集中精力制订出有效的目标。
迭代计划的输入
在SAFe中，迭代计划是细节层面的细化，也是对在敏捷发布火车PI计划过程中创建的初始迭代计划的调整。团队通过预先详尽阐述的团队待办事项列表制订迭代计划（他们通常在上一次迭代期间召开待办事项列表的梳理会议）。计划会议的输入有如下内容：
在PI计划中创建的团队和项目群PI目标
团队PI计划待办事项列表，包括在PI计划时确定的故事
基于当
最后更新：2017-05-19 16:02:16