《特征驱动开发方法》

前些天讨论中谈到了 FDD，国内已经有这方面的译著出版。
《特征驱动开发方法——原理与实践》。作者是 TogetherSoft 公司的软件专家。TogetherSoft 公司中正是采用 FDD 的开发过程。
http://www.cnforyou.com/query/bookdetail.asp?viBookCode=8921

我大致看了一下，感觉这本书的内容非常棒。而且我认为 FDD 是比 XP 的 TDD 更适合于中国的软件开发过程。
我读过 XP 的教材后的想法是：别急，先等等看。
读过 FDD 的教材后的想法是：还等什么，明天就做起来。

我对 TDD 存有疑问的原因是：
1、对于一些复杂的功能，很难写测试代码，写测试代码花掉的时间可能跟写功能代码所花的时间差不多（写测试代码并不象某些人想的那么容易，尤其是国内的很多程序员并没有达到 XP 的要求。摆摆样子写几个 TestCase 当然是很容易的事情，但是写真正有用的测试代码就是另一回事了）。而这些功能中存在的问题在系统原型搭建起来并且有了一定的规模后可以通过简单的用户测试（打开浏览器，执行一些操作）和调试器跟踪（在 Eclipse 中调试程序效率是非常高的）很快解决。所以在开发前期写大量的测试代码从成本上考虑是不合算的。
2、TDD 中似乎把单元测试的重要性提升得过高了，给人的误解是质量控制完全靠单元测试就足够了，而忽略了其它的质量控制手段。在 FDD 这本教材中，作者说：在 FDD 中，单元测试是由设计和代码审查来补充的。代码审查已被证实比单独的测试更能发现缺陷，而且还能发现不同类型的缺陷。
3、看起来 FDD 是更适合开发复杂产品的敏捷开发过程。我并没有听说过完全采用 XP 方式开发出来过什么复杂的软件产品（可能 XP 真的是只适合做简单的项目开发，不适合开发复杂的产品）。而 Together 的名字早在去年就已经如雷贯耳了。我们不仅是一个做项目的公司，更是一个做产品的公司，所以 XP 并不能帮助我们实现自己的目标。

如果说软件过程领域有两个端点 XP 和 RUP 的话，那么 FDD 差不多是位于它们的中点，与 XP 更接近些，但是无论熟悉 XP 还是熟悉 RUP 的人都可以非常容易地掌握 FDD。

很高兴看到你在关注FDD。
FDD我认为更加容易被国内的人去接受。而且如果你原来就使用面向对象的方法的话，你基本可以无障碍的去实施FDD。
其实FDD和XP非常类似，而和RUP的距离要远的多。在FDD中很少有中间的制品，而且那些中间制品也非常容易被维护和释读。而最另我惊讶的是FDD可以定量的测定项目的进展。而这个定量方法，即使是客户和高层管理者也可以掌握。而如果大家再去使用color UML会更加爽，可惜现在只是together在支持color UML。我们大家绝对应该去研究一下这个最新的敏捷方法（2001年才出现的）。
而说到纪律，使我想起了水晶，那个方法可以在纪律非常松散的情况下实施。它的理念在于可以适度的放弃效率，以适应环境。而最有意思的是，水晶是一个方法集，它针对不同的环境会采取不同的方法。特别是和ASD合并以后，新的方法会更加有趣。我觉得从《书写有效用例》就可以看出作者是一个有趣的人。而XP中的纪律是严格的，但是这样的做法，绝对不是军事化的管理。而且可以看出XP的主要创造者都是一些懒散的人。但是在XP中确实要求有严格的纪律，这是为什么呢？这些纪律是怎么来的呢？其实很简单，在一般情况下我们说到的纪律，都是对于基层人员的约束，可是在XP中纪律是人们的权利。比如当你遇到问题，而自己不能解决的时候，XP的纪律就要求你向你看到的任何人求救，那个人不管在做什么，都必须说“好的，我来帮你”。我不知道这样的纪律谁不愿意去遵守。问题在于这些纪律是怎么来的，它们不是什么管理者居高临下的制定的制度，他们是项目参与者在开始项目前，谈判签署的协定。但是我们看到国内的公司大多数都是金字塔结构的，对于XP这种强烈要求矩形结构的方法，会有不适应。
而对于TDD，我的看法是不能简单的把TDD就看作先写junit的TeatCase。它的最重要含义，在于你必须在你做一个决定前，去确定你如何对你做的决定所产生的效果加以认定。而其实写测试代码的时间往往会比写实现功能的代码的时间还多，但是这是有好处的。大家看看BOB大叔的《敏捷软件开发》就明白了先写测试会给你带来的好处。而同时由于XP中重构的发挥到了淋漓尽致，如果你没有测试的保证，这是很难实施的。
我认为FDD中也可以TDD，而且我也是这么做了。如果要研究TDD，就看看kent的TDD吧。现在已经有了影印版。
总之FDD是我现在最推崇的方法，也是很难引起争议的方法。与其去为XP和人争论，不如去实实在在的去FDD一把。

