Scrum,如何处理sprint中的bug以及如何估计bug的时间[已关闭]

估计bug是一件非常困难的事情。如果你能做到这一点,那么你很可能已经有了解决方案,而且它不再是一个真正的bug:)因此,与其试图逐一评估它们,我更喜欢的选择是分配 一些 Sprint期间的“bug修复时间”,并在此期间修复最重要的bug。这是一种尽力而为的策略,您只需在分配的时间内修复尽可能多的问题。

对我来说,一个行之有效的方法是首先不要有bug:)

其工作原理是,当发现bug时,修复它的优先级高于故事实现。只有在现有功能100%正常工作后,才能添加新功能。

关键缺陷修复的时间分配最终会反映在您的团队速度中。

“很难做出预测,尤其是对未来的预测。”

除非您分析了一个bug并找到了解决方案,否则无法对其进行估计。这就像在不知道积压工作的情况下召开scrum计划会议。

您可以使用较大的估计值来传达不确定性。历史数据的价值有限。对于手头的一个bug,即使新bug的工作分配相同,它也没有多大帮助。此外,平均而言,新的bug可能更容易,也可能更难。

Jeff Sutherland 他告诉我,在PatientKeeper,他们有一个固定的半天时间来修复一个bug。如果你的bug本质上是可以预测的,那么你可以找到一个近似的平均值,我想这是一个公平的策略。

在这种“不可预测”的bug情况下,我们所做的是分配固定的时间来找出问题所在。例如,我们选择花一天时间(或x点时间)深入研究bug,试图理解它,然后计划在下一个sprint中解决实际修复问题。然而,如果没有足够的时间来解决这个问题,我们不想在当前的sprint中浪费更多的时间,并且将不得不在下一个sprint中重新考虑它。在某些情况下,错误可能是非常严重的,你只能接受一个不确定的估计。。

用几周而不是几个小时来估算。

如果您的Scrum管理员不理解估算bug修复时间的问题,那么您的项目可能会从拥有至少具有少量编程知识的Scrum管理员中受益。

“我知道哪里出了问题,我需要更新它”, “我知道这个错误与这个模块有关,任何调试这些文件的行为我都能解决”, “我不知道为什么会出现这种错误”。 根据我们在该项目上的经验,我们可以估计前两种情况。 但对最后一个案例的估计是非常困难的。

不久前我问了一个类似的问题,得到了一些答案 good responses .

您应该能够根据一致的故事点估计,建立一个一周内可以完成多少故事点的历史记录。这还包括bug修复时间。

例如,我们知道我们可以在一周内完成20个故事点,这是以前的冲刺。这20点的开发可能会在2天内完成,但是接下来还有测试和bug修复。我们不估计开发错误,因为每个新故事都应该有一个估计,大约包括错误修复时间。在评估之前,应该调查活的bug,然后才能准确地评估。

我们估计每个bug的分析时间为4小时。此外,我们还对bug进行了优先级排序。在执行任何其他操作之前,必须先修复阻塞程序或关键错误。许多bug需要在较低的实现层中修复。但是我们有一个强大的软件来支持下一个功能。

我发现,试图估计bug并没有多大用处。只要防止它们,找到它们,让它们可见(在你的任务板上或你使用的任何东西上),确定它们的优先级并修复它们。您花费的时间将影响速度。速度才是最重要的。速度是你在下一个冲刺中可以期望取得多大进步的指标。

真正的目标是减轻与bug相关的风险;i、 e.不让时间表生效。通常,团队能够提前确定哪些故事可能会产生棘手的bug。因此,一种缓解策略是首先处理这些故事,给团队尽可能多的时间来应对意外情况。

你也可以考虑在Sprint中分配一个“特遣队”,而不是使用看板的方法来解决它们。这意味着您可以与产品负责人交谈,并向他解释缺陷修复成本是可控的(因为时态是您的时间表),根据经验,将根据团队对产品质量的感觉在每次新的迭代中进行调整。当然,我们的目标是缩短时间,提高透明度。产品负责人可以帮助确定Bug积压的优先级,将最有价值的Bug放在最上面-通常是保留值-这样优先级最高的Bug可能会被修复。。。越高越好。

一般来说,透明度应该使Scrum团队(包括PO和SM)能够确定修复的成本,并确定如何平衡交付的质量和速度。这通常是与PO建立对话的好方法:-)

我完全同意帕斯卡·蒂文特的回答。 在我们的冲刺中,通常我们会选择一些任务,如果有其他更紧急的任务,这些任务可以定制。

当一个bug出现时,我们会对它进行优先级排序,并设置它的重要性。 如果是高优先级或严重性,我们将着手进行,而这个冲刺中不重要的任务将移回积压工作。

如果没有bug或者bug不是紧急的,我们将执行所有Sprint任务。