• 测试技术
  • 博客
  • 视频
  • 开源
  • 论坛
  • 沙龙
  • 下载
  • 杂志
  • 招聘

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

软件过程改进:经验和教训

发布: 2008-4-02 13:29 | 作者: 不详 | 来源: CSPIN | 查看: 61次 | 进入领测软件测试网论坛讨论

领测软件测试网

RLU^0],n9Fi1}

m`BIh 软件测试技术第一门户;d-o$_%^RC0C x

软件测试技术第一门户)V'K@/S+K hL'v

一群对于过程改进有热情的组员是试点成功的保证。他们要有热情去学习新的流程,要有热情去沟通在执行新流程当中遇到的问题,他们要有热情去克服进行中的困难,而不是抱怨,他们要有热情去总结和改进新的流程,使它更完善,最总要的是,他们要有热情作为新流程的传播者,把流程象星星之火一样在组织中开展。一个坚决支持过程改进的领导是必不可少的。象任何其他的变革一样,一个坚决支持变革的领导是不可缺少的。在一切顺利,大家赞成的时候,也许感觉不到什么。但当变革遇到阻力,遭受暂时的困难时,这种坚决的支持就是变革是否可以继续进行的保证。因此,在过程改进的初期,于企业的高层进行沟通,让其了解到过程改进的必要性和预期的前景是十分必要的。同时最好在过程改进的开始阶段,一个誓师大会的举行也是鼓舞士气的上佳方法。在过程改进的过程中也要注意及时的通报进行的过程,取得的成果。当然在遇到困难,或需要高层支持时,更要及时开口。(这对于技术人员主持的过程改进尤为重要。)要有选择的对于KPA进行改进,不一定是最薄弱的KPA,最重要是选择你可以控制的KPA。关于这点其实并不涉及CMM的技术问题,而是一个管理问题。这里有个现实的例子,一家企业的管理有点乱,高层希望可以通过CMM的过程改进,来提高企业的产品质量,理顺工作的流程。于是任命了一个开发组的主管(代称A),来主持这个过程改进。 结果A在选择KPA的时候,认为首先应该对于实行需求管理和变更管理。因为开发组的同事们都抱怨,需求经常改变,造成的返工很多,在最终期限的压力下他们不得不经常加班。 这个本事没有问题,可是需求管理和变革管理的发起基本是在系统分析组,而这个组在行政上不归他管。公司也没有因为要进行过程改进而把他提高到一个高的级别(即使是暂时的)。

@^E3E1z {

t4},k-W"_d  现在问题来了,虽然他花费了心思去设计的流程。并对于需求部门和相关部门组织了培训。可是在进行试点的时候,他发现,当他去评审需求分析组的工作时,别人很反感。而且对于有些需求的变革也推诿到销售人员、客户等因素。同时,流程中只要有一点不太合理的地方,就抱怨的很厉害。最后试点结束,他自己很累,试点的结果也不好,改善的目标没有实现。整个过程的改进处于一种微妙的处境。最后,试点的流程并没有推广。其他的KPA过程改进也不再进行了,随着时间的推移,过程改进在企业中也不在有人提起。知道这位开发组的主管错在哪里吗? 他选错了KPA,他选了一个不属于自己管辖范围的KPA作为起点。他跑到一个不属于他的地方开始指手画脚,他是个不受欢迎的人。注定了,在一开始他就面对着对立和抱怨。这样的团队是无法经受一点点挫折和失败的。若他一开始选择配置管理,这个至于他管理范围的KPA,他可以利用手中的权利、资源和威信,组织试点。可能情况就好的多。 又或者企业的高层给这个开发主管一个虚职,比如过程改进项目组组长,并任命其他组的组长为过程改进项目组成员。情况也会完全不同。软件测试技术第一门户5bJ4M%R;Z

软件测试技术第一门户?3u