『焦不离孟,孟不离焦』 — 谈增量与迭代

『增量』与『迭代』是scrum流程中很重要的核心观念。很多scrum开发过程中的活动,也都是为了这两个观念而设计。实际运作时,有人只增量而不迭代,或是只增量的吗?有啊!不只有,还很多。这么说吧,就算你是运行scrum一段时间的专业团队,还是有可能因为种种内外在原因,而不小心有所疏漏,忘了其中一项。

迭代

任何工作法都是为了解决特定的问题。迭代工作法解决的是『人会出错』的问题。我们不要求在工作规划阶段就能掌握所有细节,也不需要正确预测未来市场发展,更不要求执行者一开始就做出完全正确的商品。我们知道人会犯错,所以我们接受错误的事实,针对错误做调整,再来看看哪里不够好,再调整。就像Essential Scrum的作者Kenneth S. Rubin说的一样:『我这本书就是写完初稿后,在从头到尾审视一遍,有些章节甚至重写了好几遍。』

迭代工作方法最大的特色就是,随着一次又一次的迭代过程,会产生品质越来越高的产品。而其缺点,则是你其实不知道你应该要迭代几次。

增量

增量工作法要解决的,则是『我不知道该做到哪里才停』的问题。不像传统计划是工作流程。在实际工作上,有很多商品在开发初期是完全不知道产品最终的样貌的,只有一个概略的规划和方向而已。于是,我只好先做一部份出来看看,再慢慢增加新功能。修改错误时也是一样,因为修改也需要时间,于是我优先修改一部份(通常是最重要的部分),再来慢慢修改其他的。简单来说,我先把所有组件实作一部份功能(并且是正确的),再把这些组建拼起来变成一个可运作的商品拿去交付。接着下一次再补上其他功能,在下一次再补一些,…,这样重复地持续,直到有一天客户说:『我觉得可以』,这时我们的工作就算告一段落了。

https://ithelp.ithome.com.tw/upload/images/20171223/20107429R6WDXU0Pa8.jpg

然而,增量式开发却有可能因为分段建构的关系,让开发者产生『见树不见林』的副作用。

焦不离孟孟不离焦

所以,『增量』和『迭代』彼此互补了各自的盲点。增量让迭代逃离『看不到终点』的窘境,而迭代则解决了增量『见树不见林』的问题:这两个人是不能单独存在的。正因为如此,scrum的流程才会设计出『冲刺』的概念,每一个短期冲刺只做一部份的工作,但是结束后要有一个完整的『可行性商品』,接着再规划进行下一次冲刺,长期并持续地改善商品。

『增量产出,持续改善』,把握这两个原则,那么你离高品质的敏捷开发也就不远了。