如何在敏捷/Scrum中处理生产支持？

Question

摘要：

在一个想要使用敏捷/Scrum软件开发过程，但也有一个巨大的生产支持/操作负担，期望快速响应时间的组织中，有什么最好的方法来确保一个足够的生产支持/操作水平，而不把所有团队的冲刺陷入混乱？

详细信息：

我目前在一个软件组织中工作，该组织由几个团队组成，这些团队(已经尝试了不同程度的成功)使用了基本上是敏捷的Scrum过程。我们生产一套网站，我们的客户用来经营他们的业务，我们收费他们的新发展，他们的要求和持续的维护和支持。

通常，在冲刺过程中会出现一些业务希望很快解决的问题。示例包括：

• 该网站没有在生产中工作，我们的客户正在电话中试图找到解决方案。
• 一些错误被发现导致了一些错误的数据库条目，需要很快进行手动更正。
• 有一些审计正在进行，客户需要我们生成不寻常的报表数据集。
• 一个新的客户端错过了一个业务关键特性请求，需要它尽快工作和推动。
• 自动化或手动测试在介绍它的sprint之后发现一个回归缺陷，我们需要在即将发布之前修复它。

我知道，对这类事情的正确反应是在下面的sprint中工作，让团队修改当前的sprint或取消sprint。但是每一个都有一些我们想要避免的问题：

• 在下面的短跑管理中工作在一定程度上购买敏捷，但是我们的付费客户并不关心我们是敏捷的，他们只是想对他们的问题做出快速反应。
• 修改当前的sprint --这可以不时地工作，特别是对于遗漏的特性请求，但是对于标准操作类型的东西--小请求--这将在很多过程中使团队陷入困境。
• 取消冲刺-这也已经做了，但它损害了我们的能力，以始终如一地提供长期.显然，在默认情况下这样做意味着放弃敏捷/Scrum，但是我们应该用什么来代替它呢？

我们想到的一个想法是，也许我们可以有一个新的团队，使用不同的流程-看板？还有什么别的吗？-处理所有这类事情，让敏捷/Scrum团队保持更稳定。

• 这是个好主意还是坏主意？
• 有没有这个名字或任何关于如何做好它的文献？

注意:我们有一个非技术的客户支持团队，他们可以帮助使用、配置和基本的故障排除和解决方法。这与需要技术技能调查或解决的问题有关--代码、数据库等。

Answer 1

您有两种选择:尝试在每个团队的Sprint计划中为其提供一定级别的支持和计划，或者创建一个使用自己的节奏操作的支持团队(可能是一个及时的流程)。

如果您对每个Sprint的支持和操作工作量有一个很好的了解，那么您可以为团队分配时间--每个Sprint来完成这项工作。如果您有历史数据，您可以使用它来计算每个时间单位中有多少支持请求，以及解决这些请求并在每个团队之间分发所需的时间。然后，在Sprint，您需要留出一定的时间用于细化，一定的时间用于支持，其余的可以用于设计和开发工作。你还得考虑一些计划外的事件，比如团队的病假。当团队将工作拉到Sprint上时，他们只会填满分配给设计和开发的时间，并确保Sprint目标可能在该时间框内实现。

另一种选择是派遣一个团队来支持和操作工作。他们将有能力处理和解决所有传入的支持请求。当支持请求量较低时，它们还能够处理其他系统范围的操作任务:基础设施升级、漏洞缓解、构建管道维护、自动化。较低优先级的操作任务可以保持在工作队列中，也可以在某人没有处理支持请求时完成。您可以为此建立一个专门的团队，也可以定期轮换执行此类工作的团队。

如果您在支持请求上花费了大量的时间，那么我会倾向于专注的团队，至少一开始是这样的。

不管采用什么方法，我都建议减少进入团队的这些支持请求的数量。执行根本原因分析并纠正导致这些问题的问题将减少您在支持请求上的时间。与其仅仅修复bug，还要弄清楚为什么在设计和开发过程中没有检测到bug，并改进这个过程。定义工作，以允许客户自助服务他们的审计需求，而不是进入开发团队。弄清楚为什么产品经理不能从涉众那里引出关键的特性请求，并在必须尽快完成之前将其开发出来。

Answer 2

最终起作用的是

修改当前的sprint --这可以不时地工作，特别是对于遗漏的特性请求，但是对于标准操作类型的东西--小请求--这将在很多过程中使团队陷入困境。

敏捷的部分要点是不必坚持一个大的前期计划。如果你这样做，你只是每周做一次瀑布。

然而，正如你所说，关于增加工作的“仪式”本身需要时间。所以，过去对我起作用的是，在每一次冲刺中只需投一张“计划外的支持”票，分配给(比如说)半天，或团队总时间的5-10%。然后，您可以围绕这些未计划的请求的第一个接触点的个人旋转。一旦一些事情需要超过一两个小时的时间来处理，它就应该被提升到一张完整的票，并有它自己的时间分配。

Answer 3

无论你选择哪一个过程，你基本上都有同样的问题。“新功能的开发太慢了”。

Scrum和一般的敏捷都试图通过一次专注于一件事情来最大限度地提高开发人员的生产力并与业务规划保持一致。显然，在繁文缛节中有一些松懈的地方，你可以在这里和那里挤一些奇怪的额外的‘紧急’的东西。但最终，如果你想要完成更多的工作，你就需要雇佣更多的开发人员。

我知道你不会想听，但你提到的大多数事情都可以通过更好地管理客户的期望来解决。当微软的Word不像你所希望的那样支持你的新业务流程时，你不需要看到比尔·盖茨。这并不是因为它在技术上与你的网站有任何不同，而是因为你与软件提供商的关系。

不要说“我们会把你的要求放在积压中”，而是说“我们现在还有很多其他工作要做”，如果你经常被要求要定制报告，那就发布一个价格来支付报告团队的费用。列出您的产品在销售时所支持的特性，停止销售人员说它可以做任何事情，并且您将添加任何客户需要的内容。