没有什么能打败敏捷团队。

--SAFe的咒语

敏捷团队

安全敏捷团队是一个由5到11人组成的跨功能团队，他们负责定义、构建、测试和在适当的地方部署一些解决方案价值的元素——所有这些都在一个短的迭代时间框中完成。具体来说，安全敏捷团队包括开发团队、Scrum Master和产品负责人角色。

正如SAFe的团队和技术敏捷能力中所描述的，敏捷团队为敏捷发布培训(ART)提供动力，并最终为整个企业提供动力。艺术负责交付更大的解决方案价值。没有队伍，就没有火车。所有的团队都在一个火车上，为它的愿景和路线图做出贡献，与其他团队合作，并参与艺术活动。此外，他们主要负责构建持续交付管道和ART DevOps功能。

团队和火车是不可分割的;整体大于部分之和。

细节

敏捷运动[1]代表了软件和系统开发方式的一个主要转折点。SAFe通过将敏捷团队授权为创建和交付价值的构建块，构建在此变更之上。如果没有有效的敏捷团队(由授权的和积极的个人组成)，组织就无法实现精益敏捷开发的更大的业务利益。

总之，敏捷团队拥有在短时间内开发增值所需的所有技能:

• 定义-详细说明和设计功能和组件
• 构建-实现特性和组件
• 测试—运行测试用例来验证特性或组件
• 部署—将特性移到“登台”和“生产”环境中

当在艺术的上下文中运行时，团队被授权、自组织和自管理。他们负责交付满足客户需求和期望的结果。团队开发软件、硬件、固件或某些组合。但最重要的是，团队代表了交付特性或组件所必需的跨功能规程的协作。

通过将工作转移到团队和培训中，而不是将人员带到工作中，企业可以在很大程度上消除工作的“项目模型”(参见精益预算)，取而代之的是创建团队，以及团队中的团队，这些团队是长期存在的，致力于不懈地提高交付解决方案的能力。这就是SAFe与传统方法的不同之处，传统方法是由管理人员引导个人进行活动。安全的团队——而不是他们的管理者——决定他们可以在迭代中构建什么特性和组件，以及如何构建它们。精益敏捷领导者提供了培养和提升高效团队所必需的愿景、领导力和自主性。由于团队在很大程度上是自组织和自管理的，因此不再需要将工作分配给单个团队成员。这使得分散决策能够一直进行到单个贡献者的级别。精益敏捷领导者的主要职责就是指导和指导敏捷团队。

SAFe团队通常混合了敏捷方法

安全团队使用敏捷实践，主要基于Scrum、看板和极限编程(XP)。大多数安全的团队都将Scrum和XP(参见安全ScrumXP)作为基本框架。产品负责人管理团队Backlog。Scrum Master帮助团队实现其交付目标，并帮助建立一个高效且自我管理的团队。

团队应用精益UX特性开发和内置的质量实践来驱动有纪律的开发和质量。这些实践——包括集体所有权、结对工作、编码标准、测试优先和持续集成——通过将质量和操作效率直接嵌入到流程中，帮助保持精益。敏捷架构完成了高质量解决方案开发的蓝图。

然而，由于SAFe是一个基于流的系统，大多数团队还应用看板来可视化他们的工作，建立过程中的工作(WIP)限制，并使用累积流图(CFDs)来说明提高吞吐量的瓶颈和关键机会。一些团队——特别是维护团队和系统团队——经常将看板作为他们的基本实践。这是因为Scrum的计划和承诺元素可能不适用于基于活动和需求、优先级变化更频繁的工作负载。

责任

SAFe有助于摆脱传统的分阶段开发模型，在这种模型中，用户价值是在长生命周期结束时交付的，输入来自不同的功能竖井(需求、设计、测试、部署)。相反，敏捷团队执行所有这些功能，同时在每次迭代中交付价值。敏捷团队负责管理他们的工作，并在从持续探索到持续集成、持续部署到随需发布的整个生命周期中产生价值。为了做到这一点，团队:

• 估计工作的规模和复杂性
• 在体系结构指南中确定他们所关注领域的技术设计
• 提交到它可以在迭代或程序增量(PI)时间框中完成的工作
• 实现了功能
• 测试的功能
• 将该功能部署到登台和生产
• 支持和/或构建构建连续交付管道所需的自动化
• 持续改进他们的过程

