敏捷開發一千零一問系列之九：整體架構什麼時機進行？（上）

這是敏捷開發一千零一問系列的第九篇。（之一，之二，之三，問題總目錄）

問題

整體架構設計在什麼時機進行？是每一個迭代作仍是先作完再迭代？

這是少數幾個被提到的技術問題。在兩天的培訓課程以後，最後剩下的純的技術問題通常只佔1/5都不到，多數都是管理問題，而管理問題中，又基本上是人的管理問題，這也說明了在「心法人事物」中，心老是第一位的。

方案

最先想寫成方案一、方案2，但感受有點像說是有不一樣的不少並行方法，以後又改爲步驟一、步驟2，又有點把事線性化了。

如今乾脆寫回成方案123吧，總之越日後的越終極一些，也越難以一步到位。

方案1：Sprint0

對於長期的項目，經常引入「Sprint0」的概念。

Sprint0就是在開始不斷開發功能的衆多Sprint迭代前，先作一個準備工做，大約持續一個迭代的週期。

準備工做的內容五花八門，從團隊組成，項目範圍，到這裏說的架構設計。有些團隊每過一段，尤爲在發佈了重要的版本後，都會從新開一個Sprint0，來分析下一個版本的架構設計。

這樣就可能出現幾種不一樣的迭代變形，最左邊的是最輕量級的（週期短的、架構不重要的），最右邊的則相反。

Sprint1 Sprint2 ... SprintN

Sprint0 Sprint1 Sprint2 ... SprintN ...

Sprint0 Sprint1 Sprint2 ... SprintN Sprint0 Sprint1 .... SprintN ...

實際上爲了解決整體集成和發佈問題，還常常採用SprintN+1的方法。

方案2：制定迭代計劃。

「架構想不全」這個問題，在於不知道將來要作什麼，若是有一個相對清晰的迭代計劃，就會驅動架構的設計走向正確的方向。

正確的方向的重要性遠遠超過「詳盡的設計」，只要架構能支撐將來的迭代計劃，即便不太詳盡，也還能夠每一個階段細化。但若是方向是錯誤的，只會「精確地走向錯誤的地方」。

有了迭代計劃後還有一個好處是架構設計能夠分階段開發了。因爲能預見將來發生的事情，所以也就能在關鍵接口處作好準備，而放心地把某些架構留待幾個月後再作。

方案3：補文檔。

本人正在用的一個方法。

當設計一個交互性很強的產品時（好比遊戲、手機軟件），有不少判斷來自於面對最終產品時的感覺，而不是數據庫結構這類東西。因此有時候不得不先把架構放在內心（不是沒有），把產品作出個雛形，得到感覺後決定是否如此，仍是更改設計。

這種方法經常伴隨巨大的返工（緣由倒不是由於不作架構形成的，作了架構，返工會更多，由於連架構也得返工；不作架構反而減小了返工量），可是對於創新性產品而言，返工不返工不是評價成敗的主要因素。

等最終結果獲得承認後，會在管理系統中補充被確認的功能的架構。

因爲產品都作出來了，因此文字中能夠引用不少肯定性的數據庫表乃至代碼等，補文檔的過程異常輕鬆。

案例

無。

分析

1. 敏捷的架構設計

以前智慧敏捷中曾經提到過一個問題「敏捷開發爲何不提倡作架構設計」。

在變化決定一切的領域（好比互聯網），提早作一個詳盡的架構的確不是一個好事情，一方面時間不運行，另外一方面等架構實現了，業務也發生了變化。

所以在這些領域工做，要嘗試把架構設計也迭代化，好比方案1表中最右邊的不斷迭代的Sprint0；另一個概念則是簡單性（Simplicity，maxmize the work not done），簡單說就是能不作的事情就推遲作，好比「三個月內不會發布的功能的架構設計」就應該三個月後作。

要作好這些事情，一個前提是不能逃避工做，也就是對如今的我與將來維護產品的人有分別心，「反正我暫時用不到，管他往後誰頭疼沒有架構設計呢」，不然就極度危險。

2. 敏捷地架構設計

每種產品的架構設計方法各不相同，若是把上面「敏捷的架構設計」理解成爲敏捷開發，那麼軍工、航空、銀行這些項目，多半就不適合敏捷開發了。

但若是說一切產品的架構設計，都應該「敏捷地」進行——就是不拘泥於形式，及不追求大而全，也不追求小二瞧，而是要放下這些包袱，輕鬆地分析這個產品到底應該怎樣作架構設計——則基本上防止四海皆准則。

本篇還有一個下篇，會講到「全民皆架構」，又會回到人的管理中來。