随笔- 48  文章- 3  评论- 578 
Bug驱动开发简介

  我第一次听到这个概念的时候觉得很好笑，Bug能驱动开发吗？没有系统哪来的Bug？ 一个系统从无到有的过程中，Bug是如何起驱动作用的呢？这里先介绍一个小例子：

  某公司经理想开发C2C系统，找到IT部门的头头说，帮我做一个吧。头头回答说系统已经做好了啊。经理疑惑了，可是现在这个系统什么都还没有，怎么叫做好了呢？头头说，对，现在什么都还没有，好大一个Bug啊！于是，他在Bug管理系统上记录了该系统第一个Bug，“BUG1，C2C系统“。然后他问经理，这个系统应该包含哪些功能呢？经理说，它要有用户管理，权限管理，物品管理等。头头接着给BUG1添加了几个子Bug，"BUG2，需要用户管理”“BUG3，需要权限管理”等。接着越来越多的Bug被添加到Bug系统中，如果想Close任何一个Bug，那么它的所有子Bug必须都被Close，也就是它的依赖。每一个Bug被分配一个Owner（当然也可以自由选择），该Owner的任务就是Fix Bug。

  Bug驱动开发是一个轻量的软件开发方法学，它利用Bug管理系统来记录要实现的功能，从大到小，逐渐具体化，而不仅限于记录系统缺陷。

  它的优势是什么呢？

    轻量。它仅仅使用Bug管理系统就可以管理所有的需求和系统缺陷，还可以利用dashboard来查看系统当前完成的进度。

    每个Bug分配到人，人的任务就是Fix Bug，有约束性。

    利用Bug系统的功能，很容易对各个需求进行排列优先级，状态跟踪。

    QA从一开始就融入团队工作，对Bug进行管理。

  优势应该不只这么多，只是我没有参与过Bug驱动开发，没有太多体会。不知道它和Feature驱动开发有什么本质的区别，就我看来这里的Bug是一种变相的需求表达方式而已。

  TDD是具体开发过程中的实践，从测试开始到实现某功能。而BDD或者FDD，更加high level，从整个系统开发流程来驱动。

 posted on 2008-06-04 00:20 紫色阴影 阅读(2036) 评论(24)  编辑 收藏 网摘 所属分类: Something

#1楼    回复  引用  查看    
 偶卖糕的       | 2008-06-04 02:39
就是测试驱动咯，bug也是测出来的
#2楼    回复  引用  查看    
 三千       | 2008-06-04 03:16
这个有意思，把需求记录于bug系统？延展了bug的范围：需求+缺陷。

或者是用bug管理工具记录了需求？

觉得只是一种概念的XX，没有新颖的东西.





#3楼    回复  引用  查看    
 金色海洋（jyk）       | 2008-06-04 07:16
这些东东都是要建立在丰富的项目经验之上的，没有经验作为基础，呵呵，就是一团乱麻。

想想那个“树”最后会是什么样子，如果出现循环依赖了怎么处理？

项目的整体设计什么时候出来呢？数据流呢？
#4楼    回复  引用    
 urtracker[未注册用户] | 2008-06-04 08:18
有点生拉硬扯的嫌疑。对bug的管理最好还是在系统基本的框架出来比较好，特别是项目的中后期和维护服务期。
欢迎参观本人开发的BUG跟踪软件：URTracker http://www.urtracker.cn
不超过5个用户是免费的。
#5楼    回复  引用  查看    
 Goumh       | 2008-06-04 08:38
是否可以这样理解：这个bug 管理类似于一个轻量级的项目计划管理，做什么？什么时候做、谁做、怎么做、为什么做，等都可以记录下来，至于楼上朋友说的，“树”、“整体设计”、“数据流”那应该是项目执行的结果，可能不适合在Bug 管理中体现了。
当然，这只是轻量级的管理，小项目可以尝试。项目达到一定规模，就难啰。
#6楼    回复  引用  查看    
 Justin       | 2008-06-04 08:44
