多个Scrum团队转移到单个待办事项列表

目前，我们有5个Scrum团队在过去一年中处理自己的产品积压。每个团队都在各自的专用系统上工作，但基础技术是相同的.Net。

关于转移到基于功能的团队进行单个积压工作的讨论很多。原因是我们的主要系统之一有大量工作要做，而它们的能力不足以完成一年中的所有工作。我认为重要的另一个原因是，它可以提供更大的灵活性来快速调整投资组合的变化。

已决定更改两个团队以处理一个积压订单，但开发人员在其他系统上没有经验。我们正在做的一件事是通过将经验系统开发人员移交给团队来进行交叉技能培训。

我的问题是，您是否经历过将两个或多个不同系统转移到单个积压工作。您面临什么挑战？您需要做什么才能使其正常工作？

我们使用一个积压订单管理大约六个项目。我说“关于”是因为它取决于您如何区分项目。

宽松地，我们有五到六个产品所有者，其中一些拥有一个以上的产品。我们有一个相当小的团队，有七个开发人员和一个团队负责人，他在有空的时候也进行编码。我们还有几位传道人与我们的流程人员合作，将想法付诸实践。当然，有些人戴着几顶帽子，使事情变得混乱，但我将忽略它。有趣的是，我们没有正式的Scrum管理员。

我们不必将积压的订单合并在一起，但这听起来像是您身边一项简单的任务。

使事情井井有条可能是一个真正的痛苦，因此，您需要考虑以下几点。

• 治理是关键。凡事都有胆识的人都必须与他人沟通，然后再进行重大更改。和/或那些进行更改的人员必须对这样做的权限感到满意（并准备为不利的更改承担责任）。我们的变革者拥有强大的行政支持，并且在各个领域都清晰划清了界限。但是，如果有疑问，我们会在更改之前先询问。

• 积压整理，优先级划分和启动会涉及更多开销。优先考虑作为一种仪式是最困难的，因为很难使所有所有者定期聚在一起。我们使用多个中介来协商优先级和/或传递不降低优先级的坏消息。

• 我们的许多工作是由外部承诺驱动的。这剥夺了我们决策的某些自主权，但这就是企业的现实。您的开发人员需要注意这一变化。如果感觉到失去控制，羽毛可能会变得轻柔。但是，我们尽量不要过度使用，我们不得不对某些将其推入冲刺阶段的产品所有者说“不”。

• 我们通常使用两种方法来标记产品积压商品所属的产品。我们之所以使用两者，仅仅是因为它使修饰和其他任务变得更加容易。

  1. 我们将在PBI标题前加上产品名称或简写版本。
  2. 我们有一个单独的字段，用于指示总体产品，也必须填写。

• 我们必须有意识地进行交叉培训，并确保每个人都能在各个领域获得帮助。关于我们的开发团队，我们拥有非常庞大的代码库。我们执行的某些代码也非常专业。在这方面，我们的团队负责人很棒，他将把我们的承诺水平降低一个档次，因此我们可以承受交叉培训带来的低效率。在这方面，拥有强大的团队领导至关重要。

• 我们会尽力维持冲刺时间框架。团队成员较新的复杂项目转化为承诺的鲜见。分支过程确实会在这里有所帮助。我们所有的工作都是针对一个分支完成的，然后将其合并回主干版本。除了临时触发器外，我们还有一个每晚运行的构建服务器。中断构建的开发人员会在24小时内了解并解决问题。期。24小时内无法解决意味着您的承诺被撤消，高级开发人员使他们感到悲伤。在维护版本方面，高级开发人员对自己最困难。

• 代码演练和审查变得更加关键。它有助于使每个人都能及时了解各个领域的变化。

• 同样，每天的站起来包括所有开发人员以及我们的UI人员。我们正处于有益的协作交流和太多人效率低下的边缘。但是，我们将站起来的时间不到15分钟，并且很快会从旁讨论中继续前进。通常，我们会在5到10分钟内完成。

