本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第3章，第3.1节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
第3章
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.
