如何在冲刺计划中处理“门票”

Question

我在敏捷团队中工作。

我们已发布产品，我们仍在努力开发未来版本。

我们收到的每个sprint都有0到5张票来修复已发布产品中的错误。

我们的团队由软件工程师（处理新开发）和维护软件工程师（处理门票）组成。

我的问题是如何计算sprint计划期间的维护时间。

目前我们有一个名为维护缓冲区的故事，我们会分配几个小时来解决故障单。我们将它用作缓冲区，因此在我们没有收到票证的冲刺中，我们使用缓冲区中的小时数进行开发工作。

我觉得这不是一个敏捷的做事方式，任何建议吗？

Answer 1

Mike Cohn在Should Story Points Be Assigned to the Agile Defect Story?中也提到了你提到的方法，他写道：

  

有时，团队会为此活动编写用户故事，例如：“作为   用户，我想要至少15个错误修复“或”，作为用户，我希望你   花费大约50个小时这个sprint修复bug以便应用程序   变得越来越高质量。“即使是没有的团队   显式写这样的用户故事通常会在其上包含一行   任务板使敏捷缺陷和bug修复可见，并且   跟踪它。

您目前有一个名为维护缓冲区的故事，您可以在其中分配几个小时来解决故障单，这与Mike Cohn的文章中所述类似，他建议为错误修复敏捷缺陷指定点。

也可能有其他选择，例如

• 为每个sprint中的错误修复设置一些时间。它可以是每个团队成员处理错误的日/周的设定时间。
• 将每个错误包含在同一sprint backlog中，将其视为部分实现的功能。 Mark Summer在Managing Bugs in Scrum中讨论了这一点。

紧急情况/修补程序时该怎么办？

您需要评估解决该紧急错误所需的关键性和工作量。由产品负责人决定团队是否放弃所有内容并开始使用此修补程序。原因是客户始终排在第一位，如果交付的产品未提供预期的值，则不会在不完整的产品中添加更多功能。没有任何框架/方法可以阻止您处理特殊情况或指示您忽略关键问题。因此，当前的sprint可以被取消，或者如果该修补程序可以由团队的一个（或一些）成员处理，那么来自当前sprint的功能或错误可以与紧急错误修复交换。

来自Production Support and Scrum的Geoff Watts的话：

  

如果问题是真正的紧急情况，产品负责人应该拥有   有权发挥“应急卡”，只要他知道了   这样做的成本 - 没有完成我们计划的项目，   可能会危及冲刺目标。

产品负责人可以使用以下3个选项中的任何一个：

• 将紧急缺陷添加到待办事项中，因为他/她已决定当前冲刺目标具有更高的优先级
• 将紧急缺陷添加到当前sprint，因为它足够严重甚至可能危及sprint目标
• 取消当前的sprint，执行此修补程序，然后在此之后启动新的sprint

Answer 2

简而言之，我将bug作为产品待办事项（PBI）提出，并将其优先于产品Backlog中的其他PBI。这样，您始终可以确保最重要的事情先完成。

Scrum的不成文合同的一部分是业务同意不打断开发团队。这部分是他们如何提高绩效。

如果您收到的热门/紧急机票不能等待Sprint的持续时间，您需要说服产品负责人，然后产品负责人会与开发团队协商，以便了解热门产品的最佳方式。

但是，这需要是一个例外，而不是规则。如果，如你所暗示的那样，你会遇到很多错误需要解决，我很想用一个使用KanBan而不是Scrum的独立团队来维护/修复缺陷。

Answer 3

我同意你的观点，这不是一个敏捷的做事方式！要问的问题是 - 您的真正目标是计划维护时间或确保您的团队在利用用户故事和缺陷的同时进行最佳利用，同时持续提供质量代码，包括缺陷修复程序？

我会更远离Derek的建议 - 并且一起使用看板和Scrum - Scrumban越来越受欢迎！既然你说过在任何sprint中你可能有0到5个缺陷，那么你的“故障需求”显然是可变的，因此需要你的“维护工程师”能力。当有0或1或2个缺陷时他们会怎么做？我认为他们也为“价值需求”做出了贡献 - 新的用户故事。

这是看板闪耀的地方。虽然您的看板的实际设计需要由您的团队进行分析，但您可以从一个简单的2泳道板开始，它反映了您当前的工作流程。一个简单的例子如下所示 -

在这里，您可以让所有工程师在任一车道上工作。随着工作的进行，取决于谁可以自由地接受它 - 并且可以接受它 - 他们会开展工作并开展工作。您仍然可以在Staging中为sprint批量处理 - 并一次部署批处理。

或者，您可能有完全单独的用户故事和缺陷通道 -

再次，您的所有工程师都在处理两条车道上的物品。但是，您可以灵活地在客户修复并接受（如果适用）后立即部署缺陷修复程序。根据您的价值需求，您将继续按照与现在相同的流程进行操作，并在每个sprint完成后进行部署。

这两种方法的优点是 -

1. 在这两种情况下，你都可以找到更多的人。
2. 您可能会在缺陷方面获得更快的响应时间，更好的SLA性能。
3. 你会得到一个更快乐的团队，每个人都可以开始学习新东西。大多数工程师不想成为“维护”人员： - ）

当然，这只是基于基本分析。如果您不熟悉Kanban或Scrumban，您应该阅读David Anderson（看板）的书籍和Corey Ladas（Scrumban）以及Yuval Yeret，Jim Benson，Masa Maeda等其他几本人的书籍，并为自己做好准备。您也可以通过www.swiftkanban.com与我们联系，我们当然也可以提供帮助。

希望这有帮助！