3、需求迭代的特殊性

    迭代式的需求开发并不是意味着需求开发平均分到各个迭代周期来进行。在理论上，应该是先做完需求分析（还有构架设计），再着手进行各阶段的开发工作。可是实际情况中，需求要保持不变可太难了。根据自身的经验，一个项目，在一开始往往可以完成的需求开发可以占全部需求开发任务的80%（估算的数字）。但是在随后的软件开发中浮现出来的需求（新增或改动）又会有20%。可是这20%的需求是极不稳定的，可能分布在项目中期，也可能分布在项目晚期，甚至可能会在项目在部署阶段才会呈现出来，这些都取决于团队的能力。这样的项目的风险其实是很高的，有些较晚才浮现出来的需求可能会花费大量的资源来实现，如果这需求又对软件架构有影响的话，那后果更是灾难性的。

    在XP中，一个迭代周期会包括多张素材卡片（Story Card），一张素材卡片都代表了系统的一项功能（functionality），这些素材卡片由项目负责人和客户、领域专家按照一定的规则，共同从需求集中抽取，决定在本次迭代中实现。一次迭代经过计划、准备素材卡片、分析、编码实现、测试、构建等步骤，呈现在用户面前的将是一个可以运行（can work）的软件。用户可以清晰的看到软件的界面，软件的使用手册，软件的输出结果。一切都是一览无遗的，不需要任何的叙述性的语句来描述软件，因为用户会自己去感受。接下来，用户的反馈意见被收集，分析，处理，必要的需求改变被安排在随后的某个迭代周期中实现。

    单独的迭代可能是线性的，但是从整体上来看，多个迭代周期形成了一个流水线般的生产方式：

　
    所以呢，需求迭代的特殊性在于需求的出现并非是迭代的，但是需求的分析和实现则是迭代的。

    4、迭代的代价
   
    就和计算机中任何的算法都必须寻求空间和时间的平衡一样，迭代方法虽然有其优势，但是同样需要付出代价。

    由于要不断的对软件进行调整，所以软件的架构（Architecture）需要比较稳定，经得起变动。这一点可能在过去比较难，现在的软件架构都相当成熟，都能胜任这种工作。例如J2EE就是一个非常出色的架构。除了架构，系统的框架（Framework）也是非常的重要，框架要足够"软"，这个方面虽然没有现成的框架可以利用，但是业界有很多关于这方面的资料，例如设计模式、分析模式。这些都是告诉你一些经验之谈。都是可以参考和采用的。

    多个的发布版本要求开发团队有控制版本的能力。多个的开发版本如果不加控制到最后必然如同洪水猛兽一般可怕，开发人员的时间都浪费在各个版本的统一上。关于版本控制，有很多的软件都能够完成这一工作。对于比较小的团队来说，简单的目录控制可能就足够了。

    上面画出的迭代示意图虽然好看，要实现可没有那么简单，如果功力不足，画虎不成反似犬，原来安排的迭代计划没有严格执行，结果是更加混乱。这时候就要求团队的项目经理有足够的计划能力，以及团队的配合。

    需求变更，并不是所有的需求都一概接受。对于时间所剩无几的项目，一个简单的需求变更都可能是骆驼身上的最后一根稻草。这就要求团队能够有需求变更的管理能力。

    5、和其它阶段的关系

    在进入细节需求之前，千万要先确定系统的架构。国内的程序员很少会专门去思考这个问题，但是会自发的去做这件事情。比如，你是选用微软的DNA，还是J2EE。这就是架构决策的一种。但是我们并没有重视架构的设计。架构方面的欠考虑，会使得架构的涉众蒙受重大的损失。想想看，一家企业想要改变原有的架构，那是需要多大的成本啊。 由于我们文章的主题是需求，所以架构方面的问题并不在讨论范围之内。但是，请记住，先决定架构，再进入细节需求阶段。当然，这并不是说，进入细节需求阶段就不能改变原先的架构了。原因很简单，亡羊补牢嘛！

    由于细节需求是迭代进行的，所以每一次迭代就像是一个小型的瀑布模型，要经历需求、分析、设计、编码、接受测试、交付等阶段。这样，细节需求实际上是和软件开发过程中的其它阶段紧密相连，其中可能并没有很明显的界限。在下一章中，我们其实可以发现，探究需求活动和其它的活动都是同步进行的。