如何解决错误修复迭代？

在过去的5个月中，我们已经非常成功地实施了Scrum。虽然，我们是从PROD3周远没有以往做任何终端到端到端的集成测试。哎哟！我需要帮助。在此之前（现在），无需解决造成这种情况的原因，我们需要计划当前的迭代，该迭代包括较小的改进和许多仍未知的错误修复。您如何考虑这种情况？您如何计划迭代以修复尚未发现的错误？

不管是否乱码，错误修正基本上是无法预测的。我相信您能做的最好的事情是：

• 立即开始测试，何时完成无需初步估计。
• 当发现每个错误时，请进行初步分析直至可以估计它。
• 估计错误并确定是否必须修复以及对于初始relese是否必须修复。
• 如果必须修复，请将其添加到迭代中。
• 绘制燃尽图。在某个时候它会开始减少，这意味着您不再以比设法解决它们快的速度找到错误。届时，您将可以在发布版本时做出粗略的估算（并逐渐更加精确）。

比您应该确保下次下次开始提早测试并随时修正错误。所有明智的方法，无论敏捷与否，都要求在开发新功能之前先修复已知的错误。另外，您还应该考虑花费了多少时间对每个功能进行错误修复，以便将来改进将功能实现为调试状态的估计。

估计和bugfixing中很好地覆盖乔尔斯波斯基循证调度和硬称职的Bug Fixin'。它与Scrum无关，但我认为它足够普遍，足以适用于大多数情况。

如何解决错误修复迭代？您如何计划迭代以修复尚未发现的错误？

关于“错误修复迭代”。发现的错误应与故事区别对待。与团队合作，估算修复每个错误的工作量（故事点），并与产品所有者/客户一起确定错误是否应该进入下一个迭代。

关于“尚待发现的错误”。团队最好是每次迭代都发现并解决问题。如果不是，请在下次回顾中进行讨论。如果产品质量太低而无法发布，则立即将最佳的“ 错误查找者 ”移至查找错误（不修复）的地方。如果质量足够高，可以提供Beta版以选择用户-那就这样做。如果不能，则至少提供实时用户演示，讨论需要改进的薄弱环节。

我们不计划“错误修复迭代”，但是我们在每个发行版之前计划系统测试迭代。系统测试是对产品所有部分的集成，回归和真实测试。测试人员测试产品（相当大的旧系统），开发人员修复发现的所有错误。如果没有发现错误，我们要么开始调查下一个项目的功能时间表，要么着手进行内部改进。

目前，我们计划在代码冻结后进行六周的系统测试（对于一个五个月的项目，包括系统测试），以确保一切正常。这是在实施迭代过程中完成的所有测试的基础。

您需要定义一组“发布”条件。这些可能包括：

• 平均故障间隔时间
• 每天发现的缺陷数量
• 每天发现缺陷的严重程度
• 未解决的缺陷数量

等等

然后，在每次迭代结束时，您需要一些人进行测试（手动或通过编写自动测试），而其他人则进行检查以查看您是否满足标准。如果您已经发布，那么如果没有发布，请再进行一次迭代。

应该有可能对此进行覆盖，并且原始数字通常不能代表应用程序的真实情况。您可能有一些非常严重的缺陷，但是它们仅在极少数情况下会出现，您可以在短期内忍受。

一种方法是编写用于集成测试的故事，在此过程中，为发现的任何错误编写新的故事，然后在下一次迭代中修复这些错误的故事。

做到这一点的另一种方法是制作一个故事，说“修复集成测试中发现的错误”。从以前的版本中，您应该了解通常会发现多少个问题，以及修复这些问题的难度，因此您可以基于该知识分配故事点。如果可以使它更易于管理，则可以将其拆分为多个组件。总是存在不可避免的不确定性。添加一些额外的故事点来说明这一点。

您可能已经迟到了，最好的方法是在每次迭代中都包含一点集成测试。恭喜您意识到这一点，并为您的下一个发行版改进了一点流程。