Bri*_*nan 4 scrum user-stories agile-processes defects
假设您正在编写一段遗留代码,该代码是在您的公司开始使用像Scrum这样的敏捷方法之前编写的.
现在让我们说你发现了一个需要修复的字段中的错误,并且从来没有写过该功能的故事.团队中的每个人都知道这个特殊功能是什么以及它应该如何表现但只是没有与之相关的故事.
现在,在当前的冲刺中,您将处理该缺陷,因为市场营销和支持部门已经厌倦了处理该问题.
你是否回想起要链接到的缺陷？您是否将您的缺陷重新标记为故事并修改格式以使其看起来像故事？如果你没有创建一个故事,你会得到缺陷的分数吗？如果您确实创建了一个故事,那么您是否可以获得修复缺陷的要点(通过故事的要点)？
处理这种情况的最佳方法是什么？
更新:假设安装过程突然在Windows 7 64位上开始蓝屏系统,并且始终要求应用程序安装在所有Windows平台上.由于Service Pack 1或类似的东西,新问题可能已经出现.
你是否回想起要链接到的缺陷？
是.值得回顾的是,确保每个人都同意这个故事.
如果它是一个无错误但又烦人的界面,那么你真的在修改工作流程,它确实需要被记录为一个合适的故事.
如果涉及到一个错误,那么有单元测试应该找到错误(但没有).这并不似乎是您的情况,但它是常见的不完整的单元测试没有发现的错误.扩展单元测试(修复故事后)也非常重要.
您是否将您的缺陷重新标记为故事并修改格式以使其看起来像故事？
并不是的.无论是否有故事,缺陷只是一个缺陷.
缺陷消失了.故事没有.
如果您确实创建了一个故事,那么您是否可以获得修复缺陷的要点(通过故事的要点)？
为什么不？
编辑.故事点问题很难.理想情况下,这些点跟踪完成的工作和创建的价值.故事==努力==分.但是在处理重用,发布和返工时会出现问题.
你有几个不相关的问题:努力,质量和价值.积分可以追踪其中一个.它无法跟踪其他任何一个.
如果你认为速度应该反映努力,那么你就不能因为错误或需求变化而取消分数.它不跟踪创建的值,也不能用于此.
如果你认为速度应该跟踪价值,那么你必须把分数拿走.它没有跟踪努力,因为工作已经完成,但它的功劳被删除了.
返工很难.错误和需求变化是一回事,它们是返工.你有很多候选人.
实施错误的"简单"错误,但故事是"正确的".理想情况下,这不计入速度.对？
"不完整的故事"错误,实施是正确的,但故事省略了一些关键(和技术)的细节.嗯.谁应该受到责备？谁的速度测量应该受到惩罚？
我们在测量什么？努力呢？工作已经完成.值？没有创造价值.
"错误的故事"错误,实施是正确的,但故事从一开始就是一个坏主意,没有人抓住它.这可以称为"撒谎用户场景".它发生了.理想情况下,这取决于速度.用户撒了谎.但是,你怎么能将这与其他任何返工区分开来？什么是"规则"？
"改变了故事"的错误,实施是正确的,故事是对的.但整体情况发生了变化,故事需要改变.这只是"增强"或"适应",就像新作品一样.当然,这不是全力以赴的工作,是吗？它可能只是对现有代码的调整,因此您不希望使用创建的完整值来过度奖励它.
我们在测量什么？努力呢？有些已经完成,但并不多.值？价值创造了.
底线.积分是一种政治武器,并不是很重要.努力或价值,但不是两者兼而有之.并不好.