目前，项目由于性能问题，仍然没有验收，维护时间日益增长，目前仍然有30万左右的尾款没有收到；更为严重的是，目前项目开发商正在投标的另一快速消费品行业著名客户的合作伙伴与该客户有很大的重叠，因此，对于潜在项目的招标造成一定的影响。
三、 经验与教训
从项目规模中可以看出，该项目的时间还是比较紧张的；另外一方面，项目交付是在合同规定日期之前完成，而且通过了所有的功能测试。从一定意义上的讲，项目的开发是取得了一定的成功的。
3.1 经验
在项目开发前，项目开发商已经通过其它项目，实施了以XP为代表的敏捷软件开发方法的部分最佳实践，并取得了很大的成功。因此，在该项目的执行过程中，项目开发商继续采用了XP的部分实践以及其它软件开发方法中的推荐做法[1][2]：
- 每日晨会：在项目实施过程中，每天早晨开发小组都要参加一个持续15分钟左右的会议，由项目经理主持，听取每个成员的进度，并根据进展情况，对于进度和资源进行调整。
由于会议是每天进行的，PM很容易从中获得真实的项目情况－"掀开地毯下面的东西"[4]，从而对风险有了较好的控制。 - 交叉审核：项目组在最初的时候原本是想采取"成对编程"的实践，但是没有获得物理和管理上的支持，因此，只能采取交叉审核的方式进行。
- 需求获取：由PM和一名对于原有系统较熟悉的开发人员进行需求获取和SRS (Software Requirement Specification) 的撰写。技术经理和其它开发人员进行需求的审核。
- 分析与设计：由一名开发人员进行系统框架的设计，其它人员进行审核；在系统框架设计进行过程中，由于系统去除订单处理以外的其它部分比较独立，因此，将其它模块分配给开发人员，而将核心部分交与技术经理进行分析与设计。开发人员在每个迭代周期内，都会在分析与设计做完后，每2人一组进行审核。
- 编码：每天下班前，2人一组，对对方的代码进行Review，发现问题及时解决。代码Review的时候，语法与规则的检查，通过Check Style的工具进行；开发人员将审查的重点放在功能实现与性能优化等方面。
- 测试：在需求文档形成以后，2个测试人员分布编写分配模块的Test Case；而在具体测试的时候，两人交叉测试对方的模块和更新文档。
- 测试先行：测试在软件开发中的重要作用已经得到了越来越多的重视，但是，由于习惯势力的影响和对于"Test-Driven Development"的不熟悉，开发小组并没有实施完全意义上的测试先行。
对于系统框架的核心类设计过程中，项目小组采取了TDD的方式进行开发。在后续的系统开发中，每个开发人员在进行开发前，首先要完成一个功能测试 ( Function Test ) 列表，将要完成的Use Case中的主要业务逻辑以及关联逻辑都要罗列出来，在提交测试人员进行集成测试之前，开发人员需要保证完成Function List中的所有选项。
在每个开发人员的模块完成并通过个人的功能测试后，测试人员进行集成测试，同时编写测试脚本，并通过自动测试工具 (Rational Robot) 进行记录。每天下班之前，测试人员会启动测试工具，进行回归测试。在第二天向PM和技术经理提交测试报告并将Bug提交至Bug Trace系统（Rational Clear Quest），由PM进行Bug的分发。每个开发人员需要在下一个迭代周期完成前，修正前一个迭代内分配的Bug。 - 持续集成：在测试先行的基础上，开发一组平均每天都会进行已经完成模块与以后系统的集成。集成由专门的人员，在开发人员将已经通过功能测试的源码Check in到源码控制系统 (ClearCase) 中以后进行，在部署应用结束以后，通知测试人员进行集成测试。
- 小步发布：项目有专门的测试与发布服务器，每天都有集成的系统在运行和接受测试。由于没有现场客户，对于已经发布的系统，是由"客户领域专家"（这个项目是由Business Development人员来充当这个角色）来进行审查的。他对于系统的意见和发现的问题，在经过PM和技术经理审核后，进入ClearQuest，分配给开发人员进行修改。
由于项目一开始就注意组织内部以及与客户的沟通和交流，同时采用了很多敏捷软件开发过程的实践，项目如期交付使用。
3.2 教训
项目在交付以后，最初的两个订货季节没有出现功能与性能上的问题。但是，由于合同中有数据迁移的条款，在项目交付2月后，项目开发商将旧应用系统中的数据导入新系统以后，在下一个大的订货季节中，持续的出现性能上的问题。在代码修改和硬件环境提高以后，系统性能目前获得了一定的改善。
从项目验收日期的日益推迟中，我们可以看出，该项目还是有很多地方做的不够，例如：
- 系统二次开发效应："第二个系统效应"是Brooks在《人月神话》中提出的一个普遍的问题，一般而言，第二个系统会倾向于过分设计[4]。
对于这个项目而言，没有犯这个错误，却发生了另外一种情况：旧系统中，对于订单信息以及产品信息的展示，不管是多是少（系统页面最多显示上千条记录），都是在一个页面中显示。这对于没有明显的层次结构，直接在Script中调用数据库记录的PHP来说，性能还是可以接受的。但是，新系统的设计中客户提出考虑系统用户习惯一致性的问题，就照搬了旧系统的页面设计；同时，在架构设计上，对于这种页面显示大量数据的情况，也没有给予充分的考虑，为后来的性能问题，埋下了伏笔。
教训一：没有考虑新平台的影响，照搬旧系统的功能以及页面设计。 - 非功能性需求：项目合同中主要描述的是系统功能性的需求，而没有非功能性需求的规定；同时，在需求获取解决，也没有明确的了解系统的性能指标等非功能性需求。主要原因在于项目开发商之前没有大规模业务系统开发的经验，对于非功能性需求没有足够的重视；同时，在测试阶段，也没有对于系统负载和性能做过测试。
因此，在项目交付以后，由于旧系统数据迁移后，数据量有了很大的增长，同时，在秋季的定购高峰中，有大量的并发用户访问，出现了下列问题：- 数据库死锁；
- 大量数据计算与显示页面速度很慢，页面要经过5～10分钟才能够完全显示；
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
