agile - 谁应该修复 Scrum/Agile 环境中的错误？

Question

在您看来，谁应该修复错误？程序员，对吧？好吧，但真的，谁……让我解释一下。

我是多个 Scrum 项目的 Scrum Master。Scrum 说“在可能的情况下保护你的资源”，我完全同意这种观点。

通常，我们整合每个 sprint 的某个百分比来修复前一个 sprint 的错误——一切都很好。

在每个 Sprint 之后，我们向客户演示和回顾，并将我们的开发代码推广到 UAT 环境（我们的客户通常不希望他的项目的一小部分上线，但这取决于他们 - 我们保持我们的通过确保我们部署工作和可测试的代码来讨价还价）。

一旦所有 sprint 完成，我们就有一个 UAT 阶段，客户在该阶段对已完成的软件进行彻底测试，以发现任何最后一分钟的错误。现在理想情况下，这些已经被捕获，但实际上有一些只是在 UAT 期间发现的。

在这个 UAT 阶段，并不是所有的开发人员都需要 100% 的时间参与项目，因此我们希望将他们重新分配给其他项目。然而，Scrum 说“在可能的情况下保护你的资源”。

我的问题是，我将开发人员分配到一个项目的 UAT 阶段，同时在其他地方与他们一起启动一个单独的 Scrum 项目。不理想 - 然而，这是目前的商业现实。

我可以：

1) 接受它并让开发人员修复他们自己的代码 - 并将开发人员的一些时间（例如，20%）分配给前一个项目的 UAT。

2) 确保移交到位，并有 1 或 2 名开发人员致力于 100% 的时间修复代码错误。

我喜欢 1)，但它让资源获取真的很痛苦。

2）让我害怕，我觉得开发人员不会对自己代码的质量负责。我觉得在确保开发人员对自己的代码拥有所有权方面有很多话要说——要求他们修复自己的错误是确保质量的好方法。没有人喜欢修复错误，所以我发现开发人员通常会尝试提前做好工作，因为他们知道无论如何他们都必须修复任何提出的问题。然而，2) 更容易规划和资源化。但是 2) 将花费更长的时间，因为修复其他人代码中的错误在时间和资源方面是昂贵的。如果它是一个复杂的修复，它可能无论如何都需要原始开发人员的帮助，并且由不熟悉该部分代码库的人修复肯定需要更长的时间。

人们怎么想？

score 13 · Accepted Answer

人们应该修复自己的代码。利用这样一个事实，即当他们可以写新东西时，没有人喜欢回去修复旧东西。如果可以确定负责该错误的开发人员，请确保他们负责修复该问题。这将鼓励开发人员在第一次编写干净的代码时更加勤奋，因为没有人希望被视为必须不断修复他们已经破坏的东西的人。在开发过程中也是如此，当有人破坏当前构建时也是如此。

更新：话虽如此，我不一定会教条主义。客户的需求是第一位的，如果无法重新分配创建错误的人来进行修复，您可能必须将修复分配给其他人。

score 9 · Accepted Answer

ScrumMaster 不分配开发人员资源。ScrumMaster 是由团队中的某个人担任的角色。

除此之外，产品负责人是“团队中的项目经理”，应该努力确保将产品稳定投入生产所需的资源。

必须改进工程实践，以便团队接近零错误。在 Sprint 结束之后存在的“Bug”必须进入产品待办列表，由产品负责人确定优先级。

score 5 · Accepted Answer

这是一个非常有趣的话题，项目管理至关重要，资源的适当分配至关重要。

我要提出的一点是，拥有专门的错误修复程序可能会提高代码的质量。如果我正在开发以我的名字命名的代码，并且我知道其他人负责，我会尽我所能确保它是好的代码。

也许需要一种组合方法。您可以在任何项目上安排几个开发人员 - 每个项目上的一对不同的开发人员 - 让他们负责在错误修复阶段预先概述该责任。这样他们就可以确保他们在项目进行以及最后的移交时跟上进度。您的资源分配更容易，客户得到一流的支持。

只是看待它的方式略有不同。

干杯内森

score 4 · Accepted Answer

在当前的项目发布之前，您的团队不应该开始新的项目工作。我认为大多数 Scrum 从业者会争辩说，在 Scrum 中没有 UAT 的位置（就像在瀑布中所做的那样）。您正在寻找的东西称为稳定冲刺，是您在上线之前的最后一个冲刺。整个团队都在努力。在此期间完成的工作包括最后一分钟的错误、GUI 美化调整、推出文档、帮助指南、操作培训和长时间的午餐。这也可能是团队自己学习新事物的好时机，而无需交付积压项目的“压力”或在开始新事物之前放松一下。基于您客户的 UAT 时间框架预期；如果它往往在较长的一侧；

无论你做什么，都不要在 Sprint 界限之外做任何工作。这是一个滑坡到瀑布式调度遗忘。

score 2 · Accepted Answer

