敏捷建模：增強溝通和理解

　　我們都看過有關項目失敗的統計信息[1]，也可能親自遭遇過失敗。大多數軟件項目都逃脫不了失敗的命運。思考一下，我們會發現導致項目失敗的方式有(顯然這個列表并不詳盡!)：

　　技術上的：

　　解決方案不能滿足項目需求(可伸縮性、性能、可靠性、成本等)

　　由于一些技術難題，我們不停推遲最后期限(或者靠增加成本保證期限)，直到項目發起人對項目失去信心并撤資

　　工作方式上的：

　　團隊不理解提供的需求

　　提供的需求并不正確

　　如果我們把這個問題抽象到一個高層次的視圖，可以發現理解問題并形成解決方案是有困難的。

　　不過這個視圖過于簡化。從問題得出解決方案，我們不應該把這個過程看成是信息的單向流動，也絕不能把它看成是一次性、瀑布式的過程。這種做法我們先前都見過，它的進展并不順利。

　　那來更新一下視圖，我們發現問題和解決方案之間互有信息流，而且需要迭代。

　　現在的認知已經清楚一些了，不過它仍然很簡單。讓我們更進一層。我們都需要認識到，開發是一項團隊活動。我們會有多個利益相關者，負責設計、開發、部署和運營的人也不少。

　　這樣我們對這種情形有了更為真實的認識。不過值得思考的空間還是很大。雖然我們力求有一個本地協作的團隊，但事實上我們的工作是分布式、網絡化的。

　　總結一下這個過程，會發現項目的成功受限于我們的如下能力：

　　1. 理解

　　a. 我們了解問題領域么?

　　b. 我們是否通曉解決方案領域?

　　c. 我們知不知道兩個領域之間該怎樣轉換?

　　2. 溝通

　　a. 利益相關者能不能把需求傳遞給確定解決方案的那些人?

　　b. 確定解決方案的人在彼此溝通時能不能把解決方案的細節描述清楚?

　　c. 確定解決方案的人能把挑戰和替代方案準確地告訴利益相關者么?

　　此外，還要認識到一個棘手的問題，就是我們需要處理地理和時間的問題(比如工作地點和時區)。

　　解決這些問題的方法有很多，它們也能增加項目成功的勝算。但我們應該從哪里開始呢?從敏捷的一些基本理念(宣言、原則和部分常識)入手是個不錯的主意。

　　與其把錢砸在一堆工具上(我敢肯定這種投入非?？捎^!)，并試圖采用命令方式和全方位的流程，還不如讓我們用不同的方法。讓我們更重視人、溝通、互動，來應對變化、交付軟件。怎么才能用這種方法給人們提供最好的支持呢?

　　一種常被忽視、低估或誤解的關鍵技術是建模的使用——尤其是我們開始采用敏捷方法之后。在反對重量級的流程和以工具為中心的開發過程時，建模也受到了牽連。讓我們花幾分鐘時間來澄清一下……

　　我們先統一一下對建模的定義。簡單說來，建模是對現實的簡化。就是這樣，不過如此。它并不意味著要用特定的符號、工具和流程。我們只是想研究復雜的東西，讓其中的一些部分易于理解。正如他們所說，有時候你是見木不見林。不必要的細節反而會讓情況更加難以理解。最好還是隱藏那些不必要的細節，只專注于具體情況的重要方面。

　　如果對建模的定義達成一致了，那我們就深入一步，考慮下敏捷建模吧。利用敏捷建模，我們可以用一種敏捷的方法去借助模型進行理解和溝通。很抱歉在這里進行了循環定義，但這很容易讓我們提出問題：“使用模型的時候，我們怎么采用敏捷方法?”

　　和一般的敏捷開發一樣，我們用一套價值觀、原則和實踐來進行指導，以便盡可能地敏捷。敏捷建模方法的重點有：

　　敏捷建模遵循敏捷宣言和原則。正因為如此，敏捷建?？梢允且环N實踐，你可以把它添加到你的敏捷工具箱里。

　　模型能用來溝通和理解。

　　我們力爭用簡單的工具創建簡單的模型。擁抱簡單。

　　我們知道需求是變化的，因此我們在創建模型的時候要擁抱變化。

　　我們的重點是交付軟件，而不是交付模型。模型能帶來價值的時候，我們就使用它們。如果模型沒有價值、不能加速軟件的交付，那我們就不創建它們。

　　我們只保留需要的模型。如果模型完成了它的使命，我們就可以把它扔掉。這能讓我們輕裝上陣，而不會陷入繁忙的工作。

　　我們使用多種模型。我們使用模型時會考慮不同的角度和抽象層次，還有不同的讀者。對于我們創建出來的所有模型，我們都知道它的讀者是誰、要達成什么目標。要是我們還沒理解目標，我們就不會創建模型。

　　根據具體情況、讀者和目標的不同，我們會結合著用非正式和正式的模型。比如說，一個模型可以由多個簡單形狀組成，用來說明系統的隱喻，也可以用UML的類圖。

　　總結

　　我們創建軟件解決方案時，建模有助于我們進行溝通和理解。因為在交付軟件解決方案的時候，溝通和理解是最關鍵的兩個環節，所以不應該忽略建模這一有價值的工具。

　　消除對建模的誤解吧，把它融匯到你的敏捷工作當中。敏捷建模遵循敏捷價值觀和原則，應該成為敏捷工具箱里的實踐之一。敏捷建模成為工具箱的一員后，會提高項目成功的勝算!

原文轉自：http://www.kuqin.com/software-engineer/20120422/320094.html