拿什么来驱动你啊，我的项目？

　　我新到这家公司，就开始了一场死亡之旅，我们的项目开发周期是3个月，人员大概有3～6个不一定。而以我的经验，我们大概要做的，是一个3～5个人年的非常复杂的创新型项目。新加盟的技术总监，是一个崇尚文档交流的“老干部”，因此，我们花了一个月的时间，在写各种各样的设计文档。真正能够用于开发的时间，是2个月。

 

　　我们这个小组的另外一位组员，也是一位经验丰富的项目经理，他崇尚的，是文档UML化描述。因此，我现在除了写文档，还要用Rational Rose画好多好多的图～～～

 

　　在他们两位来这个项目组之前，我其实已经写出了一份基本完整的User Case列表，而且和另外一位组员已经进入测试驱动的、结对编程阶段了。。。

 

 

　　大家可能已经看出来了，这其中的开发模式，简直就是混乱不堪。到底是文档驱动？UML驱动？用例驱动？还是测试驱动呢？

 

　　问题还不止这些，我们的大老板比较喜欢和我们一起讨论设计，甚至会和我们争论具体的某个算法。开发文档没有统一的管理，汇报机制没有明确的定义，项目需求随时都可能变动，就连到底我们这个小组会有几个人，都还是一个未知数，这样的死亡之组，不知各位有什么好的建议？

---

 背景资料介绍完毕，抱怨结束，下面讨论正题：

---

　　文档驱动、测试驱动、用例驱动、模型驱动、特征驱动。。。。他们都要解决的是什么问题？

　　要回答这个问题，还真不容易。我们得问一个更加重要的问题，真正驱动项目的，究竟是什么呢？我想，应该是需求吧？

 

　　那么，这些“文档”、“测试”、“用例”、“模型”、“特征”，究竟是什么呢？对于需求的描述！我们之所以不会直接用需求来驱动项目开发，而是要借助工具，来帮助我们描述需求，就是因为口语化的需求描述是非常模糊的，充满歧义的。所以，选择什么来驱动我们的项目，其实就是要看，以上这些工具，哪一个能够更好、更准确的描述需求？

 

　　文档其实是最难准确描述需求的一种方式，如果是纯文字的文档，就更难。我们的技术总监，非常喜欢读写文档，我最近也创下了一天写47页文档的最新记录。但是，当我们开会的时候，我还是经常需要提醒我们的技术总监，麻烦他再仔细看看文档第XX页的第XX段，以及配合着另一份文档的XX小节，来确切的理解我的意思！如果没有我的解释，他就会误解我的文档。

 

　　当然，如果要写出不需要我来解释，他就能理解的文档，那么文档的工作量，将会极其惊人！我以前写过一篇blog，《Jacobson博士演讲观后感》是我对UP的创始人的极度反感的集中体现。GHawk，以及交大林老师的所谓“UP”的观点，当然不可能获得我的赞同。在GHawk的最新一篇blog：《UP & XP之争，意义何在？(续)》中，GHawk说：“唯一的问题是：“如何确保测试用例的质量”。显然，我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢？“结对编程”么？嗯，这是一个不错的方式，那么最终该信赖谁呢？是Pair中的A还是B呢？或者，是Leader么？那么又是谁提出的要求呢？是老板么？还是客户？政府？法规？市场？……问题没有终结了。”

 

　　由此我可以推断，他对于XP的认识，基本上是停留在猜测的阶段。对于这篇blog的观点，我就不逐一反驳了，我的猜测是，他经历过一次失败的XP尝试，而究其原因，我猜测是因为他们那个所谓的XP Team中，没有一个人，曾经实践过一次正规的XP开发。

 

　　再来看模型驱动，这中间有一个大问题，因为需求是“问题域”的范畴，而模型，则是“解答域”的范畴，试图通过解答域的精确描述，来实现对于需求的准确描述，肯定不靠谱啊。

 

　　特征驱动，我认为FDD其实是老方法的新名词，具体的实践，可能更加接近测试、迭代式的过程。了解不过，所以我也不打算多说。

 

　　用例驱动与测试驱动，其实我认为这是一个硬币的两面，用例要尽快的翻译为测试用例，而测试用例，正是为了更加准确的表述需求用例。这是我能够想到的，驱动项目开发的，最好的方法！