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

Question

我在过去几天一直在研究和阅读有关Scrum的内容,并阅读有关Sprint规划和任务的内容.我脑海中浮现的一个问题是如何处理Scrum中的错误.Henrik Kniberg 在Trenches的非常好的书Scrum和XP中列出了一些处理这个问题的方法:

1. 产品所有者打印出最高优先级的Jira项目,将它们带到sprint计划会议,并将它们与其他故事一起放在墙上(从而隐含地指定这些项目与其他故事相比的优先级).
2. 产品所有者创建引用Jira项目的故事.例如"修复最关键的后台报告错误,Jira-124,Jira-126和Jira-180".
3. 错误修复被认为是在sprint之外,即团队保持足够低的焦点因子(例如50%)以确保他们有时间修复bug.然后简单地假设团队将花费一定的时间来修复Jira报告的每个sprint
4. 将产品积压在Jira中(即沟渠Excel).像任何其他故事一样对待错误.

这真的需要根据项目来决定还是有更好的解决方案？我可以想到每种方法的问题.是否有混合物来自那些效果最好的方法？你如何在你的项目中处理这个？

Answer 1

这是一个非常好的问题,我对这个问题的不同方法有一些看法.

1. 从积压项目中平等对待所有错误可能听起来像理论上的好主意(工作在一个地方跟踪)但在实践中不能很好地工作.错误通常是低级别的,而且数量更多,因此如果您为每个错误创建单独的用户故事,那么"真实"故事很快就会变得模糊不清.
2. 如果以对产品所有者可见的方式进行修复,则为修复保留的每个sprint中的显式时间都可以.在每日Scrum期间应该提到错误,并且在sprint审核期间应该讨论修复的错误.否则,产品所有者将不会知道项目中发生了什么.
3. 将整个积压工具放在错误跟踪工具中会产生与1中相同的问题.此外,大多数错误跟踪器都没有考虑到Scrum,为此目的使用它们可能会很痛苦.

我们发现最令人满意的解决方案是在每个sprint上放置一个名为"Tickets"或"Bugs"的用户故事.然后,可以将这样的故事划分为描述特定错误的低级任务(如果在计划期间已知)或者为一般错误修复保留给定小时数的元任务.通过这种方式,产品所有者可以看到流程,而燃尽图则反映了进度.

只记得要无情地关闭所有实际上是新功能的"错误"并为它们创建新的积压项目.还要确保在sprint结束之前修复针对当前sprint报告的所有错误,以便将sprint视为已完成.

Answer 2

实际上我觉得最好的是jpeacock从这个问题回答你是否计算了修复错误的时间？

让我引用它:

• 如果错误很容易/快速修复(一个衬垫等),那么只需修复它.
• 如果错误不是微不足道的,而不是阻止程序,那么将其添加到backlog中.
• 如果错误是阻止程序,则添加一个任务(到当前的sprint)以捕获修复它所需的工作,并开始处理它.这需要将其他内容(从当前sprint)移动到待办事项以计算新的小时数,因为可用的总小时数没有变化.

Answer 3

第一步是定义bug是什么.我教过一个bug只是一个bug,如果它的功能在生产中不起作用的意图/设计.这些成为错误类型的PBI,优先考虑新的开发.生产中缺少功能是一项功能,并成为正常的产品待办事项.在冲刺期间发现的任何有缺陷的代码被认为是不完整的工作,因为在完成当前的工作之前你不会继续下一个故事; 因为团队总是在处理有问题的代码,所以没有必要在sprint中跟踪这些缺陷.Post-it在这里非常方便,可以在队友之间快速提醒.修复损坏的代码总是先于编写新代码.如果缺陷是由于误解了故事,那么你需要在开始讲故事之前研究你的接受条件.

库存是浪费.错误跟踪是库存.错误跟踪是浪费.

从积压项目中平等对待所有错误可能听起来像理论上的好主意(工作在一个地方跟踪)但在实践中不能很好地工作.错误通常是低级别的,而且数量更多,因此如果您为每个错误创建单独的用户故事,那么"真实"故事很快就会变得模糊不清.

如果您有比功能更多的错误,那么您需要处理您的工程实践.这是一种其他错误的气味,跟踪不是答案.深入挖掘.实际上错误总是很臭.它们并不酷,如果你有很多它们,你需要找到根本原因,消除它们,并停止专注于跟踪错误.

Answer 4

不要跟踪列表中的缺陷,找到它们并修复它们 - Mary Poppendieck

事实上,如果库存是浪费,那么缺陷清单呢......

这就是为什么我总是试图通过测试驱动开发和持续集成来实现Stop-the-Line心态,以便我们找到并修复大多数缺陷,而不是将它们放在返工列表上.

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