我投票给#2。作为一名开发人员，我讨厌上下文切换，而这正是你在#1 中强加的。至于代码所有权问题，让开发人员拥有自己的代码是一种反模式。争取共享所有权：引入配对、轮换等。

第二个@kevindtimm 的评论，UAT 只是另一个冲刺。也许开发人员更少。

另一方面，敏捷软件宣言的核心是逐步交付业务价值，因此理想情况下，您应该在每个 sprint 结束时推动 PROD。如果是这样，那么 UAT 不应该是每个 sprint 的一部分。Demo不就是为了这个吗？

score 2 · Accepted Answer

我认为错误应该由原始开发人员修复。让开发人员修复其他人编写的代码中的错误可能会花费更多时间，而且可能会使他们失去动力，因为修复错误并不是那么令人兴奋。

score 2 · Accepted Answer

我真的不喜欢选项 2），因为：

它给人的感觉是工作已经完成而尚未完成（它没有完成，有错误），
我认为人们应该对他们编写的代码负责，而不是其他人，
我不认为“错误修复者”是一项工作，这样做时你不尊重人。

所以选项1）有我的偏好（但请停止谈论资源和资源）。

最后，引用一个小插曲：

如果您有单独的测试和修复周期，那么您测试太晚了。--M。波彭迪克

是的，我知道，说起来容易做起来难……但无论如何，她是对的。

score 1 · Accepted Answer

为什么不捕获一个称为“bug 债务”的积压项目，并让团队在每次迭代时对其进行估算。该项目将用于保留一些开发人员的时间来修复它（如 #1 中所示）。

我也有点担心 UAT 中出现的错误。是否有可能让团队中的一些测试人员更早地抓住他们？这种事情在从一个组到另一个组的项目中很常见。我所看到的唯一可行的方法是将其他团队整合到团队中并重新考虑测试策略。然后，UAT 做你想做的事……捕捉可用性问题和需求。你是对的，它们不会完全消失，但它们会被最小化。

score 1 · Accepted Answer

我是 Scrum 驱动团队的首席开发人员。我们倾向于在我的组织中工作的方式是这样的：

在 sprint 开始之前，每个开发人员将被分配一定比例的我们认为他们在 sprint 期间的生产力。例如，一个更熟练、更有经验的开发人员可能能够在 sprint 期间将其总时间的 70-80% 用于生产。这为意外会议和错误修复提供了时间。稍后我将讨论错误修复。我们将签署所有任务的估算，然后计划开发人员的工作。

进入冲刺阶段，开发人员将执行他计划的工作并完成他自己的测试。如果可能，随着每个工作块的完成，Scrum 负责人或产品负责人（项目经理）将进行另一个测试阶段，以确保没有任何明显需要查看的内容。在这个测试阶段出现的任何事情都会直接返回给编写它以在冲刺中完成的开发人员。我们看到的方式是，团队有效地致力于完成在 sprint 开始时交给我们的任务，因此我们需要以一种或另一种方式完成它们。

如果一个紧急的错误出现在团队中并且必须立即完成，那么我和 Scrum 负责人将根据我们的情况来决定是否有可能在不影响计划工作的情况下完成它正在做。IE 如果我们比计划提前半天并且对 bug 的估计是半天，我们将在不更改计划工作的情况下进行。如果这不可能，我们会回到产品负责人那里，由他们决定必须从 sprint 中撤出什么。

如果在 sprint 的中途将一个非紧急错误分配给团队，那么产品负责人会给予优先级，它将保留在我们的锅中。当产品负责人提出我们的下一组目标时，他将优先考虑错误和项目协同工作，这些将成为我们下一个 sprint 的计划项目。

需要注意的是，错误来自哪个项目并不重要。一切都有一个优先级，这就是需要管理的。毕竟你只有一定的开发资源。当涉及到哪个开发人员执行此操作时，这取决于几件事。你并不总是确切地知道是谁的代码引入了这个错误。特别是如果它来自一个非常古老的项目。如果同一个开发人员可以修复它，那么显然会有时间优势，但可能无法找到确切的开发人员。我们尝试和工作的方式是任何开发人员都应该能够处理任何给定的任务。在现实世界中，这并不总是可能的，但这始终是我们的最终目标。

我意识到我一直在拐弯抹角，但是在回答您关于谁应该进行错误修复的问题时，简而言之，这就是我要说的：

如果在完成工作的同一 sprint 中发现了错误，则将其发送回原始开发人员。
如果它很紧急，那么它必须去找最好的人来完成任务，因为它需要尽快完成。那可能不是最初编写代码的人，可能是更有经验的人。
如果你已经对 bug 进行了优先排序和计划，那么你也应该有时间弄清楚谁是完成这项工作的最佳人选。这将基于需要做的其他工作、开发人员的可用性和您的一般判断。

关于移交，这些应该是相当少的。归根结底，您的开发人员应该以一种对任何有任务重新访问它的开发人员来说清晰、干净和明显的方式编写代码。确保团队中的开发人员基本上都在做这件事是我工作的一部分。

