扔掉 bug 跟踪系统？

Elisabeth Hendrickson，“ testObsessed ”的作者，谈到了在敏捷项目中给bug 分门别类的想法，用做抛砖引玉。她的想法是，在迭代中发现的问题不能算是bug，只有产品负责人才有权利把某个东西叫做“bug”，在健康的敏捷团队中，理应不需要任何bug 跟踪系统。

Hendrickson 首先给出了“bug”的定义：

敏捷环境中的bug指的是，在“完成”的故事中的某个行为，与产品负责人的正常的期待产生冲突。

继而她又描述了她给“产品负责人”的定义和她对“期待”的理解，然后就提出了她的立场：在软件“完成”之前，跟“产品负责人的期待”不匹配的行为不能算是“bug”，人们需要采取的唯一行动就是立刻修复：

在声明某个故事“完成”前，如果发现了某些东西跟产品负责人的期待不一致，我们就修好它。我们不争论，不筛查，只修复。所以说我们对 bug 的容忍度为 0.
……
既然找到以后就要修好，所以不需要给它们起名字。也不需要设置优先级，我们不需要在 bug 跟踪系统里面做跟踪。我们只是马上搞定。

讲完这些以后，Hendrickson 又解释了她觉得什么才是真正的“bug”，又该怎么处理：

故事“完成”并“接受”以后，我们可能发现在某些环境中，已经完成的故事所表现出来的行为会跟产品负责人的期待相冲突。这样我们就有了 bug。 如果我们做事情的方式正确，那这些东西就不会很多。如果在一个高级的 bug 数据库中，每时每刻都有 5 个状态为“open”的问题，那做筛查和跟踪就没有任何意义。产品负责人应该把这些 bug 跟产品 backlog 中的条目一起排定优先级，团队继续工作。

如果我们没有按正确的方式做事，就会有一群该死的小孽畜们从眼皮底下溜掉。然后我们就知道过程中有问题了。这时候就不要浪费时间去管理那些逃之夭夭的 bug，而是退一步找到问题所在，从根本上断掉 bug 的源头。

在文章中，Hendrickson 也给出了这个问题的答案：如果有人觉得软件中有问题，但是产品负责人觉得“不是问题”，这怎么处理？她的想法依然是不要做记录：

我工作过的大多数传统团队（在我开始跟敏捷团队一起工作之前）都有 bug 数据库，里面充满了大量永远不会得到修复的 bug。这些东西一般都是被团队中的人报告的——通常是测试人员，优先级是“cosmetic”或者“low priority”。 这种低优先级的问题不会带来任何价值：我们对这种东西不采取任何手段。而且我们会把这些数据在一个个发布中相传下去，因为我们怀揣一个错误的信念：只要有人报告问题，即便微不足道，即便吹毛求疵，即便业务人员毫不关心，把每一个这样的时刻都记录下来还是有价值的。

数据库变成了安全毯，而不是项目资产。我们花了很多很多时间开会，讨论这些问题，列出需要修复的问题，调整优先级，但是等到下一个关键特性或者紧 急 bug 出现时，这些决策又都付诸流水。如果你觉得这些情景听起来似曾相识，那就承认了吧：这些信息对推动项目前进毫无益处。所以住手吧。不然，你付出的 代价要比回报高得多。

总的来说，Hendrickson 是希望我们在把某个东西叫做“bug”的时候更吝啬一些。说的更精确一些，她是希望我们大大减少那些被记录下来， 标记成“以后修复”的问题的数量；一直简化下去，直到任何一款 bug 跟踪系统都显得小题大做为止。她建议说，如果有了很多（真正的）bug，真的需要复杂 的跟踪，那就最好再检查一下开发流程，作出改进，这比弄一个 bug 跟踪系统来得好。

也许她的想法有点激进。不过笔者还是建议大家去读一下 Hendrickson 的文章全文（本文中只是节选而已），仔细考虑它的含义，把你的想法和经验共享出来。

查看英文原文： Throw Away Your Bug Tracking System?