过去的两个月,我们项目组8个人做一个对应(日方的見積もり是13个人月),共19本任务。
我们先搭建环境,那时日方客户的IF设计书还没有给,我们只能根据在客户现场的同事的只言片语来调查既存代码,做准备。
-》后来看来,这种调查,大方向都不太明确,多少有些盲目性。(20090506追加)
这个系统还是很大的,也很老,听说已经跑了几十年了,我们这次的任务是追加处理(供最终用户在嵌入式设备上进行使用)。
画面是另外一个公司做,我们只做处理(接受到request(一串数据),在“后台”进行处理,返回response(又一串数据))。
这个和我们以前的对应任务(比较纯粹的Web任务)有所区别,刚开始时,大家连输入什么输出什么都不清楚(没有设计书)。
还多亏在第一次电视会议中,在客户现场的同事当场画了一个图,讲解了一下,我们才了解大概流程和我们要做的处理。
期间,特别是刚开始的式样理解阶段,我们不断通过QA进行确认,并且每周和日方客户开两次电视会议。
国庆前我们比较好地调查了既存Source中关于PC的处理部分。
-》也将调查结果形成了文档,这种文档在后来的开发中也确实起到了一定作用。这边要注意一个问题,就是分配调查任务后,最终一定要形成一个调查结果(文档)。需要杜绝这种情况的出现:调查确实是调查了,但最终什么结果也没有。过段时间,想利用这个调查情况的时候,却又什么也记不起来了。(20090506追加)
国庆后,在客户现场的同事回来了两周,帮助我们理解和把关,确认了很多式样,导致那两周的QA数量大减,呵呵。
-》这个任务能最终顺利完成,这个BSE起的作用确实很大。(20090506追加)
同时,逐步地,大家对自己的任务也越来越清楚了。
然后,我们就依葫芦画瓢(特别是业务逻辑部分,基本参照PC的处理逻辑),将各自对应代码逐步写出来了,还算顺利。
都是新规文件,然后调用既存代码(客户一直强调不允许修改既存source,担心影响别的地方,这也符合OCP原则)。
但是后来遇到一个问题,现在看来,也算是一个经验教训吧,就是测试式样书的问题。
当时为了更好地控制进度(以保证按期纳品),我们对外(日方客户)排了一个Schedule的同时,内部又排一个,提前一点点。
前面的式样理解、source调查、code都是按内部计划来走的,相对于外部计划而言,时间还有点空余。
但是,后来,由于测试式样书的反复指摘和对应修改,在这上面就耗了两三周的时间,远远超过了原先安排的时间。
-》因为日方客户需要进行两轮review,我们的日方客户A的review和A的客户B的review。再加上日方客户安排的人手又不够,导致review上所花的时间超长。(20090506追加)
这个“突发”状况,不仅把我们前面争取来的空余时间全部吞掉了,还导致了纳期的延迟,比原计划延了一周。
这次对应,我们这边只做UT(单元测试),使用JUnit工具测试,每本或多或少地写了几百或几十条测试Case。
因为业务关系,很多case都要人为修改电文或者DB,一条条地测,截图(日方客户要留作Evidence)。
客户那边做SI(集合测试),应该是和另一个公司做的页面结合起来进行测试吧。
也有可能不是,因为我们部门的首席技术专家用Java Swing写了一个SI的测试工具,也纳品给日方客户了。
现在的新对应,日方客户已经注意了,将测试式样书的时间提到了Code之前(尽管实际上我们这边已经同时在做Code了)。
有几点感受:
一是前面提到的测试式样书的问题;
二是式样不断变更的问题(也许到了快要纳品的时候,还是有式样要变更。也许,这也是做项目的一大特点吧);
三是式样理解逐步的问题(式样并不是一下子在式样理解阶段就全部搞定的,可能只能说那时理解的是大部分;code时又理解一部分,写测试式样书,甚至于做单元测试的时候,还有可能发现个别式样理解错了)
今天就先写到这,以后想起再来补充。
20081113补充两点:
<!-- --><!-- --> <!-- -->
调查既存 source 时做调查文档,做些记录,以后再回过头来确认相应问题时,可以快速定位。这个问题,遇到过几次,逐步明白客户这样要求的好处了。
在数据库表很多的情况下,把自己负责的部分中要用到的表单独放到一个文件夹,用的时候找起来很方便。
<!-- --><!-- --> <!-- -->
20081210 补充:
关于测试
使用 JUnit 工具 进行 测试, 关于 case 的编号问题,因为这次 case 相当地多,刚开始是按规约来给各个 case 命名的,但是测试起来才发现,这样并不好,每测试一次,还要稍微费点力气来找下一条测试 case 。后来,改变策略,使用编号(和测试式样书的 case 号保持一致),那样测试起来更方便一些。
单元测试全部完成后,才发现,其实不需要那么麻烦(每次点击一下运行所有,然后再从几百或几十个测试方法中选择一个运行),其实只要打开 outline 视图就可以快速定位了。
感觉我们在极细微错误的认识程度上,仍然和日方客户有所差距。比如说这次 CJ 部分的测试,因为 code 时货币符号错写成了全角,需要改成半角,说小点,其实就是个显示的问题。按照我们中国人的“惯性思维”,也许这个只要对应完,重新测试一下就可以了,感觉重新截图好像就不是那么一定必要了(因为 case 很多,同时手机截图也很麻烦)。但是日方客户并不这么认为,他们认为应该尽早发现画面的文字显示有些混乱这样的小混乱,如果这一类错误都不能及时发现,那么背后肯定隐藏更大的错误。之所以这么考虑,也许是因为日方客户遵守确保安全的“ HEINLICH 法则”吧,他们对于质量的思考方式:消灭小故障,就能够确保安全。
后来,我们仔细对照画面设计书,又在我们实现的画面上发现了两三个类似的 bug 。由此,也不得不佩服日方客户工作态度的严谨。