学生以团队进行开发常常遇到的一个问题便是不知道如何组织一个团队进行工作，不知道如何分工合作，以及如何开始一个项目。而传统的瀑布型的开发方法过于重型，需要产生及维护太多文档。前期工作过长，在开始编码之前已经将大家的热情消耗了很多。目前国内外用于中小型项目的方法多采用敏捷的开发方法，而其中用得较多的是XP（eXtreme Programming）方法。这种方法的特点是对系统进行功能划分，并以此为基础进行迭代开发和增量集成。其优点是，可以让开发人员在刚开始迭代的时候，只在局部上把握系统的分析及设计。而随着迭代的进行才慢慢从总体上把握系统的设计。从而避免了在一开始即面临着分析及设计整个系统的压力，因此也不知如何下手。XP方法的编码过程也十分有利于知识的传播，让开发人员在开发过程同时也学到其他人更多的知识。

　由于XP方法的这种特点，适合于学生使用作为小团队开发中小型软件的方法。而我结合我们学生的特点，在XP（eXtreme Programming）方法的基础上对其做了某些改变，使其更适合于学生使用。该方法以及其中某些建模方法在我们的团队经过实践证明是可行的而且能够给我们的团队开发带来较好的效率。

　由于XP方法强调用户参与与反馈，并根据反馈的信息来确定下一步的开发计划与软件下一步的设计方案。因此，可经常对软件进行演示并评估来获得更多的反馈信息，包括客户以及开发人员的反馈。

　XP开发方法可以以系统用户目标级用例为功能单位，以迭代以及增量集成为原则，逐步将一个个的用例所描述的功能集成到系统代码中，从而最终完成系统的开发。

　　该方法的具体实施步骤如下：

　一． 系统规划阶段

　首先，应用面向对象的用例分析方法，对系统进行分析。得到系统的用户目标级用例的用例图以及用例描述，描述用例时尽量用通俗的语言描述用例的执行次序。然后可将每一个用例作为一个子任务用于安排迭代。关于用例分析方法可以参考《道法自然》一书。

　尽量做到一个用例只描述系统某一子部分的功能。切不要试图使一个用例中包含对系统很多功能的描述。所有这些用例不需要详尽的包含系统的所有功能，可以在开发的迭代周期间对用例进行增加，删除和更改。如果是优先级特别高的增加，删除或者更改也可以在迭代周期内进行。但是刚开始所有这些用例是我们开始的基础，它们至少应该包含系统首次迭代所需实现的所有功能，而且最好所有这些用例能够表达出系统总体上的一个概貌。而且用例描述的功能也可以作为以后验收测试的基准，并可以以用例为单位设计功能性测试。

　然后确定每个用例的开发优先级以及开发次序。并对每个用例所花的时间进行粗略估算。从而确定每次迭代大概要完成的用例数目以及迭代时间。

　二． 迭代设计阶段

　按照用例的优先级以及开发次序在还没有实现的用例中，选出用例，为本次迭代安排迭代任务。安排的用例数目由每次迭代确定的时间和所需完成的用例数目决定。

　不要提前安排下一次迭代的任务，而应该在每一个迭代过程开始之前的迭代会议上讨论并安排本次迭代过程应该做些什么。尽量不要急着去做那些没有被安排进入本次迭代过程的用例。有些用例要安排在下一次迭代任务中完成。因为XP的原则是交流，简单和反馈。经过这次迭代得到反馈信息之后。我们可能需要对用例的优先级或其他信息进行更改，或者删除一些用例，下一次迭代的任务，在下一次迭代之前才知道。

　确定了本次迭代需要完成的用例之后，接下来是进行本次迭代的分析和设计。设计尽量保持简单明了。如果设计过于复杂就想办法用某种简单的东西替代。切记，保持设计的简单易行，不要随意添加功能。不要太早地加入所有的功能，以保持系统的整洁，额外的想法可以在以后加入。而且由于每次我们所需把握的都是表现系统局部的几个用例，所以进行分析和设计的难度相对较低，而且也可以较容易的得到系统简单的设计。

　目前，一般都使用UML建模技术作为面向对象分析及设计的技术，对软件进行分析及建模。建立的模型不必过于详细以及面面俱到，所建立的软件模型记录了目前系统的总体设计原理、类的整体架构、各个子系统间的类架构、调用、产生关系以及关键功能的“顺序图”。如何使用UML进行建模可参考《UML与模式应用》，《敏捷软件开发》，《设计模式》等书。

