对比XP及FDD两种开发方法.doc

在过去十年里出现了许多敏捷软件开发方法，这些方法都希望来代替传统的瀑布式开发模型。在瀑布式开发模型中，软件开发被分成一系列阶段，包括：
l         收集用户需求
l         系统设计
l         开发
l         测试
l         部署
瀑布式开发模型基于这样的一种假设，就是：开发过程的每个阶段在下一个阶段开始时都是百分百的完成。这也导致了瀑布式开发模型的一个最大的缺点：设计上的错误往往必须到程序部署时才能发现，而此时项目都已经接近尾声，修复错误的代价是巨大的。
XP和FDD都是希望通过迭代式开发来避免瀑布式开发模型的缺点，每次迭代都意味着在较短的时间内（通常是1－3周）完成上述的所有的步骤，这就保证了即使设计时有错误，也能在开发的早期发现。

1.       eXtreme Programming
XP最初是作为尝试简化和提高软件开发的一种开发方法。大部分软件项目开发都被看作是小心翼翼实现用户的需求，而XP的重点在于强调用户的满意。
XP项目一开始就是收集用户素材（User Story），用户素材由用户编写，是一段与技术无关的文本，其目的在于提供一些特殊场景的详细描述，而不是用来估计系统的复杂性。用户素材的所有细节必须在它实现之前得到客户的确认。
紧接着就是制定发布计划。发布计划确定在系统的哪个发布版本中有哪些用户素材需要实现。每个发布版本都要经过好几次迭代，每次迭代实现一些用户素材。一次迭代包括如下阶段：
l         计划：选择要实现的用户素材及其要明确的细节
l         编码：实现用户素材
l         测试：至少每个类都要有相应的单元测试
l         验收测试：如果测试成功，新功能开发完成；如果失败，则进入下一次迭代

XP的精华主要在于：
l         简单：设计最简单的，可以work的方案。大部分项目中，开发人员往往把大部分时间都浪费在设计一些通用的解决方案上，以期适应将来可能变化的用户需求、运行平台等。要知道有时大部分变化并不是按开发人员最初想象的那样变化。
l         沟通：这既包括开发人员之间的沟通，也包括开发人员和客户的沟通。沟通是成功的关键，因为常常会出现开发人员对用户的需求不了解或误解从而造成开发的系统与客户期望的不一致。
l         测试：测试是XP的基础。XP的实践是每个开发人员可以在任何需要的时候修改任何代码，如果引入了BUG，单元测试应该能够理解捕获BUG。

2.       Feature Driven Development
FDD是由Jeff De Luca和Peter Code提出来的。FDD在需求和开发步骤上要比XP更加正式，而且还具有精确跟踪进度的能力。
FDD开发过程主要包括这样两个阶段：
l         确定待实现的特征集
l         一次实现一组特征
确定特征集是一个非常严格的过程。这一步质量的好坏会影响项目被跟踪的准确性，代码具有可维护和可扩展的能力。这个过程需要客户全职参与，这个过程的产品是一组描述问题域的UML图。
从UML图中产生一系列特征，这些特征再以客户和开发人员都能懂的语言描述。举一个购物车的例子：客户要登录在线商店去购买货物，UML图可能包括这些类图：购物车类、物品项类、客户类。这个UML图的特征集可能如下：
l         为客户创建一个购物车
l         增加一个新的物品到购物车
l         列举购物车中的物品
l         计算购物车中所有物品的价格
这些特征对用户都是非常有价值的，因为它直接反映了这个软件所应具有的功能，这些特征的粒度也是足够小，可以在一次开发迭代中就能完成。
特征实现工作开始之前，先给相关特征分组成一个个工作包，一个工作包应该能在一次迭代中完成，通常需要1－3周。每次迭代的内容包括：
l         工作包的启动会议：详细描述被包括的特征
l         设计：创建必须的类、方法以及相关文档
l         设计评审：对提供的设计进行评审，或者接受，或者拒绝
l         开发：实现并进行单元测试
l         代码评审会议：执行代码同级评审
l         发布会议：将已实现的特征进行集成

3.       Vision Statement
无论是FDD，还是XP，都是轻量级的软件开发方法。使用传统的软件开发方法，项目一直无法很好的管理，是因为里面有太多的规则需要去遵守。而FDD和XP都仅仅包含了传统的瀑布式开发过程的活动子集，虽然二者选择的活动子集是不一样的，这就决定了这两种方法有不同的适用性：
l         XP更适用于不稳定的项目，用户的需求可能是很不明确。XP对这类项目能够很好的处理，因为它有意的将那些当前不必要的活动推迟到后面的阶段
l         与FDD相比，XP适用于小规模的开发。因为XP很大程度上要依赖于项目组的沟通，然而，团队越大，沟通会越困难
l         对于FDD来说，如果需求比较稳定的话，它具有很好的预见性
l         FDD能够跟踪项目的进度，这对于许多公司中的项目开发是非常必要的

