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

我們都看過有關項目失敗的統計資訊，也可能親自遭遇過失敗。大多數軟體項目都逃脫不了失敗的命運。思考一下，我們會發現導致項目失敗的方式有（顯然這個列表並不詳盡！）：

工作方式上的：

• 團隊不理解提供的需求
• 提供的需求並不正確

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

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

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

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

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

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

1. 理解

• a. 我們瞭解問題領域嗎？
• b. 我們是否通曉解決方案領域？
• c. 我們知不知道兩個領域之間該怎樣轉換？

2. 溝通

• a. 利益相關者能不能把需求傳遞給確定解決方案的那些人？
• b. 確定解決方案的人在彼此溝通時能不能把解決方案的細節描述清楚？
• c. 確定解決方案的人能把挑戰和替代方案準確地告訴利益相關者嗎？

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

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

與其把錢砸在一堆工具上（我敢肯定這種投入非常可觀！），並試圖採用命令方式和全方位的流程，還不如讓我們用不同的方法。讓我們更重視人、溝通、互動，來應對變化、交付軟體。怎麼才能用這種方法給人們提供最好的支援呢？

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

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

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

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

1. 敏捷建模遵循敏捷宣言和原則。正因為如此，敏捷建模可以是一種實踐，你可以把它添加到你的敏捷工具箱裡。
2. 模型能用來溝通和理解。
3. 我們力爭用簡單的工具建立簡單的模型。擁抱簡單。
4. 我們知道需求是變化的，因此我們在建立模型的時候要擁抱變化。
5. 我們的重點是交付軟體，而不是交付模型。模型能帶來價值的時候，我們就使用它們。如果模型沒有價值、不能加速軟體的交付，那我們就不建立它們。
   
6. 我們只保留需要的模型。如果模型完成了它的使命，我們就可以把它扔掉。這能讓我們輕裝上陣，而不會陷入繁忙的工作。
7. 我們使用多種模型。我們使用模型時會考慮不同的角度和抽象層次，還有不同的讀者。對於我們建立出來的所有模型，我們都知道它的讀者是誰、要達成什麼目標。要是我們還沒理解目標，我們就不會建立模型。
8. 根據具體情況、讀者和目標的不同，我們會結合著用非正式和正式的模型。比如說，一個模型可以由多個簡單圖形組成，用來說明系統的隱喻，也可以用UML的類圖。

總結

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

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

在這個系列的第二部分，讓我們一起更深入地研究一下敏捷建模的價值觀、原則和實踐吧。

資源

AgileModeling.com：Scott Ambler建立、維護的敏捷建模首頁，裡面的資源又好又詳細。

敏捷建模的要點： 這個工作坊主要提供敏捷建模的基本技能。

規範敏捷交付（Disciplined Agile Delivery）：提供敏捷交付規範方法的社區網站。

關於作者

Lee Ackerman是The Emphasys Group的產品副總裁和CTO。Lee多年來主要調查、評估新理念，設計、開發解決方案，其他人做這些事情的時候他也會伸出援手。他目前的工作重點是協助一些組織，讓他們藉助自動化、重用和敏捷最佳實務去提升交付軟體的能力。

[1] 《IT項目：超支400%，卻只實現了25%的收益》：這篇新聞研究了IT項目風險和一些失敗相關的驚人資料。

查看英文原文：Agile Modeling: Enhancing Communication and Understanding

註：文章系本人原創：發佈於