感觉这个很不靠谱
#7楼    回复  引用  查看    
 bmrxntfj       | 2008-06-04 08:53
这些都不是新鲜东西。它只不过是过去开发中的一点。现在突出这点，是好事，不过完全以这种方式，我觉得不可。就像TDD，其实TDD在作者开始的时候并不是叫TDD，但是到了后来,我觉得作者有点生硬添加东西的感觉。结果就是导致什么都去测试。

BUG驱动开发，也是这样。突出它是好事，但不能孤立它，把它与其他开发方法隔离。会出问题的。
#8楼    回复  引用  查看    
 戏水       | 2008-06-04 09:09
@紫色阴影

不管TDD 还是 bug 驱动 我觉得 最重要的是让团队明确了目标。
方向明确了，目标一致了，于是乎效率有了，问题少了，成本低了。

贵公司的Cruise给俺们弄一套吧 ，不是说对开源项目团队免费么 哈哈哈
#9楼    回复  引用  查看    
 Gray Zhang       | 2008-06-04 09:11
让我想起Ubuntu的第一个bug：MS占据了操作系统的主流
#10楼    回复  引用  查看    
 马可香蕉       | 2008-06-04 09:13
感觉上面所说的bug全都是测试用例
#11楼    回复  引用  查看    
 小寒       | 2008-06-04 09:25
纯bug驱动开发部不现实吧
开发一个小软件还可以
软件真的上规模以后，根本照顾不了全局
而且，把软件开发看成一个整体的bug驱动
这样的意义何在？
思想是挺有创意的，但是实际应用又如何呢
#12楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:34
@偶卖糕的
测试驱动是说开发过程以写测试开始，然后实现功能
Bug驱动更加high level一点，实现过程也可以测试驱动

#13楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:34
@三千
的确是用bug跟踪系统记录需求，新颖的东西自然没有
#14楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:37
@金色海洋（jyk）
任何项目的需求都可以表示成为树吧，我做过的项目需求似乎没有出现过循环依赖
它只是强调以bug的形式来表达需求而已，和整体设计没有关系
#15楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:40
@Goumh
@Justin
就是一个概念靠不靠谱不知道
不过Mozilla和NetBean好像是用这种开发模式

#16楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:41
@bmrxntfj
文档驱动开发有没有隔离其他的开发方法呢？
#17楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:42
@戏水
呵呵 我还没有试用过呢
#18楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:43
@小寒
没有参与过，不知道呢
#19楼[楼主]    回复  引用  查看    
 紫色阴影       | 2008-06-04 10:43
@urtracker
有点做广告的嫌疑
#20楼    回复  引用  查看    
 追求卓越       | 2008-06-04 11:33
个人觉得这种分法不是很好。
在开发的最初期，任务是任务，bug是bug，把这两个混在一起，主要是想借助修复bug的紧迫性。但是如果前期任务能有一个很好的监管措施，那么也就没有必要把任务算作一个bug了。反之如果任务，bug算在一起，但是没有好的监管措施，那么对于管理也没有什么实质性的提高了。
#21楼    回复  引用  查看    
 求知无傲       | 2008-06-04 12:02
楼下继续
#22楼    回复  引用  查看    
 Cure       | 2008-06-04 13:53
换汤不换药啊
#23楼    回复  引用    
 Yannic Yang | 2008-06-04 14:45
想起一句话
要做的事分两种，一种是计划做的，一种是没计划但不得不做的
就是需求和bug
#24楼    回复  引用    
 Liaoyuan Ning[未注册用户] | 2008-06-06 15:29
呵呵，有意思
在我这边，需求除了在需求文档里有意外，也会在bug管理系统里面记录的，类型为work item，然后assign给一个dev去resolve；test那边开的bug的类型会是Code Defect一类的。

也算是一种bug驱动开发吧。



发表评论

昵称： [登录] [注册]

主页：

邮箱：(仅博主可见)

评论内容：

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 1213170




相关文章:

相关链接:
我要啦免费统计