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

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

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

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

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

...全文
171 3 打赏 收藏 举报
写回复
3 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
ycw 2004-09-05
每日编译的入门实践,这是我写的每日编译脚本代码:

http://blog.csdn.net/ycw/archive/2004/09/05/95192.aspx
  • 打赏
  • 举报
回复
redguardtoo 2004-09-04
很多公司这方面做的很差。

虽然把这种“常识”一遍遍强调是很烦,但是不客气地讲,国内没有几个公司具备了“常识”。每日构件脚本有谁在写?

我强烈建议斑竹列出基本的管理实践若干条,置顶。
  • 打赏
  • 举报
回复
zhuyanwei 2004-09-04
这些都是死的,而且都是大家认可的一些经验,没什么好说的.....

你把贴子放到项目管理中去吧,否则口水淹死你
  • 打赏
  • 举报
回复
相关推荐
发帖
研发管理

1246

社区成员

软件工程/管理 管理版
社区管理员
  • 研发管理社区
加入社区
帖子事件
创建了帖子
2004-09-04 07:08
社区公告
暂无公告