二、        收集用户需求
本章主要阐述软件项目中用户需求收集的过程。传统的用户需求是写在文档上，并对待实现的系统进行了详细的描述，并作为后续开发阶段的重要依据：
l         必须实现该文档上所有列举的需求
l         比较该文档和实际开发出来的系统来进行验收测试
用例，使用场景，非功能性需求以及许多其他方法都被用来描述用户和系统的交互，以实现用户的需求。
这种方法的主要缺点就是事先收集完用户的所有需求，然后客户就停止了参与。这样，一旦用户需求有错误或被误解的地方，只能等到项目的后期才能发现，这时要修正，其成本已经变得很大。
XP和FDD收集用户需求都不同于传统的用户需求收集方法，不过二者也有很大的区别。

1.         XP：收集用户素材（User Story）
XP在收集用户需求工作中花的时间相当少。用户的需求都以很短的故事形式表达。这些故事的目的仅仅是理解项目的范围，并能较正确的估算出实现所需要的时间。用户素材的收集过程很大程度上要依赖于具体的项目，一般不超过两周时间。在每一次发布计划中60－100个用户素材就足够了。每个素材的细节将在每次迭代计划会议前同客户一起讨论清楚，这种轻型的用户需求的收集过程能很从容的面对变化。

2.         FDD：构建问题域
然而，对于FDD项目来说，收集用户需求过程是非常重要，是项目成功的关键，所以这个过程我们通常叫他“Process One”。Process One的工作产品是UML图和一组特征集，UML图定义了软件系统的问题域。这个过程如果能被很好的实现，它应该覆盖了大部分业务，而且也容易在后续的版本中增加新的特征。产生的特征集也成为了项目时间范围的基础，这样就可以容易的跟踪项目。因此，FDD对用户需求的依赖程度和瀑布式开发一样。既然需求收集过程这样重要，我们就可以更好的改进这个过程，让开发人员和客户充分参与这个过程。
这个过程要求开发人员对UML要熟悉，同时，客户代表和领域专家都必须参与。建模过程可以使用UML in color，这是Peter Code引入的UML的一个变种。
建模本身也是需要多次迭代的，每次迭代都以一个业务片断的用户素材开始。开发组可以分成几个建模小组：每个小组都包括开发人员和领域专家。每个组都使用UML建模，表达相同的用户素材。各个小组可以随时演示和讨论自己的模型。在迭代的最后，从这些模型中选择一个更好的模型。这个建模迭代过程可以一直持续到反应所有用户素材的整个问题域模型完成。
好的问题域模型应该完整覆盖了客户的业务，它应该很稳定：用户对应用程序的需求可能会变，但业务应该是不变的、稳定的。除了建立业务的面向对象模型，Process One还能间接的看到开发阶段所持续的时间。FDD的拇指规则是这样说的：两周的建模应该可以让开发团队进行长大6个月的开发工作。

三、        设计和文档
XP把这个过程给跳过去了。用XP进行开发的人员建议用程序来反应设计，尽可能少的写文档。
FDD也没有要求必须写设计文档。在Process One之后，开发人员往往会把UML图的描述和一些备选方案文档化。这样文档在后期可能有很大用处，尤其对于一个开发周期比较长的项目，开发人员往往忘了最初设计的初衷，文档这时可以起提醒的作用。如果客户要求的话，正式的用户需求也可以写在这个文档中。
不过FDD要求许多正式的文档，其目的在于设法使项目的信息得以公开。这些信息可以放到公司内部网上，公开的信息可以是：开发人员列表，赞助者和领域专家，UML模型和注释，代码规范，使用的工具，单元测试报告，进度报告等等。

四、        开发和测试
FDD和XP都是以短迭代进行开发的。本章就阐述这两种开发方法迭代的内容，主要是二者在开发实践中的区别。
FDD和XP首先在团队组织上就有不同的结构。FDD需要几个CP（chief programmer），并要求CP在团队中具有丰富的经验，能够担当技术领导者的角色，同时能够承担其他一些责任。在团队的层次组织里，CP应该居于项目经理和开发人员之间。不过在XP团队里就没有这种层次结构了。

