我第一次听到这个概念的时候觉得很好笑，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，从整个系统开发流程来驱动。