关于生命周期模型和过程定义。我的理解是生命周期模型定了项目生命周期的一些阶段,通过描述阶段包含的活动和输出来描述一个生命周期模型。过程定义是对生命周期模型中各活动采取的方法进行裁减(选择)。
      
我的疑问如下: a 、生命周期模型只定义包含几个阶段还是也包含阶段内的活动?例如:瀑布模型,包含需求、设计、开发、测试,这就是一个生命周期模型吗?还是说,要描述实现阶段是否包含详细设计活动?也就是说有详细设计的实现阶段和美有详细设计的实现阶段是否是一个生命周期模型?
                          b
、如果确实存在一些模块,因为某种原因(如能力不足)不进行详细设计,而其他一些模块进行详细设计。那这个生命周期模型是什么样的?哪些做哪些不做是否属于裁剪?如果不属于裁剪,这种情况如何解决? <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

你这个问题问得很好。

首先,我希望说明“定义过程( defined process )”是 CMMI 的名词。意义非常特殊,是指第三级项目按标准过程裁剪出来,在项目里实施的过程。你把它说成过程定义。这是不对的。虽然我觉得 CMMI 的词用得不好,但是我们需要能够不被这些事情干扰,导致把概念弄糊涂了。你的问题,有一部分是因为你对这些词的含义了解不够精确而造成的。你想想,“生命周期模型”与“生命周期模型的定义”之间的分别在哪里?

a )作为 EPG ,需要定义一套“标准规程”让项目可以裁剪使用。项目呢,需要制定项目里面所有的活动,同时保证这些活动是符合标准规程的。所以, EPG 在制定标准规程的时候,使用了几个生命周期模型,来组织其他各层活动的定义。每一个生命周期模型,看起来都是阶段,里程碑,评审点,输入、输出、以及它们的质量要求等等。其他的细节都在子过程与过程单元里定义,组成了整个“标准规程”。你一定要说“生命周期模型”只包括阶段,不包括阶段内的活动也可以。但是“标准规程”的定义,应该包括这些活动作为子过程与过程单元的。项目裁剪也是一样。项目策划的结果,就是它的“定义过程”,一定包括各个阶段的活动细节的。

我们的标准规程定义的不好。比如:标准规程不应该定义评审需要 80% 的覆盖,或是 65% 。反正不应该有一个数据要求。为什么?因为不同的项目有不同的目标。有些产品质量高一点,有些进度要求快一点。这个覆盖度,是项目负责调整(裁剪)的。标准规程应该定义:工作产品需要验证,验证方法包括: xxx yyy ,评审, zzz 等等。评审可以是:同级评审、多人复审、等。同级评审需要预审、开会、整改等。就够了。

你把阶段与活动分开,也不是不可以。我觉得这个不应该对你掌握过程理念不重要。如果你觉得重要,可能你的了解还不十分到家。我倾向于把全部当成生命周期的整体。同一个“生命周期模型”引申出来的不同的实施(“定义过程”),每一个都是一个完整的生命周期,但是也是一个特殊的实施。

b )大家经常有一个我觉得是非常不符合过程管理理念的想法:我们的裁减,或是其他举措,都是因为“没有能力”。为什么我们接受没有能力的情况?这是姑息。我们要对员工有要求,要求他们提高,接受培训,达到需要的技能水平。不能因为没有能力,就把一些重要的事情裁剪掉。我们裁剪,只能是因为这样做比较合理,可以更有效地满足目标!

你的案例提到是否有详细设计,或是说,把详细设计裁剪掉,是否还是同一个生命周期模型?这个要 EPG 按实际情况定义清楚。如果“标准规程”里的某一个生命周期模型要求有详细设计,不能裁剪,那么你把它裁掉,就违反了这个生命周期模型的定义了。如果某一个生命周期模型要求有详细设计,并且提供裁剪准则。那么,按准则把它裁掉,就还是符合这个生命周期的。

你的问题应该是:如何判断每一个因素的重要性,并且按它们的重要性,安排在不同的过程层次上:哪些是阶段性的,哪些是子过程的,哪些是过程里的参数,等等。这就需要你清楚每一个活动的意义与作用了。就拿详细设计来说,这个活动的意义与重要性在那里?假设我们有两个生命周期模型:一个是“资深员工快速响应模型”,另一个是“外判编程模型”。那么,一个当然定义详细设计可以裁减掉,另一个就不能。但是就是“资深员工快速响应模型”里,也可能有需要作详细设计的情况,比如一个模块的实施非常独特,是一种大家不清楚的技术,详细设计就可能有帮助,所以就做了。在这个情况,在同一个生命周期模型里,可以有些模块做详细设计,有些不做。

最后,请留意,“瀑布”、“迭代”、“螺旋”等等,都是生命周期的类型,不是模型。每一个生命周期模型,都会按产品、团队特征、采用的技术、方法、等等而制订的。每一个模型都有它的作用。我鼓励大家把生命周期的选择使用作为项目定义过程最高层次的“裁剪”。