　如果目前已完成的系统设计适合于添加本次所需实现的功能，并且容易做到。即采用目前的设计，在这个设计的基础上添加新功能的设计，否则对目前的设计进行重构并将新功能添加在其中。一般情况下，后者在前一至两次迭代时可能会发生。因为刚开始时对系统的了解不够深入，随着迭代的进行，对系统的了解会慢慢深入。所以，将会产生更适合于系统的设计，使系统更能适应变化，添加新的功能。这个时候不要害怕对系统的设计进行改变会带来很大影响。因为，每次迭代所需要完成的用例并不多，这样使系统很能够适合于变化。并且刚开始时系统并不大，很容易对设计以及目前代码进行重构。如何进行重构，可参考《重构》一书。

　完成初始设计之后，根据所产生的子系统以及各个可独立编码及测试的单元进行分工合作。分成若干个小任务。这些小任务之间有先后顺序，将小任务分配给每个人。确定编码标准，编码标准详细到每个编码细节的规定。

三． 迭代编码阶段

　考虑到学生的特殊性，我们可能不能按照XP传统的结对编程方式进行编程。但是，为了让小组的每个成员均能够熟悉系统整体的代码并均匀分配工作量。并让知识在开发人员之间传播，我们可以将采用一种称为“接力棒”式的编程方式。即按照排好顺序的任务进行编码。所以第一个开始的编码任务就是第一个小任务，也即是由认领该任务的人接过第一棒，开始编码。在编码之前，每个人均应根据自己任务的需求先写出测试用例，（该测试用例用于验收你的代码是否完成了该任务以及是否有出错以及异常）再进行编码。

　编码过程中，每个人在代码中一定要写足够的注释，让别人从代码中就可以看出代码中类的架构及联系，还有编码的思想。最后让代码有自解释能力。

　一个单元的代码编写完成后用编码前编写的测试用例进行单元测试，如果测试有出错，在改错之后应该增加新的测试用例再次测试，直到确保你的任务没有错误以及异常。然后将代码和测试用例一起存入代码库，两者同时成为系统的一部分。

　执行任务的人要在规定的时间内完成自己的任务，一般小任务完成时间是一到两天。小任务完成后，将完成的功能集成到系统里面并将“接力棒”传给下一个任务的那个人。并向下一个人或者整个团队做开发报告。报告内容可以包括：

　1. 本次你执行小任务过程中所遇到的问题以及解决方法。

　2. 对你的任务的代码做说明以及对关键地方进行解释，但是不必过于详细，因为我们已经有类间的架构以及关系图，同时你又在你的代码中做了足够的注释。

　3. 所采用的技术说明。

　这个过程同时也是促进知识传播以及大家互相学习的一种方法。

　下一个人接过上一个人的“接力棒”，也即接过了整个系统的所有代码。接着开始编码，用相同的过程方式执行自己的任务，直到自己的任务完成，做完开发报告并交给下一人。然后下一个又用相同的过程方式执行自己的任务，这个过程一直持续到本次迭代过程的所有任务都已完成。

　对整个迭代结果完成的系统进行整合测试及优化，看看是否完成了预定的功能以及是否有错误及异常，当有错误时，改进之后要引入新的测试用例，再次测试。本次迭代完成后要对目前已有代码进行重构，关于重构的原则，请看《重构》一书。以相同的过程，进行下一次迭代。迭代一直进行直到小组成员一致确认完成系统，然后对整个系统进行整体测试以及整体代码重构。

　四． 系统整体测试阶段

　对整个系统进行整体的集成测试及最后的代码重构。关于系统整体测试的方法，参考有关的软件工程书籍。而重构方法以及原则请参考《重构》一书。

参考资料：

《程序员》2003合订本

Erich Gamma 、Richard Helm 、Ralph Johnson 、John Vlissides.

设计模式－可复用面向对象软件的基础. 机械工业出版社

Robert C. Martin. 邓辉 译. 敏捷软件开发. 清华大学出版社

　 Martin Fowler. 候捷、熊节 译. 重构. 中国电力出版社

王泳刚、王泳武. 道法自然－面向对象实践指南. 电子工业出版社