第八周
由于发现了一个utility class的潜在的问题，大家同意需要用新的方式来使用这个class，并对现有的源码进行核查及修改。
在一个模块的编码和单元测试基本完成之际，最令人恼火的是发现描述这个模块的“故事板” 还在更新，而这个“故事板”在我们决定开始干这个模块之前是已签发（signed off）了的。没有办法，只得重读这块“故事板”，并对源码以及单元测试进行相应的修改。
第九周
这周的主要工作是在“哑”后端服务系统是建立新的“哑”功能和数据，以便能对新开发的模块进行“集成”与功能测试。这实在是一件太花时间的活。
第十周
非常不想看到的需求改变又来了。又是重读新的需求说明，修改相应的源码。而在与业务分析员的讨论中，又发现我们对一个“故事板”中的一处功能有不同的理解。最后，当然是得根据业务分析员的意见，对源码进行修改。
最后，终于作了源码审阅，并根据审阅者的意见对源码作了整理，然后整理出设计文档。把这些源码与文档传给在客户那边的同事们去和真正的后端服务系统连接并测试。
第三至六月
第3－6月基本上是顺着第6－10周的路子走，但也有一些明显的变化：
系统调试。建立“哑”后端作测试被认为有些不值得，因为花的时间太多。最后两个月的做法是等一块“故事板”在我们这边完成后（编码、单元测试、源码审阅），派一个或两个人飞到客户那边去待3－5天作系统调试。这样的花销也很大，但客户似乎并不十分在意。
源码质量。源码中需“重整”（refactoring）的地方被不断的查找出来并写入到文档中，编码也在不断地增补，源码审阅变得比较正规，并有一份专门的文档。审阅者对源码进行审读后，需列出需修改或进一步说明的地方。程序员需对每一处进行相应的修改或说明，签名后交给审阅者签名确认。审阅的标准主要是编码标准和源码“重整”（refactoring）文档。
进度规划。随着开发的进展，对每个新的“故事板”的规划和进度表制订越来越精确。
讨论与思考
下面的讨论将主要围绕一些XP的实践原则展开。
用户在场（On site customer）
尽管开发组的一部分在客户地点，但主要的开发工作却是在公司本部进行的。这里没有用户，没有业务分析人员。这点显然与XP的原则相违背，而其造成的不利影响贯穿于项目始终。首先是对制订计划与进度表的影响。一般来说，在制订计划之前，开发人员需要花一两天读一个“故事板”，然后作出初步估计。故事板简单易读，能使人很快地大致了解一个功能模块的需求。但是，很多地方比较模糊，有些地方在阅读文档中仔细一点就能看出来。这时最好有用户/业务人员在场，马上就能澄清。象我们靠电话和email，时间花的多，还不见得能说得很清楚。
第二个影响要更严重一些。“故事板”中的不确定性有些在读故事板时能发现，而有些就只能到了编码的时候才能暴露出来。由于业务分析人员在客户那边，只能靠电话和email，其质量当然不如面对面的讨论好。特别是当不能及时得到答案而时间又紧迫时，程序员往往得靠经验和“推理”作一些假定。如果是错的话，就只能在功能测试和用户接收测试时再改了。
另外一个类似问题是与后端系统通讯的规范说明，这是由另一个项目组提供。那么我们与他们之间也是有个沟通的问题。而糟糕的是该项目组也是在客户那边，因此只能靠电话和email。总之，我觉得这个项目的实践是从反面证明了用户在场的重要性。
制订计划与进度
如上所言，制订计划和进度表是从阅读“故事板”和规范说明开始。经过若干电话与email的往来后，制订出一个计划，主要是把需完成的模块进一步分解成一些任务，以及估计完成每个任务要花的时间，以0.5天为一个单元。该计划是一个spreadsheet文件，放在项目的文档服务器上，大家随时可查看。
“并行开发”
我们的项目有一点和正规的use case driven的过程不太一样。一般是一个周期主要是做一个 use case。在我们项目中，一个“故事板”大概算一个use case。如在“工作笔记”中所言，在项目走上“正轨”后（从第六周开始），一般是2－3人做一个“故事板”。所以，一般同时可能有两三个“故事板”在进行。每个“故事板”的周期约3－4周。这样做的好处是提高了生产率，但我觉得这样做的前提条件是每个开发人员必须是有足够的经验与技能，还有就是熟悉开发过程（第4－5周的实践是非常重要的）。
单元测试
单元测试是客户的一个要求。在前两个月，我们做还有些“过分”。我们是用NetBeans提供的工具对每个类（class）都生成相应的JUnit测试类（test class）。对一个类而言，其中的每一个 public和protected method都在test class中有对应的一个test method。而这个test method 里只有一个fail语句。这样强迫你用测试来替换这个fail（当然你也可以把它删掉）。结果我们发现花了很多时间去写getter和setter的测试，实在不值得，因为这些methods非常简单。我们因此说服客户，允许我们不用对getter和setter些测试。不过，我倒是发现，对 getter的测试，实际上是在测试相应attribute的初始值。设置初始值常常被忽略，而会在运行中引起一些问题，如最常见的NullPointerException。
单元测试通常要求把被测的对象孤立起来，即测试不要用到其他的类。而实际中，一个类往往要用到其他的class提供的服务来完成自己的功能，最常见的如使用数据库或一个远程服务。单元测试需要切断这种依赖性，即一次只测试某个我们需要测的类。这可以利用Mock Object （“模拟对象”）技术来达到，例如，用一个mock service来代替真正的service，而我们可以很方便地对这个mock service进行状态设置。在我们的单元测试中就大量地运用了这种技术。网上有一些工具可用来帮助产生mock objects，如MockMaker，可以节省一些时间。
总的来说，单元测试的确提高了源码质量。那些逐步建立起来的test cases，我感觉是起到了一张 “警戒网”的作用。源码修改需要作改动时，这种作用特别明显。不过，我们也注意到，对一个类进行完整的单元测试所花的时间往往不少于编码的时间。因此，一个很重要的问题是决定测试到什么程度。XP的建议是对“可能会出问题”的地方要重点测试。但什么是“可能会出问题”的地方则需视具体情况而定。
系统集成与功能测试
由于我们这里没有一个真正的后端系统，因此没办法作真正的集成与功能测试。在项目的前半期，我们曾建立了一个“哑”后端，这的确对我们的测试/调试起到了很大作用。但是，当越来越多的功能加入后，“哑”后端变得越来越负责和不可维护。最后，我们只得放弃这种做法。
项目的管理层曾作了很大努力，想使我们这里能直接连上客户那里的后端系统，这在技术上是完全没有问题的（毕竟这是网络时代）。但不幸的是，这个合理要求没能得到满足。所以项目后半期，当一个“故事板”的的编码与单元测试完成后，一般由编码者或测试者飞到客户那里去做集成与功能测试。
结对编程（pair programming）
在我们这个项目的实际中，pair programming与“传统”上的意义有些不同。首先，因为我们坐得都很靠近，如果某人有什么问题，只要一叫，一般就会有人跳起来跑过去帮忙。这可算是一种 “基于解决问题”的pair programming。
另外一种更主要的是方式是编码与单元测试的结对。由于测试者对于如何使用一个（待测试）的类一般不会有着与编码者完全一致的思路，这样对于发现问题是很有帮助的。另外，由于测试者一般都会在测试时详细阅读源码并与编码者讨论，这对于改进一个class的细部设计与实现也是很有用的。但这种审阅与源码有所不同，这里主要是着重“逻辑”的正确与有效，而源码审阅则偏重于源码的风格与标准的统一。
还有一种方式可称之为“结对排故”（pair debugging），我发现这种情况多在系统功能测试中出现。如果在测试中出现一个问题（bug），找来找去找不到（因为这时涉及的东西的较多），搞得昏头胀脑。那么最好是抓一个同事到屏幕边上（最好不是和你搞同一个部分的），然后给他讲讲是怎么回事。他可能会一眼看出问题所在（如果他曾遇到过类似的问题），或者会从另一个角度来提供一个思路。另外，常常也有这种情况，来帮忙的可能只是听着，而你在讲的时候可能就自己发现问题了。我想这是因为你在给其他人解释一件事的时候，你实际上是在强迫你自己清理自己的思路，而这肯定是有助于找到问题的（特别是在昏头胀脑的时候）。
编码标准（coding standards）
项目开始的时候，我们就决定采用Sun的“Java Code Conventions”作为我们编码标准的蓝本。随着项目的进行，大家不断地讨论并同意加入一些与项目有关的标准，例如：
所有的classes和所有的public and protected methods都必须要有JavaDoc注释；
对于packages,classes,variables的命名标准；
如何使用集合（collection）类型，如变量的类型需是interface，如Map而非HashMap；
如何使用实数类型，如规定用double而非float；
如何使用logging（我们使用log4j）；
如何处理exceptions，等等
源码审阅（code review）
源码审阅一直是项目的要求之一。但在项目的前半期，这点做得不是很正式。当然，一个主要的原因是大家想尽快地做出一些功能。这样造成的一个后果是源码开始有些杂乱并且不一致。项目后半期开始比较严格地进行源码审阅，并且规定一个“故事板”的源码在进入系统测试之前一定要有正规的源码审阅。
进行源码审阅时，审阅者一般是根据编码标准上所列的条款对源码进行检查，看是否符合标准。同时，也可对一些具体实现上提出自己的看法。这些意见用一张专门的表格一项一项地记录下来，交给编码者修改或给出进一步的说明。最后，审阅者对源码复查，对每一项进行核对，满意之后签字认可。我们的经验表明，这样的源码审阅大大地提高了源码的质量以及可读性和可维护性。另外一个作用是使refactoring得以经常及时的进行。
源码重整（refactoring）
我们项目里，refactoring基本上是与编码标准和源码审阅同步进行的。项目的前半期，基本没有refactoring，尽管有些不好的码段或实现被不断的发现并记录在案。当然，主要原因还是由于大家想集中精力先做出一些功能。在项目的后半期，开始和源码审阅一起较严格地执行。和源码审阅一样，这样做的结果是大大地提高了源码的质量。
以上这些就是对这个项目的一些观察与思考。总之，对开发人员来说，这个项目有许多的不确定性，这主要反映在需求与规范文件上，也反映在相关项目组之间的协调（或扯皮）上。项目组分散两地，测试环境的缺乏都是开发中的很大问题。在这种情况应用XP的实践原则，如密切沟通，单元测试，源码审阅与重整，能有效的（也许是艰苦地）推进项目的进展。
