需求迭代与项目风险控制.doc

需求迭代与项目风险控制 个文章由舜亚科技的 Jimmy 发表在《程序员》 2007.2 期，其中的案例全部引自本公司的项目。 作者介绍：柯自聪 /eamoi 舜亚科技软件工程师，专注于 Web 应用程序开发，关注 OA、门户、电子政务、电子商务领域、 RIA，著有《 Ajax 开发精要 --概念、案例与框架》一书以及《 Ajax 开发简略》、《 LiferayPortal 二次开发指南》等开源文档。 全文： 软件项目是需求驱动的典型代表，项目从立项、开发、测试到交付，需求的变化迭代是很正常的事情，这点对于大型项目尤其明显。需求迭代如果控制不好，很容易增大项目的风险 ，导致项目的失败。与国内的很多软件公司相似，笔者所参与的项目也存在需求迭代的问题。本文从需求迭代入手，结合项目实际，探讨需求迭代与项目风险控制的关系，希望项目需求有序迭代。 需求迭代，不可避免的轮回 软件项目的启动源于市场和客户的需求，通过对市场的需求调查以及典型目标客户的需求访问抽象出需求规格说明书，进而才开始原型系统的设计，经过对原型系统的评估之后启动真实系统的设计和开发。 在原型系统设计阶段，由于各种各样的因素，比如客户没有将实际需求表达清楚，或者需求分析人员对业务的理解有偏差，据此设计出来的原型系统 可能与市场、客户的真实需求不是很匹配，那么随着原型系统构建的深入，必然触发需求的迭代。 在真实系统的设计和开发过程中，随着对系统的理解的深入，客户也可能对需求进行深化、扩展或者变更，研发工程师对需求的消化，这也会触发需求的迭代。 即使真实系统交付使用，随着业务的发展，客户的需求可能发生变化；而且客户在使用系统的过程中，必然会对系统提出进一步改进的要求，修改原有功能的操作方式，增加新的功能，这些也会要求需求的进一步迭代。 在这一系列的迭代过程中，如果没有很好的控制迭代的过程，评估迭代的成本，有效管理迭代的需求 ，那么很容易形成需求迭代无穷无尽的假象，项目团队穷于应付每一次需求迭代，项目开发高度紧张，发布日期遥遥无期，这样必然给项目带来很高的风险。 Diapers 项目是一个面向北美市场的电子商务站点，已经运行三年。最近客户决定对 Diapers 项目进行升级改造。项目经理或者需求分析工程师负责沟通客户，分析抽象客户的真实需求，并撰写需求说明书；软件工程师根据需求说明书拟定技术方案，并着手进行编码；测试工