• 我无法谈谈对速度或总体承诺和燃尽率等指标的影响。这些方面还不够重要，不足以让我们密切关注。YMMV，因此请考虑一下。这也假定每个团队对故事点的定义都相当相似。如果没有，那么合并后的初始估计值就会混乱。由于您使用的计量单位与以前不同，因此它也会产生一些历史比较问题。简便的解决方法是只为度量标准声明一个“新团队”，并在合并后开始收集数据。

• 我们已经从这种方法中受益匪浅。我们进行了一些冲刺，所有手都集中在一个区域上，我们可以在短时间内实现许多变化。您不应低估能够迅速在特定项目上应用正常数量的开发人员两倍的价值。但是您必须提前进行交叉训练。这也意味着我们永远不会因为测试周期，修饰或其他原因而让开发人员“无所事事”。我们总是有待解决的积压。

• 为研发项目投入时间。否则，它们很容易从裂缝中溜走，而您将失去在这些领域进行投资的机会。

• 真正从事无自我编码的工作，尽管您可能在某个领域拥有专家，但您没有代码领域的所有者。当将不同样式引入一个区域时，防止遭受挫伤的机会很重要。只要新代码符合团队标准并且可以正常工作，就应该很好。仅仅因为这不是专家的工作方式，这并不重要。

• 确保涉及的团队使用相同的编码约定和样式。在这里，没有什么会像不一致那样给您的整合尝试带来破坏。

• 继续进行回顾，并将其作为一个小组。重要的是要让每个人都对有效的，无效的以及需要以不同方式尝试的内容给予反馈。这有助于提高团队内部的友情感，并在开发过程中赋予主人翁感。

正确的Scrum答案是“问团队”。这是自组织的原则，在这种原则下，他们应该能够进行自我重组以快速完成工作。您会看到团队中的许多人比局外人拥有更多的背景知识，他们知道什么是最好的。这也包括产品负责人。

我认为您是来这里问问题的，因为有些事情感觉不对，您有隐忧。因此，我将向您提供一些建议，与团队讨论以做出正确的决定。

产品拥有者

积压的产品所有者只有一个，应该是业务人员或代表业务的人员。它不应该是IT管理。大量的待办事项有很多项目，并且有多个团队，单个PO可能无法应付。因此，您可能希望将积压订单分开。

如果有多个PO，那么您肯定需要多个积压，因为团队应该在冲刺中专门处理一个PO和积压。原因是团队不需要管理产品所有者优先级之间的冲突。

产品开发与维护

维护团队致力于许多小的增强功能，多个不同产品（可能还有多个产品所有者）的错误。这些BAU团队需要IT管理的支持，以帮助安排和管理多个产品所有者之间的冲突。

项目团队应一次专注于一种产品，以最大程度地减少上下文切换，并一次交付一种出色的产品。上下文切换可能会导致交付许多中等程度的产品，并带有一定程度的技术债务。

上下文切换

使用多个产品或不同功能会导致上下文切换，这会降低团队的生产力。在确定下一步工作以及什么团队应从事的工作时，采购订单应将此因素考虑在内。切换的数量并非微不足道，不仅仅是理论上的问题，这是真实的，而且我亲眼目睹了团队因此而降低了80％的生产率。

一个好的PO将尝试使用小组功能和工作类型来帮助团队减少上下文切换，从而提高绩效。

风险

可悲的是，管理层试图将时间，金钱，预算和业务压力的风险施加于团队上。并且团队对此表示同意。作为开发专业人员，您应该简单地陈述决策的事实和影响，并使企业自己承担风险。

例子

• 同意一个荒谬的时间。确切地说，要做好工作并让企业管理时间问题要付出什么努力？

• 估计。业务期望团队在复杂和不确定的世界中准确地进行估计。团队应询问业务人员他们正在采取哪些措施来减轻是否由于无法预料的挑战而超出了估计值，而这种挑战很有可能发生。团队不应该考虑肥胖，而应该考虑业务。

