敏捷開發智慧型敏捷系列之三做不做架構設計？

這是敏捷開發智慧型敏捷的第三篇。（之一，之二，之三，之四，之五，之六）

甲：「敏捷不應該寫架構設計，應該每個迭代都是相同的，才能達到自相似性（這是ken shweber說的）。」

乙：「如果不寫架構設計，很容易返工，早晚還得重來。」

甲：「大不了重構，這是敏捷開發重要的實踐。」

乙：「重構？重構的成本很高的，做幾個迭代，後面重構都重構不過來了。」

甲：「架構設計寫了很容易過度設計，而且在編碼的時候還很容易全部推翻重來；。」

這個架構文件要不要寫呢？寫，為什麼？不寫，為什麼？寫，怎麼寫？不寫，怎麼不寫？

先把話說絕點，敏捷就是不寫架構設計。那為什麼不寫架構設計？

還是為了減少浪費。

敏捷有兩個理由認為寫架構設計是浪費時間。

第一，業務需求是多變的。之前的架構寫得再好，中間需求一變，架構還的改動，費時費力；很多需求可能是無用的，早期可能規劃了，後期又會發現用不上，如果架構裡邊考慮了這些無用需求，就會過於龐大。

第二，架構設計很難判斷是否正確、完備。這個本人也很有體會，本來以為很好的設計，到了編碼的時候發現不是那麼回事，這時候就得從頭翻騰。評審一下如何？可惜，除了最終的軟體，多數需求、架構、測試用例……都很難評審，評審半天，問題還是很多。

敏捷的這些假設，整體上非常普遍，可以說是在嘗試「做好架構」而不得之後的妥協。

不在那些總是改來該去，還不知道是否可行的東西上浪費時間，是敏捷不做架構的出發點。

但是如果徹底不寫架構設計，又可能返工，怎麼辦呢？當然是本著「最小浪費」原則來做架構設計。

下面是一些寫和不寫的內容：

寫：相對穩定不變的，重構成本很高的，能看出對錯的

不寫：概念性的那不太準的，很容易擴充套件的，說不清對錯的

具體要寫什麼不寫什麼，很大程度上要受到業務穩定性、技術的先進性、人員能力等各方面的影響。

所以，所有架構文件的所有寫法，在每個企業都不相同，不應該問「敏捷開發應該怎樣寫架構文件？」，而是應該問「如果我的業務、技術、人員如此，應該怎樣寫架構文件？」，而若能這樣發問，答案肯定可以自己找到了。

智慧型敏捷的乙個本質方法，是要去理解敏捷這樣做的目的是什麼，而不是敏捷應該怎樣做。

倘若日後出現了先進的架構方法，或許架構就變成一種很容易做、很容易評審、很容易變動的東西，那時候就是另外一種說法了。但敏捷在架構設計這件事情上的本質目標卻永遠不變：減少浪費。

5分鐘又到了，散會。

敏捷開發智慧型敏捷系列之三 做不做架構設計？