本节书摘来自华章出版社《SAFe 4.0参考指南：精益软件与系统工程的规模化敏捷框架》一书中的第3章，第3.5节 作者［美］迪恩·莱芬（DeanLeffingwell），更多章节内容可以访问云栖社区“华章计算机”公众号查看。
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所示。
有些团队在部分步骤中应用在制品限制，从而在迭代中创造“拉动”过程，持续平衡工作以提高产能。事实上，很多团队把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.
