• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

浅谈项目管理的几大过程

发布: 2008-1-18 16:52 | 作者: 司智 | 来源: 项目管理者联盟 | 查看: 85次 | 进入软件测试论坛讨论

领测软件测试网

 

预估其实并不是一次性工作,在整个项目过程中,预估始终需要。预估似乎没什么特别需要提的地方,每个PM接到项目的时候自然会有预估,在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底,安排计划时不至于毫无头绪。

  4.进度计划

  进度计划就是一个模块或功能要写多长时间,PM安排个日期,设立里程碑,叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说,合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说,进度计划毫无疑问是噩梦。

  显示进度计划一般有先后顺序图,甘特图和里程碑图表。上回邵卫老师讲课,推荐的工具是m$的PROJECT,这个工具我还不会用,因为没时间去摸索。我的头倒是用的很溜了,近一个月来他就用这个PROJECT画了一个又一个的里程碑图,不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST,效果上来看,因为有强大的时间压力,效率上比之前确实要提高不少,可是我们也只能结结巴巴的赶完进度。由于TEAM里人少,我们都是一个人做几个人的活。我每天早晨六点多出门,经过将近两小时颠簸,八点多点已经坐在位子上,中午吃15分钟的饭,干到晚上八点下班,到家吃完饭往往已经11点了。一个多月我从来没吃过早饭,没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能,开发更多的模块,但是对我们的情绪也是有很大的影响。所以说,项目里程碑是一把双刃剑,合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响,进度将会大大延缓。关于PM和团队的问题我们后面会讲到,这里我先祥林嫂一把,然后跳过。

  里程碑图表的特征是任务,成员和时间,任务和成员用文字标志,时间用数字描述并辅助以图线跨度,象阶梯一样非常形象,一目了然。管理起来非常方便,完了的打个钩就可以了。

  网络逻辑图是表示任务和逻辑关系的示意图,可以用先后次序表示,也可以用关键路径表示。其实把各个活动划分为1,2,3,4等阶段,每个阶段包括小活动1.1,1.2,2.1,2.2,2.3,2.4,3.1,3.2,3.3,4.1,4.2等,日程计划也分四种,一般只提到从前向后和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口,我们打个比方:2阶段指向3阶段,那么2阶段里的4个子阶段也都指向3。假设2.1结束时间为1月12日,2.2结束时间为1月22日,2.3结束时间为1月15日,2.4结束时间为1月20日,那么,2阶段中最晚的结束时间是2.2的1月22日,所以在3阶段中的3个子阶段3.1,3.2,3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧,我就不举了,刚才几个123打的我累死了:)

  项目经常需要调整进度。在不改变项目范围的情况下,调整进度有几种方法:利用快速跟踪手段来改变任务间的关系;将串行的任务改成并行;改变工作方法(可能改变WBS);改变日期限制,使关键路径上的任务开始或结束的更早。虽然方法多样化,在我看来只有一条,就是拼命的压榨程序员的劳动力。如何压榨,还是个技巧。如前面所分析的,需求分析恨不得多分点时间给它,压需求是不太可能;测试阶段后期接近完工,罗里巴唆的事情一大堆,忙都忙不完,那时候PM一门心思提前/按时完工,好收钱,压那段时间似乎也不太可能。说来残酷,最能压的还是CODING,编码阶段往往是压缩重点,总之大家埋头苦干就是了,大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情,相信不少人都有很深的体会,这里伤心事情也就不提了。只是我总结一下,让未来的PM们有压榨后来人的依据,呵呵。测试前期也可以适当的压一压,那时候人刚完工,都比较懒散。国内一般企业规模都不大,没有专门的质量控制部门,所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里,编码压缩是很容易实现的事情,因为那些程序员真的是技能熟练的装配工人,压起来方便的很。他们这样培养人的目的或许就是为了压缩吧?!

  四.控制和执行阶段

  1.软件开发

  实在没什么好说的,也是大家最不愿意谈的,平时在公司里谈的已经够多的了,还要在这里受我唠叨。需要提醒的依然是团队合作精神和完善的文档管理制度。SOURCESAFE这些工具有时候还是有必要使用的。经常看到有人说天才程序员不写注释什么的。我相信有这种天才程序员,因为我碰到过几个。我爱人公司里也有一个,他们的一套产品核心代码就是这个人写的,4年过去了,周边代码换了好几茬,核心算法始终没换过,可惜这小子跟了李洪痔,如今已经不知所踪了。但是他的代码似乎也要有点注释的,没有注释过段时间再天才的程序员也不能保证他是最有记忆力的。而且,对一个项目的编码来说,靠一两个人打天下如今是不可能了。别人的公司都是团队,两人智慧胜一人,这头还在靠一个天才支撑门面,实际上市场可就别人抢了去,那时候再天才也没用了。编码的时候讲究技术公开,程序员不要藏着掖着,对大家没好处,PM要想办法调动大家创新思维的积极性,营造良好的技术讨论氛围,碰到技术难关的时候就容易攻破了。

 

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/


关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网