项目回顾：一个开发人员的观察与思考

项目背景
这个项目的客户是欧洲一家人寿保险公司。该保险公司目前进行的一个计划是对现有的业务流程（business process）和IT系统进行较大规模的改造，以适应新的市场要求。我们的项目是这个计划的一个组成部分，它的目标是建立一个浏览系统与保险公司的后端保险管理系统相连。这个浏览系统用Web浏览器作为用户界面，以取代目前使用的字符终端界面。 2002年初，公司的有关部门（专门作金融服务）曾作了一些可行性研究工作。项目于2002年四月底正式启动，主要的开发工作于10月底结束。然后由另一组人马进行用户接收测试（user aclearcase/" target="_blank" >cceptance test）。

技术与系统构架
系统采用J2EE技术，系统基本上是三层（3-tier）结构，即Web接口（web presentation），应用逻辑（application logic）和后端服务器（backend）。

系统需求与规范
该项目主要有两种文档提供给开发人员：一种是系统功能描述，由一系列的模块组成。每个模块类似于一个use case，主要给出了该模块需实现的屏幕/窗口（screen shot），并一般地描述了这些屏幕上的操作以及它们之间的切换。这样的模块描述文件在项目中被称之为“故事板”（story board）。“故事板”由业务分析人员（business analyst）会同用户产生。另一种文档是与后端服务器接口的规范说明，如命令格式，数据格式等，由后端系统设计开发组提供。按照项目规定，两种文件都需要经过充分讨论并基本稳定下来之后，由相关负责人员签发（sign off），然后交给开发组。

项目团队与工作地点
项目组有14个开发人员，2个业务分析人员（business analyst），一个项目经理。主要开发组在英国（10个开发人员），项目经理和其余人员则在客户所在地（与英国有一小时的飞行的距离）。

工作笔记
由于工作习惯，我一般每天都作工作笔记。而在这个项目中前两个多月中，我也每周都写一篇小结，主要是对项目运行的观察（所计述的都是对我所在的公司本部开发组而言）以下便是稍作整理后的前十周的小结（略去了公司和人员的名字）。这些笔记可能显得有些杂乱和琐碎，列在这里的主要目的是想忠实地把我眼中的项目进展情况展现出来。

第一周
开发组成员逐步聚集到项目组所在地。我们十来个人都坐在一起，边上一个大白板。这种坐位设置非常利于交流，特别是Cockburn所称的“渗透”式交流。各成员的技能方面也各有所专，如Java，EJB，JSP等。
项目有个时间录入跟踪系统（time tracker/timesheet）。每人需录入每天所做的任务和时间。这主要用于项目管理，而这些历史数据也是对新任务进行规划评估的基础。
这周的主要工作是设置工作环境。每人一个Windows NT或XP 2000作为工作站。我们选用的 IDE（Integrated Development Environment）是NetBeans。选用NetBeans的主要原因是经费问题（NetBeans是开放式源码并免费）。源码控制是用的Microsoft SourceSafe。源码库放在一个项目所用的专门服务器上。而项目的文档材料，如需求分析，系统架构以及开发管理文件，如时间进度表等。
虽然项目已决定使用J2EE技术，但具体的系统架构仍然需要建立。初步的选择是一个应用框架（application framework）。这个框架是由我以前参加的一个项目发展而来，我对它的起源和演化都相当了解，因此我也开始对这个框架进行评审（review）。
我注意到没有单元测试环境，便开始作一些这方面的工作，因为组里只有我有过建立及使用单元测试的经验。
第二周
我建立了一个基于JUnit的单元测试框架，并写了一份2页纸的简短介绍，包括单元测试的概念与实践，以及一种称之为“Mock Object”的技术，因为我认为我们的系统需用到这种技术。
本周有一次角色分配。一位精于JSP的同事将主要负责前端（front-end presentation），两位对项目所涉的后端有较多知识并参加过可行性研究的同事将更多地与在客户地点的business people （业务人员）打交道，一位对编码标准（coding standards）有浓厚兴趣的同事负责收集大家在编码方面的问题并执笔编码标准文档，还有一位精于Ant的同事主要做工具开发与配置管理（configuration management），等等。
我们的编码标准主要是以Sun Microsystem的“Java Code Conventions”为蓝本。另外，客户要求源码中所有的public and protected methods必须要有JavaDoc说明。一些与我们的特定系统有关的问题，如命名惯例（naming convention），将随着开发进程不断地编入文档中。
大家对现有的“故事板”进行的讨论分析，并分解出一些具体任务，然后大家根据自己的角色和兴趣sign up（“认购”）任务并开始设计与编码。
关于源码控制与源码库，大家同意每天早上更新自己的工作版本（working copy）。如果要修改或加入文件，在check in之前，一定要保证整个源码能通过编译。
第三周
大家继续上周的设计与编码工作。同事们似乎都是Cockburn所说的“good citizen”，工作中人人争先，个个奋勇。
随着编码的进展，一个问题开始出现了。我们这里没有后端系统，所以不能对开发的程序进行完整的测试与集成。
星期四，项目安排了一次电视会议（video conference），参加者是我们这边的成员与在客户那边的成员。两边的同事通过电视见见面，每人作一简短的自我介绍。然后主要是讨论了当前开发中的问题。最严重的问题包括需求与规范文档没能按时签发（signoff），以及我们这边没有测试环境。
第四周
由于客户对我们选用的应用框架（application framework）仍有疑虑，应客户要求，我们公司找了一位有着非常丰富的开发经验的、并且在我们目前所用的应用框架（application framework）上做出过系统的技术权威向客户解答他们的问题。
新来的技术权威是位敏捷方法（agile methodology）的热心者，我们在他的建议下准备采用类似XP的过程，首要目标是向客户，也是向我们自己显示出我们能出活（we can deliver）。周一下午，全组开了一个两小时的会议：
确定了要实现的一个很基本的功能，该功能其实大部分的编码已完成。
围绕这个功能，分解出若干需完成的任务，如：源码审查（code review），源码修改， 单元测试，建立“哑”（dummy）后端以作为初步功能测试与集成，找一台空机器以作 系统建造与演示，等等。
大家根据自己的特长与兴趣来“瓜分”把这些任务。
根据每人对完成自己任务所需时间的估计制订出工作流程与进度，以0.5天为一单元。
根据进度表，“交货”时间为下周四中午12:00点。届时，我们需提供一份release notes， 上面将列出系统安装的步骤。按照这些步骤，我们需要：
在一台只有操作系统的空机器上建立运行系统所需的环境；
编译源码并安装系统；
运行系统并演示所完成的功能。
因为下周一周二放假（庆祝女王登基五十周年），时间非常紧迫。大家开足马力，开始工作。
第五周
尽管大家尽了最大努力，星期四的期限没能完全达到，其主要原因是系统安装上有些没预料到的 困难。但最终在星期五中午完成了所有的要求并进行了系统演示。
星期五下午全组会议，主要是对这一周期中的开发过程进行讨论，特别是那些感到最困难的事情。 大家发现以下这些任务花的时间比预想的多：
熟悉应用框架和系统架构；
建立“哑”后端服务系统以作测试环境
建立单元测试
系统安装。
第六周
根据上周的讨论，编码标准（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）文档。
进度规划。随着开发的进展，对每个新的“故事板”的规划和进度表制订越来越精确。