Mike Cohn成功敏捷系列：Bug要不要放进Backlog里？

亲，

 

经常有人问是否要把Bug写成用户故事。

 

【格式探幽：AIS与自然的格式】

为了回答这个问题，可以考虑下用户故事的目的。用户故事是对话的占位符。写用户故事的目的是作为对进一步讨论的提示。

 

这意味着书写的内容需要服务于讨论。用户故事是讨论的提示和起点。

 

可以想象，在某些情况下，把Bug写成用户故事是有益的，甚至可以用AIS格式：As a …, I want… so that…

 

但在其他情况下，以自然的方式表述更佳。经常可以简单地表述为“当用户这么做时系统会垮掉”。

 

这都没问题。

【Backlog为什么而生】

不需要Backlog里全是用户故事。不需要Backlog中每一项都用AIS格式书写。

 

产品Backlog的目的是承载已知的、必要的工作。

【Bug的三级堤坝：吼一声、迭代Backlog、产品Backlog】

 

因此真实的问题不是：是否把Bug写成用户故事。而是：是否把Bug放在Backlog。

 

当Bug被发现时，团队（和PO）应当考虑立即修复。发现的人对程序员吼一声“嘿，技师，用户这样时你的代码崩了。。。”程序员马上修复。

 

如果做不到，Bug应当被加到迭代Backlog，并在当个迭代的晚些时候修复。

 

但如果修复Bug需要更多时间，并且优先级不高，或者妨碍团队达到迭代目标，那么Bug就可以加到产品Backlog。

 

但不必写成用户故事。用最自然的方式写Backlog项，能帮助团队成功敏捷。

 

Should you write user stories for bugs?

Hi ,placeholder for a conversation. The written portion of a user story serves as a reminder to discuss what’s needed.As a …, I want… so that…” template.But others are likely best expressed however seems most natural. Very often that is simply, “The system crashes when a user does this-and-that.”And that’s fine.The goal has never been that an entire product backlog should be user stories. The goal has definitely not been to have everything on a product backlog written with “As a…, I want… so that…”The goal is to have a product backlog that represents the known, needed work.So the real question is not whether to write bugs as user stories but rather whether to put a bug on the product backlog at all.

When a bug is found, the team (and its product owner) should consider simply fixing it immediately. Whoever found the bug yells to the programmer, “Hey, Pat, your code blows up when the user does…” And the programmer fixes it right then.