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. http://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. http://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计划时确定的故事
基于当时状况产生的额外故事，这些额外故事来源于PI计划环节之后产生的缺陷、重构和新故事等
从先前迭代中得到的反馈，包括在迭代过程中没能顺利完成的那些故事（没有达到完成的定义，请参阅5.10节中的“规模化的完成定义”）
从系统演示中得到的反馈
计划迭代
在迭代计划会议之前，产品负责人会根据团队在项目群增量中的进展，准备好一些初步的迭代目标。通常情况下，在会议开始时，产品负责人需评审拟定的迭代目标和团队待办事项列表中优先级较高的故事。在迭代计划会议期间，敏捷团队讨论实施方案、技术问题、非功能性需求（Nonfunctional Requirement，NFR）和依赖关系，然后制订迭代计划。由产品负责人来定义要实现什么（what）；由团队来定义怎么做（how）和做多少（how much）。
在整个会议期间，团队对接收标准进行详细阐述并且评估完成每个故事的工作量。根据他们的完成速度确定候选故事。很多团队将每个故事分解成任务，并以小时为单位对任务进行估算，以便确认他们是否有能力和技能去完成相应的工作。一旦确认，团队将全力投入工作，并通过可视化的工具记录迭代待办事项列表，如故事板或其他工具。迭代计划会议的时间盒最多不超过4个小时。
确定速度
首先，团队对他们在即将到来的迭代中执行工作的容量进行量化。每个团队成员确定其可用时间和不可用时间，以及其他需要承担的职责。同时也考虑其他的常规职责（参见3.7节中关于“容量分配”的描述），比如维护职责，这些常规职责与新故事的开发有着显著不同。
迭代目标
一旦团队成员的容量已经明确，团队就应把注意力放在理解一个或多个迭代目标并对其达成一致意见，而这些目标正是以PI计划会议中建立的团队和项目群的PI目标为基础的。迭代时间距离PI计划会议越近，就越有可能保持项目群目标不变。
故事分析与估算
团队会以建议的迭代目标作为参考点，对其待办事项列表进行评审。对每个故事进行讨论，涉及相对难度、规模大小、复杂程度、技术挑战和接收标准。最后，团队对故事的估算达成共识。通常团队待办事项列表也包含其他类型的故事，包括构建基础设施工作的使能、重构、研究探针、架构改进以及缺陷，这些故事也会进行优先级排序和估算。
任务
许多团队会将故事再分解成任务。随着任务的确立，团队成员也会对其进行讨论：谁会是完成任务的最佳人选，大约多久会完成（通常以小时计算），它可能和其他任务或故事存在的依赖关系。一旦将这些内容都了解清楚了，团队成员就需要为确定的任务承担起责任。当团队成员开始执行任务时，他们的迭代容量就开始递减，一直减少到零。通常情况下，迭代接近尾声时，一些团队成员会发现自己承诺了过多的任务，而另一些人还有容量空余。这种情况下，团队会进行更深入的讨论以达成任务的均匀分配。
承诺
当团队成员容量之和达到承诺的故事需要的容量时，就不会再从团队待办事项列表中承诺更多的故事了。此时，产品负责人和团队针对将要完成的最终故事列表达成一致意见，并且重新检查和描述迭代目标。此后整个团队就会全身心致力于迭代目标，而工作范围在迭代期间保持固定不变。
参与人员
迭代计划会议的参与人员包括：
产品负责人
Scrum Master，负责主持会议
所有其他团队成员
任何其他利益相关者，包括来自其他敏捷团队或者敏捷发布火车的代表，以及负责某个专题的专家
议程
迭代计划会议议程示例如下：
团队决定可用的迭代速度
产品负责人介绍迭代目标，团队经过讨论并最终同意目标
团队按顺序（或按优先次序）对每个故事进行讨论。对于每一个故事，团队还应该：
按照故事点确定或调整每个故事的大小，必要时对其进行拆分
通过交谈详细阐述每个故事的接收标准
基于规模和价值/时间/风险，产品负责人可能对故事进行重新排序
可选工作：按照排定的顺序，团队将故事分解为任务，并以小时为单位进行估算、明确责任
一旦计划的故事点达到了团队的容量，就不再讨论新的故事了
团队和产品负责人协商并最终确定所选择的故事
每个人都对迭代目标做出承诺
指导原则
下面是举行一个成功的迭代计划会议的技巧：
会议的时间限制在4小时以内
会议由团队发起并举行
团队对工作所做出的承诺，不应该超出自身容量或历史速度
相对估算、速度和标准化故事点估算
敏捷团队使用相对估算来估算故事点的规模大小（参考资料[2]和[3]）。使用相对估算，每个故事的规模大小（工作量）是相对于其他故事的规模来进行估算的。团队的迭代速度等于迭代中能完成故事的规模大小的总和。了解团队的速度可以帮助制订计划，这也是限制WIP的一个关键因素，因为团队不会承担超出他们以前速度所能完成的故事点。团队也可以使用速度来估算需要花多长时间才能完成大型的特性或史诗，特性和史诗同样也可以用故事点来估算。
标准化故事点估算
在标准的Scrum中，每个团队的故事点估算和速度是局部的、独立的。有可能一个小型团队使用自己的估算方式得到的速度为50，而另一个较大的团队估算出的速度只有12，其实这样的结果对其他团队来讲没有什么参考意义。
然而，在SAFe中故事点速度必须标准化，以方便那些需要很多团队支持的特性或史诗可以建立在合理的经济环境中。毕竟，如果你不知道投资的是什么，就无法确定潜在的投资回报。
为了做到这一点，SAFe团队创建了一种方式，使得一个故事点对一个团队和其他团队都有相同的意义。在这样的方式下，伴随着对不同区域经济情况的调整，工作的估算和优先级排序可以基于从故事点到成本的转化来完成。这对初始的PI计划特别有用，因为很多团队是初次接触敏捷，他们需要一种方法来估算第一次PI的工作范围。以下说明了如何开始估算：
除了产品负责人之外，给团队中的每一个成员8个点（非专职成员可做适当调整）
每个团队成员休假日和公共假日减1个点
找到一个较小的故事，花费大约半天时间开发、半天时间测试和验证，将其定义为1个点
相对于上述故事，对其他所有的故事进行估算
例如：假设一个6人组成的小团队，包括3个开发人员、2个测试人员和1个产品负责人，他们都没有休假计划，那么就可以估算初始速度= 5人×8点=40点/迭代。（注：如果开发人员和测试人员中有一人同时担任Scrum Master，则速度可能需要调整得慢一点）。
通过采用这种方法，所有团队都可以用共同的方式进行估算，管理人员就能够为某一特定领域的团队，公平、快速地估算一个故事点所需的成本。然后，他们以有意义的方式为即将实现的特性或史诗建立总成本估算。
注：在此之后，没有必要校准团队估算或速度，这仅仅是一个共同的起始基准。
虽然团队会随着时间的推移提高其速度，这确实是一件好事，但事实上这个数字往往相当稳定，影响团队速度的更大因素是团队规模、结构和技术背景，而不是生产率的变化。而且，如果有必要，财务规划人员可以稍微调整一下每个故事点的成本。相对于那些在非标准化情况下，大规模团队间大相径庭的速度呈现来说，这种财务调整的影响就显得微不足道了。
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 9.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 10.
[3] Cohn, Mike. Agile Estimating and Planning. Robert C. Martin Series. Prentice Hall, 2005.
3.10 迭代执行
没有执行的愿景只是幻觉。
——托马斯·爱迪生
摘要
每个敏捷团队都有一个核心焦点：在短时间盒内开发出一个有效、高质量、可工作、测试过的系统增量。这也是每个精益–敏捷团队、项目群、价值流、投资组合乃至整个企业所面临的根本挑战。如果缺乏有效的迭代执行，即使有完备的准备和计划，也无法实现规模化，解决方案的质量也会受到影响，所有人都会感受到负面的业务影响。
本节将对如何在整个迭代时间盒内进行工作管理提供有效的指导，这些指导对于独立运行的团队或者敏捷发布火车上的团队都适用。
在迭代过程中，团队密切合作，共同定义、构建和测试迭代计划中承诺的故事，并全部展示在团队演示中。团队使用故事、看板和每日站会来跟踪迭代进展和提高价值流。团队在迭代中交付故事，并避免“瀑布”模式，他们会省思实践和挑战，来保证持续增量的小步改进，他们与敏捷发布火车上的其他团队有效合作，通过采用内建质量以保证正确地构建大型系统。这些工作需要花很大精力完成，但是高效的敏捷团队完全能胜任这些工作。?
详述
敏捷团队与传统项目管理和开发模式有所不同，他们得到充分的授权，充满能量和激情，富有使命感和清晰的愿景，从而专注于更快速的价值交付。其核心就是有效地执行每一次迭代。每个团队可能会采用不同的做法，但关注的焦点都是一样的，即通过交付迭代计划中承诺的故事来实现迭代目标。
除了有效的局部迭代执行，敏捷团队有一个更远大的使命，即优化项目群执行。这也是SAFe的四个核心价值观之一。
为实现这个目标，团队在敏捷发布火车的环境中运作，以协调各团队达成一致并实现团队和项目群的PI目标。所有团队都有相同的迭代节奏和时间以保证在进行团队演示和系统演示时，能够同步他们的工作成果以便集成、评估和演示。?
成功迭代执行的关键要素包括：
跟踪迭代进度——使用故事板和看板来跟踪迭代的进度
持续和增量地构建故事——避免“迷你瀑布”，并增量式构建故事
持续沟通——通过团队每日站会进行持续沟通和信息同步
改善流——通过管理在制品，内建质量，持续接收故事来优化流
项目群执行——以敏捷发布火车的模式运作来实现项目群PI目标
跟踪迭代进展
跟踪迭代进展需要对故事、缺陷，以及迭代期间团队的其他活动进行状态的可视化管理。为此，大多数团队会在自己的工作区域或者会议室里，在墙壁上使用大型可视化信息雷达（big visible information radiator，BVIR）。?看板团队使用看板板，ScrumXP团队使用故事板，大致如图3.10-1所示。
使用这个简单的故事板，团队只需要将红标尺移动到当前日期，就能对团队在迭代中的当前状态提供一个简单易懂的可视化评估。（图3.10-1清楚地显示了当前迭代是存在风险的。）团队可以基于这些信息来讨论成功完成迭代所需的工作。如果远程参与者或关键利益相关者需要获取状态信息，团队可以通过网络摄像头、电子邮件或网页进行分享。当然，如果需要进行规模化，几乎所有敏捷团队都能使用敏捷项目管理工具来捕获故事、状态、缺陷、测试用例、估算、实际进展、任务分配、燃尽信息等，而且这些内容都是大型可视化信息雷达的有益补充。
图3.10-1 使用故事板跟踪迭代进度
持续沟通
团队协作的关键是具备开放的环境和在同一地点办公。否则，由于问题和假设造成的延迟，将很快导致价值交付的延迟。在最坏的情况下，在不同工作地点的团队可以通过网络摄像头、即时信息和其他协作工具长期保持在线，从而建立一个开放的沟通环境。
每日站会（DSU）
每天，团队成员在同一时间和地点召开会议，通过回答以下问题来协调他们的工作：
我昨天做了什么故事（及其状态）？
我今天能够完成什么故事？
我工作过程中遇到什么困难了吗（我被阻碍了吗）？
每日站会是团队信息同步和自组织的关键。最有效的每日站会，是团队站在标明了当前迭代目标故事状态的BVIR前进行的。每日站会需严格控制在15分钟之内，它不是解决问题的会议，而是一种用来识别问题、依赖关系和沟通的机制，问题可以在每日站会完成之后处理。Scrum Master在“会后处理板”（Meet After Board）上记录需要进一步讨论的问
题，只有与问题有关的成员需要参与“会后处理”会议。无效的每日站会表现有：需要更系统化的方法并陷入深层次的讨论，并且常常需要Scrum Master协调和干预。
注意 虽然每日站会属于Scrum框架，但许多看板团队也在其看板前进行每日站会，来协调工作和检视面临的瓶颈或在制品问题。
改进流程
管理在制品
限制在制品提供了一种策略，可以预防开发中遇到的瓶颈问题，也有助于改进流。同时还能提高团队的专注力，促进信息共享和集体所有权。所有SAFe团队成员都应该对他们的在制品和流有着清晰的理解。
一般来讲，看板小组都会使用限制在制品的方法，ScrumXP团队有时也会采用限制在制品的方法。应用在制品可以是显式的或隐式的——例如，隐式的应用表现在，当团队成员计划自己的工作时，只接受按照其速度预测可完成的故事数量。这种方式强制要求输入的工作（协商的迭代目标和故事）与容量（团队的速度）相匹配。?迭代时间盒也可以限制在制品，它可以在一定时间内防止不受控制的工作蔓延。
ScrumXP团队也可以在他们的故事板上使用显式的限制在制品方法。例如，图3.10-1中如果没有限制在制品，开发人员在完成故事5之后会做什么呢？他们很可能会开始另一个故事的开发。但如果限制“处理中”和“测试”阶段的在制品数量为3，开发人员则可能会去帮助做测试，这样总产出便会增加。要了解更多有关限制在制品的内容，请参阅SAFe原则#6。
内建质量?
敏捷发布火车以最快的、可持续的前置时间来执行和交付新功能。为此，他们必须创造可预测开发速度的高质量系统。SAFe采纳了一系列质量管理方法和工程实践，以致力建立适用于最大型的解决方案的内建质量，例如测试优先、持续集成、重构、结对工作和集体所有权。确保从一开始就保证质量，以便更快、更容易、更低成本地进行价值交付。?
持续接收用户故事
持续地接收故事，可以不断提升流动性。（图3.10-1展示了一个非流动的迭代，团队在6天内只接收了1个故事。）团队成员一旦准备好就可以演示新故事，而不必等待迭代结束时的团队演示。没有被接收的故事则由团队成员进行返工。这样做可以快速有效地解决问题，也会防止其他成员在不可工作的故事之上，继续开发新的故事，还可以防止团队成员在不同的上下文场景中来回切换所带来的开销。
测试自动化
在可能的情况下，尽量将产品负责人和敏捷团队成员描述的系统接收标准，转换成可以反复运行的故事接收测试用例，并随着系统开发进行持续改进以确保测试用例的适用性、一致性。自动化也能实现快速的系统回归测试，强化持续的系统级集成、重构和维护。通常，这些测试使用业务可读性、领域专业性的语言编写，从而可以为系统创建“可自动执行的规范和测试”。?
连续和增量式构建故事?
避免迭代内的“瀑布模式”
团队应该避免将迭代“瀑布”化的趋势，确保以迭代的方式完成“定义–构建–测试”的循环，如图3.10-2所示。
增量式构建故事
图3.10-3说明了如何将故事拆分成纵向的独立切片，从而实现真正的增量式开发、集成和测试。
图3.10-2 通过跨职能的迭代，避免“迷你瀑布”模式
图3.10-3 增量式开发的关键是用纵向切片的方式实现故事
增量式构建故事可以缩短反馈周期，使得团队能够增量式地对可工作的系统进行持续集成和测试，也可以让敏捷团队成员能够更好地理解相应的功能，实现更频繁的结对开发和集成。团队内外甚至敏捷发布火车团队之间的依赖关系，也可以进行更有效的管理，因为被依赖的团队可以更早地接触新功能。增量式构建故事还有助于减少不确定性，验证架构和设计决策，促进早期学习和知识共享。
专注于项目群执行?
虽然迭代成功很重要，但所有敏捷团队的最终目标是成功实现项目群增量的执行。?为帮助确保团队避免仅仅专注于本地优化而忽视整体优化，SAFe各团队会共同计划、共同集成和演示、共同学习，如图3.10-4所示。
关于各团队共同工作的实践，以及成功实现项目群增量开发的详细内容，可以参考3.2节中的描述。
图3.10-4 各团队会共同计划、共同集成和演示、共同学习
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.11 团队演示
可工作的软件是进度的首要度量标准。
——敏捷宣言
眼见为实。
——佚名
摘要
在人们真正看到、触碰到最终成果之前，故事或特性都只是一个抽象的概念，所以向客户（或其代理人）演示可运行的、经过测试的系统，是一个具有实质意义和影响深远的时刻。为此，在SAFe中，基于解决方案的不同范围定义了3种演示：解决方案演示、系统演示和团队演示。系统演示是由敏捷发布火车的所有团队提供的对新系统所有内容的集成展示，而解决方案演示则是衡量价值流进展的首要度量标准。
本节将对团队演示进行描述。团队演示基于Scrum定义的仪式，用于评审本次迭代所完成的增量结果，有些看板团队也会使用团队演示。如果要计划和举办一次有效的团队演示，是需要团队成员提前做一些工作的。如果没有这种演示，团队就无法得到快速反馈，也无法沿着正确的方向前进。
详述
团队演示的重要性不言而喻，它提供了一种快速的方式，可以从发起人和客户那里收集到基于上下文的反馈。所以，每次演示提供3个重要职能：
团队演示是迭代时间盒的结尾，同时体现了团队成员所做出的贡献与努力，向业务提供了新的价值
团队演示为团队提供了一个机会，可以向业务部门展示自己做出的贡献与努力，并让团队感受到工作和进展中的满足感与自豪感
团队演示允许客户和利益相关者看到可工作的特性并提供反馈
目的
团队演示的目的是向产品负责人和其他利益相关者展示可工作的故事，并得到他们的反馈，从而度量团队的进展。团队演示是一个1～2小时的新功能演示，其准备工作是在迭代计划期间就开始考虑了，团队需要思考如何对所承诺的故事进行演示。团队应该能演示每个用户故事、探针、重构，以及新的非功能性需求。这种“以终为始”的心态，能帮助和培养团队对所需功能点达到更细致深入和更准确的理解，从而也有助于迭代计划的进行。
流程
团队演示一般从评审迭代目标开始，然后走查所有承诺过的故事。每个已完成的故事要以一个可工作、已测试的系统来演示。探针可以通过用研究成果的形式来演示。当把所有已完成的故事演示之后，如果存在没有完成的故事，团队可以反思一下没有完成的原因。这种讨论通常会帮助团队发现开发障碍或风险、错误假设、优先级的变更、不准确的估算，或者过度的承诺。可以把这些结果带到迭代回顾会议上，团队就如何更好地计划和执行以后的迭代进行更深入的讨论。图3.11-1说明了团队演示情况。
团队演示除了能让团队感受到他们在已结束的迭代中的出色工作之外，还可以让团队省思一下他们距离完成PI目标的差距和进展情况。
参与人员
团队演示的参与人员包括：
敏捷团队，包括产品负责人和Scrum Master
敏捷交付火车中的其他利益相关者，或者本迭代中涉及的共享服务人员
业务负责人、高层管理者（发起人）、客户，还可能有其他团队的成员。当这些人参加团队演示时，他们通常会把兴趣和对细节的关注，更多地放在如何与系统演示保持一致性上。否则的话，可能由于团队演示往往更加注重在团队的细节层面上，容易导致“演示疲劳”。
议程
下面是团队演示议程的一个示例：
评审此次迭代的业务环境和迭代目标
演示每个故事、探针、重构，以及可应用的非功能性需求，并收集反馈
讨论所有未完成的故事，并且查明原因（原因可能会有助于下一次迭代计划）
识别从本次迭代或演示中涌现出来的当前最新风险和障碍
指导原则
以下是成功进行团队演示的一些小提示：
团队成员对单个故事的演示准备，要限制在1～2小时
演示会议的时间盒设定为1～2小时
最小化PPT幻灯片的使用
只演示已完成故事的可工作、已测试的系统功能（参照5.10节中关于“完成定义”的描述）
如果一个主要的利益相关者不能参加，产品负责人应该在会后及时跟进向其汇报进度并获得反馈
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 9.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, chapter 15.
3.12 迭代回顾
团队定期地反思如何能提高成效，并依次调整自身的举止表现。
——敏捷宣言
摘要
在每个迭代结束时，采用Scrum框架的敏捷团队成员会聚集起来举行一次迭代回顾会议（有时看板团队也会进行回顾），在回顾中讨论他们所采取的实践，以及如何改进。每次回顾的时间盒是1小时或更短的时间，团队在回顾时需要总结“哪些工作做得好”“哪些工作做得不好”和“哪些工作下一次可以通过改进做得更好”。
每次回顾都包括定量和定性两个方面。定量评审是收集和审查团队所使用的指标并度量其绩效；定性部分会讨论在最近的1～2个迭代中团队所采用的各种实践方法和所面临的挑战。当问题已经被识别出来，也分析了根本原因，讨论了潜在的纠正措施后，就会把改进故事放入团队待办事项列表中。
详述
敏捷团队通过迭代回顾来省思已完成的迭代，并获取新的想法用以改进迭代的过程。这有助于在个人和团队中贯彻持续改进的概念，持续改进也是SAFe精益–敏捷思维的支柱之一。迭代回顾还有助于确保每一次迭代过程中，对团队的流程都进行一些小的改进。
回顾过程需要整个团队的参与，他们与Scrum Master一起，通过应用工具和流程，进行数据采集和问题解决。团队实施的回顾分为两部分：定量部分和定性部分。
定量评审
团队评估他们是否达成了迭代目标，这是一个二元的评定标准，答案为“是”或“否”。他们也同时收集那些已商定的分析标准，比如团队速度，通常包括两部分内容：一部分用于新功能的开发，另一部分致力于已有功能的维护，二者缺一不可。
敏捷团队收集和应用其他可视化的迭代指标，并帮助其过程改进。同时这些数据也可以作为输入，用于后续的定性研究。
定性评审
首先，团队评审那些在以前的回顾中已经识别出来的改进故事的完成情况，然后分析流程现状，并把焦点放在找到他们下一次迭代可以做得更好的1～2件事情上。由于许多改进的故事所涉及的范围较大，所以团队应该将它们划分为更小的改进故事，从而使团队能够专注于在一个迭代中的具体改进工作。
关于迭代成功的几种流行的主观反馈技术如下（参考资料[1]）：
个人——每个人写下记事贴，分小组找出其中的规律
欣赏——记录下是否有人曾经帮助过你，或者帮助过团队
概念——选择一个词语来描述本次迭代
评分——迭代评分范围为1～5分，给本次迭代打分，然后集体讨论如何使下一次迭代达到5分
简单——列出3列内容，然后开放性讨论
以上最后一种方法比较常用，由Scrum Master在纸上画出3列内容，分别是 “做得好的”（What Went Well）“做得不好的”（What Didn’t）和“下次可以做得更好的”（Do Better Next Time），然后开始进行开放性头脑风暴会议。这种方法执行简单，而且使得所有成就和挑战都清晰可见，如图31.12-1所示。
图3.12-1 团队的回顾会议结果示例
议程
一个迭代回顾议程的示例如下。
第一步：定量
团队是否达到迭代目标（是/否）？收集和评审团队已商定的迭代指标。
第二步：定性
回顾上一次迭代中的改进故事。它们都完成了吗？如果没有，我们需要针对这些改进故事做些什么？
对于本次迭代，进行分析：
哪些是做得好的？
哪些是做得不好的？
哪些是我们可以在下一次做得更好的？
指导原则
以下是成功进行迭代回顾的一些小提示：
保持会议的时间盒在1小时或更短的时间。请记住，每两周举行一次会议，目标必须足够小，按照持续改进的步骤进行。
只挑选1～2件可以在下次做得更好的事情，并将其作为改进故事，在下一次迭代中进行实施。
确保每一个人都发言。
Scrum Master应该花费时间准备回顾会议，因为它是迭代改进的主要手段。
聚焦在团队可以处理的改进项上，而不是那些无法解决的内容。
确保在迭代回顾开始时，进行定量评审的过程中，对前一个迭代中的改进故事进行评审并查看其进展情况。
迭代回顾是一个团队的内部会议，应该只限于团队成员参与。
参考资料
[1] Derby, Esther and Diana Larson. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007, Chapter 15, “Regular Reflection and Adaptation.”
3.13 故事
故事，作为一种“行话”，能够使用户和开发者充分理解，达成一致，从而高效地协同工作。
—Bill Wake，极限编程联合发明人
摘要
故事是敏捷开发过程中用于定义系统行为的主要工件。故事不是需求，它是对期望实现的较小功能的简明描述，通常从用户的角度，使用用户的语言来进行编写。每个故事都可以支持系统功能的小型和纵向切片实现，从而可以支持系统的增量开发。敏捷开发中，故事基本上取代了传统的需求规范文档，也可以在后期用需求规范文档汇总成必需的传统需求文档。
故事对于要实现的意图提供了足够的信息，可以让业务人员和技术人员充分理解。故事是“承诺进行交谈”的，它作为一个载体，可以对系统行为和影响进行全面的讨论，而对细节的讨论，可以推迟到故事准备就绪进行实现时再进行。通过接收标准的确定，故事在实现过程中变得更加明确，而系统的质量也得以保证。接收标准可以在接收测试的过程中被自动捕获和验证。不论是最初描述故事的时候，还是后期方案演进的时候，这些测试都可以保证系统的功能被正确地实现。这是SAFe内建质量实践的至关重要的一环。
使能故事是另一种类型的故事。它们不是用来描述系统功能的，而是用来支持探索、架构和基础设施等相关方面的工作，并将这些工作进行可视化呈现。
详述
SAFe框架提供了一个四层的体系结构，用于描述功能层面的系统行为，包括：史诗（Epic）＞能力（Capability）＞特性（Feature）＞故事（Story）。它们和非功能性需求一起构成了敏捷需求（系统行为）的描述要素，用来定义系统和解决方案意图，建模系统行为，并构建起敏捷架构跑道。
史诗、能力、特性和使能，它们被用于描述更大的意图行为，而细节的实现是通过故事来描述的，故事是团队待办事项列表的组成部分。大多数故事来源于项目群待办事项列表的业务和使能特性，也有一些是团队根据自己的情况创建的。
每个故事都是一个小的、独立的行为，可以通过增量实现向用户和解决方案提供相应的价值。故事是功能的纵向切片，有助于确保在每个迭代都交付新价值。为此，就需要对故事进行必要的拆分，使其能在一个迭代中实现。
起初，故事被写在一些索引卡片或者记事贴上。因为索引卡片是有形的实体，有助于在团队、故事和用户之间建立起联系，鼓励大家一起编写用户故事。这些卡片也是动态的，有助于将工作任务进行可视化，可以把它们贴在墙上或放在桌子上，重新排序、相互传递，甚至抛弃掉某些卡片。这些卡片可以帮助团队更好地理解其工作范围（“哇，看看这些故事，让我们接收这些工作吧”）和工作进展（“看看这些故事，都是我们在本次迭代内完成的”）。
虽然任何人都可以写故事，但是只有产品负责人有权批准故事进入团队待办事项列表和接收故事进入系统基线。当然，在整个企业环境中使用记事贴，不太容易进行规模化扩展，所以就出现了很多敏捷项目管理工具，用于辅助管理和跟踪故事。SAFe里有两种类型的故事，用户故事和使能故事，接下来将详细介绍。
故事的来源
在SAFe里，故事通常来源于业务特性和使能特性的拆分，如图3.13-1所示。
图3.13-1 业务特性拆分成故事的示例
用户故事
用户故事是表达功能需求的主要方式，它们基本上替代了传统的需求规格说明书。（然而，在某些情况下，用户故事被用于理解和开发要实现的系统功能，而这些系统功能后期要被记录在传统的需求规格说明书里，以便检查功能的合规性、可追踪性，或者其他用途。）
用户故事以价值为中心，它着眼于用户而非系统，展示出用户的兴趣。为此，推荐的表达方式是如下的“用户之声格式”：
作为一个<用户角色>，我可以<活动>，以便<业务价值>
使用这种格式，团队可以持续地关注和理解谁正在使用这个系统，他们如何使用这个系统，以及他们为什么需要这个系统。应用这种用户之声格式，能够提高团队在该领域的胜任能力，他们可以逐渐地、更好地理解用户真正的业务需求。图3.13-2提供了一个例子。
虽然用户故事的格式比较通用，但也不是每个系统都与最终用户打交道。有时，“用户”是一台设备（如打印机）或者其他系统（如交易服务器）。在这种情况下，故事的描述可以采用如图3.13-3所示的格式。
使能故事
团队也需要开发一些技术方面的功能，这些功能可以用于实现许多不同的用户故事，或者用于支持系统中的其他组件。在这种情况下，故事可能不直接接触任何终端用户。这就出现了使能故事，使能故事可以支持探索、架构和基础设施建设，就像其他内容的推进器一样。在这种情况下，故事的描述就是从技术的角度，而非用户的语言了，如图3.13-4所示。
图3.13-2 用户之声格式的 图3.13-3 系统作为用户的 图3.13-4 使能故事示例
用户故事示例 用户故事示例
使能故事可以包括以下内容：
重构和探针（与极限编程中的定义相同）。
构建或改进开发/部署的基础设施。
运行需要人工干预的任务（例如，检索100万个网页）
根据不同的目的，生成不同的产品或组件的配置
执行特殊类型的系统质量验证（例如，安全脆弱性测试等）
当然，使能故事和用户故事一样，可以进行演示，典型的做法是可以演示生成的工件，或者通过用户界面（UI）、打桩（stub）和模拟（mock）进行。
编写好的故事
3C：卡片（Card）、交谈（Conversation）、确认（Confirmation）
Ron Jeffries是极限编程的发起者之一，他提出了用户故事的3C方法。
卡片（Card）指的是用一张索引卡片、记事贴或使用其他工具，捕获和表明用户故事的意图。索引卡片很自然地提供了团队和故事之间的联系。卡片的大小从物理上限制了故事描述的长度，从而也限制了系统行为的早期特征。卡片也可以帮助团队“感觉”到故事涉及的范围，比如团队手中拿着10张卡片的感觉，与用眼睛看10行电子表格的感觉是有区别的。
交谈（Conversation）表达的意思是在团队、客户/用户、产品负责人和其他利益相关者之间“承诺进行交谈”。这是一些必要的讨论，用来决定为了实现某些意图所需要的细节行为。这些交谈也可能会产生其他形式的变化，比如模拟、原型、表单、算法、时序图等。交谈跨越了故事的整个生命周期：
待办事项列表的梳理
计划
实现
演示
交谈提供了共享的氛围，这是正式文档所无法提供的。交谈通过讨论功能的具体实例，让需求变得不再模糊。交谈也有助于发现一些没考虑到的情况或者一些非功能性的需求。有些团队也会在故事卡片的确认栏中记下他们将如何演示该故事。
对接收标准的确认（Confirmation）提供了明确的条件，用于确保故事可以被正确地实现，并且满足了所有相关的功能性和非功能性的需求。图3.13-5提供了一个示例。
敏捷团队会尽可能地做到自动化接收测试，通常使用业务可读性、领域专业性的语言编写，由此为系统创建“可自动执行的规范和测试”。自动化也提供了对系统进行快速回归测试的能力，这种能力增强了持续集成、重构和维护。
对好故事进行投资
人们通常会用Bill Wake发明的缩略词“INVEST”来提醒良好的故事应该具备的要素：
I——独立性（Independent，独立于其他所有故事）
N——可协商（Negotiable，灵活的意图表述，不是合同）
V——有价值（Valuable，提供给客户有价值的纵向切片）
E——可估算（Estimable，小的，也是可协商的）
S——小的（Small，适合一次迭代完成）
T——可测试（Testable，充分地理解如何进行测试）
在参考资料[1]和参考资料[2]中，可以得到更多信息。
故事的估算
SAFe中的ScrumXP敏捷团队使用故事点和估算扑克（参考资料[2]和[3]），对其工作进行估算。故事点是一个数字，用于代表以下内容的：
数量——有多少？
复杂度——有多难？
知识——哪些是已知的？
不确定性——哪些是未知的？
故事点是相对的，它们和任何特定的度量单位无关。假定一个最小的故事，给它赋1点，然后其他故事的大小（工作量）可以相对于这个最小的故事进行估算。SAFe应用修改过的斐波那契数列（1，2，3，5，8，13，20，40，100）来体现估算中的不确定性，尤其是对于一些较大的数字（如20，40，100等）（参考资料[2]）。
估算扑克
敏捷团队通常使用“估算扑克”，可以综合专家意见、模拟类比、分解等手段来快速可靠地进行估算（也可以使用其他的估算方法）。使用“估算扑克”的规则有：
所有团队成员都参加
发给每个估算者一叠卡片，1，2，3，5，8，13，20，40，100，∞，以及 ?
产品负责人参加会议，但不做估算
Scrum Master参加会议，但不做估算，除非他也参加实际的开发工作
对于每一个需要估算的工作项，产品负责人讲读故事的描述
进行问题的提问和解答
每个估算者独立地选出一张估算卡片，用于代表他的估算
所有的估算卡片同时翻开，所有参与者能看到其他人的估算
给出估算点数最高和最低的人，向其他人进行解释
经过一番讨论，每个估算者使用估算卡片重新进行估算
估算将会倾向于收敛。如果没有，重复以上过程
进行一些前期的设计讨论是适宜的，然而，花费过多的时间用于设计讨论就是浪费精力。估算扑克的真正价值就是对故事的范围达成一致，而且也很有趣！
速度
团队的速度等于一个迭代中完成的所有故事（达到了完成定义）的故事点的总和。了解团队的速度有助于制订计划，也是限制在制品的一个关键因素，因为团队不应该承担超过其速度的过多故事。大型的史诗、能力、特性和使能，都会使用故事点进行估算，所以速度也可以用于估算它们的交付时间。
估算的通用起始基准
在标准的Scrum中，每个团队的故事点估算和速度是局部的、独立的。有可能一个小型团队使用自己的估算方式得到的速度为50，而另一个较大的团队估算出的速度只有12，其实这样的结果对其他团队来讲没有什么参考意义。
然而，在SAFe中，故事点速度必须有一个通用的起始基准，以便于那些需要很多团队支持的特性或史诗可以建立在合理的经济环境中。为了做到这一点，SAFe团队创建了一种方式，使得一个故事点对一个团队和其他团队都有相同的意义。在这样的方式下，伴随着对不同区域经济情况的调整，工作的估算和优先级排序可以基于从故事点到成本的转化来完成。毕竟，如果没有可比性的“通用货币”，就无法确定潜在的投资回报。
对于故事和速度所采取的一种通用的起始基准如下：
对于团队中的每一个开发人员、测试人员，给予8个点（如果非专职成员做适当调整）
每个团队成员休假日和公共假日减1个点
找到一个较小的故事，花费大约半天时间开发、半天时间测试和验证，将其定义为1个点
相对于上述故事，对其他所有的故事进行估算
例如：假设一个6人组成的小团队，包括3个开发人员、2个测试人员和1个产品负责人，他们都没有休假计划，那么就可以估算初始速度= 5人×8点=40点/迭代。（注意：如果开发人员和测试人员中有一人同时担任Scrum Master，则速度可能需要调整得慢一点）。
通过采用这种方法，故事点数在某种程度上可以类比于一个理想开发人日，所有团队都可以用共同的方式进行估算，管理人员就能够为某一特定领域的团队，公平、快速地估算一个故事点所需的成本。然后，他们以有意义的方式为即将实现的特性或史诗建立总成本估算。
注意 在此之后，没有必要校准团队估算或速度，这仅仅是一个共同的起始基准。
虽然团队会随着时间的推移提高其速度，这确实是一件好事，但事实上这个数字往往相当稳定，影响团队速度的更大因素是团队规模、结构和技术背景，而不是生产率的变化。而且，如果有必要，财务规划人员可以稍微调整一下每个故事点的成本。相对于那些在非标准化情况下，大规模团队间大相径庭的速度呈现来说，这种财务调整的影响就显得微不足道了。而且没有通用的起始基准，也就无法进行企业的规模化，因为无法找到决策的经济基础。
故事拆分
颗粒度小的故事可以更快、更可靠地实现，因为小颗粒可以快速地通过系统，减少变异性，易于管理风险。因此，把大颗粒的故事拆分成小颗粒的故事，是每一个敏捷团队的必备生存技能，也是增量式开发的一项艺术和科学。有10种故事拆分的方法（参考资料[1]），以下是这些方法的简要总结：
1.工作流程步骤
2.业务规则变化
3.主要工作量
4.简单/复杂
5.数据的变化
6.数据入口方法
7.延迟系统质量
8.操作（例如：创建、读取、更新、删除或CRUD）
9.用例场景
10.创建一个探针
图3.13-6展示了以上第9项中，通过用例场景拆分故事的示例。
图3.13-6 将大故事拆分成小故事的示例
SAFe需求模型中的故事
正如SAFe需求模型所描述的那样，该框架使用了一套完备的工件及其之间的联系，用于在精益和敏捷的环境中定义和测试复杂系统。图3.13-7说明了在大框架中故事的呈现方式。
图3.13-7 在SAFe 需求模型中的故事
如图3.13-7所示，故事通常是由特性衍生出来的（有时也有例外，比如团队根据具体情况创建的故事），而且每个故事都与故事接收测试相关联。在极限编程和SAFe的ScrumXP中，每个故事都会有一个单元测试，单元测试的主要作用是确保故事的实现是正确的。此外，因为单元测试容易自动化，所以这是自动化测试的一个关键起始点，可以参考8.2节中的描述。
注意 在图3.13-7中，使用的是UML方式描述对象之间的关系：0对多（0，1），1对多（1..*），1对1（1），等等。
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chapter 6.
[2] Cohn, Mike. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.
3.14 迭代目标
清晰的阐述可以让深刻的思想更加出色。
——Luc de Clapiers
摘要
迭代目标是敏捷团队和产品负责人达成的共识，是可以在一个迭代内完成的业务和技术目标的高度概括性描述。敏捷发布火车作为自组织、自管理的众多团队的集合，可以通过各团队的迭代目标进行汇总和有效协调。迭代目标有助于团队成员和产品负责人把共同的使命对齐到迭代中，也有助于每个团队对齐到项目群的PI目标上，从而可以为理解和处理团队之间的依赖提供依据。最后，迭代目标可以为团队、管理层以及业务负责人之间的沟通提供一份简单的协议，让所有人可以朝一个共同的目标努力，管理层可以持续地获知工作进展。
无论团队应用Scrum还是看板，迭代目标都提供了一种共同的语言，让项目群利益相关者、管理层和敏捷团队可以保持一致，管理依赖，并在项目群增量的执行过程中进行必要的调整。
详述
正如3.9节中所述，计划过程会产生三个输出：
1.迭代待办事项列表，由承诺在迭代内完成的故事组成。
2.迭代目标的描述，如图3.14-1所示。
3.为了实现迭代目标，敏捷团队对于需完成工作的承诺。
迭代目标往往反映了以下几点：
特性、特性切片或特性部分，如研究、必要的架构等
业务或技术里程碑
架构、技术或基础设施工作
常规的工作
其他承诺，如维护、文档等
迭代目标可以通过完成迭代待办事项列表来实现，但这并不意味着要完成所有故事才能达成迭代目标。换句话说，迭代目标要高于任何特定的故事。有时候，甚至有必要添加预先未能想到的故事，才能实现迭代目标。
为什么需要迭代目标
迭代目标在SAFe和Scrum中是必需的（Scrum称之为冲刺目标）。敏捷团队在一个迭代里通过完成足够小的故事来开展工作。把用户价值分割成足够小的、纵向的、可测试的故事，这是一项基本的敏捷能力，但这样往往会造成“只见树木不见森林”。在敏捷发布火车中，迭代目标会帮助团队从更高的角度理解和维护每次迭代待完成的工作，以及要在下一次系统演示会议上的演示内容。这就是透明性、协调一致和项目群执行的基础，它们是SAFe四个核心价值观中的三个。简单地说，团队承诺在一个迭代里完成一系列用户故事是不够的，团队必须始终关注每次迭代的业务价值，而且能够用业务术语与业务负责人、管理层和其他利益相关者就这些价值进行沟通。
迭代目标提供了三方面的价值，从而构成了一个全面的方法来帮助团队和敏捷发布火车保持协调一致，并始终致力于一个共同的目标和使命，具体描述如下。
将团队成员对齐到共同的目标
迭代执行是一个快速和激烈的过程，两周的时间一晃而过。迭代目标可以帮助团队和产品负责人，回到他们最初计划发布业务价值时所达成的共识，保持团队和项目群PI目标的对齐，并帮助团队落地实现已确定的目标，如图3.14-2所示。
将项目群团队对齐到共同的PI目标并管理依赖关系
SAFe团队并不是一些敏捷孤岛。相反，它们属于一个更大的项目群环境和目标的有机整体。因此，每个团队必须与其他团队和发布火车工程师就下一个迭代的目标进行沟通，从而能够确保大家保持对齐到项目群PI目标上。此外，各个团队的迭代目标也提供了发现和解决依赖关系的必要环境，如图3.14-3所示。
提供持续的管理信息
为了扩展到项目群层面，同时又要保持精益和敏捷的理念，这就依赖于建立自管理、自组织的敏捷团队。这些团队应该很少需要行政管理干预或日常监管。在这种情况下，经理们可以向上管理和跨团队管理，而不是向下管理。这样就可以创建一个充分授权的、更加精益的组织，管理层就可以承担更多责任，用自己的组织能力来消除障碍并帮助推动组织级改进。然而，管理层不能也不应该抛弃理解团队的责任，他们应该了解团队正在进行的工作以及开展这些工作的原因，因为管理者仍然负有责任去提高组织的开发能力并保证价值发布的成果。为此，将发布火车上的迭代目标进行汇总，从而提供一个简单的、文本化的、以两周为周期的工作内容概要，如图3.14-4所示。
图3.14-2 迭代目标帮助团队对齐 图3.14-3 迭代目标对齐团队到项目群PI目标，
并帮助识别团队间的依赖关系
图3.14-4 迭代目标提供了可视化及与管理层的沟通途径
参考资料
[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
3.15 内建质量
通过快速集成学习环，进行增量式构建。
—— SAFe原则#4
摘要
内建质量是SAFe的四个核心价值观之一。企业以最快的可持续前置时间交付新功能，并应对瞬息万变的商业环境，这些都有赖于解决方案的质量。内建质量不是SAFe特有的概念，它是精益–敏捷的核心原则之一，有助于避免与需求召回、返工及缺陷修复相关的延迟成本。敏捷宣言同样专注于质量，其中有一条敏捷原则是这样描述的：“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强”（参考资料[1]）。内建质量对于大规模系统的价值是确切无疑的，并且属于强制性的。为此，本节将介绍软件、固件和硬件的质量实践。
软件方面的质量实践——很多是受到极限编程的启发，而且在极限编程中也有描述——可以帮助敏捷软件开发团队，确保他们所构建的解决方案是高质量的，易于响应变化的。这些实践间的相互协同的本质，重点在于频繁地确认，以及建立一种把工程和匠艺作为关键业务推动者的自发的文化氛围。
对于固件和硬件，其质量目标和软件是相同的，但是在物理和经济上有些不同，因此实践上也有些差异。这些差异包括，固件和硬件的开发会更加专注于建模、模拟和更多的早期探索过程，以及更多的设计验证和更频繁的系统级集成。
详述
当企业需要应对变化时，建立在良好的技术基础上的软件和系统更容易去改变和适应。这对大型系统来说则更为重要，因为即使是小缺陷的累积效应以及错误的假设，都可能造成令人无法接受的后果。
实现高质量的系统是一项严谨的工作，需要持续的培训和承诺，但对业务收益的投资也是非常必要的：
更高的客户满意度——低缺陷率的产品和服务能提供更好的客户满意度、更高的安全性、更好的投资回报，并给业务部门增添更多的信心。
开发组织的预见性与信任——如未在解决方案的质量上进行可靠的控制，那么对新功能的开发不可能做出可预测性的计划，也无法确定开发的速度。因此在公司内会造成一种信任感缺乏，降低个体对软件工艺的荣誉感，造成士气的低落。
可延展性——当组件能清楚地表达设计意图，展现出简洁的风格，并在系统架构上支持集成和测试，这时投入更多的人力和资源会为企业带来更多的商业价值。否则，增加更多的开发和测试人员反而会给企业带来拖累，最终将导致高度不确定的、企业无法接受的质量和延迟。
速度、敏捷性和系统性能——更高的质量有助于提高可维护性和增强快速开发新业务功能的能力。同时也会提高团队维护和提升关键的非功能性需求的能力，包括：性能、可扩展性、安全性和可靠性。
创新的能力——创新出现在聪明的、富有激情的人身上，以及由他们所掌控的环境中。在高质量创造出的良好技术环境下，创新的想法能够很容易地产生原型、测试和演示。
下文将对在软件、固件和硬件上达成内建质量的实践进行总结。
软件
SAFe是建立在长达几十年的不断演化、不断追求更好的工程实践的基础之上的，在很大程度上受到了创新性的精益和敏捷方法的推动。当谈到软件工程时，极限编程实践起着引领的地位（参考资料[2]）。除了敏捷架构在保证系统级的质量中所起的关键作用之外，SAFe还引入了关键的精益–敏捷软件工程实践，以帮助团队实现最高级别的质量。下文总结了这些实践，其中的两个——持续集成和测试先行，在本书中会有更深入的阐述。
持续集成
持续集成（Continuous Integration，CI）是一种软件工程实践，它每天不间断地把开发人员自己工作空间中的代码合并到单一主干代码分支上。通过这种方式，所有共同开发程序的人员能一直保持在最新的程序版本上工作，开发人员之间的程序缺陷能立即被发现，假设也能立刻得到验证。持续集成有助于避免系统集成的延迟风险，及其对系统质量和项目可预测性的不利影响。
持续集成需要专业的基础设施和工具，包括自动化构建服务器和自动化测试框架。但更重要的是需要建立一种文化和使命感，要求个人和团队以交付完全集成和全面测试的软件为荣。
在SAFe中，团队至少每天执行一次本地集成，但同样重要的是要将完整的系统进行集成，并在必要的时候运行回归测试，以确保系统向期望的方向发展。在初期实现每日集成不太可行，所以合理的初始目标可能是，在每迭代中至少实现一到两次全系统的集成。这样也为成功地进行每两周一次的系统演示提供了基线。
8.1节中提供了关于该主题的更多内容，特别是系统级和解决方案级的持续集成。
测试先行
测试先行是一种鼓励团队在代码实现前深入思考系统行为的哲学。它提升了编码的效率并使得产品更易于使用，它同时建立了一种更为全面的测试策略，由此系统的需求被转化为一系列的测试案例，通常这些测试案例在编写代码前会事先写好。
测试先行策略可细分为测试驱动开发（TDD）和接收测试驱动开发（ATDD）。两者都由自动化测试所支持，自动化测试是支持持续集成、团队速度和开发有效性所必需的。
在测试驱动开发中，开发人员首先编写自动化单元测试案例，执行测试案例并观察其运行失败，然后编写一个最小的代码用以通过测试。测试驱动开发主要适用于编码方法或者单元（技术）层面，这保证了测试的真实存在，防止镀金和编写不必要的更复杂的代码。同时，测试驱动开发还有助于保证需求能持续得到自动化测试，并保持最新的状态。
接收测试驱动开发是一种先进的技术，表征系统行为的接收标准由产品负责人确定，然后将接收标准转换为可反复执行的接收测试，在系统演进的过程中保证持续的一致性。接收测试驱动开发有助于团队专注于系统级别的、用户可观测的需求，这给团队提供了清晰的成功标准。
8.2节中提供了关于该主题的更多内容。
重构
重构是“重组代码的现有结构，改变其内部结构而不改变其外部行为的技术”（参考资料[3]）。敏捷避免“大量的前期设计”（BUFD），并遵从“即使在开发后期，也拥抱需求变
更”（参考资料[1]），这意味着当前的代码库在业务需要新增功能时是经得起考验的。为了保持这种应变能力，团队不间断地通过一系列小的改进持续进行重构，为未来的发展打下坚实的基础。如果因为“总是希望增加新功能”，而忽视重构，就会快速构建起一个僵化和不可维护的系统，最终导致经济效益越来越差。
重构是实现浮现式设计的关键，而且是敏捷开发中必要和不可或缺的组成部分。有关重构的更多指导信息，请参见“重构”的有关阐述。
结对工作
结对工作与结对编程相对应，结对编程是极限编程中的一种强制实践，需要两个程序员在同一台电脑上工作。一个人编码，另一个人是观察员，负责评审、检查和为编码过程增值，在结对过程中角色可以互换。在每写一行代码前，结对人员都要讨论需要做的事情，并达成对需求、设计、测试的一致理解。观察员检查代码，提出关于如何提高代码的意见，并指出潜在的错误。结对编程中会进行实时的、全面的同行评审。
结对编程是极限编程的组成部分，但它也是有争议的，有些人认为结对增加了成本，因为两个人在同样的代码上工作。同时，结对编程也可能面临人际交往和文化上的挑战。
对很多人而言，结对编程过于极端了。然而在实践中，敏捷团队中有很多种不同的结对工作方式，每一种都有其价值，并且可以结合起来应用。有的团队在所有编码工作上都遵循结对编程标准，就像极限编程中所描述的那样；有的团队中开发人员与测试人员针对故事进行结对，在故事完成时评审彼此的工作；还有的团队更倾向于自发的结对，开发人员在关键代码片段、重构遗留代码、开发接口定义以及系统级别集成等有挑战性的工作上进行结对。结对工作是重构、持续集成、测试自动化，以及代码集体所有权的重要基础。
集体所有权
集体所有权“鼓励每个人为项目的所有部分贡献新的想法。任何开发人员都可以更改任意一行代码去增加新的功能、修复缺陷、改进设计或重构。没有人会成为变化的瓶颈”（参考资料[4]）。集体所有权在SAFe体系中尤为重要，因为大型系统拥有大型代码库，最初的开发人员很可能已经不在项目团队中了。即使那些人还在团队中，如果总是依赖某一个人去修改代码，就会造成工作上的交接，也一定会带来延迟等待。
扩展集体所有权的实施，需要在整个项目群中遵循经过验证的、一致商定的编码标准，拥抱简单的设计，揭示代码结构中的意图，并建立接口机制用于进行灵活的系统修改。
固件和硬件
除了编码以外，没人能够扩展低质量的组件或系统。硬件元素都很少涉及“软”的部分，比如电子、电气、流体、光学、机械、包装、热能等，所以它们更加难以变更，而且如果发生变更会更为昂贵。如图3.15-1所示（参考资料[5]），固件和硬件中的错误和未经证实的假设可能导致更高的变更和返工成本。
如下文所述，这种更高的后期变更成本，促使网络物理系统的精益开发人员使用一些相关实践，确保在解决方案开发过程中的内建质量。
探索早期迭代
正如参考文献[6]中所强调的，即使在建造“哈雷–戴维森摩托”时，也需要一个非常完整的团队在道路上测试新的摩托车，更频繁的设计周期是系统构建者的有效工具，它能够用以加快对产品知识的掌握，降低风险和后期发现错误的成本。在这方面，SAFe使用与软件相同的方式来处理固件和硬件，比如所涉及的迭代和项目群增量节奏，以及目标期望等都大致相同。然而，早期的迭代是特别关键的，因为变更成本还没有达到很高的水平。精益系统构建者应用“更软”的工具系统展开更快的迭代，包括以下内容：
敏捷架构
基于模型的系统工程
基于集合的设计
频繁的系统级集成和测试
持续集成是许多软件解决方案的一个有价值的、可实现的目标。然而，在网络物理系统中却难以应用甚至难以想象，因为有许多物理部件——模具、机械、小部件等，产品演变缓慢，而且无法每天进行集成和评估。但是，这不能成为延迟和难于进行集成的借口。
毕竟，最终所有不同的组件和子系统——软件、固件、硬件等——必须集成到一起，才能提供有效的解决方案级的行为，而且越早越好。为此，精益系统构建者尝试在早期频繁地集成和测试子系统和完整系统。这通常需要增加在开发、部署、测试等基础设施方面的投资。
设计验证
然而，仅仅集成和测试是不够的。首先，由于系统的各种组件在可用性方面的依赖，集成和测试可能在整个流程中发生得太晚；第二，集成和测试不可能覆盖所有可能的使用情况和失败场景。为了解决这个问题，系统构建者执行设计验证以确保设计满足解决方案的意图。设计验证可以包括：诸如子系统之间需求的规范和分析的步骤，最差情况下的容忍度和性能分析，失败模型和影响分析，可跟踪性，热分析，环境，以及其他系统级部署方面等。
在软件领域，虽然设计验证的诸多方法也很重要，但由于软件的变更成本较低，所以在设计的选择上不需要太多的事先承诺。然而，对于固件和硬件，需要前期设计方面的更多考虑，以及工作规范上的保证。
参考资料
[1] Manifesto for Agile Software Development. www.AgileManifesto.org.
[2] Beck, Kent, and Cynthia Andres. Extreme Programming Explained: Embrace Change. Addison-Wesley, 2004.
[3] Fowler, Martin. Refactoring.com.
[4] http://www.extremeprogramming.org/rules/collective.html.
[5] Rubin, Ken. http://www.innolution.com/blog/agile-in-a-hardware-firmware-environment-draw-the-cost-ofchange-curve.
[6] Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.
