修复其他人造成的错误是一种好方法吗？

让我们假设一个由四个开发人员组成的团队正在构建应用程序的情况。在测试阶段，错误由用户报告。谁应该修复它们？提交错误代码的人，还是有空的人？

敏捷开发（scrum）中首选的方法是什么？

敏捷开发中的首选方法是尽可能快地修复它们，无论谁可用。这仅仅是因为代码的所有权不属于任何人，而是属于整个开发人员组。如果一个人持续引起错误，则这是另一个问题，需要单独解决。

默认情况下，此人。原因很简单：反馈。错误为个人和专业反馈提供了很好的机会。如果其他人修复了我的错误，我将再次犯同样的错误，因为我不会从中学习。

如果该人员不可用，则可以由其他人修复，但该人员应遵循错误的生命周期。

作为项目经理，我会避免将错误链接到特定的开发人员。如果需要完成，请职能/开发经理执行。关注团队。团队需要修复一个错误。

我不知道Scrum如何处理这种情况，但是在我的团队中，我们有类似交叉测试/代码审查的内容。这样，如果发现错误，开发人员和审阅者都将讨论修复该错误的最佳方法。

我相信，只要解决方案适合，开发人员或审阅者都可以应用它。但是，重要的是要避免开发人员和测试人员之间发生任何形式的冲突。

Rgds

编辑：不确定我是否清楚自己，但重要的是要强调审阅者是团队中的另一位开发人员。

1. 评估错误
2. 如果对原始开发者来说修复起来更快/更有意义，请交给他们
3. 如果团队中的任何人都可以解决，请让任何人来解决。

我完全同意史蒂文所说的代码属于所有团队。还有其他一些原因，您不应该将该错误提供给他们的创建者：

据我所知，在许多情况下，很难确定是谁引起了该错误。即使您正在使用诸如SVN之类的文档管理系统，跟踪错误代码也可能会花费大量时间。因此，在我看来，请将漏洞提供给任何有空的人。

如果要跟踪错误的产生方式，可以在闲暇时间（在所有团队之前）向维修人员询问情况。由于您的团队很小，我认为这将分享有关可能的错误的经验，而不会让任何人感到尴尬。

关心修复漏洞的原因只有三个：成本，速度和专业发展。

而且这三个都有优点和缺点。例如，专业发展，一方面是一个机会，可以更多地了解代码，另一方面，它是一种机会，可以识别您所犯的各种错误并在将来避免某些错误。还是花些钱，大概是犯错的人能够更快地解决它，并且可能更便宜，另一方面，花费时间来识别谁犯了错，并将其分配给适当的人-时间在很多情况下，它超出了修复错误的范围。

敏捷的方法是让开发人员自行分配问题，我仅出于充分的理由才将其覆盖。

在我的团队中，我们始终根据优先级进行决策。如果提交代码的人有空，他/她将修改该代码。如果该人员正在处理某些优先级较高的故事，则任何有空并且可以尽快修复代码的人都将对其进行修复。如果每个人都忙于在当前迭代中处理更高优先级的任务，则根据与其他案例和缺陷相比的优先级，在下一个迭代中安排此修复程序。

想一想：谁对这个错误有更多的了解？开发团队。

因此，让他们决定如何处理该错误。他们拥有代码，因此对代码负责。

您可以通过管理项目，在项目范围内分配一些时间来解决错误并让他们独自完成工作来为他们提供帮助。

避免做出很多决定，即您（作为PM角色）所拥有的信息少于团队。

请参阅有关以下问题：如何避免对软件开发团队进行微观管理？

我说，您需要一个错误跟踪系统，以记录由错误报告的错误，然后根据不同的工作负担将错误分配给不同的人员。还指出导致错误的是谁的代码，然后有一个报告显示一周内有多少编码员和哪些应用导致了x个错误。

然后，您可以向编码人员展示该代码，以显示它们如何导致错误。

预防错误的最佳方法是让所有人参与其中的修复工作。我的意思是将错误修复程序分配给不同的人，以全面了解导致错误的原因和解决方法。

然后，也许每个人一个月或两个月后修复错误，修改或创建您的编码风格指南，以通过编写/记录编程标准来帮助防止将来出现系统范围的错误。

发现错误后，整个开发团队都有责任对其进行修复。

如果人们认为错误应该由其作者修复，就好像在说“我没有解决问题，漏洞不在我的身边”。但是，如果孔不固定，船仍会沉下去，您和其他所有人都在船上。

个人需要意识到自己是团队的一部分，并了解该代码及其职责属于所有人。项目的成功取决于所有团队成员。