1.         迭代计划
两种开发方法都是以正式的计划会议作为迭代的开始，不过在执行的活动上略有区别。
1)        XP计划
首先客户选择一组待实现的用户素材，开发团队同客户一道就用户素材的细节进行讨论并确定清楚，然后以开发者的语言重写用户素材，并估计出这次迭代所需要的时间。对于前面一次迭代中出现的BUG和失败的单元测试，可以加到本次迭代的任务中。
2)        FDD计划
CP首先准备迭代计划会议，将适当数量的相关特征组织到一个工作包中。通常一个团队都有好几个CP，每个CP都单独负责一个迭代。每当新的迭代开始，CP根据情况选择开发人员组织一个迭代小组，然后每个开发人员负责一些特征集。在FDD中，强烈建议代码负责制。整个团队最后完成了所有要迭代的特征集，如果需要的话，开发人员应随时和客户联系来确认模糊的特征。遇到复杂的情况时，团队还需要画时序图。计划会议还需要对迭代里程碑建立时间约束。
3)        二者区别
主要的区别是在XP中，迭代在整个团队范围进行，而FDD是组成一个由3－5人组成的临时小组来负责每次迭代，所以FDD的一个优点是：因为团队小，沟通非常方便。
XP中的迭代具有自我调节的特点，每次迭代出现的bug可以等到下次迭代去修复，失败的单元测试可以在下次迭代中设法使它通过。这样，如果一次迭代中选择的用户素材过多，无法完成时，会延续到下一次迭代，导致下一次迭代就不会增加太多的用户素材。
FDD有两种比较好的机制做保障：
l         CP的丰富经验
l         如果某个开发人员完成不了任务，也不会降低整个开发团队的进度，因为其他团队在并行进行
XP在整个迭代期间没有明确的阶段划分，每天的活动好像都差不多。而FDD不一样，它有许多里程碑：
l         迭代计划会议
l         设计阶段
l         设计评审会议
l         编码阶段
l         代码评审会议
l         集成
FDD允许我们能非常好的跟踪整个迭代过程，尤其是迭代的周期较长（如3个星期）。然而，如果迭代周期非常短（如一周）的话，频繁的会议所增加的管理成本会显的很高。

2.         设计和评审
XP没有正式的设计阶段，设计一般只在迭代开始以及后来需要的时候进行。
FDD有设计阶段和设计评审会议。在设计阶段，开发人员声明待实现的特征的主要类，方法以及属性，并最好以代码注释的形式文档化，想java doc那样。当设计结束后，团队中的每个成员都可以拿到别人设计的副本进行评审，大家可以在设计评审会议上对彼此的设计提意见，不过为了节省会议时间，评审工作应该在会议前就完成。
FDD设计评审会议旨在发现在迭代中一些错误的决定，以免整个迭代偏离方向。如果每个成员的设计都没有问题，那么可以进行开发了。为防止评审会议规模过大，建议迭代团队应该尽量小，包括CP在内，最好不超过5人。FDD的一个好处就是产生一定量的代码文档。
XP不相信代码文档。虽然XP没有特定的设计阶段，但是其开发过程还是在每天的会议中得到控制，而且，结队编程也防止错误设计的风险。

3.         编码阶段
XP和FDD都非常关注这个阶段，尽管二者的过程有很大区别。他们都很强调编写标准的代码，这样开发人员在阅读彼此的代码会更加容易，代码也不容易出错，代码评审效率也会提高。
XP和FDD也非常强调单元测试，测试代码既可以在编码之前完成（TDD），也可以在其之后完成。XP强烈要求先写测试代码，后完成编码。而FDD则没有这种要求，只要对应每个类都有测试用例就可以了。
1)        XP中的编码
XP只认代码，XP的编码过程包含了许多活动。最著名的莫过于XP提出的结队编程，两个开发人员坐在电脑前面，一个在写代码，两个人都在思考。乍一看，好像在浪费时间，实际情况却相反。原因如下：
l         在编复杂的代码，两个人可以随时进行交流
l         编码的过程也是代码评审的过程
l         这样会使经验比较少的开发人员成长的更快
l         人们往往要花点时间在别的事情上，如读邮件，浏览有些网页等
XP倡导重构。重构就是在不改变功能的情况下，提高代码质量。
XP拒绝代码责任制，每个人的代码其他人都可以修改。通过浏览和修改别人的代码有时会增加开发人员对系统的全面理解，如果某个人离开了团队，也不会造成很大的影响。当然，必须要限制的是：没有读懂别人的代码是不允许对其进行修改的。
2)        FDD中的编码
FDD中的编码就没有XP那样令人激动和富有挑战性了。因为在编码开始前，待实现的特征在Process One过程，迭代启动会议，设计评审会议中已经有充分的讨论了。类和方法完全都定义完成，它们都在代码文档中被详细描述，编码基本上就是机械活动了。
与XP不同的是，FDD不赞成重构。对重构的主要争论就是人们认为重构花费了时间却不会给客户带来一丁点的价值。代码评审会议应该确保代码的质量。
FDD强烈建议代码责任制，其主要理由是每个开发人员熟悉自己的代码，能够更好的面对一系列的变化。
那团队成员离开了该怎么办？FDD从以下几个方面提供保障：
l         足够的代码文档，这样理解别人的代码就比较简单
l         开发人员一般都比较了解别人代码主要做什么，因为他们都参与了设计评审
l         在代码评审时，开发者能够阅读到别人的代码

