在20世纪90年代后期,IT发现了原型概念,并将其应用于应用开发。原型模型是迭代过程的前身——小规模设计和构建,在组件中快速完成,然后测试和调整组件。和现今的迭代方法一样,这个前身是一个好主意,但实际上并不奏效。调整通常需要比预期更长的时间,业务用户经常失去耐心,这一概念从未被广泛接受。
在二十世纪初期,迭代过程被采纳为业务流程管理(BPM)的一个中心原则,BPM本身是从业务再造中发展而来。大概在同一时间,IT重新设计了原型模型,而这一次,将其作为设计和解决方案的“迭代”嵌入到敏捷软件开发方法中。
所以,再一次的,我们使迭代成为一个主流过程,并再次获得各种结果。
在我们进一步讨论之前,我想清楚地说明我是迭代方法的支持者——我只是希望它能正常工作,真正有帮助。
但实际上,根据历史,迭代过程有好有坏。
让我们先来讨论一下缺点,最后以优点结束。
迭代过程中的问题
有一个谬见,认为迭代可以使项目更早完成。我,以及很多专业人士都没听说过迭代确实节省时间的项目。(当然,肯定有人可以证明迭代可以节省时间,但我并不认识。)我知道有评价团体赞扬了敏捷方法,然而,迭代,却被报告有难以置信的70%的项目失败率,BPM相关项目则更高。值得注意的是,很多这些项目最终都取得了成功,一旦它们完成了永无止境的设计、构建、评估和重新设计的迭代工作。
那么在迭代过程中,我们需要怎样做,才能缩小谬见与现实之间的差距呢?我们首先来讨论我亲身经历过的几个迭代现实。
无休止:迭代可以不断进行,不断扩展解决方案的设计和构建,远远超出预期。在迭代中,并不是为了第一次就让新的设计起作用——目标是快速,并且“灵活”,然后通过多次迭代进行改进。对于更倾向于分析的管理者,解决方案总是可以更好,永远没有尽头。在这种情况下,管理者认为下一次迭代会比这一次更好。
风险增加:每当团队创建新的迭代模型时,必须对其进行全面重新检查——如果没有,交付有问题的产品的风险,随着每个模型而增加。这再次延长了构建解决方案所需的时间。这是一种反复试验的方法,最终会带来一个很好的解决方案,但它可能不是最有效的方法。
中断:在某一截点,宣布成功,并安装解决方案。但迭代过程还在继续,因为已经安装的可能并不完整。这会导致业务中断,因为部分解决方案或者不同版本不断实施,再次发生改变。
混乱:经过几次解决方案的迭代,没有一个员工知道他们应该做什么或应该怎么做。最后的结果就是业务人员和经理的沮丧。
用模拟控制迭代次数
迭代是一个很好的概念,当被正确使用和控制时,可以很好地起作用。
对于一些CIO和应用开发领导者来说,这种“正确的方式”需要将业务和IT BPM相关的概念,方法和技术相结合,来最好地解决每个问题。 然而,在将BPM方法(通常是瀑布型方法)和IT BPM方法(通常是基于敏捷的方法)相结合时,关键是设置机制来控制迭代次数,以及每次迭代的预期。
在这部分讨论中,我假设应用解决方案开发团队能够创建满足业务和技术需求的应用。这个假设意味着应用将提供所需的服务。这并不意味着应用解决方案的运行完全顺利,或者如预期般有效。这也不意味着应用解决方案是灵活的或完整的。也不意味着应用解决方案消除了复杂性。
但这些需要迭代的问题可以有效地处理。在IT BPM和业务BPM方面,我建议团队考虑使用模拟建模来评估每个迭代设计。模拟工具将指出瓶颈,解决方案在不同工作负载下如何工作,以及设计中的许多其他问题。
使用模拟结果,重点关注设计改进,团队不断优化设计。这样,改进评估是基于严格的模拟效率评估,而不是“让我们试试,来看看结果。”最终,迭代次数受到控制,需要的次数更少。同时,这种方法也产生了更好的业务设计。
让迭代过程更顺利
当交付目标产品或服务的概率很高时,当模拟和财务评估表明业务的工作流程和其他方面最优时,说明新的业务流程模型,是起作用的。将现有的状态模拟结果与新的解决方案的运营模拟相比较时,团队还能够预测项目效益——使用新运营(工作流程)时,通过新设计,消除业务问题可以节省的成本,通过消除或减少错误可以节省的成本。
一旦业务流程模型在使用模拟工具时,可以证明有效和高效,那么这些应用可以由BPM套件(BPMS)工具生成。假设使用BPMS工具,可以生成“straw man”版本的应用。
此外,使用传统测试技术,“stub”来测试应用,模拟将数据传递给另一个应用,和“驱动程序”来模拟解决方案系统从其他应用接收数据的情况,可以进一步优化模型和解决方案设计,以确保支持计算机应用的工作流程和运营,可以完成目标结果。
在BPM项目中应该考虑stub和驱动类型的迭代——特别是那些由BPMS工具支持的项目。至于业务设计迭代过程,stub和驱动类型迭代必须计划和仔细的控制。此外,业务设计迭代,当正确管理时,该项目测试和修改周期可以带来更好的结果。
总而言之,控制迭代的这两个方法,消除了业务流程开发中的许多固有问题,让团队可以更快地创建更好的结果。