八、结项

　　计划与实际情况对比：产品功能、工作成果、产品质量、投入人员、工作量、成本等

　　申请结项理由和项目自我评价

　　对项目进行综合评估，总结经验教训。

　　有价值的结项管理至少包括三项内容：

　　一、对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。

　　二、对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。

　　三、总结经验教训，使整个机构受益。

　　实施建议：

　　对结项管理过程域产生的所有有价值的文档进行配置管理。

　　做好必要的保密工作。

　　结项评审工作不能简化。

　　对结项评审委员会进行必要的培训，使他们树立正确的观念，从而严格把关

　　输出：

　　结项申请书、结项评审报告

　　下面是这些核心工具的运用经验：

　　1、必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则：

　　1）程序员尽量每天只在下班前提交一次；

　　2）提交的代码必须是在自己的机器上是正常运行的；

　　3）每次提交都必须用简短的话说明自己提交代码的功能描述。

　　2、建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。

　　3、用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考）

　　4、测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况，或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。

　　5、开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。

　　6、管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。

　　这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本，

　　随时掌握产品的走向……等等。