我在敏捷团队中工作.
我们有一个已发布的产品,我们仍在努力开发未来版本.
每个sprint我们都会收到0到5张票,以修复已发布产品中的错误.
我们的团队由软件工程师(处理新开发)和维护软件工程师(处理门票)组成.
我的问题是你如何计算sprint计划期间的维护时间.
目前我们有一个名为维护缓冲区的故事,我们分配几个小时来解决故障单.我们将它用作缓冲区,因此在我们没有收到票证的冲刺中,我们使用缓冲区中的小时进行开发工作.
我觉得这不是一个敏捷的做事方式,任何建议？
您提到的方法也包含在Mike Cohn的故事中,应该分配给敏捷缺陷故事吗？,他写道:
有时团队为此活动编写用户故事,例如:"作为用户,我希望修复至少15个错误"或"作为用户,我希望您花费大约50个小时来修复错误,以便应用程序逐渐变为错误更高质量."即使是没有明确编写此类用户故事的团队,通常也会在其任务板上添加一行,以使敏捷缺陷和错误修复可见,并进行跟踪.
您目前有一个名为维护缓冲区的故事,您可以在其中分配几个小时来解决故障单,这与Mike Cohn的文章中所述类似,他建议为错误修复敏捷缺陷分配点.
还有其他选择,比如
紧急情况/修补程序怎么办？
您需要评估解决该紧急错误所需的关键性和工作量.由产品负责人决定团队是否放弃所有内容并开始使用此修补程序.原因是客户始终是第一位的,如果交付的产品没有提供预期的价值,那么就不会在不完整的产品中添加更多功能.没有任何框架/方法可以阻止您处理特殊情况或指示您忽略关键问题.因此,当前sprint可以被取消,或者如果该修补程序可以由团队的一个(或一些)成员处理,那么来自当前sprint的功能或错误可以与紧急错误修复交换.
用生产支持和Scrum的Geoff Watts的话来说:
如果问题是真正的紧急情况,产品负责人应该有权使用"紧急卡",只要他知道这样做的成本 - 没有完成我们计划的项目,并可能危及冲刺目标.
产品负责人可以使用以下3种选项中的任何一种: