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

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

問題

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

方案

以前提到了在時間的角度上，從技術和商業層面上的架構設計，下面看看橫向的架構設計。

方案1：開發人員全體參與架構設計

敏捷開發總體上是一個崇尚「跨職能」的管理方法，開發和測試融合（因此纔有不少相似自動化測試、單元測試、持續集成這些須要開發人員強參與的測試活動），開發與產品融合（開發人員要參與客戶價值分析）等等，因此在架構設計與編碼這兩塊，也不會分得很開，不能有人專門作架構，另一些人專門編寫代碼。

一方面，「架構設計」一旦變成一個文檔，就要被寫，被讀，效率不說，中間難保不發生歧義，所以作架構的人和寫代碼的人在必定程度上融合一下，能大量減小沒必要要的架構設計，尤爲是某些細節。

二方面，文檔或設計自己不是工做產品，在上面投入太多的工做量，極有多是浪費而非保障。

固然問題是：哪些人有能力作架構？

這個問題若是換成：哪些人能夠開一家新的世界500強企業？答案是「大學在校生」（IT界最近的世界500強多數都是在大學裏邊成立的）。因此一樣是這些人，同樣能作架構，只是看怎麼作了。

方案2：用師徒團隊搭建全民架構團隊

若是沒有專門的架構人員和編碼人員，那麼最好的結構就是師傅們作架構，同組的徒弟們將其實現爲編碼。

「這不也是分工嗎？」是的，可是因爲師傅們與你們密切合做，因此他很快就會把架構能力傳遞到徒弟手中，也會逐漸找到一些幫助本身作架構的徒弟，從而讓本身能騰出手來作更大範圍或更高層次的架構。

因爲師傅要爲全組的成敗負責，因此這種傳授過程是由衷的，中間沒有什麼能夠扯皮的。（關於這種機制如何運做若是有疑問，請參考「鬆結對編程系列」）

方案3：商務人員參與架構

一個產品中有三樣東西是核心：商業模式，業務架構，技術架構。

其中業務架構是核心，商業模式是從外界觀察到的業務架構，而技術架構是從技術角度看到的業務架構。怎麼講呢？請看案例。

案例

好比360這個軟件，它的技術架構究竟是什麼？

剛開始，看上去是個單機版的殺毒軟件；後來呢，變成了一個雲查殺；再日後，出現了瀏覽器；又弄了一些五花八門的網絡功能，甚至包括聊天……

若是單獨從技術的角度看，很難把一個單機版的殺毒軟件重構成聊天軟件，除非在早期就有人想到這個軟件往後要用來聊天。誰會在早期知道呢？業務人員。

業務人員能「預知」將來，因此就不要讓開發人員矇在鼓裏，而是提早作好技術準備和儲備，架構的變遷就瓜熟蒂落。

分析

實際上不管質量、進度、成本、架構、客戶價值、賺錢……這些，都應該是「全民」的，至少是儘可能全民的。

不然，天然就會有人沉迷於本身負責的那一部分，而將其餘的置於本身能夠抱怨、對抗的另一個部門，很難把整個事情作好（有我）。

有一家企業在面試等待區會故意放置一個扔在中間的掃把，看哪一個面試者在進入的時候會將其扶起來。很難說咱們是否會須要一個有心把掃把扶起來的程序員，可是咱們的確須要一個能幫助開發組作好架構的業務人員，也須要一個能幫助架構師寫好架構的程序員，還須要能幫助程序員把架構實現出來的架構師……