第四周

* 由于客户对我们选用的应用框架（application framework）仍有疑虑，应客户要求，我们公司找了一位有着非常丰富的开发经验的、并且在我们目前所用的应用框架（application framework）上做出过系统的技术权威向客户解答他们的问题。
* 新来的技术权威是位敏捷方法（agile methodology）的热心者，我们在他的建议下准备采用类似XP的过程，首要目标是向客户，也是向我们自己显示出我们能出活（we can deliver）。周一下午，全组开了一个两小时的会议：
o 确定了要实现的一个很基本的功能，该功能其实大部分的编码已完成。
o 围绕这个功能，分解出若干需完成的任务，如：源码审查（code review），源码修改， 单元测试，建立“哑”（dummy）后端以作为初步功能测试与集成，找一台空机器以作 系统建造与演示，等等。
o 大家根据自己的特长与兴趣来“瓜分”把这些任务。
o 根据每人对完成自己任务所需时间的估计制订出工作流程与进度，以0.5天为一单元。
o 根据进度表，“交货”时间为下周四中午12:00点。届时，我们需提供一份release notes， 上面将列出系统安装的步骤。按照这些步骤，我们需要：
+ 在一台只有操作系统的空机器上建立运行系统所需的环境；
+ 编译源码并安装系统；
+ 运行系统并演示所完成的功能。
* 因为下周一周二放假（庆祝女王登基五十周年），时间非常紧迫。大家开足马力，开始工作。

第五周

* 尽管大家尽了大努力，星期四的期限没能完全达到，其主要原因是系统安装上有些没预料到的 困难。但终在星期五中午完成了所有的要求并进行了系统演示。
* 星期五下午全组会议，主要是对这一周期中的开发过程进行讨论，特别是那些感到困难的事情。 大家发现以下这些任务花的时间比预想的多：
o 熟悉应用框架和系统架构；
o 建立“哑”后端服务系统以作测试环境
o 建立单元测试
o 系统安装。

第六周

* 根据上周的讨论，编码标准（coding standards）进行了更新。
* 对第二三周所作的工作重新进行了讨论并制订了新的进度表。这个周期的工作其实包含了 三个use case（或“故事板”），每块“故事板”基本上由两个人负责。其他人则主要完善 单元测试框架及建造“哑”后端系统。
* 本周工作中发现，有一处设计/模型需修改以适应新的功能。多数人被吸引到讨论中并提出 了若干方案。我提出用一种“角色模式（role pattern）”，因为我认为它非常适用我们 现在的情形。

第七周

* 关于修改模型的讨论继续，后是决定采取一个简单的方法（虽然hacking的味道很重），这主要是考虑到系统的特点和“简单性”原则。（有趣的是，我离开项目组后，有位同事做后续开发，又来和我讨论role pattern，并且决定使用一种更复杂的role pattern）
* 本周的开发工作中也发现了“故事板”的一些问题。因为“故事板”不是精确的规范说明，因此在编码时会遇到一些含糊不确定的地方，需要询问用户或business analyst。
* 由于新的class naming conventions（取名规则），对有些部分的源码进行了重写。这是件很花时间与精力的事情，特别是要非常仔细（据说有些IDE支持这种工作）。

第八周

* 由于发现了一个utility class的潜在的问题，大家同意需要用新的方式来使用这个class，并对现有的源码进行核查及修改。
* 在一个模块的编码和单元测试基本完成之际，令人恼火的是发现描述这个模块的“故事板” 还在更新，而这个“故事板”在我们决定开始干这个模块之前是已签发（signed off）了的。没有办法，只得重读这块“故事板”，并对源码以及单元测试进行相应的修改。

第九周

* 这周的主要工作是在“哑”后端服务系统是建立新的“哑”功能和数据，以便能对新开发的模块进行“集成”与功能测试。这实在是一件太花时间的活。

第十周

* 非常不想看到的需求改变又来了。又是重读新的需求说明，修改相应的源码。而在与业务分析员的讨论中，又发现我们对一个“故事板”中的一处功能有不同的理解。后，当然是得根据业务分析员的意见，对源码进行修改。
* 后，终于作了源码审阅，并根据审阅者的意见对源码作了整理，然后整理出设计文档。把这些源码与文档传给在客户那边的同事们去和真正的后端服务系统连接并测试。

第三至六月

第3－6月基本上是顺着第6－10周的路子走，但也有一些明显的变化：

* 系统调试。建立“哑”后端作测试被认为有些不值得，因为花的时间太多。后两个月的做法是等一块“故事板”在我们这边完成后（编码、单元测试、源码审阅），派一个或两个人飞到客户那边去待3－5天作系统调试。这样的花销也很大，但客户似乎并不十分在意。
* 源码质量。源码中需“重整”（refactoring）的地方被不断的查找出来并写入到文档中，编码也在不断地增补，源码审阅变得比较正规，并有一份专门的文档。审阅者对源码进行审读后，需列出需修改或进一步说明的地方。程序员需对每一处进行相应的修改或说明，签名后交给审阅者签名确认。审阅的标准主要是编码标准和源码“重整”（refactoring）文档。
* 进度规划。随着开发的进展，对每个新的“故事板”的规划和进度表制订越来越精确。