将bug修复融入Scrum流程的最佳方法是什么？

作者: 易米烊光
发布时间: 2024-12-23 08:27:32 (12天前)
转自：

10 条回复

0#
回复此人
afs-loliaholic | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 其实我认为最好的回答是 <a href="https://stackoverflow.com/users/18381/jpeacock"> jpeacock </A> 从这个问题 <a href="https://stackoverflow.com/questions/175344/do-you-count-the-hours-spent-on-bug-fixes-towards-the-scrum"> 你是否计算了修复错误的时间？ </A> </p> <P> 让我引用它： </p> <UL> <LI> 如果错误很容易/快速修复（一个衬垫等），然后修复它。 </LI> <LI> 如果错误不是微不足道的，而不是一个阻止程序，然后将其添加到待办事项中。 </LI> <LI> 如果bug是阻止程序，那么添加一个任务（到当前的冲刺）来捕获修复它所需的工作，并开始研究它。这个需要移动其他东西（从当前的冲刺）到积压以计算新的营业时间因为你的总时数可用没有改变。 </LI> </UL> </DIV>

编辑
1#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我不知道为什么像修复bug一样简单的事情会因为规则而变得复杂.. Scrum的规则很少，还记得吗？每个功能，支持，推荐或缺陷都是Scrum中的Backlog问题，没有区别。因此，正如Scrum指南所说： Sprint中的任务绝不仅限于您在计划会议期间决定的内容每日Scrum帮助人们一路讨论“障碍”。 </p> <P> 为什么？ </p> <P> 因此，如果您希望将缺陷（即积压问题）纳入PBI或保留在此Sprint中并将其交付，那么您将作为一个团队进行合理的讨论和思考...... </p> </DIV>

编辑
2#
回复此人
镜乃Kagamino | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <BLOCKQUOTE> <P> 不要跟踪列表中的缺陷，找到它们并修复它们 - Mary Poppendieck </p> </BLOCKQUOTE> <P> 实际上，如果库存是浪费，那么缺陷清单呢...... </p> <P> 这就是为什么我总是试图实现一个 <EM> 停止的线 </EM> 通过测试驱动开发和持续集成的心态，以便我们找到并修复大多数缺陷，而不是将它们放在返工列表上。 </p> <P> 当缺陷通过时，我们在编写新代码之前修复它们（无论如何都没有完成错误的故事）。然后，我们尝试修复我们的流程，使其更加防错，并在发生错误时检测它们。 </p> </DIV>

编辑
3#
回复此人
呵呵 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 更好的问题是如何在开发阶段停止创建错误？见 - ＆GT; <a href="http://bit.ly/UoTa4n" rel="nofollow"> http://bit.ly/UoTa4n </A> </p> <P> 如果您要识别并记录错误，则必须在将来某个时间进行分类和修复。这导致“稳定冲刺”，即整个冲刺只是为了修复错误。或者您可以将它们添加回待办事项并将其作为未来冲刺的一部分进行优先级排序。这也意味着您将提供并期望签署并发布包含已知错误的软件（P3＆amp; P4又称化妆品和次要商品）。 </p> <P> 这不是真的敏捷吗？ </p> </DIV>

编辑
4#
回复此人
石茶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我已经在我们的项目中提出了这个想法，即每三个sprint引入一个简短的错误修复sprint。我们目前的冲刺是三个星期。 </p> <P> 这个想法是，它将允许所有开发人员专注于修复错误，允许专注于常规冲刺中的新故事，并定期关注减少技术债务。 </p> <P> 错误修复将被分组到相关的故事和优先级。重点不在于sprint之前的大小调整，因为开发人员在努力修复bug修复而不会陷入理解缺陷的本质。 </p> <P> 有没有人试过这个或者对他们认为这可行的方式有任何反馈？ </p> <P> 干杯，凯文。 </p> </DIV>

