软件项目范围的敏捷管理模式（上）.docVIP

软件项目范围的敏捷管理模式（上） 　　0引言 　　项目管理是一项非常有挑战性的工作,尤其是软件项目管理。做项目管理的人都知道“项目三角形”法则,也就是制约项目的三个因素———时间、成本、范围各构成三角形的一边,其中一个因素的变化必然引起另一个或者两个同时发生变化, 　　例如项目要赶进度(缩短项目时间),可以投入成本、增加人力,或者将原定计划要实现的范围缩小,如何做取舍就要靠项目经理进行权衡选择。如果要做个譬喻,项目经理不亚于是“在针尖上跳舞”的舞者,他甚至可能要在捉襟见肘的寸方三角形舞台上导出一段“不可能完成任务”(mission impossible)的“群舞”。 　　1 范围管理概论 　　项目经理如此不幸,而软件项目经理就更可以说是“不幸中的不幸”,因为根据经典数据统计,软件开发项目的成功率目前不超过50%,如果时光回退十几年,这个数字会再低十个百分点,而且对于规模越大的项目,其成功率越低。 　　到底是哪些原因导致如此低的成功率,通过对过往失败项目案例进行整理和分析,人们生了问题才临时采取行动,试图迅速地解决问题。这样的管理方式往往让项目组很被动,也大大增加了管理成本,并使项目的进度面临很大的风险,所以必须采用主动式的风险管理模式,防患于未然。 　　发现其中一个主要的“败因”是范围管理失去了控制,从而引发“范围蔓延”(Scope Creep),以这种方式失败的项目表现为:项目已经比原定计划大大延期,客户仍在源源不断地有新需求,或者对已经完成的功能提出各种修改意见,开发团队士气低迷,总有完不成的开发任务,项目预算已几乎消耗殆尽,而距离项目收尾却遥遥无期。 　　范围管理难在何处?通过对以这类原因失败的项目进行分析和总结,大致可以归为客户方和开发方两大“责任方”。这里有两种观点。 　　(1) 责任在于客户。这类观点通常是由开发方“总结”得出的,经常从开发方的技术人员口中听到诸如此类的抱怨,“我们的客户从项目一开始就不清楚需要做什么”,“他们总是在变,今天想要这个,明天又想要那个,更难以忍受的是他们的要求又往往是矛盾的”, 　　这种来自于客户方的需求“模糊”以及“朝三暮四”,使得项目的范围充满了不确定性,而开发方头上悬着“范围”—“时间”—“成本”这一“项目三角形”达摩克利斯之剑,范围的变动就意味着项目开发周期的延长和成本增加,带来的严重后果就是项目严重超支、项目延期难以交付而导致最终的项目失败。 　　(2)责任在于开发方。幸运的是开放方的责任并不是客户“投桃报李”总结出来的,开发方拥有很好的自觉反省,自己道出了“苦水”。他们通常认为,项目失败很大的一个主因是范围的定义不够明确,做不到可量化、可验证的程度,因而在进度和成本的量度和控制上面引发了多米诺效应,最后导致项目的“滑铁卢”。 　　而为什么项目开发方的管理团队无法做到范围界定明确的程度,原因有以下几个: 　　1)开发方缺乏规范的项目范围管理过程是最主要的原因。比如缺少范围评审环节,开发方与客户方无法在项目开头就对项目范围进行很好的商讨、澄清,并达成共识而且共同签署范围确认书,给后来的范围蔓延埋下隐患; 　　又比如开发方没有对变更进行有效的管理控制,在项目进行过程中,面对客户方“漫天要价”提出的后续需求缺乏有效变更系统加以辨别、遴选、记录和处理,最终由“量变”引发“质变”,项目范围远远超出最初预计。 　　2)开发方缺乏正确的方法作为指导。这里的方法即指软件工程领域中的方法,比如需求采集方法,也指项目管理中的方法,比如在范围分解的时候,运用正确的工作分解结构(WBS)法进行范围划分。 　　3)没有使用必要的项目管理工具进一步加强范围管理以及其他管理活动,给项目成功带来更高的保险系数。典型的工具有微软的Project 2000,以及IBM的统一项目管理平台。 　　以上对范围管理失控原因的总结和分析都很有道理,从中拿出任何一条,都可以在众多失败的项目中找到支持的佐证。为了解决范围管理这个难题,项目管理协会(PMI)和软件工程协会(SEI)都提出相应的范围管理体系。 　　PMI的项目管理知识体系指南(PM-BOK)对范围管理的定义是“为了成功完成项目,需要确保项目包括所需的全部工作,但又只包括必须完成的工作的各个过程”,从这个定义可以得知PMI的范围管理是一个过程管理,它关注的是在项目进行过程中的各项工作活动需要围绕项目交付展开,既要包含所有必需的活动, 　　也不能包含不必要的活动,简而言之就是不多不少(just-in-time)。PMI的范围管理主要划分为五个过程展开,这五个过程分别是范围规划(planning)、范围定义(definition)、范围分解(break-down)、范围核实(verification)以及范围变更控制(con-trol),这五个过程是这么定义的。