最近在重新看《軟件工程》，看到敏捷這一章，有一些疑惑和思考，記錄一下

書里面講敏捷的好處： 越到后期，變更的成本越低

我比較困惑，假設(shè)兩種情況，敏捷和傳統(tǒng)模式開發(fā)同一個產(chǎn)品的情況下，來從邏輯上看成本：

情況1： 敏捷和傳統(tǒng)模式采用同樣的技術(shù)設(shè)計，不同點是： 敏捷迭代逐步交付功能；傳統(tǒng)模式把所有功能都做好再交付功能

總成本： 因為是一摸一樣的功能，一模一樣的技術(shù)設(shè)計，一模一樣的團隊，那么開發(fā)的總工作量應該是一樣的，不過因為敏捷是迭代交付的，所以測試、發(fā)布過程會重復多次，從總體成本上面來看，敏捷模式比傳統(tǒng)模式要多

變更成本： 因為一摸一樣的功能，一摸一樣的技術(shù)設(shè)計，一摸一樣的團隊，同樣的變更，變更的開發(fā)工作量應該也是一摸一樣的，所以，在這種情況下，敏捷的變更成本會比傳統(tǒng)模式低，反而總成本是高的

情況2： 敏捷和傳統(tǒng)模式采用不一樣的技術(shù)設(shè)計，不同點在于： 因為傳統(tǒng)模式盡量在最早期統(tǒng)計了所有的需求，所以技術(shù)團隊可以針對盡量多的信息提前做一些統(tǒng)一性的設(shè)計，提高擴展性和復用性；敏捷模式由于希望快速交付可用功能，所以在早期版本的時候沒有過多的考慮未來的擴展性，復用性，而是盡量用簡單的方案快速實現(xiàn)功能，在后期接到新需求的時候，會采用兩種方法：1. 在現(xiàn)有系統(tǒng)上打補丁；2. 重構(gòu)現(xiàn)有系統(tǒng)來適用于新的變化。按照我的經(jīng)驗，打補丁只會增加技術(shù)債務，時間久了重構(gòu)不可避免

總成本： 如果是實現(xiàn)了相同的功能，因為在迭代的過程中，敏捷為了快速交付，不得不打補丁直到重構(gòu)，而傳統(tǒng)模式可以提前計劃好所有功能，省去了重構(gòu)的成本，所以從總成本上來說，敏捷開發(fā)增加了總成本

變更成本： 因為傳統(tǒng)模式會提前應對于可能的變化，所以只要產(chǎn)品沒變（核心邏輯沒有變），傳統(tǒng)模式的提前設(shè)計會讓后續(xù)的變更成本更小，而敏捷快速交付的方式，會因為打補丁重構(gòu)的過程導致后續(xù)變更成本更高

這就是我的困惑，然后我思考了一下，為什么敏捷還這么流行呢？到底敏捷的優(yōu)勢在哪里呢？我的結(jié)論是： 因為敏捷可以更快的發(fā)現(xiàn)你做的是錯誤的產(chǎn)品，也就是： 敏捷在應對“產(chǎn)品核心邏輯變更”或者說是“老產(chǎn)品廢棄”的情況下，比傳統(tǒng)的模式有更大的優(yōu)勢，因為它更早的讓用戶看到了可用的產(chǎn)品，可以更早的知道產(chǎn)品是不是“做對”了，而且省成本的前提是： 采用快速實現(xiàn)+打補丁+技術(shù)重構(gòu)的方式

所以，敏捷適用的場景是： 不知道自己產(chǎn)品核心邏輯是不是正確的情況。如果明確的知道產(chǎn)品核心邏輯就是對的，那就應該在最開始把產(chǎn)品核心模型設(shè)計好，考慮到后來的擴展性和復用，而不要用敏捷的模型

敏捷的正確實踐也應該是：快速交付+打補丁+重構(gòu)的循環(huán)，要不然也沒辦法避免產(chǎn)品核心邏輯錯誤帶來的更大的變更成本