用户操作
[留言]  [发消息]  [加为好友] 
订阅我的博客
XML聚合    FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
Smilings的公告
软件测试入门参考资料: http://blog.csdn.net/Smilings/category/208363.aspx
文章分类
My Loving
一五一十部落
冷暖人生(一)
冷暖人生(二)
凤凰十周年
疯狂英语--其中有我喜欢的CR
精彩访谈--我的大学
闾丘露薇 ROSE GARDEN
国外测试交流网站
forrester
sqatester
stickyminds
usability
worksoft
技术交流
Bea WebLogic
David.turing
mercury官方网站
python官方网站
软件测试博客推荐
jackei的测试生活与人文读本
KerryZhu软件质量专栏
KIKI专栏
T.Sing'Blog
卖烧烤的鱼
崔启亮的blog
森林木的专栏
段念的blog
陈绍英的blog
默默耕耘者
软件测试学习网站
“测试工程师”网站
“海松小屋”的软件测试专栏
51testing
UML软件工程组织
一起测试软件测试论坛
测试时代
软件测试基地论坛
存档

原创  走进外企之项目管理篇 收藏

来到新公司,加入了一个功能非常庞大的系统开发团队中,无论是项目的组织架构还是项目的管理流程,都很规范,角色的划分也很清晰,需求分析工程师、开发工程师、测试工程师,各施其职各尽其责。
在原公司有将近一年的时间都是负责CMMI5流程改进,流程在国内项目中的推广很难,管理层的目光大多集中在利润,至于用怎样的流程开发,并不太在意,能快速完成任务满意客户就是硬道理。那一年,我们花了很多的时间和精力在通过CMMI5认证,我们最终也通过了,但CMMI5认证的通过也就意味在一片喜洋洋的宣传中宣布流程管理的结束。关于流程管理的一切,又回到了原点,悲哀。项目的时间很紧,资源不足,流程自然就靠边站了。我在那一年所积累下来的流程管理经验,让我对测试发生了很大的改观,可惜,我们的项目没有很好的利用。在离开原来的公司前,我写了一份长长的建议书,作为我离开公司的最后一次共享,不知那份建议现在能否给公司或部门或某个项目带来一点点的帮助呢?

新公司流程管理的规范和坚持,让我开了眼界。项目的开发流程,是标准的软件开发流程,需求分析和评审、系统设计和评审、开发实现和Code Review,测试设计和评审、测试进行和跟进,一切都进行得有条不紊。有一点让我印象特别深刻的是项目的开始,会有经验丰富的系统分析工程师与客户谈需求,需求谈完之后,会在公司内部与其他的需求分析工程师和Team Leader一起讨论需求的合理性,客户的需求中有哪些是合理的哪些是不合理的,内部讨论完之后再去跟客户谈。不像以前,被动地接受任何来自客户的合理或不合理的需求。

项目的日常工作开展也很有效。每周一个全体成员参加项目例会,总结过去一周的工作进度和遇到问题,安排新一周的工作内容和注意问题,刚进公司的时候这样的会议让我一下子就清晰了现在项目处于哪个阶段自己又需要做些什么。项目的管理划分成了几个不同的小组,每天一个Team Leader会议,跟踪当天的项目进度和问题。对于需求变更,由系统分析工程师先做设计和实现的评估,然后正儿八经地开需求变更会议,需求分析人员、开发人员、测试人员在一起讨论需求变更的来源、实现以及各人的任何安排和完成时间,当然这么重要的会议,自然少不了PM。这些,是我以前一直大力推广的,这里的管理理念与我不谋而合,让我开心了一把。

流程的规范管理,确保了软件在规定的时间内正确完成客户的需求。不过,任何一样东西都有两面性,无可避免地,我跟它来了一个很大的碰撞。比如,每个人的工作划分都很细,各自熟悉的都是自己的那部分,开发只管实现至于为什么要这样做很少关心,有时候发现一些问题,需要找到好几个人,经过好几个流程,花了很长的时间,才会有一个明确的解决方案。回想以前公司,通常是开发人员和测试人员一起讨论就敲定了,效率相当的高,当然这样也有不好的地方就是软件的质量与开发人员和测试人员的水平和责任心有很大的关系。软件管理,自然就是量化管理,比如有多少个功能点,有多少个测试案例,功能点实现得怎样,测试进行得如何,PM关心的是这个量化的结果,说到底最关心的是测试了多少个测试案例和测试通过率是多少。他们不停地问测试完了吗?通过了多少?无形中,测试人员的注意力就在测试案例是否测试完成以及是否测试通过了,至于异常的流程却忽略了,而项目在真正的运行中,大多都是由异常引起的问题。我在老公司为什么可以将一个频频出故障的产品变成一个在全国各大省运行将近两年都没有故障,那是因为我对异常的思考和测试很充分。但是,现在,留给我对异常的思考的时间很少,我真的很着急。不过,幸运的是,项目管理组很open,对于我的着急、我的建议,他们注意到了并承诺在以后中改进,项目管理组能接受任何的建议,我喜欢这样的气度。至于改进的结果怎样,且拭目以待。

原来,没有东西是绝对的好,看上去很美的东西,自己一直追求的东西,当你真走近的时候,你会发现,美的背后也有瑕疵。关键是,在美与瑕疵的面前,怎样去平衡、怎样去改善。

让我意外的是,半年后,项目的管理流程来了一个非常大的转变,从原来传统的标准开发流程转换成Agile开发模式。项目组按功能划分成了几个小的Team,每个Team由Team Leader, SA, Developer和Tester组成,这几个角色在一起紧密地工作和交流。从需求分析、开发设计、代码编写和集成测试,在一个Team内都是非常清晰的,大家沟通也是很有效,特别是在需求分析的前期开发、测试与需求分析人员一起讨论需求和设计,很多问题都在需求分析阶段就解决了,很大程度上提高了软件的质量,降低了开发与测试的成本。不过,这也有不好的地方,每个Team都非常清楚自己的功能,但是Team与Team之间的交流并不是很多,全局把握做得不好就容易缺失功能的整体价值。让人开心的是,项目组也注意到这点并安排相关的同事做全局的把握,至于最终的效果会怎样,现在还不好做评价。

在我看来,流程是为了项目服务,能使项目有效地高质量完成的流程就是好的流程,尽管我们的流程不是最完善的,还是有很多值得改进的地方,但是我们一直在探索、在改进,我们不只是追求流程,而是追求流程所给项目带来的实际收益。这是值得国内很多公司学习的地方,我真的希望,我们的本土软件,不要一味地追求所谓的流程,很多所谓好的东西的确是好,但未必适合你,很多好的东西也许只是一个光环,至于这个光环能够给项目带来多少实际的好处就是另一回事了。

发表于 @ 2008年11月24日 22:33:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:自动测试闲言杂语 | 新一篇:自动化测试基本策略

  • 发表评论
  • 评论内容:
  •  
Copyright © Smilings
Powered by CSDN Blog