文档驱动、测试驱动、用例驱动、模型驱动、特征驱动。。。。他们都要解决的是什么问题?
要回答这个问题,还真不容易。我们得问一个更加重要的问题,真正驱动项目的,究竟是什么呢?我想,应该是需求吧?
那么,这些“文档”、“测试”、“用例”、“模型”、“特征”,究竟是什么呢?对于需求的描述!我们之所以不会直接用需求来驱动项目开发,而是要借助工具,来帮助我们描述需求,就是因为口语化的需求描述是非常模糊的,充满歧义的。所以,选择什么来驱动我们的项目,其实就是要看,以上这些工具,哪一个能够更好、更准确的描述需求?
文档其实是最难准确描述需求的一种方式,如果是纯文字的文档,就更难。我们的技术总监,非常喜欢读写文档,我最近也创下了一天写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其实是老方法的新名词,具体的实践,可能更加接近测试、迭代式的过程。了解不过,所以我也不打算多说。
用例驱动与测试驱动,其实我认为这是一个硬币的两面,用例要尽快的翻译为测试用例,而测试用例,正是为了更加准确的表述需求用例。这是我能够想到的,驱动项目开发的,最好的方法!
