空间管理您的位置: 51Testing软件测试网 » kuailederen » 日志

我不可以人云亦云，应为我是思考者；我不可以沿着别人的足迹前进，应为我怀疑迷失方向；我所能做的就是思考再思考，实践再实践。我不停的问自己也建议同道中人问问自己：难道我们所能做的只是copy现有的东西，不可以创新什么东西吗？在我看来，测试仍然没有任何定论，一切看自己。

cmmi过程我们所不得不面对的困难

上一篇 / 下一篇 2009-03-03 13:21:27 / 个人分类：转载

查看( 246 ) / 评论( 0 ) / 评分( 0 / 0 )

1234234209

前期过程改进需求分析不到位导致目的和结果的南辕北辙

过程改进和软件开发一样，前期的需求分析是否到位可以说很大程度上决定了项目的成败，CMM/CMMI的前期分析过程叫作"Gap Analysis"（差异分析或差距分析），目前国内咨询公司给出的CMM/CMMI咨询方案中比较典型的差距分析过程包括：2天的文档审查，2天的访谈和一天的编写报告。很显然，对于软件开发这样一个复杂的系统工程来说，短短3－5天的时间可能可以得出表明上的“差距”在哪里，但其实并不能真正了解导致这些“差距”产生的深层次的原因在哪里，而以简单量化的形式得出的差距分析报告（其主要内容是一张根据PA罗列了CMMI中所有SP的Excel大表格）更不能全面反映它们相互之间的各种约束关系。而整个CMM/CMMI过程改进就在这种头疼医头，脚疼医脚的表面文章中展开了。

一个软件企业过程改进的需求和CMM/CMMI的要求之间并不能划等号，所谓“种刮得瓜，种豆得豆”，前期机械的按照CMM/CMMI的PA来分析企业的过程改进需求，最终得到的结果往往和企业实际的情况相差甚远。

缺乏可操作的方法和有效的技术手段

再好的理论也是需要有效的方法来实现的，虽然我们可供选择的方法并不在少数，但这些方法在实际环境中的可操作性以及是否拥有有效的技术支撑手段手段，却是众多企业面对的一大难题。以下是软件企业经常会碰到的一些问题：

1、他们通常被告知需要根据员工的日志对项目任务的完成状态进行同步更新，以便随时能够根据项目进展提供一张漂亮的跟踪甘特图。但在缺乏有效工具平台（大多数企业并没有部署MS Project服务器版本）的情况下，QA们（或PM们）只能痛苦的埋头于一堆Excel日志表格和计划MPP中，重复着这种低级而极易犯错的工作——显然这种坚持并不能持久的
2、他们通常被告知需要从需求、设计、编码一直到测试建立有效的双向跟踪，但他们从咨询方获得的通常仅仅是一张由Excel编制的需求跟踪矩阵模板。鉴于需求之间的关联性和版本衍生导致的复杂性，我想我们用脚趾头都能想明白，任何一个稍具规模的应用的需求跟踪都是不可能仅用一张Excel表格来做到的。
3、他们通常被告知要在有效估算的前题下编制计划，并被推荐使用某个相对成熟的估算技术——如功能点，但是我们的估算人员要面对的往往是庞大而复杂的功能结构分解和有限的时间，在这种情况下即便是借助一些简单的工具也需要付出巨大的工作量，而如果是纯手工作业则基本上没有现实的可操作性。于是最终往往只能退而求其次选择一些基于经验的估算方法——如Delphi法，而Delphi法的应用在缺乏经验和有效约束的情况下最终慢慢变成了流于形式的“拍脑袋”——一切又重新回到了起点

虽然从国际知名厂商到国内一些企业都提供大量的过程管理工具，但工具作为一种辅助手段，其选型、部署、集成和使用都需要根据企业的实际情况做大量的工作，而这项工作，我们在大多数公司给出的咨询方案中却几乎看不到。

有效约束机制的缺位

光靠一堆文档建立起来的过程是很难被有效执行的，尤其是在中国，技术人员跳槽和岗位变换的频繁度远高于西方的软件企业，约束机制的缺位往往导致已经被定义好过程难以被有效的执行，并随着时间的推移逐渐放弃越来越多的已定以过程——企业拿到证书后，过程慢慢几乎又回到原点的案例并不在少数——换句话说，CMM/CMMI评审以前，是过程改进，评审以后则是过程倒退，这和过程改进的初衷是完全背道而驰的。

因此，如果没有可靠而有效的约束机制，定义得再好的过程最终也难免沦为一堆尘封的旧文件，而约束手段的建立必须从两个方面入手——管理制度的完善和有效技术手段的应用，而这也很少能在众多公司给出的方案中看到。

收藏举报

TAG:

查看全部评论