我们最近在工作中采用了Scrum，并且在代码被接受后出现了一堆小错误。其中包括拼写错误和其他单行修复。为每件小事创造大小为0.5的故事似乎是浪费时间。编写故事需要花费更多时间并指出它，而不是修复故事。如果每个sprint中只有一个或两个，那么很容易修复它们并且不用担心为它们创建故事。但是，如果由于应用程序很大而有10或20个或更多，这可能会开始累积大量的开发人员时间，这些时间不是通过Scrum计算的。虽然可能很容易说QA工作人员和产品所有者在原始故事被接受之前应该更加彻底，但我是开发人员，所以这基本上不在我手中。
到目前为止，我们提出了一些不完美的想法：
有什么建议吗？
答案 0 :(得分：12)
你的第三个答案是最好的方法。冲刺只是团队承诺在规定的时间内完成指定数量的工作。如果您正在接受sprint中间的其他工作，那么您将通过处理sprint开始时团队未承诺的事情而偏离原始承诺。
以下是我们的工作：
以下是您的其他解决方案的问题：
有一个故事说“在应用程序中修复了90％的错误”，然后你猜测该sprint中会出现多少错误，有多少可以修复，然后根据预期的工作量来指出
再次，见上文。您希望避免在sprint期间可以填充的空桶工作。这违背了团队明确承诺的目的。团队如何承诺他们不知道或没有估计的事情？
另外，这可能很容易失控，成为一个产品所有者，通过填充那个真正伪装成缺陷的优秀功能来“按缺陷设计”。
有一个大小的故事，比方说，8，在sprint结束时总是被接受，你可以修复尽可能多的bug。这显然需要非常信任，每个人实际上都在做8个人的工作
这听起来很奇怪。团队应该在新的sprint计划开始时接受工作，而不是在上一个sprint结束时。此外，这将真正长期扭曲您的速度。 Scrum指的是Product Backlog Items，而不仅仅是Stories，所以没有什么可以说你不能把缺陷包含在PBI中。
记录错误，但在下一个sprint之前不会对它们起作用。它们可以单独指向或作为一组指向。这样做的好处是更加“Scrummy”，但导致基本上1小时的修复延迟三周。
你提出了一个有趣的观点，我们对此也有一些担忧。然而，这个1小时的修复（不管它有多快）可能不会花时间与积压中的其他东西相叠加。最重要的是，您希望将这些决策推送给产品所有者，并让他们自由地优先考虑团队花费的所有工作。
答案 1 :(得分：5)
我坚信，一个过程只有改善情况的能力才是最好的。这个过程应该适合你，而不是相反。
如果遵循敏捷Scrum流程到'T'的弊大于利，那么现在是时候在Scrum流程之外找到更好的解决方案了。
我们已经创建了一个迷你'QA'冲刺，并在每个冲刺结束时加入。它是在代码完成之后但在发布之前。在这短短的时间内，会仔细审查问题，并根据风险和关键性批准纳入问题。在此时间段内修复的问题具有一定程度的自定义审核流程，但主要在定义的Scrum流程之外工作。
答案 2 :(得分：3)
您是否在回顾过程中发现了这些错误的原因？您是否正在使用工程（XP）实践，即进行TDD测试驱动开发，自动功能测试将每日完整回归测试以及配对和故事卡与验收标准。
当发现缺陷时，是否确定了根，并且是一个自动化单元和功能测试添加到您的测试工具中，以便在它再次发生时捕获到这样的缺陷？
据我了解，您的缺陷率太高了。如果至少每天进行TDD和全功能回归测试，那么在UAT期间达到零缺陷并不罕见。
在短期内，您可以向团队收取x个单位/工作点来修复缺陷（查看过去的迭代，如果每次迭代需要x个小时来清理小错误，则减去从团队的能力开始的时间。）长期，关注根本原因并改善团队的工程实践。
通过测量缺陷修复的成本，我们看到了以下关系。如果在开发过程中缺陷成本为1倍，则在功能测试期间需要花费2倍的时间来修复，在UAT期间修复需要3倍，在生产时修复需要4倍。通过编写具有验收标准的故事卡，配对开发，测试驱动开发和自动功能测试以及至少每日完整回归测试，您将显着提高质量并降低成本。因此，您不需要从团队的容量中减去任何时间来提高速度。
答案 3 :(得分：3)
这是Scrum项目中对声音工程实践的强烈需求的一个很好的例子。
“[我们]在代码被接受后出现的一堆小错误遇到了麻烦”
这表明你的“完成定义”不够强大。
“这些包括诸如拼写错误之类的内容”
这些拼写错误是否出现在用户界面上？在接受代码之后，任何人发现它们都应该在接受代码之前发现它们。
与缺陷有关的事情是：1）立即修复它们，2）对系统进行检测，以便下次更早地捕获类似的缺陷并且3）改进您的过程，以便导致缺陷的错误类型是将来不太可能发生。这些都是技术问题。
答案 4 :(得分：1)
谁负责支持您投入生产的代码？如果您的团队确实处理了支持请求，则这些拼写错误和其他外观问题属于该类别并得到适当处理。如果没有，那么你可能不得不让偶尔的冲刺类似于“补丁”冲刺，其中没有添加新的功能但是许多旧的东西被修复并且技术债务被降低到合理的水平。或者将小错误的错误合并到一个说“修复网站上的所有拼写错误”的故事中。
如果您使用Scrum Google "technical debt"或"broken windows"了解其他人如何处理这些事情，可能会有其他想法。
答案 5 :(得分：1)
我的项目已成功实施以下政策：
缺陷修正始终优先于功能开发。目标是始终保持零开放缺陷，重视100％的工作特征而不是几乎正常工作的特征。
缺陷可以并且应该在找到后立即修复。只有在某些非开发人员或开发人员发现无法立即修复缺陷的情况下才需要提交故障单。
需要对代码库进行体系结构级别更改的缺陷会将体系结构调整部分记录为故事并进行估算。计划到即将到来的冲刺。缺陷状态在故事实施中设置为待定。
Sprint backlog受到保护，不受外部变化的影响，但团队本身可能会在sprint中间引入新内容，这是在任何时候都能满足零缺陷所需的目标。
如果缺陷不值得修复（基于一些基本的成本效益分析），那么它就会被忽略以防止未修复开放缺陷污染问题跟踪器。
优先考虑故事实施的故障修复将不时达到你的速度，但没关系。从长远来看，你实现故事的效率会提高，因为代码库中只有少量的技术债务。
答案 6 :(得分：1)
我们通常做的事情，如果Bug与您正在开发的内容无关，或者说在冲刺期间发生的任何其他“无关”活动，就是创建一个“偶然”。
从sprint的“容量”中删除基本上是一段时间，并且将根据需要专门执行sprint目标之外的活动。这可以通过以下方式实现：
每日团队专注于Sprint目标，但有一个“缓冲”时间（Contingent）来处理外部问题。在每日站立时，PO可能会出现每日传入的问题，完成Sprint任务的团队成员（因此没有中断）最终会解决其中一个问题。
时间是在特遣队上预订的，当结束时必须关闭。
团队有权与产品负责人沟通，特遣队的时间已经结束，如果他希望他们保留Sprint的承诺，他将不得不决定他是否希望他们这样做，或者在每日问题之后继续运行，从Sprint中放弃一些价值。
它总是很公平; - ）
我们将其用于以下方面：实时产品的错误和维护（5-15％），准备即将到来的冲刺（10％）......
HTH
答案 7 :(得分：0)
如果错误导致您停止处理sprint目标，您仍然可以决定取消迭代并重新计划。但这是一个安静的艰难决定。