此外，在任何可能的情况下，敏捷团队都具有构建和管理持续交付管道的技能和职责，并尽可能独立地发布其元素(特性、组件、子系统或产品)。

合作和文化

敏捷团队的动力来自于一个共同的愿景，以及他们向客户交付价值的承诺。每个团队成员都全身心地投入到一个单独的团队中，并投入到激烈的工作中。团队成员持续并积极地与其他团队合作，以管理依赖关系并解决障碍。团队内部的关系基于信任，由共同的任务、迭代目标和团队PI目标促进。通过在学习周期中构建有规则的反馈循环，协作将不断得到改进。每一个有形的价值交付都能鼓励信任，减少不确定性和风险，并建立信心。

团队只有通过持续的沟通和协作，以及快速、有效和授权的决策才能履行其职责。如果可能的话，团队的配置是为了方便每小时和每天的沟通。标准的团队会议在某种程度上依赖于所选择的方法，但是它们通常包括每日站立会议、迭代计划、迭代评审、backlog细化和迭代回顾。

敏捷团队就在火车上

安全的敏捷团队并不独立运作;它们通过协作和构建越来越有价值的工作解决方案增量来为艺术提供动力。所有团队都在一个管理和指导培训的共同框架内工作。他们一起计划，一起集成和演示，一起部署和发布，一起学习，如图1所示。

图1所示。敏捷团队一起计划，一起集成和演示，一起发布和部署，一起学习

一起计划

所有团队都参加PI计划，在那里他们一起计划并承诺一组PI目标。他们为一个共同的愿景和路线图而工作，并就实现目标的方法进行协作。清晰的内容权威角色有助于规划和执行过程。产品负责人是更大的产品管理团队的一部分。团队的单个团队积压部分是由计划积压驱动的。

此外，作为艺术的一部分，并根据经济框架，所有敏捷团队都参与到评估工作的公共方法中。这为帮助决策当局根据经济学指导行动进程提供了一种有意义的方法。

集成和演示在一起

交付复杂、高质量的系统需要紧密的团队间合作和协作。为了支持这一点，团队使用一个公共的艺术节奏，并在每个迭代的开始发布和交流迭代目标。它们还在ART同步期间更新其他团队，并通过与来自其他团队的团队成员交互来积极管理依赖关系。

当然，目标并不是简单地让团队朝着目标“冲刺”。相反，我们的目标是让系统在基于质量的、可度量的增量中快速前进。为了支持这一点，团队应用内置的质量，并进行持续的探索、持续的集成和持续的部署。这发生在团队内部和整个培训过程中——同时一起工作，在每次迭代结束时完成一个聚合的系统演示。

一起部署和发布

敏捷团队通过整个持续交付管道来驱动价值。他们围绕持续的探索与产品管理协作，他们不断地集成，他们不断地将他们的工作部署到登台和生产环境中。

敏捷团队通过早期和频繁地部署到生产环境中来帮助验证特性假设。他们设计自己的系统的方式能够将解决方案与发布解耦，并能够按需发布。

一起学习

所有安全的团队都在不断地改进(参见精益敏捷思维文章的第4支柱)。除了迭代回顾和特别的过程改进之外，团队还参加ART Inspect and Adapt (I&A)会议，在会议上，他们确定并优先化被纳入到以下PI计划会议中的改进待办事项。这就关闭了循环，因为团队和ART一次只前进一个迭代和PI。当然，学习并不局限于回顾。学习是不断发生的，实践社区(cop)也为学习提供了便利，它的成立是为了帮助个人和团队提高他们的功能和跨功能技能。

了解更多

• 敏捷软件开发的[1]宣言。http://agilemanifesto.org/。
• [2]Leffingwell,院长。扩展软件敏捷性:大型企业的最佳实践。addison - wesley, 2007年。
• [3]Lencioni,帕特里克。团队的五大功能障碍:一个领导寓言。2002年?。

原文：https://www.scaledagileframework.com/agile-teams/

本文：https://pub.intelligentx.net/safe-agile-teams

讨论：请加入知识星球或者小红圈【首席架构师圈】