BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

扔掉bug跟踪系统?

| 作者 Mike Bria 关注 0 他的粉丝 ,译者 李剑 关注 1 他的粉丝 发布于 2009年3月31日. 估计阅读时间: 4 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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?

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

软件开发没有银弹 by soft SG

敏捷实践是好的,但没有一成不变的万能之法,灵活运用才是正道——而怎么算是正确的,对这个问题答案,只有方法论可以照搬,方法不能照搬。

当前的Bug Trace很大程度上起到了对团队人员任务进展的跟踪,如JIRA,不单纯是Bug Trace,从某种意义上讲,应是Project Management Suit。在敏捷实践中不可能不犯错误——从需求,框架,编码实现等等方面,团队越大,问题越多,特别是团队成员素质不一,问题就更多。如果项目就2个人,估计什么工具都不需要了,Excel全部搞定,如果是20个人,就另当别论了。

Bug界定以及关注的核心 by Xia Base

Elisabeth Hendrickson的意思并不是要扔掉Bug跟踪系统,而是要界定到底什么是Bug,其意见就是与需求相违背的才是,否则就不是,一切以需求为准,与需求无关的可以忽略不考虑。因为在实际开发过程中,经常会出现“离题”的情况,浪费时间而对项目开发本身并无实际好处。反之,与需求相关的则需要跟踪并处理。

Re: Bug界定以及关注的核心 by Zhang Kaifeng

我同意你的观点,在story完成之前,测试人员非要认为开发过程中的错误实现也是bug,那只能是测试人员硬要证明自己的存在价值了。

bug与maintenance by 徐 毅

理解了在敏捷中两者之间的关系,你就理解了Elisabeth的观点。

精辟!一看这姐姐就是道儿上的。 by jiang yan

如果不能修复,就不要记录;
如果不被重审,就不要流传;
这样采购敏捷。
超过100个Bug在Open,就等于没有bug。

可惜,要Manager也这么精辟才行。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

5 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT