需求迭代与项目风险控制[1]

 软件项目是需求驱动的典型代表，项目从立项、开发、测试到交付，需求的变化迭代是很正常的事情，这点对于大型项目尤其明显。需求迭代如果控制不好，很容易增大项目的风险，导致项目的失败。与国内的很多软件公司相似，笔者所参与的项目也存在需求迭代的问题。本文从需求迭代入手，结合项目实际，探讨需求迭代与项目风险控制的关系，希望项目需求有序迭代。

    需求迭代，不可避免的轮回

    软件项目的启动源于市场和客户的需求，通过对市场的需求调查以及典型目标客户的需求访问抽象出需求规格说明书，进而才开始原型系统的设计，经过对原型系统的评估之后启动真实系统的设计和开发。

    在原型系统设计阶段，由于各种各样的因素，比如客户没有将实际需求表达清楚，或者需求分析人员对业务的理解有偏差，据此设计出来的原型系统可能与市场、客户的真实需求不是很匹配，那么随着原型系统构建的深入，必然触发需求的迭代。

    在真实系统的设计和开发过程中，随着对系统的理解的深入，客户也可能对需求进行深化、扩展或者变更，研发工程师对需求的消化，这也会触发需求的迭代。

    即使真实系统交付使用，随着业务的发展，客户的需求可能发生变化；而且客户在使用系统的过程中，必然会对系统提出进一步改进的要求，修改原有功能的操作方式，增加新的功能，这些也会要求需求的进一步迭代。

    在这一系列的迭代过程中，如果没有很好的控制迭代的过程，评估迭代的成本，有效管理迭代的需求，那么很容易形成需求迭代无穷无尽的假象，项目团队穷于应付每一次需求迭代，项目开发高度紧张，发布日期遥遥无期，这样必然给项目带来很高的风险。

    Diapers项目是一个面向北美市场的电子商务站点，已经运行三年。最近客户决定对Diapers项目进行升级改造。项目经理或者需求分析工程师负责沟通客户，分析抽象客户的真实需求，并撰写需求说明书；软件工程师根据需求说明书拟定技术方案，并着手进行编码；测试工程师根据需求说明书和测试用例对项目进行测试；项目经理引导客户确认项目的最终功能呈现，并在必要的时候启动需求迭代过程。

原文转自：http://www.ltesting.net