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

    能够预见到的是，需求的每次迭代都会不同程度的对项目产生影响，对此需要评估由此所带来的成本。不只是项目经理和需求分析工程师，软件工程师和测试工程师也应该参与这个过程，评估此次迭代是否会影响现有的技术架构，哪些功能点可能受到影响，哪些系统模块需要修改，测试用例是否应该重新编写，团队需要为此次迭代额外付出多少时间成本，是否会造成项目的延期等等。

    评估之后，如果需求迭代对项目的进度可能造成比较明显的影响，项目经理应该和客户有效沟通，告知需求迭代的成本，尤其是时间成本。

    另外，需求的每次迭代也必然给项目带来一定的风险，包括技术风险和发布风险。迭代后的需求可能影响原有的技术方案，尤其是核心业务逻辑的变更。团队要重新对技术方案进行梳理，检查该技术方案是否仍然可以达到既定的目的。需求迭代之后，软件工程师需要一定的时间调整开发进度，测试工程师也需要根据新的需求对系统重新测试，这必然影响项目的发布周期；作为项目经理，应该预见到这一点。

    GS项目是某公司重点研发的一个以政府机关行政审批业务为服务目标的产品，在其进行产品升级改造的同时，其竞争对手也在着手准备同类产品的新版本发布，市场的压力要求产品尽快完成版本的升级。但是在新产品即将进入集成测试阶段的时候，公司突然决定对产品的界面进行比较重大的调整。这一次调整导致代码和测试的返工，使该产品的发布时间推迟了两个月，错过了销售的黄金期，市场和客户对于新产品的期待已经逐渐降低，结果产品的销售量远远不如预期。如果公司之前对界面需求迭代有比较清晰的成本和风险评估，那么应该不会这么仓促的触发迭代。

    Diapers项目团队意识到Diapers项目的需求迭代的周期是比较短的，因此对于每次迭代的需求，软件工程师和测试工程师都会协同项目经理进行评估，判断消化所有需求并测试所需要投入的工作量，以及由此所可能带来的时间成本和技术风险，团队成员已经彻底摆脱了害怕需求迭代的心态。

    明确项目发布的需求边界

    软件不是十全十美的，需求的迭代是永无止境的。需求的迭代周期是不定的，与其在最终版本中包括所有的需求，不妨在这期间发布若干个小版本，明确每个小版本的需求边界。这好比长跑途中的若干个里程碑，每跨过一个里程碑就意味着向重点又前进了一步。

    每个小版本都包含有限的功能需求，测试工程师可以针对这些功能需求同步展开测试工作，提早触发Bug，尽量争取测试时间。客户也可以从这些小版本中提前看到真实系统的雏形；随着版本的逐步升级，项目距离发布日期也越来越近，和需求的差距也越来越小。

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