4.         代码评审
代码评审有这样几个重要的目标：
发现代码中的错误。代码评审就是象单元测试那样去发现代码中的错误，尤其是进行单元测试比较苦难的代码，如UI，发现代码错误主要靠代码评审
l         强化代码规范
l         使经验不足的开发人员得到快速提高，分享最佳编程实践
l         使开发人员熟悉彼此的代码
FDD有一个正式的会议，叫“代码评审会议”。在迭代过程中，每个开发人员打印出自己的代码，然后分发给其他的成员。代码评审应该在代码评审会议之前开始，会议本身应只用来讨论提出的问题并提出解决方案的。
在代码评审方面，XP和FDD都各有自己的优缺点：
l         在XP中，代码评审在结队编程时完成
l         在FDD中，代码被多人评审。因为通常来说，在结队编程中，一个人对另一个人的代码进行评审只能发现一些特殊的问题，可能还会存在其他一些问题不能发现
l         FDD中的代码评审与编码实践分离开。这样，如果迭代开发的周期较长，或者团队成员超过5个，那么代码评审将是非常低效的。因为在一次长的迭代过程中会产生大量的代码需要评审，这样代码评审时人们注意力可能会分散，潜在的bug会增多。

五、        部署
在瀑布式开发过程中，部署通常是项目开发的最后阶段，当所有的代码编完并测试完成，部署就开始了。部署阶段可能与开发阶段采用的开发方法没有多大的关系。通常，一些大公司会建立单独环境来进行产品部署、测试和集成。
XP和FDD在他们的迭代周期里都包括部署，不过由于上述原因，一般都不是进行真正的部署到产品环境中。不过，应用需要被集成和运行，到客户那里，由客户使用已实现的特征然后进行反馈。
不过有时有些特殊的情况是持续集成无法继续下去。
XP的实践要求客户代表是开发团队的成员，他们的一个责任就是使用正在开发中的系统。不过FDD不要求客户必须参与，因为FDD的许多规则能够确保及时得到用户的反馈。
六、        跟踪进度
对项目进行跟踪的能力是非常重要的。只有那些小的项目或者内部项目可以不必进行进度跟踪。对于大项目或者外部项目，其进度必须要被跟踪。瀑布式模型的一个特点就是进度跟踪比较粗糙。一般一个项目的各个阶段都要明确给出完成的百分比，以便项目经理可以向上面的管理层进行汇报。新的开发方法在这方面的能力还是比较好的。

1.         XP中的进度跟踪
XP对进度跟踪没有提供什么，它只确保进度是可视的。每次新的迭代增加的新功能都是可以通过用户的验收测试。不过如果要弄清项目到底什么时候完成，XP就比较困难了。一种办法就是比较已完成的用户素材和未完成的用户素材来计算。不过显然这是很不精确的，因为有时在实现一个用户素材中可能又会产生一个新的用户素材。
XP是及其敏捷的，它只适用于那些需求不明确或者需求经常改变的项目，这种情况下，项目完成的日期可能没有太大的意义。

2.         FDD中的进度跟踪
FDD提高了精确跟踪进度的能力，它基于以下两种事实：
l         Process One结束后，所有待实现的特征已经很明确了
l         每次迭代都有一个已定义的周期，给出完成的百分比。如下图
Domain Walkthrough
Design
Design Inspection
Code
Code Inspection
Promote to Build
1%
40%
3%
45%
10%
1%
这样我们就可以计算出项目完成的日期，并生成进度跟踪报告。手工生成这些报告成本比较高，所以FDD项目需要工具能自动生成这些报告。
FDD也面临项目完成日期的问题。Jeff De Luca提到FDD方法允许项目有10%的变更而不推迟项目的最后期限。他认为对软件系统来说需求变化应该不是业务本身的变化。因此，问题域应该一直反映着正确的业务视图。新需求的增加不应该影响已经实现的大部分特征。