• 技术债务。团队应该估算经过充分测试的高质量代码，并据此进行估算，即，由于压力而停止编写缺陷。如果企业想要降低质量，那么这就是他们承担的风险，而当事情出错时，这就是他们的问题。

专业精神

通过陈述正确的事物达到商定的质量来成为专业人员。根据现有事实估算出您的最佳能力。当这些事实发生变化时，请进行沟通并调整估计值。作为开发团队，开发出优质的产品并且不会承担商业风险。传达和管理期望。

检查和适应

团队应该一直在寻求改进的方法，如果他们觉得这会使事情变得更好，那就应该尝试一下。然后检查是否有改进。最后，他们应该适应并改进他们的新方法，或者如果不起作用，则将其废弃。寻求改进的背后意图应该始终存在。

底线

最终，积压的管理是采购订单的选择。他/她如何管理工作队列取决于他们。唯一的想法是，他们必须保持所有团队的工作流程健康并处于良好状态。因此，取决于PO来决定。

合同

在sprint计划会议中，团队应该期望得到一个清晰，明确和有序的经过整理的产品待办事项列表。通过与PO的简短讨论，团队应该确切了解PO的需求。 什么。然后，团队专注于他们将如何构建。

如果PO做好了充分准备的计划会议，那么谁在乎如何管理积压。如果采购订单不准备参加冲刺计划会议，则应由SM解决，并使其非常明显，因为这是完全不可接受的，并且不是团队问题。

我们刚刚吸收了另一个团队的积压。团队只有一名成员（我知道团队成员不多），但他们的积压工作尚有实际工作。我们对他们的工作不是很熟悉，他们对我们的也不是很熟悉。

即使您的待办事项已合并，也不意味着每个人都必须立即进行所有工作。期望如此是不合理的，因此不必担心每个人都能立即完成两个待办事项中的所有事情。

取而代之的是，让两个团队完全按照他们之前的工作进行工作。唯一的区别是一切都在同一积压中。

然后，每个迭代/冲刺都会使每个团队的一些成员处理另一个积压的故事。通过不让每个人都同时处理不熟悉的项目，您可以分散学习彼此系统的成本。随着时间的流逝，您的团队将逐渐吸收彼此的知识。

如果您事先进行了所有学习，则将遭受重大的性能损失。高级管理人员一定会注意到这一点，您将被迫吸收另一个团队的积压工作，希望新团队可以弥补糟糕的表现... :)开个玩笑，不过，这是我的建议。

我假设您（或管理层）想为两个团队创建合并的待办事项的原因是，您希望能够只为一个系统选择待办事项，并使两个团队都在他们身上工作。

在这种情况下，请期待被迫在他们不熟悉的系统上工作的团队会遇到很多摩擦。期望团队将竭尽全力（即与他们的“家庭”系统有关的小积压项目）继续研究他们以前正在使用的系统。谁来责怪他们？做一些自己不擅长的事情是没有意思的。另一个团队擅长而不擅长的事实会使情况变得更糟-因为这会使您看起来更加愚蠢。

因此，要取得成功，唯一的方法就是将两个团队分解成两个混合的团队。只有这样，您才有机会让所有开发人员快速（当前）“重要”系统上加快速度。

那样做并不是很好。我的上一家公司进入单一产品单一团队模式，因为在大公司中，我们有不同的人从事不同的工作。

在项目之间进行切换也需要付出很多努力，而且如果有新人来开始开发开销，那确实很大。一个必须获得对已开发系统，不同存储库等的访问权限。

我更喜欢专业化，人们知道他们在做什么，拥有所有需要的信息，知道项目的陷阱，人们没有那种必须将它们从一个项目放到另一个项目才能使他们工作，从中吸取一分钱的感觉。他们。

即使他们闲着自己的项目，与从一个项目跳到另一个项目相比，他们在熟悉的内容上也更有生产力。