敏捷软件开发之特性驱动开发FDD介绍

• 持续集成Continuous Integration.

• 对领域（业务）对象建模Domain Object Modeling.

• 按特性开发Developing By Feature.

• 类的所有者Individual Class ownership.

• 按特性组织团队Feature Teams.

• 源代码控制Source Control.

• 汇报/结果可见性Reporting/Visibility of results

 

观点汇集：

1.在FDD中，它认为： 只有良好定义的并且简单的过程才能被很好地执行。

2. 不过FDD由于必须有2个关键的人物—— 首席构架师和首席程序员，因此门槛并不低。同时由于FDD的客户参与度可以做的很高，那么团队的文化很容易受到其客户的文牍主义的影响。 并且由于 FDD 的前期工作可能会很长，因此也很容易被人们搞成一场打着敏捷旗帜的重型方法会展。不过好在如果你提前意识到这三个方面的问题，它们就可以预防。

 

Ozzzzzz：

首先FDD没有强求你使用color UML，但是我实在找不出比这个方法更加简单明了的领域建模的方法了。 问题领域内被认为存在四种类的模版，粉红的 Moment/Interval, 黄色的 Role ，绿色的 PPT （ Party,Place,Thing ），蓝色的 Description 。而 Domain Neutral Component 是一种在业务系统中反复出现的模式，用我的话来说就是什么人在一个什么时间以一种什么身份做什么样的事情。我相信有的人可能不知道什么是名词，但是他也能把一件事情按照上面的格式来表达。当初我曾经交给我的客户使用CRC卡片建模，他们并没有觉得有什么复杂。而当我给他们color UML的时候，客户觉得比CRC还简单明了，并且感觉自己也可以做一个程序员。

 

而 Feature——

 

同时我们会发现 如果长期使用 FDD 在一个领域或者几个相关领域进行程序开发，那么领域模型会愈来愈固定，而以此为基础的人员会愈来愈成为某个方