我们最近在工作中采用了Scrum,并且在代码被接受后出现了一堆小错误.其中包括拼写错误和其他单行修复.为每件小事创造大小为0.5的故事似乎是浪费时间.编写故事需要花费更多时间并指出它,而不是修复故事.如果每个sprint中只有一个或两个,那么很容易修复它们并且不用担心为它们创建故事.但是,如果由于应用程序很大而有10或20个或更多,这可能会开始累积大量的开发人员时间,而这些时间并未通过Scrum进行计算.虽然可能很容易说QA员工和产品所有者在原始故事被接受之前应该更加彻底,但我是开发人员,所以这基本上不在我的手中.
到目前为止,我们提出了几个不完美的想法:
有什么建议？
The*_*att 13
你的第三个答案是最好的方法.冲刺只是团队承诺在规定的时间内完成指定数量的工作.如果您正在接受sprint中间的其他工作,那么您将通过处理sprint开始时团队未承诺的事情而偏离原始承诺.
这就是我们的工作:
这是您的其他解决方案的问题:
有一个故事说"在应用程序中修复了90%的错误",然后您可以猜测该sprint中会出现多少错误,可以修复多少错误,然后根据预期的工作负载指出错误
再次,见上文.您希望避免在sprint期间可以填充的空桶工作.这违背了团队明确承诺的目的.团队如何承诺他们不知道或没有估计的事情？
此外,这可以很容易地失控到一个产品所有者,该产品所有者将通过填充该存储桶并具有非常伪装成缺陷的功能来"按缺陷设计".
有一个大小的故事,比如8,在sprint结束时总是被接受,你可以修复尽可能多的bug.这显然需要非常信任,每个人实际上都在做8个人的工作
这听起来很奇怪.团队应该在新的sprint计划开始时接受工作,而不是在上一个sprint结束时.此外,这将真正歪斜在长期的速度.Scrum指的是Product Backlog Items,而不仅仅是Stories,所以没有什么可以说你不能把缺陷包含在PBI中.
记录错误,但在下一个sprint之前不会对它们起作用.它们可以单独指向或作为一组指向.这具有更多"Scrummy"的优点,但导致基本上1小时修复的延迟三周.
你提出了一个有趣的观点,我们对此也有一些担忧.然而,这个1小时的修复(不管它有多快)可能不会花时间与积压中的其他东西相叠加.最重要的是,您希望将这些决策推送给产品所有者,并让他们自由地优先考虑团队花费的一切.
小智 5
我坚信,一个过程只有改善情况的能力才是最好的.这个过程应该适合你,而不是相反.
如果遵循敏捷Scrum流程到'T'弊大于利,那么现在是时候在Scrum流程之外找到更好的解决方案了.
我们已经创建了一个迷你"QA"冲刺,并在每个冲刺结束时加入.它是在代码完成之后但在发布之前.在这短短的时间内,会仔细审查问题,并根据风险和关键性批准纳入问题.在此时间段内修复的问题具有一些额外级别的自定义审核流程,但主要在定义的Scrum流程之外工作.