敏捷是如何优化需求过程的

      在传统的基于瀑布的开发模型中。基本的过程  需求-设计-开发-测试，在实践中大家往往提的最多的就是需求问题。需求问题一类是由于需求分析本身的完整性和准确度不足；另一类，就数需求传递中的问题。尽管要求安排评审，还要求需求人员写的尽量的细，但是大家往往发现，后面开发人员还是要与需求人员讨论，测试也需要去再学习。需求人员也很苦恼，我已经写这么细了，怎么还不清楚。研发人员认为，需求人员写这么粗，等真正实现时才发现很多问题没描述清楚。负责任一点的，会去找需求人员讨论。很多可能就是按自己的理解来做了。

      在需求模糊时间紧急的情况下；需求人员也不能将需求细化到每一个细节，产品人员也不能给出详细的设计图；开发人员得到的只是简介的需求说明，开发人员也无从着手开发，此时需求人员不知道开发人员看到需求能够理解到什么程度，开发人员有可能根据对需求的理解不够清楚导致走弯路，这样会影响项目的进度和质量。

     

可能几种方案

A、需求人员直接将需求细化到每一个细节，产品人员给出详细的设计图。

B、需求人员给出简介的需求，开发人员给出需求确认书包含文字说明和设计图。

评价：

A方案

按照业界的流程，详细需求分析用了较长的时间，而且给出了详细需求和设计图之后，留给开发人员的时间很短，难以在很短的时间内很快地消化这些需求和设计。

B方案

1. 需求人员给出简要的需求，为需求方节省出多余的时间交给开发人员；同时开发人员和需求人员同时开始对需求细化和分析。

2. 开发人员可以对需求进行细化到开发中，根据以往的开发经验可以提前预料到一些可以避免bug，这样在后续的开发中可以很顺手、思路也更清晰，

3开发人员将需求确认书给需求人员确认时，如果有不合理或错误的地方马上和开发人员进一步沟通，再次确认后，迅速达到需求沟通一致；

4 开发人员负责对各自的模块的需求确认，也同时在需求确认中加入一些关键设计点和设计思路；

 

在实践中对于xx项目中验证，未使用需求确认书，对于大部分功能实现完后都有偏差需要从新修改。在yy项目中验证，使用需求确认书后对于需求与实现效果可以得到很大的提升，减少了项目的需求理解偏差和避免了许多的被推翻的工作。

xx平台项目中在没有使用需求确认书的任搜模块开发，开发完后的需求理解不一致，到开发完成后才发现，总体质量评价只能达到70%；后面yy项目中对任搜模块进行改进，使用了需求确认书后，在保证需求理解一致得到情况下，开发质量和开发进度可以得到很大的提升；

1、开发人员之间负责各个模块，责任明确，避免需求方和开发人员推诿的情况发生。

2、开发人员在进行需求确认后，思路清晰一气呵成，减轻了反复沟通导致阻塞开发人员工作，有利于把事情一次性做对，更好地把控工作质量。

3、可以大大的提高开发人员各方面的能力，如设计、沟通、思考、编写文档；

4、可以提高对项目进度的把控；当开发人员对一个业务功能十分理解后可以更有效地评估开发时间。

5、按时保质保量完成开发任务，并得到客户的表扬。

其实大家看看，这个过程就是敏捷开发中的需求澄清的过程。因此，敏捷开发的过程，其实是对传统的过程在特定应用场景特别是在需求模糊，灵活度要求高的情况下，进行了优化的。也为我们做其他的过程优化提供的很好的案例和可借鉴的地方。