SAFe中敏捷团队相对Scrum的实践特点

在向朋友们发布 关于燃尽图的第一篇文章, 之后，评论中提出的第一个问题是：“很想更详细地了解你们在SAFe方面的经验”。因此，在本文中我将结合我们的实践，阐述SAFe相对Scrum的工作特点。我绝不声称这是第一手真理，并欢迎同事们提出任何修正和澄清。

首先，我以要点形式列出在我看来SAFe与SCRUM工作方式最主要的区别。

• Scrum中的Increment与SAFe中的Program Increment
• ART - 敏捷发布火车
• 相互协作的团队数量
• PIPE
• SOS
• PO - 不是业务所有者
• RTE
• 用于学习的第五个冲刺
• 系统演示

Scrum中的Increment与SAFe中的Program Increment。 实际上这是不同的术语，但很容易混淆，因为我们这里没人使用Program Increment这个术语，大家都只说Increment——而那是SCRUM中使用的另一个术语。不过在我看来，从含义上讲它们相当相似。SCRUM中的Increment本质上是当前产品加上冲刺计划中已完成状态（通过团队DOD）的故事。Program Increment是火车（敏捷发布火车）向生产交付增量价值的时间区间。在我们的实践中，这是4个为期两周的开发冲刺加1个学习冲刺。

敏捷发布火车 - 是共同致力于同一价值流的团队之团队。我们简单地称之为火车，但按照框架正确来说应称为“Solution”。在我们的情况下，这一规则并未完全遵守，从技术角度看团队经常致力于不同的产品，因为大多数业务特性是综合实现的，涉及多个产品。这是从技术方面而言。但我相信，有人会把所有IT系统视为公司的一个产品，也许这样甚至更正确。

相互协作的团队数量 在SAFe中我们这里要多得多，建议一个火车中总共最多125人。我们有3个火车，并非每个都遵守这一规则，有些火车人数超过125人。据我所知，SCRUM没有描述如何与其他团队协作，这与SAFe不同，SAFe对此有非常明确的建议。在我看来，最鲜明的相关工件是Program Board。

它显示火车中各团队之间的相互依赖关系，我们每周的Scrum Of Scrums（SOS）活动就是围绕讨论它进行的。

大约每2.5个月（每5个冲刺）会发生一次事件 PIPE - 项目增量计划活动. 这是所有分布式团队聚集在一个大厅里为期2天，规划接下来2.5个月工作的时候。在此活动过程中会产生诸如Program board之类的工件，例如，它显示每个火车中各团队之间的所有依赖关系，上面我已经展示了它的样子。每个团队的Scrum Master在此活动中的任务是引导发现尽可能多的依赖关系，然后尽可能消除它们（例如通过口头传递能力从一个团队到另一个团队，或将依赖从一个团队转移到另一个团队，使团队能够自主实现其特性而不依赖任何人）。在实践中我们就是这样做的。首先将特性分解为User Story，User Story分配到4个冲刺中。特性放置在Program Board上，并标注与其他团队存在的依赖关系。在活动期间会对此进行讨论和调整。

SOS - Scrum Of Scrum。 此活动每周为每个火车单独举行。火车中所有团队的Scrum Master在线聚集，展示火车的Program Board，并讨论特定火车团队的所有依赖关系和特性的状态。本质上，此活动是为了集中同步火车内各团队。有点像站会，但每周一次，且不是为团队，而是为Scrum Master。

PO（产品负责人） - 不是业务所有者。有Product Manager——他与相应业务方向的Business Owner合作，本质上将特性分发给产品负责人。产品负责人则直接在团队中工作——将特性拆分为User Stories（在我们的情况下与团队共同完成），并不总是拆分，但我们一直在这个方向上不断进步。

RTE（发布火车工程师 - 列车司机。Scrum Master of Scrum Masters。主持其列车的 SOS 活动。在特性层面与 Product Manager 互动。主持 PIPE。

第五个冲刺用于学习 - 是的，与 Scrum 不同，这里在增量末尾为团队分配了整整一个冲刺用于学习。在实践中，我们通常首先将其用于参加内部培训，包括 SAFe 相关的培训，但不仅限于此。我们尽量将私人课程和聚会安排在这个时间。此外，我们还有一些开发人员会在第 5 个冲刺期间扩展自己的技术栈，以便能够弥补团队中某人的能力（在需要时提供后备支持）。

System Demo。 在 PIPE 之后，每个团队都有一份针对增量的目标清单，并且每个目标都由列车的 Business Owner 按 10 分制进行评估。这被称为 Business Value。这些目标分为主要目标和扩展目标。主要目标是团队认为在实现过程中没有任何风险的目标。扩展目标是存在实现风险的目标。所有目标都是强制性的，工作量规划涵盖所有目标。在 System Demo 上，Business Owner 验收增量的工作成果。假设一个团队有 3 个主要目标，评分分别为 10、6、8，以及 2 个扩展目标，评分分别为 10、3。假设 Business Owner 分别给出了以下评分：8、6、4、2、0。现在可以计算目标达成百分比：100% 取主要目标的初始分数总和，在我们的例子中是 10+6+8=24。已达成的分数计算时考虑扩展目标（即团队在 24 分中达成了 20 分），因此团队的目标达成百分比为 (20*100)/24 = 83.3%。正常结果被认为是达成 80% 到 100%。

在其他所有方面，我们都按照 SCRUM 运作。嗯，或者说几乎在所有方面 :) 关于我们的经验：我可以说，从我的角度来看，演进是显而易见的。经过一年的运作，团队大幅成长，变得自组织，不过有些团队确实解散了，但即便在此之中也能看到某种演进。还有成长的空间。

来自 facebook 同事的评论

«热尼亚，你好！你写的东西很棒，好样的！关于列车我稍微纠正一下——它们不是围绕产品组建的，而是围绕价值流组建的。而在我们的零售业务中，从 SAFe 的角度来看，我们不是列车，而是 Solution。只是为了沟通方便和简化理解，我们继续称之为列车）»

– Konstantin Voronin （Ingosstrakh 项目办公室代表）

«嗯，也许有人会注意到，从 SAFe 的角度来看，目标评估是在 I&A 上进行的（SD 作为其中一部分参与，但与评估没有直接关联），而 SD 本身应该每个冲刺都进行（在团队演示之后）。但我们目前还远未达到这一点，所以我们有意识地按照你文章中写的那样来称呼一切）»

– Konstantin Voronin （Ingosstrakh 项目办公室代表）

«热尼亚，请继续，非常有用！»

– Alexey Ionov （SAFe 认证培训师）