迭代化开发新问题

这周去拜访一个客户，他们正在实施RUP，问及效果如何，听到了一些关于迭代化开发的新问题。

这位客户是一家集成商，主要为甲方开发应用软件系统。实施迭代化开发的主要目的是控制项目风险，应用项目的最大风险一般都在于需求，采用迭代化可以通过迭代产生的原型系统来收集甲方客户的反馈，从而及早修正对于客户需求的误解。但是开发团队并没有象预想中那样收集到甲方的反馈，甲方还是习惯于用传统的瀑布模型来评价、验收系统，他们并没有对项目过程中交付的原型系统进行认真的确认，所以也没有太多的意见反馈给开发团队，很多需求的变更还是要到系统正式验收时才被提出来。因为在甲方的观念中，他们还不太认可项目结束之前所提交的中间结果。

另外，项目的合同是按照瀑布模型的阶段来签的，需求分析、概要设计、详细设计、编码完成、验收测试是项目回款的里程碑。采用迭代化开发之后，在原定的概要设计交付时间点上，可能需求分析和概要设计都只完成了部分的工作，比原定计划要晚一些；而详细设计和编码工作都已经开始了一部分，比原定计划要提前一些。这样就不能按照原定时间点来要求甲方就需求分析和概要设计那部分工作量付款，对于中国的集成商而言，项目回款是比合同签定都要重要的工作。

这些问题给我们的经验教训是应用项目开发采用迭代化开发流程，也需要让客户理解这一点，项目工作说明书中的工作单元内容也需要跟迭代化开发流程来符合。软件开发流程关系到所有的涉众(Stakeholder)，仅仅是开发团队理解并实施这一流程是不够的。

还有一个反馈来自于很多项目团队，认为迭代化开发概念上听起来很有道理，但在项目中实施后往往感觉不到采用这处方法后对项目有什么太大的帮助。迭代化开发的主要目的在于控制项目风险，常见的项目风险如技术架构、客户需求等等。但是日常工作中的项目往往没有太多的风险，我们开发的往往是重复性的项目，电信事业部做的就是不同运营商的BOSS项目，社保事业部就是为不同省份开发社保系统，虽然有特殊需求，但系统架构和基本需求完全一样；更多的项目是对现有系统的维护性开发，实现客户提出的变更请求和改正软件缺陷，一般不会涉及到系统架构的改动。在这种类型的项目中，迭代化开发体现的不是对风险的控制，而是系统增量式开发而不断给涉众所带来的信心和鼓舞，开发人员可以在较断的时间周期内看到自己所开发的系统可以“跑”起来了，客户则可以看到整个项目在不断地往前推进。