编辑
5#
回复此人
IP地址 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在我们的案例中（绿地开发，2-3个开发人员）发现错误被写下来，清楚地标记为一个错误，并根据它们的严重性将它们分配给下一次迭代或留在积压中。在出现严重和紧急错误的情况下，它们会被添加到正在进行的迭代中。 </p> </DIV>

编辑
6#
回复此人
氷寒 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 这是一个非常好的问题，我对这个问题的不同方法有一些看法。 </p> <OL> <LI> 从积压项目中平等对待所有错误可能听起来像理论上的好主意（工作在一个地方跟踪）但在实践中不能很好地工作。错误通常是低级别的，而且数量更多，因此如果您为每个错误创建单独的用户故事，那么“真实”故事很快就会变得模糊不清。 </LI> <LI> 如果以对产品所有者可见的方式进行修复，则为修复保留的每个sprint中的显式时间都可以。在每日Scrum期间应该提到错误，并且在sprint审核期间应该讨论修复的错误。否则，产品所有者将不会知道项目中发生了什么。 </LI> <LI> 将整个积压工具放在错误跟踪工具中会产生与1中相同的问题。此外，大多数错误跟踪器都没有考虑到Scrum，为此目的使用它们可能会很痛苦。 </LI> </醇> <P> 我们发现最令人满意的解决方案是在每个sprint上放置一个名为“Tickets”或“Bugs”的用户故事。然后，可以将这样的故事划分为描述特定错误的低级任务（如果在计划期间已知）或者为一般错误修复保留给定小时数的元任务。通过这种方式，产品所有者可以看到流程，而燃尽图则反映了进度。 </p> <P> 只记得要无情地关闭所有实际上是新功能的“错误”并为它们创建新的积压项目。还要确保在sprint结束之前修复针对当前sprint报告的所有错误，以便将sprint视为已完成。 </p> </DIV>

编辑
7#
回复此人
AsuRa | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 没有一种尺寸适合所有解决方案，每个项目都不同。错误也可能被分类为关键任务，几乎不值得修复。 </p> <P> 除非对系统的运行至关重要，否则我更喜欢将bug变成故事卡。这使得功能开发与错误修复的优先级非常明确。在错误修复被认为是“在sprint之外”的情况下，错误修复可能会转向修复真正微不足道的错误，而真正重要的业务功能尚未开发。 </p> <P> 在将错误设置为故事方法之前，我们已经通过了许多排列。尝试一些不同的东西，并在团队复古会议上重播它们。 </p> </DIV>

编辑
8#
回复此人
12345 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 第一步是定义bug是什么。我教过一个bug只是一个bug，如果它的功能在生产中不起作用的意图/设计。这些成为错误类型的PBI，优先考虑新的开发。生产中缺少功能是一项功能，并成为正常的产品待办事项。在冲刺期间发现的任何有缺陷的代码被认为是不完整的工作，因为在完成当前的工作之前你不会继续下一个故事;因为团队总是在处理有问题的代码，所以没有必要在sprint中跟踪这些缺陷。 Post-it在这里非常方便，可以在队友之间快速提醒。修复损坏的代码总是先于编写新代码。如果缺陷是由于误解了故事，那么你需要在开始讲故事之前研究你的接受条件。 </p> <P> 库存是浪费。错误跟踪是库存。错误跟踪是浪费。 </p> <BLOCKQUOTE> <P> 从积压项目中平等对待所有错误可能听起来像理论上的好主意（工作在一个地方跟踪）但在实践中不能很好地工作。错误通常是低级别的，而且数量更多，因此如果您为每个错误创建单独的用户故事，那么“真实”故事很快就会变得模糊不清。 </p> </BLOCKQUOTE> <P> 如果您有比功能更多的错误，那么您需要处理您的工程实践。这是一种其他错误的气味，跟踪不是答案。深入挖掘。实际上错误总是很臭。它们并不酷，如果你有很多它们，你需要找到根本原因，消除它们，并停止专注于跟踪错误。 </p> </DIV>

编辑

登录后才能参与评论