IT项目管理 “轻”方法与满意质量

来源：互联网

2013/7/15 14:59:33

传统意义上的软件方法学描述通常“能够”处理任何大小的项目，而实际上真正的困难就来自于如何对这些方法加以裁剪以适合较小的项目。针对这种理论与实际的脱节现象，国际上一些著名的软件工程专家提出所谓“重（heavy）”方法和“轻（light）” 方法之分，试图为快速发展的软件工业探寻更切合实际的解决方法。

分享到：新浪微博腾讯微博

本文关键字：项目管理 IT

　　究竟选择需求分析的“轻”方法还是“重”方法很大程度上受到公司产品上市时间或合同期限压力的影响。同时，公司雇员的流动率也是一种影响因素：作为形式化开发过程的理由之一认为，如果有一份详细的文档来记录需求、设计和编码，那么一旦在项目进行中关键开发成员离职所造成的混乱将会被尽量减小。

　　然而，尽管1970年代和1980年代的系统生命周期预期为十年或二十年，也许Interbet时代的网络公司更愿意正式承诺其电子商务应用仅持续一年，然后被废弃或完全重写。如果正是这种情况，并且如果下一代应用预期与当前应用存在质的差异，那么仅仅为了达到SCM-CMM三级就遵循需求分析“重”方法还真的有意义吗？

　　同样地，针对设计和测试工作采用什么样的形式化和严格程度才是合适的呢？与项目管理有关的时间汇报、进展汇报、状态会议及其他常见活动又如何呢——尤其针对那些仅持续一周或两周的项目？这些问题总是相互关联的，但是一些传统上被接受的答案却需要至少每隔几年重新审视一下，因为成本-收益参数正在随着商业环境、技术和软件开发人员的变化而不断变化。

　　轻方法还重新审视了历史上有关投入资源在需求分析的假定，以及投入资源在过程改进的假定。1981年Barry Boehm在他的经典著作“软件工程经济学”（Software Engineering Economics）中指出了一项惊人发现，即如果我们在项目的系统分析阶段引入一个缺陷的话，那么在项目的分析阶段发现这个缺陷会比允许这个错误直至进入设计阶段才被发现节省约10倍资源。但是Boehm在此做了一个在新千年的头十年中未必依然正确的基本假定：仅当该缺陷在生命周期某阶段发生时可通过某种方式加以鉴别，那么这种数量级增长关系图才是相关的。在今天的环境中，这个前提假定在许多商业条件下都是不成立的。比如，当Bill Gates阐明对于浏览器IE的需求时，可能他会说“就象Netscape Navigator那样，但要更好”，可能Netscape的Marc Andreesen也会这样想：“我希望使Navigator就象Mosaic一样，但要更好。”但是当Tim BernersLee在构建WWW的初始版本和浏览器的第一个草样时又该如何考虑呢？让他写出详细需求的意义何在呢？

　　与此同时，重方法的倡导者争辩说，如果一个缺陷在开发阶段就被发现，那么就不应当责备引入该缺陷的个人，而应重新检查允许该缺陷发生的过程本身。但此处又有一个基本假设，也就是说，我们值得投入资源在鉴别一个过程中潜在缺陷的唯一理由是我们希望再次使用同样的过程——因为我们的下一个项目将会与上一个项目足够相似，很自然就应使用同样的过程。但是现在事物变化是如此之快，以至于完全不能保证第N+1个项目会与第N个项目有任何相似之处。因此，昨天的过程可能不得不为了明天的需求而发生实质性变化，换言之，也许只有投资于过程中的重要缺陷才是值得的，因为一些细节仅针对某个特定项目才有意义。