我希望这个对你有用：）

score 1 · Accepted Answer

如果某些错误在我看来比某些卡片更重要，则其中一部分由产品负责人来确定优先级。如果 PO 是“立即修复这些错误”，那么应该将错误修复移至列表顶部。如果有许多高优先级的错误，那么可能值得进行一次稳定冲刺，其中修复了错误并且没有完成新功能。我很想问 PO 他们希望在错误上花费多少时间，尽管我不确定这有多实用。

拥有维护开发人员的想法很好，但您是否考虑过将代码更改从维护工作和开发新功能的工作中合并可能会带来一些痛苦？是的，这只是踩脚尖，但我经历了一些痛苦的合并，由于测试和开发环境之间的变化如此之多，我花了一天时间与 2 个开发人员试图推广代码。

我可以建议另一个开发人员修复这个错误，以便其他人了解某些东西是如何编码的吗？让多人共同开发某个功能有助于促进集体所有权，而不是代码的个人所有权。另一部分是有时其他人可能更容易处理错误，因为他们之前已经修复了这种错误，尽管这也可能导致应该定期检查的依赖关系。

score 0 · Accepted Answer

我通常遵循选项 1。通常是因为资源流向了其他项目。如果您通过讨论错误是如何产生的来进行根本原因分析，那么公众尴尬会产生一个小的副作用。如果您对项目灌输了任何所有权感，那么如果他们的代码显示的错误百分比高于其他代码或合理的情况，您的开发人员应该会感到尴尬。

我通常会发现，在这些情况下，如果大多数开发人员忙于修复旧错误，他们实际上会感到沮丧。当其他人必须清理他们的错误时，他们不喜欢它。

灌输主人翁意识和自豪感至关重要。如果你还没有这样做，你总是指望惩罚的威胁让他们做正确的事情。

score 0 · Accepted Answer

我认为人们也应该修复自己的代码。为什么要浪费时间在交接上？

在每个功能完成时进行 UAT 可能是值得的；因此，“测试人员”与“开发人员”一起测试功能。测试人员应该能够通过 UAT 标准。

如果 UAT 中与利益相关者之间存在更多问题，那么它们是变更请求，或者验收标准可能一开始就模棱两可！

score 0 · Accepted Answer

始终尝试让原始开发人员修复他们自己的错误，恕我直言。这部分很容易。如果您有一些行为不专业并推卸责任的开发人员生产高质量的软件，请给他们一个引导。如果问题是文化问题，请阅读 Linda Rising 的“Fearless Change”，并开始担任变革推动者的 SM 角色。我就在你身边，所以这不仅仅是我打你的头；我在我的工作中做同样的事情:)。

但是，您遇到了更大的问题。

你是分配资源的 Scrum Master？哎呀。Scrum 指南要求SM

...[服务]开发团队以多种方式，包括：

指导开发团队进行自组织...

我知道我们都没有理想的组织来实践 Scrum。然而，这应该每天都在折磨你，直到它得到改善。Scrum 专家简单地说：

开发团队由组织组织和授权来组织和管理他们自己的工作。

**第二，不要再说资源了。停下来吧。资源是煤炭、木材和天然气。人不是资源。**

第三，这个 UAT 是 Scrum 团队的一大障碍。如果我对您的理解正确，客户有一个巨大的红色按钮，他们可以按下并通过说“您必须在完成之前修复此问题”来完全炸毁“完成”工作。任何受此影响的 Scrum 团队都不再有速度、预测等。这些东西都衡量“完成”和潜在的“完成”工作；他们依赖于可能交付的“完成”软件。以下是 Scrum 指南如何描述产品增量：

增量是一个 Sprint 期间完成的所有 Product Backlog 项目的总和，以及所有先前 Sprint 的增量值。在 Sprint 结束时，新增量必须是“完成”，这意味着它必须处于可用状态并符合 Scrum 团队对“完成”的定义。无论产品负责人是否决定实际发布它，它都必须处于可用状态。

您可以通过以下几种方式改善这种 UAT 情况：

将客户的 UAT 转换为一个简单的反馈循环，即来自 UAT 的功能请求，而不是不完整软件的通知。
让他们的 UAT 测试人员在 Sprint 期间与开发人员一起工作，并确保工作“完成”。
不要将工作带入 Sprint，除非有 UAT 人员来验证工作是否适合目的。

我意识到这些似乎都不“商业”合理，但你是 SM。如果整个组织中没有其他人在说这些事情，那么您总是必须愿意这样做。

我意识到这听起来像是在踢裤子，但你需要从某人那里得到它。这有点像10 年前（哇）现在的旧鞋/玻璃瓶场景。

如果您想进一步探索，请随时与我联系。我是一名 Scrum Master，很乐意帮助您度过这个艰难的场景。

agile - 谁应该修复 Scrum/Agile 环境中的错误？

13 回答 13

Related

Reference