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

面的专家。同时更多类似的Feature，会频繁的出现。以至于当你仅仅使用以前的Feature就可以分析出现在的客户业务存在的问题。也就是说使用color UML和Feature不仅仅可以对需求进行整理，还可以对业务进行整理。

 

而且如果你够敏感，你会发现FDD被称为Processes。确实FDD第一次的使用就是在一个大型的项目，并且最后结果很成功。并且就 如同 Lean 一样， FDD 这里大型项目的例子非常多 —— 无论是从代码的数量，需求的复杂，参与的人员数量，进行的时间，这些方面来说大型项目并不是 FDD 所欠缺的。而在小型和中型项目上，FDD由于可以很好的记录经验，也可以取得很好的效果。同时 由于 FDD 的过程太少了（才 10 页 A4 ），因此很少有人有对他做裁剪的欲望。同时这个方法使用的技术也够简单明了，也很少能够被人所非议是不是不容易学习掌握。不过确实FDD的内容没有包括SCM和coding方面的内容，但是你可以结合XP的持续集成，TDD，重构来完善他。而且由于Feature的结构统一，以其为基础构造Test Case是更有指引性。况且由于FDD使用温和的代码责任，你也不会产生过分重构的问题。而由于Feature的粒度统一，对于控制check in和check out也方便，因此至少做到每日构建是容易做到的。

 

colorUML其实可以用一句话来表达。

任何的需求（其实任何的事情）都可以表现为 :

什么人（或者事物） 在一个什么时间（或者什么时间段） 以一种什么方式 做了一种什么样的行为。

 

当然你还可以使用不同的时态来构造这个表达。其实这是我们语言上陈述句子的基本形式，当然你可以使用oo的方式来构造。不过我觉得fp的基本要素也孕育在其中了。也就是说这个基本的模式，其实oop和fp都是这个基本现实形态的一个投影。

 

开发一个全面模型

Jeff De Luca认为，与其它敏捷方法相比， FDD 在初始阶段（开发一个全面模型）允许项目团队掌握整个项目，以便回答诸如“项目还剩多少没完成”之类的问题：

 

如果我们完全是纯粹的增量迭代开发——即仅限于迭代内的需求与分析——那么，我们当然很难回答“整个项目我们进行了多少”，以及“项目还有多少没完成”。因为我们还没有浏览过剩下的需求呢。所以一开始一定要做一些信息收集或分析活动，以便我们了解并设定可以跟踪和反馈的基线，这样我们就可以回答上面的问题了。 FDD 是唯一一个能够正确做到这一点的敏捷方法。

 

在这一阶段的这个问题上可以看作是 大量预先设计（ Big Design Up-Front ， BDUF ）：

并不是做BDUP那种被人鄙视的“全面预先设计