在传统的基于瀑布的开发模型中。基本的过程 需求-设计-开发-测试,在实践中大家往往提的最多的就是需求问题。需求问题一类是由于需求分析本身的完整性和准确度不足;另一类,就数需求传递中的问题。尽管要求安排评审,还要求需求人员写的尽量的细,但是大家往往发现,后面开发人员还是要与需求人员讨论,测试也需要去再学习。需求人员也很苦恼,我已经写这么细了,怎么还不清楚。研发人员认为,需求人员写这么粗,等真正实现时才发现很多问题没描述清楚。负责任一点的,会去找需求人员讨论。很多可能就是按自己的理解来做了。
在需求模糊时间紧急的情况下;需求人员也不能将需求细化到每一个细节,产品人员也不能给出详细的设计图;开发人员得到的只是简介的需求说明,开发人员也无从着手开发,此时需求人员不知道开发人员看到需求能够理解到什么程度,开发人员有可能根据对需求的理解不够清楚导致走弯路,这样会影响项目的进度和质量。
可能几种方案
A、需求人员直接将需求细化到每一个细节,产品人员给出详细的设计图。
B、需求人员给出简介的需求,开发人员给出需求确认书包含文字说明和设计图。
评价:
A方案
按照业界的流程,详细需求分析用了较长的时间,而且给出了详细需求和设计图之后,留给开发人员的时间很短,难以在很短的时间内很快地消化这些需求和设计。
B方案
1. 需求人员给出简要的需求,为需求方节省出多余的时间交给开发人员;同时开发人员和需求人员同时开始对需求细化和分析。
2. 开发人员可以对需求进行细化到开发中,根据以往的开发经验可以提前预料到一些可以避免bug,这样在后续的开发中可以很顺手、思路也更清晰,
3开发人员将需求确认书给需求人员确认时,如果有不合理或错误的地方马上和开发人员进一步沟通,再次确认后,迅速达到需求沟通一致;
4 开发人员负责对各自的模块的需求确认,也同时在需求确认中加入一些关键设计点和设计思路;
在实践中对于xx项目中验证,未使用需求确认书,对于大部分功能实现完后都有偏差需要从新修改。在yy项目中验证,使用需求确认书后对于需求与实现效果可以得到很大的提升,减少了项目的需求理解偏差和避免了许多的被推翻的工作。
xx平台项目中在没有使用需求确认书的任搜模块开发,开发完后的需求理解不一致,到开发完成后才发现,总体质量评价只能达到70%;后面yy项目中对任搜模块进行改进,使用了需求确认书后,在保证需求理解一致得到情况下,开发质量和开发进度可以得到很大的提升;
1、开发人员之间负责各个模块,责任明确,避免需求方和开发人员推诿的情况发生。
2、开发人员在进行需求确认后,思路清晰一气呵成,减轻了反复沟通导致阻塞开发人员工作,有利于把事情一次性做对,更好地把控工作质量。
3、可以大大的提高开发人员各方面的能力,如设计、沟通、思考、编写文档;
4、可以提高对项目进度的把控;当开发人员对一个业务功能十分理解后可以更有效地评估开发时间。
5、按时保质保量完成开发任务,并得到客户的表扬。