你是否计算了修复错误的时间？

Question

嗨,我是scrum方法的新手,并寻求一些帮助以熟悉环境,并想知道是否需要一个桶来跟踪开发人员和QA花在部署和错误修复和重新测试上的时间.似乎它可能会对图表产生重大影响.

Answer 1

我的团队正在支持许多遗留应用程序,因此在每个sprint期间发生了相当多的计划外错误修复.我们采用了以下做法:

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

当我们添加新的bug任务时,我们会将它们与计划任务区别开来,以便在sprint审核期间轻松查看.有时计划外的工作最终会超过我们冲刺的50%,但由于我们正在将计划项目推送到积压工作,因此我们很早就知道我们没有提供我们计划进行的冲刺.

事实证明,这对我们的团队处理遗留应用程序非常有用,因为我们没有人像我们希望的那样对系统熟悉或自信.

Answer 2

在冲刺期间发现的属于该冲刺的错误应该自动修复,就好像任务/故事没有开始一样.从之前的冲刺中出现的错误可以输入错误积压并按照正常积压进行优先排序.

编辑:刚刚意识到,通过提及"bug-backlog",我打开了"多个积压"这是一个坏主意.更好的方法是使用bug标记在积压中标记条目,或者只接受积压中的任何其他故事.

sprint中出现的严重错误的数量应该是最小的,因为所有内容在接受之前已经过测试,并且在sprint结束时交付给项目所有者.

实际上它不应该影响图形,因为你将承诺修复一定数量的错误(通过PO的选择 - 一些错误的优先级低于新功能)以及当错误从sprint本身出现时,那么任务真的很糟糕没有这样做,所以可以意识到并花时间修理它.

编辑:意识到其他事情 - 有时候在Scrum团队工作并不总能保护你免受必须维护其他应用程序,支持等的现实.虽然这真的很糟糕并且让整个想法成为一个团队积压的单一积压并且重点不是真的有效,现实情况往往是你需要每周保留固定的小时数来支持/维护.不要鼓励这一点,但如果这是现实,请尝试并指定一个人(轮换所以他不会感到悲伤)每周一个固定的小时专用于所述支持角色.通过这种方式,你知道会发生什么,因为速度是相对的 - 它在某种程度上似乎对冲刺的影响较小.