我正在开发一个Scrum项目,用C语言编写固件代码用于ASIC.
我们经常很难找到错误.但是我如何估计这些错误呢？
我总是告诉Scrum主管我没有能力估计它们,因为我真的很讨厌错误的时间估计.
你们如何在Scrum项目中处理这个问题？
估计错误是一件非常困难的事情.如果你能做到,那么你可能已经有了解决方案而且它不再是一个真正的bug :)所以,不是试图逐个估计它们,我首选的选择是在Sprint期间分配一些 "bug修复时间"在此期间修复最重要的错误.这是一个尽力而为的策略,您只需在分配的时间内尽可能多地修复它们.
对我有用的一种方法是首先没有bug :)
这种方法的工作方式是,当发现错误时,修复它优先于故事实现.只有在现有功能100%工作后才能添加新功能.
当然我们对错误进行分类.这种停止生产线方法仅适用于严重错误.少于严重的错误被视为功能增强故事,在即将到来的冲刺中估计和计划与任何其他故事一样.
关键错误修复的时间分配最终会反映在您的团队速度中.
"很难做出预测 - 特别是关于未来."
除非你已经分析了一个错误并且修了一个解决方案,否则无法估计.这就像在不知道积压的情况下进行Scrum计划会议.
您可以使用大估计来传达不确定性.历史数据的价值有限.即使新错误的工作分配相同,它对手头的一个错误也没有多大帮助.此外,新错误平均可以更容易或更难.
我问过Jeff Sutherland,他告诉我,在PatientKeeper,他们有一个固定的估计半天来修复一个bug.如果您的错误的性质是它们可以相当可预测,以便您可以找到近似的平均值,我想这是一个公平的策略.
但是,在实践中我并不总是发现这一点.通常很难理解错误是什么,分析它可能需要更长的时间而不是解决它.这通常会使错误高度不可预测且难以估计.必须分析您在sprint中包含的所有任务,并且错误通常需要比其他任务更多的分析.
我们在"不可预测的"错误的情况下所做的是分配固定的时间来确定问题所在.例如,我们选择花费一天(或x点)挖掘试图理解它的bug,然后计划解决下一个sprint的实际修复.但是,如果没有足够的时间来解决这个问题,我们不希望在当前的冲刺中浪费更多时间,并且不得不重新考虑它.在某些情况下,这个错误可能非常关键,你只需要估计不确定.
京公网安备 11010802040832号 | 京ICP备19059560号-6 