去年我所在的那个 XP 开发团队，前两天在网上与他们的一位核心开发人员（现在已经做 PM 了）聊天时得知，他们已经不再做单元测试，不再坚持测试驱动，结队编程很早就已经不搞了。我问他不做单元测试能叫 XP 吗？他说当然不是 XP 了。通过进一步交流后得知，他们现在采取的开发方式与 FDD 是非常接近的。
这证实了我从去年以来的一些疑问和预测。在我看来他们搞的什么单元测试就是在走过场，那些简单的测试代码能否奏效是很值得怀疑的。他们出于 CTO 本人的喜好把开发平台完全转移到 Linux 上也是我所反感的。他们使用的是 Linux+NetBeans+Mozilla+KXMLEdit 做开发，还准备使用 Mozilla 的 XUL 来做 UI，完全甩掉 IE，这些做法都是我认为过于激进的做法。当然这些是与 XP 无关的，他们实施 XP 失败不完全是 XP 和 TDD 的过错。
Kent Beck 确实是天才，但是适合天才的开发方式未必适合普通人。好在敏捷开发方法字典里的成员已经很多了。所以我们现在可以从 FDD 开始。当然也别忘记了 ozzzzzz 的建议，Color UML 是更重要的东西。

最近经常看到讨论数据建模和对象建模的问题，还看到业务建模的问题。而我觉得我们说了这么久，真的没有color UML那么几页纸对我触动大。虽然uml with color不是设计的解决方案，但是你会看到它对于需求了领域的把握是非常出色而令人经验的。赶快学习，不要耽误。
简单的令人吃惊，有效的令人吃惊的东西。我实在是佩服together的创意，和他们逻辑严谨的思维方式。它用4个原型概况了很多让人迷惑的东西，用12个组件推出了经常出现的一些场景模式。我想如果谁有时间，把那200页左右的《Java Modeling in UML  with Color》翻译成中文就好了。

XP 中还有一个问题是没有软件详细需求文档，而仅仅有一系列的 User Story。
Alistair Cockburn 在《编写有效用例》第 18 章“用例概述和极限编程”中写到：

这段话回答了我对 XP 的另一个主要的疑问，同时也说明了为什么 Alistair Cockburn 后来要自创水晶开发方法。
XP 对于用户提出了过高的要求，不仅难以找到符合 XP 要求的程序员，而且难以找到符合 XP 要求的用户。反复打扰客户是很招人嫌的，打搅次数多了客户甚至会怀疑你是否听不懂人类的语言。要客户派一个人来和开发人员一起工作，他们往往会派一个无关紧要的人过来（真正的业务专家往往都非常忙，不可能经常过来与程序员共同工作）。这样的人没有任何决策权，对业务也没有完全理解，他提供的意见你能完全相信？

因为有以上的这些顾虑，我的结论是 XP 不是适合中国软件企业的开发过程。国内的软件企业可以借鉴 XP 中的一些最佳实践，但是绝对不能全盘照搬 XP 的做法。

这本书由下载么

好像有把，我有这本书的6章，你到网上seek一下。
我以前看的时候没有感觉，最近忽然开窍。发现用它提供的四种原型和12中组件，去作商业建模以及需求分析很简单。这样就不用我去死啃分析模式这本晦涩无比的蹩脚英文书了。
嘿嘿，我这个人看书还是喜欢看学院派写的书，到底是专业写书的人啊。技巧不会有问题。可惜工程派写书内容好，就是文笔不好。国内刚好相反，学院派写书和翻译书就是怎么让你不懂怎么来，他们可以真的以为只有看不懂的书才是有内容的书。

我上传一个试试看

color uml原来是业务建模的基础设计方案啊，谢谢大家分享

嘿嘿，也不是只针对业务建模。其实它可以应用在很多地方，你看看就明白了。非常有意思的想法，启发了我想到很多东西。