敏捷時代的建模：敏捷團隊的擴張除了代碼還需要什么?(3)

　　擴張

　　極限編程團隊先實現后分解(conquer and divide)，而不是相反(divide and conquer) – Kent Beck在一個不到10個開發者的小型團隊中，你或許不需要在代碼庫之外再去維護某些模型了。但是當開發規模擴大到多個團隊之后，你就會從建模中獲得更大的好處。

　　但請記住，不要僅僅為了將知識傳遞給某個你不認識的人，而花費太多時間去準備繁重的文檔(而沒有編寫任何代碼)。即使團隊的規模變得更大了，你也應該嘗試著首先按照某種簡單的垂直劃分的方式實現某個關鍵用例，將它作為架構的一個示例。隨后，你將這個示例的可工作代碼以及“保留模型”的知識分享給某個子團隊。換句話說，不要嘗試“先分解后實現”某個用例(在桌面上分解問題，隨后將貼在墻上的規格說明丟給某個子團隊并讓他們實現)，而是讓他們“先實現后分解”(關于這一話題的更多討論，請閱讀Craig Larman與Bas Vodde的文章——《大規模敏捷設計與架構》)。

　　這里，我將描述多個團隊如何使用“保留模型”互相交流整個系統的“Big Picture”。首先有一個名為“Tiger”的團隊，它有不足10名成員，他們將嘗試實現第1部分內容。在首次成功的實現之后，他們就可以將之前所述的各種“保留模型”作為良好的文檔，用以互相交流對系統的理解。在Sprint 1中，Tiger團隊首先完成了第一個關鍵用例，它建立起了第一個可作為范例的架構設計，并以此建立了軟件架構文檔(SAD)，作為保留模型的版本1.0。不要把這些模型當做一個規格說明，而是把它們當作建立理解和共識的基礎平臺。再一次記住，不要僅僅把這些文檔的信息簡單地傳遞給子團隊。

　　圖9，Tiger團隊與子團隊

　　溝通設計意圖并達成共識的最好方式，就是與子團隊一起開展一次建模研討會(圖9)

　　(單擊圖片以放大)

　　圖10，建模研討會的進程，在墻上顯示的是保留模型的內容

　　在建模研討會上，Tiger團隊的一名成員Ken(見圖9)首先解釋了SAD，并簡單描述了各個模型。在問答階段，他將核心思想與系統的結構關聯在一起。接下來，他以關鍵用例為例，解釋了各個系統組件如何協作以實現某個用戶目標，并使用這些組件設計出一至兩個關鍵用例，在實現時可以使用臨時模型，并可實行結對編程。

　　無需使SAD顯得非常完整，以研討會的形式建立起共識，拋棄信息傳遞的做法，并開展內容詳實的對話，這就非常好了。

　　反饋是子團隊研討會的一個重要部分。圖9中，子團隊1的Ken與子團隊2的Tom將結果反饋給Tiger團隊，并與其他成員一起討論如何改善這些保留模型。圖11顯示了研討會過程中眾人的各種想法，包括了眾人的理解與反饋。

　　(單擊圖片以放大)

　　圖11，研討會結束后的架構圖，包含了眾人的留言反饋

　　這種研討會的方式需要不斷保持。并且以建模的過程，而不是最終的模型作為促進理解的方式。請記住，要將“模型”作為一個動詞，通過建模以達到對話的目的。

　　人是知識的傳送帶

　　許多設計思想都存在于種族記憶(tribal memory)中——Grady Booch對于開發與維護系統來說，盡管保留模型以及代碼庫能夠覆蓋大部分的必要知識，但仍有一部分隱藏的知識保留在團隊成員的腦海中。Grady Booch將其稱為種族記憶。

　　日本有一所神廟名叫伊勢神宮。其中有一座神廟建筑，建立在兩個相鄰場地的其中一塊，并且兩塊場地具有同樣的大小。每隔20年，他們就會把建筑從一處移至另一處。不僅神廟經過了重新建造，并且它的莊嚴外表與寶庫也得到了翻新。這一儀式將建筑的知識從這一代神廟傳到下一代。雖然沒有任何設計文檔，但通過一起進行重新建造的過程，技術、工具以及實踐知識都得以從這一代傳遞到下一代。記住，“經驗是最好的老師”，并且只有在眾人齊心協力時，才能夠傳遞最豐富的設計知識。

　　伊勢神宮(圖片來源：維基百科)

　　建模的小提示

　　理解了我所介紹的思想與經驗之后，在最后我將提供一些小提示，你可以在每日的建模會議或研討會中用到它。

　　“逆向與模型”，許多UML工具支持“逆向工程”這一特性，它能夠將代碼即時轉換為圖形。其中某些工具支持從源代碼中進行拖放操作，甚至直接支持Github代碼庫的URL。你還可以將從代碼中逆向工程所得的包與類作為進一步建模的基礎。這樣，你就不僅僅可以從保留模型開始建模，還能以代碼庫所生成的模型作為建模的基礎。

　　“打印與繪制”，如同之前所說的，一個具有良好互動性的建模研討會應該在墻上(或者桌面上)貼上幾張大紙，并使用這些紙張開展對話，將心得與反饋直接繪制在這些打印紙上(圖11)。

　　“投影儀與白板”，在研討會上分享模型的另一種方式是使用投影儀與白板，以模擬“打印與繪制”的情況。使用投影儀在白板上展示保留模型，并在白板上繪制各種留言，或者粘上便條貼。

　　“回顧”，我在之前推薦了一些我認為最簡單的保留模型，但每個團隊都可能有不同的情況。因此建議首先從我的建議，或者你覺得合適的模型作為第一部分的保留模型。并在每個Sprint之后為你選擇的模型作一個回顧，討論一下哪些模型起到了良好的作用而哪些沒有，以及另外還需要哪些模型?？傊?，找到你的保留模型。

　　“思維導圖建模“，在與用戶交流時、做計劃時以及其它一些氛圍輕松但非常重要的工作時，UML以及其它軟件工程圖的作用并不理想，這時就可以使用思維導圖了。具體細節請閱讀《敏捷建模與思維導圖和UML》。以下這個示例思維導圖是我為某個用戶創建的，名為“用戶故事探索”。

原文轉自：http://www.kuqin.com/shuoit/20131123/336470.html