《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一3.2 敏捷团队...

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

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所示。

共同计划

所有团队共同参加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/.