51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3434|回复: 8
打印 上一主题 下一主题

[讨论] 项目问题咨询

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-5-26 16:47:21 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
如果有个小项目出现下面的问题,请问如何处理:
1.由于软件外包,进度经常由于客户的要求经常变化,所以进度表的指导和执行力不强。
  我对项目经理的建议:近期的要详细制定,远期的只要有个大概的期间及可
  现在情况:进度表现在基本上有点像日报了,只是把今天所完成的任务进度填写,计划栏已不填写。
2.配置管理,现在基本上没有做
  因为是小项目,当初我考虑是把一些需要的文档用VSS抓起来即可,现在出现的版本控制困难的问题,项目经理想抓就抓,想放就放
  我的打算,还是严格遵守cmmi的要求,至少要CM(人员)明确化
望各位大虾指点一二!!!!

[ 本帖最后由 笨猪 于 2008-5-26 16:53 编辑 ]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2008-5-27 10:03:26 | 只看该作者
1.由于软件外包,进度经常由于客户的要求经常变化,所以进度表的指导和执行力不强。
  我对项目经理的建议:近期的要详细制定,远期的只要有个大概的期间及可
  现在情况:进度表现在基本上有点像日报了,只是把今天所完成的任务进度填写,计划栏已不填写。
我觉得首先要尽量界定客户的变化是否是合理的变化,我觉得要尽量控制需求的变更,要知道需求的不断变化,整个项目组要花很大的代价去满足需求的变化,如果变化是合理的,我的拙见是,最好是制定项目的里程碑,从上面那段话,我感觉项目的目标不是很清楚,大家只知道今天完成什么事情,但是对项目的发展进度,项目近期目标都不是很清楚.我以前也待过一个项目,和你们这个项目的情况也比较类似,当时我们的需求也是不断的变化,不断的深入,但是我觉得,我们项目组很好的一点就是,大家很清楚目前项目处于什么阶段,我们的近期目标是什么,我们的最终目标是什么,每个阶段要达到什么样的程度,在每个阶段结束后,项目经理都会对这一阶段的工作进行总结,制定出下一阶段的目标

2.配置管理,现在基本上没有做
  因为是小项目,当初我考虑是把一些需要的文档用VSS抓起来即可,现在出现的版本控制困难的问题,项目经理想抓就抓,想放
当项目还处于开发-测试阶段,并且需求不断变化的情况时,加入配置管理是比较困难的,拿我自己参与的项目来说,我是做测试了,对需求的不断变化和开发bug的不断反复是深有感受,我也多次向我的项目经理建议进行版本控制,但是每次都不通过,首先我们那一批的开发都是新人(刚刚从大学毕业),对规范化的版本控制还有经历过,如果突然加入版本控制,怕大家都不适应,造成项目进度的拖延,第二是,需求变化太频繁,并且代码也相当不成熟,代码的大量反复是不可避免的,如果进行版本控制,可能得不到预期得效果.

还有就是cMM,自我认为CMM确实是很好,但是不能全部照搬,应根据实际情况而定.
以前是本人得一点拙见,我从事测试也不是很久,希望能和大家多沟通,共同成长,上述不对得地方,希望大家给我指出!!!
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2008-5-27 14:10:01 | 只看该作者
原帖由 likejuntesting 于 2008-5-27 10:03 发表
1.由于软件外包,进度经常由于客户的要求经常变化,所以进度表的指导和执行力不强。
  我对项目经理的建议:近期的要详细制定,远期的只要有个大概的期间及可
  现在情况:进度表现在基本上有点像日报了,只是把今 ...

对于CM,您的意思是现在不需要对版本进行控制,我想知道当时你是如何去做的!如何去对应的
对于进度,你的意思是我是明白了,但是这些是项目经理的脑子中的东西,还是经过文档化的东西!
我现在做的好像和您的意思差不多,首先项目经理知道大概有几个阶段,每个阶段对应的大概的开发日期
然后再对应的阶段计划安排的要很详细,其他还比较远的阶段暂时不考虑。不知道这样做有没有问题,
还请赐教!谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2008-6-25 16:05:19 | 只看该作者

回复 1# 的帖子

公司有项目管理方面的规程吗?有就照做,没按规范来就写QA审计报告,和项目经理对某个问题产生争议就找上一级领导协调.
如果没有规定应该怎么做,你可以写过程改进建议,一定要有依据.
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2008-6-25 16:07:24 | 只看该作者

回复 1# 的帖子

QA只是发现问题,没有解决问题的职责和权力
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2008-6-27 15:50:25 | 只看该作者
原帖由 woynzd 于 2008-6-25 16:07 发表
QA只是发现问题,没有解决问题的职责和权力


我没记错的话,QA应该要提出相应的解决方案。不然QA真成了文秘了。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2008-6-28 10:00:00 | 只看该作者

回复 6# 的帖子

先把规范整出来,按规范做事.如果规范都是大家之前认可的,那么解决方案就是照做,不照做就写进审计报告,就这么简单.
从头到尾最难的是写规范,持续的过程改进最后的产出还是规范,制定科学合理的规范并严格执行才是唯一的解决方案.
做过程改进不是制造问题并解决问题.
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2008-6-28 10:28:12 | 只看该作者
原帖由 笨猪 于 2008-5-27 14:10 发表

对于CM,您的意思是现在不需要对版本进行控制,我想知道当时你是如何去做的!如何去对应的
对于进度,你的意思是我是明白了,但是这些是项目经理的脑子中的东西,还是经过文档化的东西!
我现在做的好像和您的意 ...


小项目是什么规模?如果项目人员少,周期短,就没必要搞得很复杂.能裁减的尽量裁减,保留需求设计评审,里程碑会议就行.
进度总在变,我想合同上规定的完工时间总是不变的吧,无非就是阶段时间节点在变.根据项目情况,各阶段按工作量倒推,总是可以确定下来各阶段的时间节点的.
小项目不应该有很大的版本问题吧,能做出多少个版本呢?控制好需求设计文档和项目计划的变更,提醒开发人员管理好自己的代码,把接口函数定义清楚,版本问题对项目的困扰不大.
说来说去我们无非是协助项目经理把项目成果做得符合客户要求,结合实际就是做过程裁减,大概也就是敏捷式开发说的那些东西.
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2008-6-28 10:40:05 | 只看该作者
换个角度说,假如你是项目经理,当你面对项目时间紧,开发任务重,还有人整天跟你讨论要写这文档那文档、例会、里程碑、变更、版本控制。。。你烦不烦呢
初学CMM的人第一感觉都是:文档真多,感觉很繁琐。初级QA给人的感觉也是让工作由简到繁。对于QA,下一步的提高是如何让工作由繁到简,这也是我自己现在考虑的问题。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-16 09:36 , Processed in 0.066505 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表