一旦执行了软件过程评估,我询问项目组成员是如何接受产品的变更需求的,其中一位回答说“无论何时市场代表提出什么变更要求,他们总是说同意,我们就只好努力去做出来”。他并未正面回答我的问题。不被控制的变更是项目陷入混乱、不能按进度执行或软件质量低劣的共同原因。为了使开发组织能够严格控制软件项目应确保以下事项:
- 应仔细评估已建议的变更。
- 挑选合适的人选对变更做出决定。
- 变更应及时通知所有涉及的人员。
- 项目要按一定的程序来采纳需求变更。
只有项目风险承担者在开发过程中能控制变更,他们才知道将交付什么,哪一项将会导致与目标的差距。对项目越深入了解后,你就越能发现采纳变更需求条件的苛刻。在需求文档 1中一定要反映项目的变更,需求文档应精确描述要交付的产品,这就是你的原则。要是软件需求文档同产品不一致,那它就毫无用处,甚至就象没有一个软件需求文档来指导开发组开发一样。
当你不得不做出变更时,应该按从高级到低级的顺序对被影响的需求文档进行处理。举个例子,一个已建议的变更可能影响一个使用实例和功能需求但不影响任何业务需求 2。改动高层系统需求能够影响多个软件需求。如果在最低层需求上做出变更, (典型的情况是一个功能性需求),可能会导致需求同上层文档不一致。
1 控制项目范围的扩展
扩展需求对百分之八十的管理信息系统项目造成风险。扩展需求是指在软件需求基线 3已经确定后又要增添新的功能或进行较大改动。问题不仅仅是需求变更本身,而是迟到的需求变更会对已进行的工作有较大的影响。要是每个建议的需求都被采纳,对于项目出资者(sponsor)、参与者与客户来说项目将永远也不会完成—事实上,这是不可能的。
对许多项目来说,一些需求的改进是合理的且不可避免。业务过程、市场机会、竞争性的产品和软件技术在开发系统期间是可以变更的,管理部门也会决定对项目做出一些调整。在你的项目进度表中应该对必要的需求改动留有余地。若不控制范围的扩展将使我们持续不断地采纳新的功能,而且要不断地调整资源、进度、或质量目标,这样做极其有害。这儿一点小的改动,那儿一点添加,很快项目就不可能按客户预期的进度和预期质量交付使用了。
管理范围扩展的第一步就是把新系统的视图、范围、限制文档化并作为业务需求的一部分,评估每一项建议的需求和特性,将它与项目的视图和范围相比较决定是否应该采纳它。强调客户参与的有效的需求获取方法能够减少遗漏需求的数量,只在做出提交承诺和分配资源后才采纳该需求。控制需求扩展的另一个有效的技术是原型法,这个方法能够给用户提供预览所有可能的实现,以帮助用户与开发者准确沟通.
事实上,控制范围的扩展的方法是要敢于说“不”。很多人不喜欢说“不”,开发者只好在各种压力下接受每一项建议的需求。“客户总是对的”,“我们将使客户完全满意”这些话哲理上是正确的,一旦按此办事就要付出代价。忽视代价并不能改变“变更不免费”的事实。我知道一个成功的商业开发公司,它的首席执行官习惯于建议新的特色但开发管理者总是说“现在不行”。“现在不行”比简单地拒绝灵活很多,因为他暗含在后续版本中采纳其特色的希望。把客户提出的所有特色都采纳将会导致错过提交日期,质量的下滑,开发人员的疲劳不堪。尽管客户并不总对,但他们是上帝,所以你应该尽可能在下一版本中满足他们的需求。
在理想的情况下,在开始构造前应该收集到所有新系统的需求,而且在开发中基本上不变更。这就是“瀑布”型软件开发生存期模型的前提,但在实践中,它却不太有效。当然,某种程度上,对特定的版本应该冻结需求,不再变更。然而,很早确定需求却忽视了有时候客户并不知道需要什么的现实,开发人员应该对用户这些需求变更作出响应。为了对付这些实际情况,你需要有根据地采纳变更过程。
2 变更控制过程
一个好的变更控制过程给项目风险承担者提供了正式的建议需求变更机制。通过这些处理过程,项目负责人可以在信息充分的条件下做出决策,这些决策通过控制产品生存期成本来增加客户和业务价值。你通过变更控制过程来跟踪已建议变更的状态,确保不会丢失或疏忽已建议的变更。一旦你确定了一个需求集合的基线,你应该对所有已建议的变更都遵循变更控制过程。
变更控制过程并不是给变更设置障碍。相反地,它是一个渠道和过滤器,通过它可以确保采纳最合适的变更,使变更产生的负面影响减少到最小。变更过程应该做成文档,尽可能简单,当然首要的是有效性。如果变更过程没有效率且冗长,又很复杂,大家宁愿用旧方法来做出变更决定。
控制需求变更同项目其它配置管理决策紧密相连。管理需求变更类似于跟踪错误和做出相应决定过程,相同的工具能支持这两个活动。然而记住它是工具而不是过程。使用商业问题跟踪工具来管理已建议的需求变更并不能代替写下变更需求的内容和处理的过程。
2.1 变更控制策略
项目管理应该达成一个策略,它描述了如何处理需求变更。策略具有现实可行性,要被加强才有意义。下述需求变更的策略是有用的:
- 所有需求变更必须遵循的过程,按照此过程,如果一个变更需求未被采纳,则其后过程不再予以考虑。
- 对于未获批准的变更,除可行性论证之外,不应再做其它设计和实现工作。
- 简单请求一个变更不能保证能实现变更,要由项目变更控制委员会决定实现哪些变更 。
- 项目风险承担者应该能够了解变更数据库的内容。
- 绝不能从数据库中删除或修改需求变更的原始文档。
- 每一个集成的需求变更必须必须能跟踪到一个经核准的需求变更。
当然,大的变更会对项目造成显著的影响,而小的变更就可能不会有影响。原则上,应该通过变更控制过程来处理所有的变更。但实践中,可以将一些具体的需求决定权交给开发人员来决定。但只要变更涉及两个人或两个人以上都应该通过控制过程来处理。 有一个项目它由两大部分组成,一个是用户集成界面应用,另一个是内部知识库,但缺乏变更过程。当知识库开发人员改变了外部界面但没有将此变更通知应用开发人员,这个项目就碰到了麻烦。还有一个项目,开发人员在测试时才发现有人应用了新的已被修改的功能却没有通知小组中其余人员,导致重做了测试程序和用户文档。采用统一的变更控制方法可以避免这样的问题所带来的错误、开发的返工和耗费时间。
2.2 变更控制步骤
2.3 变更控制工具
自动工具能够帮助你有效地执行变更控制过程。有许多人使用商业问题跟踪工具来收集、存储、管理需求变更。可以使用这些工具对一系列最近提交的变更建议产生一个列表给变更控制委员会开会时做议程用。问题跟踪工具也可以随时按变更状态分类报告变更请求的数目。
挑选工具时可以考虑以下几个方面:
- 可以定义需求变更的数据项。
- 可以定义需求变更生存期的状态转换图。
- 可以加强状态转换图使经授权的用户仅能做出所允许的状态变更。
- 记录每一种状态变更的数据,确认做出变更的人员。
- 可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。
- 可以根据需要生成标准的或定制的报告和图表。 一些商业需求管理工具内置有简单的变更建议系统。这些工具可以通过联系链 4从建议变更找到特定的需求,使得任何时候,无论谁作出需求变更,均可以通过 e-mail及时通知涉及到的人员。
3 变更控制委员会
软件开发活动中公认变更控制委员会为最好的策略之一。变更控制委员会可以由一个小组担任,也可由多个不同的组担任,负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用。典型的变更控制委员会同样决定在哪一些版本中纠正哪一些错误。许多项目已经有负责变更决策的人员,而正式组建变更控制委员、制定操作步骤会使他们更有效地工作。
广义上,变更控制委员会对项目中任何基线工作产品的变更都可做出决定,需求变更文档仅是其中之一。大项目可以有几级控制委员会,有些负责业务决策(例如需求变更),另一些负责技术决策。有些变更控制委员会可以独立做出决策,而有些只是负责决策的建议工作。高级变更控制委员会做出的决策对计划的影响应比低级的大。小项目中,只需一两个人就可做出所有决策。
看到“变更控制委员会”这个词组,会使某些人想到一群高高在上而且浪费时间的官僚分子。然而,应该想到有变更控制委员会的企业结构可以帮助你很好地管理项目,哪怕是一个小项目。这个结构并不浪费时间或是累赘,相反会很有效率。一个有效率的变更控制委员会定期地考虑每个需求变更,并且基于对由此带来的影响和获益做出及时的决策。变更控制委员会只要能让合适的人做正确的事就足够了,不必追求大而全。
3.1 变更控制委员会的组成
变更控制委员会的成员应能代表变更涉及的团体。变更控制委员会可能包括如下方面的代表:
- 产品或计划管理部门。
- 项目管理部门。
- 开发部门。
- 测试或质量保证部门。
- 市场部或客户代表。
- 制作用户文档的部门。
- 技术支持部门。
- 帮助桌面或用户支持热线部门。
- 配置管理部门。
对于小项目只需几个人充当其中的一些角色 5就可以,并不一定要面面俱到。组建包含软、硬件两方面的项目的变更控制委员会时,也要包括来自硬件工程、系统工程、制造部门或者硬件质量保证和配置管理的代表。建立变更控制委员会在保证权威性的前提下应尽可能精简人员。大团队可能很难碰头和做出决策。确保变更控制委员成员明确担负的责任。有时为了获得足够的技术和业务信息,也可以邀请其他人员参加会议。
3.2 变更控制委员会总则
设立变更控制委员会的第一步是写一个总则,描述变更控制委员会的目的、授权范围、成员构成、做出决策的过程及操作步骤。总则也应该说明举行会议的频度
- 制定决策
制定决策过程(程式)的描述应确认:
- 变更控制委员会必须到会的人数或作出有效决定必须出席的人员数。
- 决策的方法,例如:投票、一致通过或其它机制。
- 变更控制委员会主席是否可以否决变更控制委员会的集体决定。
变更控制委员会应该对每个变更权衡利弊后做出决定。 “利”包括节省的资金或额外的收入、增强的客户满意度、竞争优势、减少上市时间。“弊”是指接受变更后产生的负面影响,包括增加的开发费用、推迟的交付日期、产品质量的下降、减少的功能、用户不满意。如果估计的费用超过了本级变更控制委员会的管理范围,上报到高一级的委员会,否则用制订的决策程式来对变更做出决定。
交流情况 一旦变更控制委员会做出决策时,指派的人员应及时更新数据库中请求的状态。有的工具可以自动通过电子邮件来通知相关人员。若没有这样的工具,就应该人工通知,以保证他们能充分处理变更。
重新协商约定 变更总是有代价的。即使拒绝的变更也因为决策行为(提交、评估、决策)而耗费了资源。变更对新的产品特性会有很大的影响。向一个工程项目中增加很多功能,又要求在原先确定的进度计划、人员安排、资金预算和质量要求限制内完成整个项目是不现实的。当工程项目接受了重要的需求变更时,为了适应变更情况要与管理部门和客户重新协商约定。协商的内容可能包括:推迟“交货”时间、要求增加人手、推迟实现尚未实现的较低优先级 6的需求,或者质量上进行折衷。要是不能获得一些约定的调整,应该把面临的威胁写进风险管理计划中,这样当项目没有达到期望的结果时就不会有人惊奇了。
4 测量变更活动
软件测量是深入项目、产品、处理过程的调查研究,比起主观印象或对过去发生事情的模糊回忆要精确得多。测量方法的选择应该由所面临的问题和要达到的目标为依据。测量变更活动是评估需求的稳定性和确定某种过程改进时机的一种方法,这种时机可以减少未来的需求变更。需求变更活动的下列方面值得考虑:
- 接收、未作决定、结束处理的需求变更的数量。
- 已实现需求变更(包括增、删、改)的合计数量(也可以用在基线上占需求总数的百分比来表示)。
- 每个方面发出的需求变更的数量。
- 每一个已应用的需求(是指已划过基线)建议变更和实现变更的数量。
- 投入处理变更的人力、物力。可以先用简单的测量法在组织中建立氛围,同时收集有效管理项目所需的关键数据。获得经验后就可以建立复杂的测量方法来管理项目。
因为需求在不断变化,所以不必在定基线前知道实现的变更需求数量。然而,一旦划好了需求基线,应遵循变更控制过程来处理建议的变更,并开始跟踪变更的频率(需求的稳定性)。这种图表的最终趋势应为零。持续高频率的变更隐含了项目超期的风险。同样也表明原来需求的基线确定不完善,应该改进需求获取的策略。
一个项目管理者应该知道频繁的需求变更会使产品不能按时交付。可以通过跟踪产生需求变更的来源深入剖析这个问题。项目管理者就可以与市场代表和项目组一起讨论采取何种措施来减少销售部门提出的需求变更。以数据作为这种讨论的出发点比盲目地开一些面对面的会议更有建设性。
现实中的软件项目均有需求变更。严格控制变更管理策略可以减少变更造成的混乱,改进的需求开发 7技术可以减少面临的需求变更的数量。效率高的需求获取和管理策略将增强按时交付的能力。