将错误修复融入Scrum流程的最佳方法?[关闭]

这是一个非常好的问题,当涉及到解决这个问题的不同方法时,我有一些观察。

1. 在理论上(在一个地方跟踪工作),将所有的bug与积压的项目同等对待可能听起来是一个好主意,但在实践中效果并不好。bug通常是低级的,而且数量更多,所以如果为每个bug创建一个单独的用户故事,那么“真实”的故事很快就会被掩盖。
2. 如果以产品所有者可见的方式完成,那么在每个sprint中为修复预留的显式时间是可以的。在日常的Scrum中应该提到bug,关于修正的bug的讨论应该在Sprint审查中进行。否则,产品所有者将不知道项目中发生了什么。
3. 将整个积压工作放入bug跟踪工具会导致与1中相同的一组问题。此外,大多数bug追踪器的设计并没有考虑到scrum,因此使用它们可能会很痛苦。

我们发现最令人满意的解决方案是在每个sprint中放置一个称为“tickets”或“bugs”的单用户故事。然后,这样的故事可以分为描述特定bug的低级任务(如果在计划期间知道的话)或为一般bug修复预留给定时间的元任务。这样,产品所有者就可以看到流程,而燃尽图反映了进度。

记住要无情地关闭所有实际上是新特性的“bug”,并为它们创建新的积压项。还要确保在冲刺结束之前修复针对当前冲刺报告的所有错误,以便将冲刺视为已完成。

事实上,我认为最好的答案是 jpeacock 从这个问题 Do you count the hours spent on bug fixes towards the scrum?

我举个例子:

• 如果错误易于/快速修复(一个 衬里等),然后就把它修好。
• 如果bug不是微不足道的,而不是 拦截器,然后将其添加到积压工作中。
• 如果该bug是阻止程序,则添加一个 任务(到当前冲刺)到 捕获修复它所需的工作, 开始工作吧。这个 需要移动其他东西 (从当前冲刺)到 新工时的待处理订单 因为你的总可用时间 没有改变。

第一步是定义什么是bug。我教导说,如果一个bug是功能性的,而它不能按照预期/设计在生产中工作,那么它只是一个bug。这些将成为Bug类型的PBI,将优先于新的开发。生产中缺少的功能是一个特性,并成为正常的产品积压项。在冲刺过程中发现的任何有缺陷的代码都被认为是不完整的工作,因为在完成当前的工作之前,您不会继续进行下一个工作;由于团队总是在处理有问题的代码,因此不必在冲刺过程中跟踪这些缺陷。张贴它可以非常方便地在这里快速提醒队友。修复损坏的代码总是先于编写新代码。如果缺陷是由于误解了故事,那么在开始故事之前,您需要根据自己的接受条件来工作。

存货是浪费。错误跟踪是库存。错误跟踪是浪费。

在理论上(在一个地方跟踪工作),将所有的bug与积压的项目同等对待可能听起来是一个好主意,但在实践中效果并不好。bug通常是低级的,而且数量更多,所以如果为每个bug创建一个单独的用户故事,那么“真实”的故事很快就会被掩盖。

如果你有比特性更多的错误,那么你需要在你的工程实践中工作。这是一种气味,感觉到其他东西有问题,跟踪不是答案。深入挖掘。实际上,虫子总是很臭。它们并不酷,如果你有很多,你需要找到根本原因,消除它们,停止关注跟踪错误。

不要在清单上跟踪缺陷,找到并修复它们——玛丽·波彭迪克

事实上,如果库存是浪费的,那么缺陷的库存呢…

这就是为什么我总是试图实现 停止线 具有测试驱动开发和持续集成的思想,这样我们就可以发现和修复大多数缺陷,而不是将它们放在返工列表中。

当缺陷通过时,我们会在编写新代码之前修复它们(有缺陷的故事无论如何都不会完成)。然后,我们尝试修复我们的流程,使其更具防错性,并在缺陷发生时检测到缺陷。

没有一刀切的解决方案,每个项目都是不同的。错误也可以从任务关键到几乎不值得修复的分类。

除非对系统的运行至关重要,否则我更喜欢将bug变成故事卡片。这使得特性开发和错误修复的优先级非常明确。在一个错误修复被认为是“冲刺之外”的场景中,错误修复可能会朝着修复非常小的错误的方向发展,而真正重要的业务特性却没有得到开发。

在将bug作为一个故事方法之前,我们已经进行了很多排列。尝试一些不同的事情,并在团队回顾会议上重放它们。

在我们的案例中(Greenfield Development,2-3个开发人员),发现的bug被写下来,清楚地标记为bug,并且根据它们的严重性,它们被分配到下一个迭代中,或者保留在backlog中。在关键和紧急错误的情况下,它们被添加到正在进行的迭代中。

我不知道为什么像修复bug这样简单的事情会因为规则而变得复杂……Scrum的规则很少,记得吗? 每个特性、支持、推荐或缺陷都是Scrum中的积压问题,没有区别。所以,正如Scrum指南所说: 冲刺中的任务从不局限于你在计划会议中所做的决定。 每日的Scrum可以帮助人们讨论沿途的“障碍”。

为什么?

因此,如果您希望缺陷(即积压问题)进入PBI或停留在这个冲刺中并交付它,那么您可以作为一个团队进行讨论并理性地思考……

更好的问题是如何在开发阶段停止创建bug? 见-> http://bit.ly/UoTa4n

如果您正在识别和记录Bug,那么您将需要对其进行分类和修复,然后在将来的某个时候进行修复。 这将导致“稳定冲刺”,即一个完整的冲刺,只是为了修复错误。或者您可以将它们添加回积压工作中,并将它们作为未来冲刺的一部分进行优先级排序。 它还意味着您将提供并期望获得已签署和发布的软件,其中包含已知的bug(p3&p4 aka cosmetic and minor)。

这不是很敏捷吗?

我已经在我们的项目中提出了每三次sprint引入一个简短的bug修复sprint的想法。我们目前的冲刺是三周。

其想法是,它将允许所有开发人员集中精力修复bug,允许在定期的冲刺中只关注新的故事,并保持对减少技术债务的定期关注。

错误修复将被分为相关的故事和优先级。重点不在于Sprint之前的大小调整,因为开发人员很难在不理解缺陷本质的情况下调整错误修复的大小。

是否有人尝试过或对他们认为这可能如何工作有任何反馈?

干杯, 凯文。