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

　　敏捷方法已經成為了當前軟件開發的主流模式，可工作的代碼(以及自動化測試)被認為是團隊最重要的產出。

　　那么是否不再需要建模了呢?UML真的已死?我并不這么認為。

　　在本文中，我將探索在敏捷時代，建模方法依然適用并且扮演關鍵角色的所在。尤其在開發規模擴張到多個團隊后，對整個系統的“Big Picture”達成共識將變得非常關鍵。

　　敏捷中的“設計”在哪里

　　雖然代碼表現了事實，但它并沒有表現事實的全部 – Grady Booch在開篇部分，我將描述一個使用Scrum的敏捷團隊的精簡流程。圖1展示的是一個經過有意簡化的流程，它僅僅保留了關鍵的部分。

　　列舉在“Product Backlog”中的“用戶需求” 。

　　開發團隊從列表中選取一些需求，并在一個較短的迭代(或者一個Sprint)時間內實現它們。

　　每個Sprint結束后，團隊創建了“可工作的軟件”(或者是“增量內容”)，表現為“產品代碼”與“測試代碼”。

　　圖1，簡單的Scrum框架

　　在這個最精簡的框架中，團隊所知的是“Product Backlog”上的“用戶需求”，而產出的是代碼(“產品代碼”與“測試代碼“)所呈現的“可工作的軟件”。這里并未顯式地描述兩者間的設計成果。理想的情況是，這個Sprint所產生的設計意圖作為團隊產出的一部分，已經體現在最終發布的代碼中了。但有些信息是無法用代碼直接表達的。Scrum本身是一種流程框架，它并不有意圖地表現任何設計的部分，但團隊中仍然少不了各種各樣的設計工作。

　　正如Grady Booch所說，“代碼表現了事實，但它并沒有表現事實的全部”。因此如果有些信息無法以代碼形式進行表述或交流，我們將把這些知識財富保留在哪里呢?這正是本文嘗試解答的疑問。

　　寫文檔就不是敏捷了嗎?

　　建模是為了進行對話 – Craig Larman與Bas Vodde對以上問題的一個回答也許是：“在我們的腦海中!”。每日例會、結對編程、設計研討等等互動性的實踐以一種同步的方式持續地將團隊成員的思想進行歸總。但是當團隊開始擴張、或分布在不同地域、或有成員離開團隊時，“腦海中的模型”的內容會被很快遺忘。我們需要以文檔的形式將對系統的共識保存起來，以分享那些僅用代碼形式不易保留及溝通的信息。

　　敏捷方法清晰地闡述了一個觀點，即對話的價值更勝于文檔，因此編寫繁重的設計文檔(它經常會重復代碼中表述的信息)并非正確的途徑。我們應該采取的途徑是只編寫那些使對話更有效的文檔，它應該盡可能保持最簡單的模型集合，與代碼產生互補作用。

　　模型勝過代碼的一個方面是它的可視化表達能力。換句話說，在某些情況下，文字是一種糟糕的交流媒介。圖2表現了文字交流會失效的一種情況(感謝Jeff Patton為我推薦了這本書)。

　　圖2，文字交流的失敗

　　我猜測，這個“悲劇的”蛋糕是在給蛋糕廠家的電話答錄機留言時的誤解造成的(譯注：訂購者的原意是在“Best wishes Suzanne”這一句下方(Underneath that)加上“We will miss you”)、如果訂購者能夠用一張簡單的圖片(配上文字)來表達他的意圖，那絕對可以避免這個悲劇。有些時候，真的是“一圖勝千言”。

　　那么，在敏捷團隊中，該怎樣為了實現目的而有效地使用模型呢?

　　敏捷建模以及兩種模型

　　保留建模，但去掉那些官僚主義的東西 – Scott Ambler“敏捷建模”是一系列可以應用在你的團隊里以實現有效建模與文檔的實踐。這一方法遵循了敏捷價值與原則，并且使你依然可以從建模中受益。這里要強調的是，建模是為了更好地開展對話，而不是僅僅為了信息傳遞。

　　我們的軟件開發團隊已經在使用敏捷建模的實踐與原則，并且發現模型起到的最主要作用是以可視化方式交流系統設計的“Big Picture”或者說是“鳥瞰圖”，這一點是單憑代碼難以表現的。缺乏模型的支持，整個團隊的工作就好似盲人摸象，“四個盲人在摸象，每個人只能感覺到他所觸摸的那一部分，最終花費了許多時間，才把這些部分統一成一個整體：一頭大象!”

　　我的建議是，保持并維護一個反映“Big Picture”的模型，它應該包括以下內容：

　　系統的“架構”，以便于團隊對于整個系統結構有一個初步的認識。

　　“領域模型”將幫助團隊理解問題領域中的各種概念。

　　“關鍵用例”有助于發現系統的典型用戶，并了解他們如何從系統中受益。

　　以上每一點對于建立對系統的理解都是非常關鍵的。缺少了模型的支持，你又怎樣確保達到這種理解程度呢?如果你的代碼庫內容龐大，但只基于你所看到的一小部分不完整的內容推測系統的“Big Picture”，那么你將會對于如何維護整個代碼庫做出糟糕的選擇。“Big Picture”不僅反映了團隊對于系統的理解的模型，并且也構成了他們在對話中以及在代碼中所用到的詞匯，例如代碼的結構，以及各種編程結構的命名方式，包括類、方法、變量、字段、數據、配置等等。換句話說，這些模型不僅對于團隊建立起對系統整體的共識非常重要，同時也促使團隊保持代碼庫的一致性與可維護性。

　　另一方面，某些臨時模型的信息以代碼形式記錄下來之后，這些模型就會被丟棄。這一類別的模型包含畫在白板上的松散類圖，它通常包含一些類以及描述這些類的交互情況的時序圖。這種模型將鼓勵你開展有效的對話，其中產生的各種信息將以代碼形式固定下來，并隨后丟棄。

　　因此這一觀點的核心是將模型分為兩種類別 –應保留模型將作為資產保留維護，而臨時模型則促進了有效的對話。我們將前者稱為“應保留模型”或“保留模型”，而將后者稱為“臨時的模型”或“臨時模型”(圖3)。要注意的是，“保留模型”并不代表“已凍結的”，而是代表“應長期維護的”，并且將持續發展。在下一節中，我將為敏捷團隊推薦三種“保留模型”。

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