在二十世纪初期，迭代过程被采纳为业务流程管理(BPM)的一个中心原则，BPM本身是从业务再造中发展而来。大概在同一时间，IT重新设计了原型模型，而这一次，将其作为设计和解决方案的“迭代”嵌入到敏捷软件开发方法中。

所以，再一次的，我们使迭代成为一个主流过程，并再次获得各种结果。

在我们进一步讨论之前，我想清楚地说明我是迭代方法的支持者——我只是希望它能正常工作，真正有帮助。

但实际上，根据历史，迭代过程有好有坏。

让我们先来讨论一下缺点，最后以优点结束。

迭代过程中的问题

有一个谬见，认为迭代可以使项目更早完成。我，以及很多专业人士都没听说过迭代确实节省时间的项目。(当然，肯定有人可以证明迭代可以节省时间，但我并不认识。)我知道有评价团体赞扬了敏捷方法，然而，迭代，却被报告有难以置信的70%的项目失败率，BPM相关项目则更高。值得注意的是，很多这些项目最终都取得了成功，一旦它们完成了永无止境的设计、构建、评估和重新设计的迭代工作。

那么在迭代过程中，我们需要怎样做，才能缩小谬见与现实之间的差距呢?我们首先来讨论我亲身经历过的几个迭代现实。

无休止：迭代可以不断进行，不断扩展解决方案的设计和构建，远远超出预期。在迭代中，并不是为了第一次就让新的设计起作用——目标是快速，并且“灵活”，然后通过多次迭代进行改进。对于更倾向于分析的管理者，解决方案总是可以更好，永远没有尽头。在这种情况下，管理者认为下一次迭代会比这一次更好。

风险增加：每当团队创建新的迭代模型时，必须对其进行全面重新检查——如果没有，交付有问题的产品的风险，随着每个模型而增加。这再次延长了构建解决方案所需的时间。这是一种反复试验的方法，最终会带来一个很好的解决方案，但它可能不是最有效的方法。

中断：在某一截点，宣布成功，并安装解决方案。但迭代过程还在继续，因为已经安装的可能并不完整。这会导致业务中断，因为部分解决方案或者不同版本不断实施，再次发生改变。

混乱：经过几次解决方案的迭代，没有一个员工知道他们应该做什么或应该怎么做。最后的结果就是业务人员和经理的沮丧。

用模拟控制迭代次数

迭代是一个很好的概念，当被正确使用和控制时，可以很好地起作用。

对于一些CIO和应用开发领导者来说，这种“正确的方式”需要将业务和IT BPM相关的概念，方法和技术相结合，来最好地解决每个问题。 然而，在将BPM方法(通常是瀑布型方法)和IT BPM方法(通常是基于敏捷的方法)相结合时，关键是设置机制来控制迭代次数，以及每次迭代的预期。

在这部分讨论中，我假设应用解决方案开发团队能够创建满足业务和技术需求的应用。这个假设意味着应用将提供所需的服务。这并不意味着应用解决方案的运行完全顺利，或者如预期般有效。这也不意味着应用解决方案是灵活的或完整的。也不意味着应用解决方案消除了复杂性。

但这些需要迭代的问题可以有效地处理。在IT BPM和业务BPM方面，我建议团队考虑使用模拟建模来评估每个迭代设计。模拟工具将指出瓶颈，解决方案在不同工作负载下如何工作，以及设计中的许多其他问题。

使用模拟结果，重点关注设计改进，团队不断优化设计。这样，改进评估是基于严格的模拟效率评估，而不是“让我们试试，来看看结果。”最终，迭代次数受到控制，需要的次数更少。同时，这种方法也产生了更好的业务设计。

让迭代过程更顺利

当交付目标产品或服务的概率很高时，当模拟和财务评估表明业务的工作流程和其他方面最优时，说明新的业务流程模型，是起作用的。将现有的状态模拟结果与新的解决方案的运营模拟相比较时，团队还能够预测项目效益——使用新运营(工作流程)时，通过新设计，消除业务问题可以节省的成本，通过消除或减少错误可以节省的成本。

一旦业务流程模型在使用模拟工具时，可以证明有效和高效，那么这些应用可以由BPM套件(BPMS)工具生成。假设使用BPMS工具，可以生成“straw man”版本的应用。

此外，使用传统测试技术，“stub”来测试应用，模拟将数据传递给另一个应用，和“驱动程序”来模拟解决方案系统从其他应用接收数据的情况，可以进一步优化模型和解决方案设计，以确保支持计算机应用的工作流程和运营，可以完成目标结果。

在BPM项目中应该考虑stub和驱动类型的迭代——特别是那些由BPMS工具支持的项目。至于业务设计迭代过程，stub和驱动类型迭代必须计划和仔细的控制。此外，业务设计迭代，当正确管理时，该项目测试和修改周期可以带来更好的结果。

总而言之，控制迭代的这两个方法，消除了业务流程开发中的许多固有问题，让团队可以更快地创建更好的结果。