一次迭代式开发的研究(九):从容应对需求变更

来源 :一次迭代式开发的研究                                                          作者:fangang  


前面我们已经详细描述了一次迭代式开发的完整过程,首先是项目计划的前期分析——工作量评估和优先级评估,然后是制订迭代式的项目计划,最后是按照项目计划执行项目。每天,运用Burn-Down Table监控项目进程,随时掌握项目进度的偏差(是滞后还是超前),然后制订相应的应对方案予以调整,直到最后的项目结束,一切似乎进行得比较顺利。但真实的情况往往不是这样,这里忽略了一个最重要的因素,那就是需求变更。

   如果没有需求变更,我们就不需要采用迭代式开发了,瀑布模型足矣。正如我在第一章谈到的,我们的软件开发存在着风险,这个风险就是需求变更。需求变更无处不在,就如同我们人类面对的浩瀚无垠的宇宙,必须得有防护措施应对可能的风险。需求变更的防护措施是什么呢?那就是采用迭代式开发。那么,迭代式开发是怎样防护来自用户的需求变更呢?我们用一个情景剧来详细解读。

   A先生是一个项目经理,他准备开始一个新的软件开发项目。他首先组织需求人员与客户一起进行了深入的需求调研,进行了详细的需求分析,最后制定出一份需求规格说明书,与客户进行签字确认。同时,他又组织了设计人员,与需求人员进行讨论,将所有的需求进行任务分解、工作量评估,以及优先级评估。随后与公司领导讨论,与客户领导协商,确定项目需要配备的人员、花费的资金,以及所需的时间。最后,一个迭代式的项目计划制订出来。

   万事俱备之后,项目开始进入执行阶段。A先生制作了一个Burn-Down Table监控项目进度,开始了第一个迭代期。一切进行得比较顺利,项目顺利地完成了第一个迭代期的所有任务,顺利提交第一份交付物。正当大家认为项目会一直这样顺利地进行而喜笑颜开时,事情发生了——客户看到第一份交付物时,对一些功能不太满意,对这样那样的功能提出了修改意见,甚至还提出了新的功能——需求变更发生了。

   当客户对需求提出变更时,我们往往第一反应就是记录,然后回去照着做,但很多经验证明这样是不对的。不加分析而草率地修改客户提出的变更需求,是造成客户频繁变更需求的根本原因。我们前面提过,客户提出需求的一个重要特点就是,当软件没有真正设计出来时,客户往往是说不清楚自己的真正需求的。因此,当他再次看到上次提出变更以后修改的内容,很有可能还不满意,这就意味着还要继续改,直到他满意为止。这样,反复修改是再所难免。

   当客户提出需求变更时,我们首先应当弄明白的是客户为什么要提出这样的需求。这时候,需求分析员应当站在使用者角度,站在业务角度,去理解这样的需求,理解其提出来的动机。也许客户在做这个操作时要查看一些相关信息,也许这个数据和那个数据有逻辑关系,甚至其原因就是一个非计算机专业的人看到这个界面不容易理解、有误解,或者操作就有困难。

   当理解了用户提出变更的真实动机以后,随后分析的就是这样的变更有没有必要,可不可实现,或者是否有更合理的解决方案。每次我们都会将一些客户提出的不合理的,或者无法实现的需求变更退回去,并且提出我们的理由。只要遣词得当、理由充分,客户往往能接受我们的建议而取消这些需求(多用建议的语气,少用命令的口吻)。而另一些变更需求,我们常常从用户表面的语言中分析出他们真实的需求,并提出一个更加合理的建议。这样做,客户不仅会欣然接收你的建议,而且会有一种你就是他肚里的蛔虫那种感觉,对你更加信任,你在客户心里的威信也就随之增加。

   当客户提出变更需求,并且经过分析已经确定出修改方案以后,A先生就马上回去组织人员进行设计和开发了,殊不知这将是项目后期出现巨大隐患的重要原因。迭代式开发的正确做法应当是怎样呢?这个问题我们下回详细分解吧。

本文链接:http://www.hihubs.com/article/119

关键字:一次迭代式开发的研究(九):从容应对需求变更

若无特别注明,文章皆为Hubs'm原创,转载请注明出处...O(∩_∩)O

ToolFK 公众号