在您看来，谁应该修复错误？一个程序员，对吗？好的，但是真的，谁...让我解释一下。
我是一个跨越Scrum项目的Scrum Master。 Scrum说'在可能的情况下围绕你的资源'，这种情绪我全心全意地同意。
一般来说，我们将每个sprint的某个％年龄整合到前一个sprint中的错误修复 - 一切都很好。
在每次Sprint之后，我们向客户演示和回顾，并将我们的开发代码推广到UAT环境（我们的客户通常不希望他的项目的一小部分上线，但这取决于他们 - 我们'通过确保我们部署可运行和可测试的代码来保持我们的讨价还价。
一旦所有冲刺完成，我们就会有一个UAT阶段，客户端会对已完成的软件进行全面测试，以找出最后一分钟的错误。现在理想情况下这些已经被捕获，但实际上有一些只在UAT期间被发现。
在这个UAT阶段，并非100％的时间都不需要项目中的所有开发人员，因此我们希望将它们重新分配给其他项目。然而，Scrum说'尽可能围绕你的资源'。
我的问题是，我正在将开发人员分配到一个项目的UAT阶段，同时在其他地方启动一个单独的Scrum项目。不理想 - 然而，目前这是一个商业现实。
我可以：
1）使用它并让开发人员修复自己的代码 - 并将开发人员的一些时间（比方说，20％）分配给上一个项目的UAT。
2）确保切换到位，并且有1或2名开发人员100％致力于修复错误代码。
我喜欢1），但这会让资源成为屁股的真正痛苦。
2）让我感到害怕，我觉得开发人员不会对自己代码的质量负责。我觉得要确保开发人员拥有自己的代码并要求他们修复自己的错误是确保质量的好方法。没有人喜欢修复bug，所以我发现开发人员通常会先尝试做得更好，因为他们知道他们必须解决任何问题。但是，2）更容易规划和资源。但是2）将需要更长的时间，因为修复某人的错误代码在时间和资源方面是昂贵的。如果它是一个复杂的修复程序，它可能需要原始开发人员的帮助，而且对于那些不熟悉代码库部分的人来说肯定需要更长的时间来修复。人们的想法是什么？
答案 0 :(得分：14)
人们应该修复自己的代码。充分利用这样一个事实：当他们写新东西时，没有人喜欢回去修理旧东西。如果可以识别负责该bug的开发人员，请确保他们负责解决问题。这将鼓励开发人员在第一次编写清洁代码时更加勤奋，因为没有人希望被视为必须继续修复他们已经破坏的东西的人。在开发过程中也是如此，当有人打破当前构建时。
更新：话虽如此，我不一定会说教它。客户的需求是第一位的，如果创建错误的人无法重新分配以进行修复，则可能必须将修复程序分配给其他人。
答案 1 :(得分：9)
ScrumMaster不分配开发人员资源。 ScrumMaster是团队成员完成的角色。
除此之外，产品负责人是“团队项目经理”，应该努力确保将产品稳定投入生产所需的资源。
必须改进工程实践，以便团队接近零错误。在Sprint结束时存在的“错误”必须在产品Backlog上进行，以便由产品负责人确定优先级。
答案 2 :(得分：5)
这是一个非常有趣的话题，项目管理至关重要，适当的资源分配至关重要。
我要提出的一点是，拥有专用的错误修复程序可能会提高代码的质量。如果我正在开发具有我的名字的代码，我知道其他人负责我会尽我所能来确保它是好的代码。
也许需要一种组合方法。你可以在任何项目上采用几个开发人员 - 每个项目都有一个不同的对 - 并让他们负责预先确定责任的错误修复阶段。这样他们就可以确保他们在项目进行过程中达到最快速度，并在最后进行交接。您的资源分配更容易，客户得到顶级支持。
看待它的方式略有不同。
干杯 森
答案 3 :(得分：4)
您的团队不应该开始新的项目工作，直到当前的工作。我认为大多数scrum从业者会认为UAT的scrum中没有位置（就像在瀑布中所做的那样）。您正在寻找的是一个稳定冲刺，并且是您上线前的最后一个冲刺。整个团队致力于此。在此期间完成的东西包括最后一分钟的错误，GUI美化调整，推出文档，帮助指南，操作培训和长时间午餐。对于团队来说，这也是一个很好的时机，可以在没有“压力”的情况下自行学习新东西，或者在开始新事物之前放松一下。根据客户的UAT时间表预期;如果它往往是在较长的一面;您可能还会将非面向客户的任务推迟到此sprint中，例如日志监控，服务器设置脚本，维护屏幕或其他misc工具构建。
无论你做什么，都不要在Sprint边界之外做任何工作。这是一个滑入斜坡的瀑布式调度遗忘。
答案 4 :(得分：2)
我认为错误应该由原始开发人员修复。让开发人员修复由其他人编写的代码中的错误可能会花费更多的时间，而且可能会使他们失去动力，因为修复错误并非如此。
答案 5 :(得分：2)
我真的不喜欢选项2）因为：
所以选项1）有我的偏好（但请停止谈论资源和资源）。
最后，引用一句话：
如果您有单独的测试和修复周期，那么测试太晚了。 --M。 Poppendieck的
是的，我知道，说起来容易做起来......但是，她是对的。
答案 6 :(得分：2)
我投票给＃2。作为开发人员，我讨厌上下文切换，这就是你基本上强加的＃1。至于代码所有权问题，让开发人员拥有自己的代码就是反模式。争取共享所有权：引入配对，轮换等。
对于第二个@kevindtimm的评论，UAT只是另一个冲刺。也许w /更少的开发人员。
另一方面，敏捷软件宣言的核心是逐步提供业务价值，因此理想情况下，您应该在每个冲刺结束时推送到PROD。如果是这样，那么UAT不应该是每个sprint的 part 。这不是演示的目的吗？
答案 7 :(得分：1)
我是Scrum驱动团队的首席开发人员。我们倾向于在我的组织中使用它的方式是：
在sprint开始之前，每个开发人员将分配一小部分我们认为他们在sprint期间的生产效率。例如，一个技能更高，经验更丰富的开发人员可能能够在sprint期间将其总时间的70-80％用于生产。这为意外会议，错误修复提供了时间。我马上就会修复bug。我们将获得已签署的所有任务的估算值，然后计划开发人员的工作。
进入sprint，开发人员将执行他计划的工作并完成自己的测试。如果可能的话，每个工作块完成后，另一个测试阶段将由Scrum领导者或产品所有者（项目经理）进行，以确保没有任何明显需要查看的内容。在这个测试阶段出现的任何东西都会直接回到编写它以在sprint中完成的开发人员。我们看待它的方式是团队已经有效地致力于完成在sprint开始时给我们的任务，所以我们需要以这样或那样的方式完成它们。
如果一个紧急错误进入团队并且必须在这一刻完成，那么我和scrum领导者将会考虑是否可以在不影响计划工作的情况下完成它，具体取决于如何我们正在做的事情。 I.E.如果我们提前半天，对错误的估计是半天，我们将在不改变计划工作的情况下进行。如果那是不可能的，我们会回到产品负责人那里决定必须退出冲刺的产品。
如果通过sprint将非紧急错误分配给团队，那么产品所有者会优先考虑它，它将保留在我们的底池中。当产品所有者然后提出我们的下一组目标时，他将优先考虑错误和项目一起工作，这些将成为我们为下一个sprint计划的项目。
需要注意的是，bug来自哪个项目并不重要。一切都有优先权，这是需要管理的。毕竟你只有一定的开发资源。当谈到哪个开发人员做它取决于几件事情。你并不总是确切知道哪些代码引入了这个bug。特别是如果它来自一个非常古老的项目。如果同一个开发人员可以修复它，那么显然有时间好处，但确切的开发人员可能无法使用。我们尝试和工作的方式是任何开发人员都应该能够处理任何给定的任务。在现实世界中，这并非总是可行，但这始终是我们的最终目标。
我意识到我在这里一直在喋喋不休，但在回答你关于谁应该修复错误的问题时，我会说：
关于切换，这些应该是相当小的。在一天结束时，您的开发人员应该以一种方式编写代码，这使得任何有重新访问任务的开发人员都能清楚，清晰且明显。确保团队中的开发人员基本上这样做是我工作的一部分。
我希望这有助于：）
答案 8 :(得分：1)
如果有些错误比某些卡片更重要，那么部分原因在于产品负责人要优先考虑。如果PO是“现在修复这些错误”，则应该将错误修复移到列表顶部。如果存在许多高优先级错误，则可能值得进行稳定冲刺，其中错误被修复并且没有新功能完成。我很想问PO他们想要花多少时间在bug上，但我不确定它有多实用。
拥有维护开发人员的想法很不错，但您是否考虑过将维护操作和开发新功能的代码更改合并到哪里可能会有些困难？是的，这仅仅是踩脚趾，但我有一些痛苦的合并，其中一天花了2个开发人员试图推动代码，因为测试和开发环境之间的这么多变化。
我是否可以建议其他开发人员修复错误，以便其他人知道某些内容是如何编码的？让多个人参与某些功能可以帮助促进集体所有权，而不是个人对代码的所有权。另一部分是有时候其他人可能会更容易犯错误，因为他们之前已经修复了这种错误，但这也会导致应该定期检查的依赖。
答案 9 :(得分：1)
为什么不捕获名为“bug debt”的积压项目，并让团队在每次迭代时对其进行估算。该项目将用于保留一些开发人员的时间来修复它（如在＃1中）。
我也有点担心UAT中出现的错误。是否有可能让团队中的一些测试人员更早地抓住他们？这种事情在项目中非常普遍，在这些项目中，它从一个组到另一个组被抛到了围栏上。我看到的唯一方法就是将其他团队整合到团队中并重新考虑测试策略。然后，UAT做你想做的事情......捕捉可用性问题和要求。你是对的，他们不会完全消失，但他们会被最小化。
答案 10 :(得分：0)
我认为人们也应该修复自己的代码。为什么要一直浪费手机？
当每个功能完成时，可能值得做UAT;因此，“测试人员”与“开发人员”测试功能一起工作。测试人员应该能够遵守UAT标准。
如果UAT中存在更多与利益相关者有关的问题，那么它们就是变更请求，或者首先接受标准可能是模棱两可的！
答案 11 :(得分：0)
我一般都遵循选项1.通常因为资源转到其他项目。如果您通过讨论如何创建错误来进行根本原因分析，那么公众尴尬会产生一个小的副作用。如果你已经在项目中灌输了任何所有权感，那么如果他们的代码显示比其他代码更高的错误百分比或者合理的话，你的开发人员应该会有点尴尬。
我通常会发现，在这些情况下，如果他们太忙而无法解决旧的错误，大多数开发人员实际上感到很沮丧。当其他人不得不清理他们的错误时，他们不喜欢它。
灌输所有权和自豪感至关重要。如果你还没有这样做，你总是依靠惩罚的威胁来让他们做正确的事情。
答案 12 :(得分：0)
总是试图让原始开发者修复自己的错误，恕我直言。这部分很容易。如果你有一些开发人员表现得非专业并且推卸他们生产高质量软件的责任，那就给他们启动吧。如果问题是文化问题，请阅读＆＃34;无所畏惧的变化＆＃34;由琳达瑞星（Linda Rising）担任变革推动者，担任SM角色。我和你在一起，所以这不是我打你的头脑;我在工作中做同样的事情:)。
但是，您遇到了更大的问题。
您是Scrum Master分配资源吗？让人惊讶。 Scrum guide将SM调用
...... [服务]开发团队有几种方式，包括：
在自组织中指导开发团队......
我知道我们都没有理想的组织来练习Scrum;然而，这应该每天都在啃你，直到它得到改善。 Scrum gude简单地说：
开发团队由组织组织和授权 组织和管理自己的工作。
**其次，停止说资源。停止它。资源是煤炭，木材和天然气。人不是资源。 **
第三，这个UAT是Scrum团队的一大障碍。如果我正确地理解你，那么客户就会有一个巨大的红色按钮，他们可以按下并完全炸掉并且完成＃34;完成＆＃34;工作说，＆＃34;你必须在它完成之前解决这个问题。＆＃34;任何受此影响的Scrum团队都不再具有速度，预测等等。这些都是衡量和完成的事情。并且可能＆＃34;完成＆＃34;工作;他们依靠＆＃34;完成＆＃34;可能可以发货的软件。下面是Scrum指南如何描述产品增量：
增量是已完成的所有产品待办事项项目的总和 在Sprint期间以及之前所有增量的值 冲刺。在Sprint结束时，新的增量必须是“完成”， 这意味着它必须处于可用状态并符合Scrum团队的要求 “完成”的定义。无论如何，它必须处于可用状态 产品负责人是否决定实际发布它。
您可以通过多种方式改善此UAT情况：
我意识到这些看起来都不会出现在商业上＃34;可信，但你是SM。如果整个组织中没有其他人说这些话，你总是愿意这样做。
我意识到这听起来像裤子里的一脚，但是你需要从某人那里度过它。这有点像10年前（哇）现在的old shoe / glass bottle情景。
如果您想进一步探索，请随时与我联系。我是Scrum Master的同事，很乐意帮助你完成这个艰难的工作。