有关项目管理的一点实践经验!(产品成形过程探讨)

　　引言：

　　在论坛上经常看到很多人有关项目管理的经验，而且都是长篇大论，侃侃而谈;总是看得我晕头转向，总感觉，都是停留在人的作用上，总是强调管理中的人为因素，几乎很多条目都是带有很强的人为色彩，看完后，总是觉得这些经验很不错，但是自己往往却很难在自己的项目中具体实施。

　　想法：

　　本人是一个实践主义者:)，自己在项目管理中，总是尝试抛开人为因素的困扰，利用一些简单通用的工具来协助项目管理，通过这些工具的运用，让它们自动来推动项目管理的进程，减少人为因素的问题，形成一条无形的推动项目进程的生产链条。

　　核心链条：

　　源代码管理工具 => Bug追踪工具 => 每日编译工具

　　WinCVS/CVSNT => Bugzilla => BAT和Perl脚本

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

　　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，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本，随时掌握产品的走向。。。等等。

　　另：有关项目管理中与客户、与公司上层、成本、进度等等，这里没有具体谈，但如果切实运用以上经验，会在一定程度上简化这些关系的复杂度，使得各个环节变得相对简单。