『增量』與『迭代』是scrum流程中很重要的核心觀念。很多scrum開發過程中的活動，也都是為了這兩個觀念而設計。實際運作時，有人只增量而不迭代，或是只增量的嗎？有啊！不只有，還很多。這麼說吧，就算你是運行scrum一段時間的專業團隊，還是有可能因為種種內外在原因，而不小心有所疏漏，忘了其中一項。

迭代

任何工作法都是為了解決特定的問題。迭代工作法解決的是『人會出錯』的問題。我們不要求在工作規劃階段就能掌握所有細節，也不需要正確預測未來市場發展，更不要求執行者一開始就做出完全正確的商品。我們知道人會犯錯，所以我們接受錯誤的事實，針對錯誤做調整，再來看看哪裡不夠好，再調整。就像Essential Scrum的作者Kenneth S. Rubin說的一樣：『我這本書就是寫完初稿後，在從頭到尾審視一遍，有些章節甚至重寫了好幾遍。』

迭代工作方法最大的特色就是，隨著一次又一次的迭代過程，會產生品質越來越高的產品。而其缺點，則是你其實不知道你應該要迭代幾次。

增量

增量工作法要解決的，則是『我不知道該做到哪裡才停』的問題。不像傳統計畫是工作流程。在實際工作上，有很多商品在開發初期是完全不知道產品最終的樣貌的，只有一個概略的規劃和方向而已。於是，我只好先做一部份出來看看，再慢慢增加新功能。修改錯誤時也是一樣，因為修改也需要時間，於是我優先修改一部份（通常是最重要的部分），再來慢慢修改其他的。簡單來說，我先把所有組件實作一部份功能（並且是正確的），再把這些組建拼起來變成一個可運作的商品拿去交付。接著下一次再補上其他功能，在下一次再補一些，...，這樣重複地持續，直到有一天客戶說：『我覺得可以』，這時我們的工作就算告一段落了。

然而，增量式開發卻有可能因為分段建構的關係，讓開發者產生『見樹不見林』的副作用。

焦不離孟孟不離焦

所以，『增量』和『迭代』彼此互補了各自的盲點。增量讓迭代逃離『看不到終點』的窘境，而迭代則解決了增量『見樹不見林』的問題：這兩個人是不能單獨存在的。正因為如此，scrum的流程才會設計出『衝刺』的概念，每一個短期衝刺只做一部份的工作，但是結束後要有一個完整的『可行性商品』，接著再規劃進行下一次衝刺，長期並持續地改善商品。

『增量產出，持續改善』，把握這兩個原則，那麼你離高品質的敏捷開發也就不遠了。