《特征驱动开发方法》

谈谈自己的看法
对于XP和敏捷建模, 我觉得对于中国的企业来说完全照搬是肯定不合适的.

对于中国的程序员和开发团队, 我觉得其XP和敏捷建模是对程序员和开发团队自身的要求, 他们教导程序员如何去对待程序, 如何对待团队,  特别是敏捷建模的五个原则, 我觉得有种教人如何做人的程度.

所以就xp和敏捷建模而言, 应该成为对程序员的要求, 当然也有所取舍.
在我离开原来的那个公司前, 在公司内部的开发规范中的对程序员的要求中, 我基本引入了敏捷建模的五个原则, 我不打算在整个项目中引入他们, 但是就程序员个人而言, 这些应该是对他们的基本要求.

对于TDD
我不太支持把测试提到这样的高度, 倒是如何程序员从这里面学习和了解到测试重要性, 到也不错. 测试还是应该的, 在我自己的开发规范中, 我对单元测试定义了这样的一些原则
a)对关键代码进行测试
b)对接口代码进行测试
c)不要对一目了然的代码进行测试,比如说get和set方法
d)不要对系统或相关软件自动生成的代码进行测试
e)不要对jsp文件进行测试
对于主要的代码, 还是应该测试的, 对于其他的我同意dlee的意见


FDD
还没有了解过, 现在就去了解, ^_^   希望真的能够具体实施起来.

呵呵，我并不是反对做单元测试（这里我说的单元测试不是严格意义的单元测试，与 XP 的自动测试基本上是一个概念），只是觉得它的效果还应该通过 Code Review 等其它措施来加强，但是单元测试是客观的（自动化的），Code Review 的主观因素（责任心、能力）很大。单元测试是一个非常重要的问题，绝对不是可有可无的。因为它是保证 XP 运转起来的关键。如果没有单元测试，也无法确信重构没有损害原有功能。完全依靠用户测试效率低下而且与测试者的责任心、对业务的理解程度关系太大。这一点在我们以前的一个项目中出了很多问题，正因为测试不足妨碍了产品质量，造成后期绝大部分工作是在查找并修改 bug，而不是添加新的功能，直接导致了成本的上升。
开源软件开发有一个基本的驱动因素“搔到了痒处”，我们现在也是觉得提高质量是一个必须要解决的迫切问题了。
所以我们马上也要做自动测试和持续集成。我正在读 Kent Beck 的《Test-Driven Development》，建议其他朋友也读一读。做好测试最重要的是要有一些如何做的指导，如何使用 JUnit/HttpUnit/Cactus 相信大家的能力都可以轻易掌握。

XP 和 FDD 很接近，我们可以组合这两种开发过程的最佳实践，创造出符合企业自身特点的开发过程。过程很大程度上属于管理的范畴，管理是不可以移植的。以前 linuxtea 的 joe 推荐《麦肯锡方法》和《麦肯锡意识》两本书，我读后觉得受益非浅，建议大家找来一读。

《麦肯锡方法》和《麦肯锡意识》刚好我也读过, 虽然不是和软件开发相关的书, 但是也很不错, 值得一看.

dlee我想我的上一贴中并不说你反对做单元测试. 哈哈, 解释一下.

我感觉在现在推出的软件工程中, 有一个部分包括xp,敏捷建模,TDD等等, 都把软件开发中的一些方法和概念用到了极端, 我自己不是很提倡这样作. 

要想使用这些软件工程, 对于个人的要求很高, 首先你要理解他的思想,他所提倡方法, 而且要真真用到实处. 我想提出这些方法的大师都不会说为了作这些方法而实施这些方法, 就好像我们说不能为写文档而写文档一样, 最后做完了, 对后续的工作没有什么意义.

所以我觉得对于中国程序员来说, 应该的是学习其中提到的各种方法和思想, 并结合实际工作作出取舍.
比如说:
测试, 测试在实际工作中是一件非常必要的事情, 但是为什么测试, 测试什么, 怎样测试, 测试要到达什么结构, 就需要向TDD和XP学习了. 对于重构等等也是这样.

自己建议所有从业2年以上程序员可以把dlee和ozzzzzz提到的相关的方法好好看看.

我上面传了color uml。其实简单的要命，可是我觉得它给我分析问题的思路做了很大的扩展。我相信大家用几个小时读读就可以明白，其实类之间还可以建立这样的联系。之所以我喜欢，就是因为它简单，根本就不用我们花费太多的时间去学习。我想以大家的英文水平，看一章1个小时就足够了。第六章是说FDD的可以不看，因为有dlee推荐的那本。关键看第一章。说实话我第一次看根本就没有感觉，懂是都懂了，就是不知道有什么价值。当时还认为这么简单的东西就写一本书，还开发一个together是不是有些小题大做。最近才忽然想明白，原来这东西还可以有这么大的功效。而我觉得其实如果我仔细研究问题域，我们还可以对这个模型作扩展。

精彩的讨论!!!

coloruml  应该还有2个附录和java代码的样例,哪位仁兄能找到,恳请也上传一下.

最近花了点时间看了一下colorUml的书,还看了coadletter 的文章.
http://community.borland.com/coadletter/ 
觉得color uml确实是个非常有实际指导意义的分析方法. 但具体实现时,
还是有很多疑惑,主要一个障碍是看不到代码级的样例. 
     o6z 或其他仁兄, 能否则再贡献点colorUml的使用心得体会.

tuti
为什么你需要代码级的事例呢?这个问题很奇怪是不是?
colorUML是一种分析方法,可以算作分析模式,产生的是分析模型而不是实行的代码.这个分析模型需要你做适应具体环境的改造,比如你应用donet和就j2ee实行同样一个分析模型最后的结果就完全不同.同时由于各自不同的设计重点不同,你的实现方法也不同.而且由于分析模型反映的是人们对于事物的认识,所以很多情况下这个分析模型在不同的人分析相同问题的时候得到的结果也不同.

colorUml的分析结果，是以uml的class图方式呈现的，这让我自然联想到，
class图所对应的代码框架。《分析模式》明确指出了分析模型和实现之间的区
别。colorUml的class图,给我的印象是分析的结果，就是领域模型的代码骨架。这也是colorUml给我一个疑惑。

      即便colorUml只是分析模式与具体实现无关，实际应用中也会产生存在分
析模式如何去实现的问题。如果认同源代码就是设计的理念，代码能更准确的反
映设计意图。colorUml一书在我看来，象是一本研究成果总结，而不是学习向
导。从书评上看 说好说差2极分化很严重，我觉得可读性并不很好。在学习和使
用中，没有代码样例可以参照，起码对于我个人来说还有些困难。

如果大家觉得不好懂colorUML,我可以准备一个讲解性的东西.不过我觉得只要做出了分析模型就算尽到了它的责任.我看不出类图和源码之间有什么区别,而分析模型如何实现为设计模型,则纯粹是一个艺术化的设计活动.类似的方法学上的方法唯一我知道的就是RUP的那个健壮分析,我不觉得这个分析方法好,无非只是为CASE找到可以一个使用的途径.

搬个板凳来准备听o6z来讲