軟體開發其實就像工兵掃雷

張恂提出的太極敏捷有一個重要觀點：

風險管理是軟體專案管理的第一管理

與之相關的有一個推論和比喻：

軟體開發、軟體工程（或者軟體專案管理）其實就像工兵掃雷



（來源：百度百科/地雷）

當心這些傢伙，不要讓它們成為你的專案殺手！


在軟體開發和軟體工程中我們一直大量地使用“比喻”、“類比”來闡釋概念、說明道理，而這個比喻過去被我們忽視了，國內外大師和專家們好像都鮮有提及，因此我把它提出來。

在軟體專案管理中，首先會有一個 scope 的概念，伴隨著 scope 有廣度和深度的概念。也就是說，軟體需求有一個範圍，理想的情況是，我們既不要多做，也不要少做，做的內容也正好是客戶所需要的，即 just enough。

現在假設給你 1 平方公里（1000 * 1000 米）的地域，部隊要從上面通過，下面可能存在著威力不同的地雷、炸彈等各種爆炸物，只要任何一顆具有一定殺傷力的地雷發生爆炸都可能造成人員傷亡，導致任務失敗。作為擔負重要使命的工兵，你會怎麼處理？

地雷代表了任何可能導致軟體工程專案失敗的風險，它們具有一些共同的特點，比如隱蔽性，不經過仔細的探查，往往很難被發現，而且一旦沒有被排除，在人員沒有防備的情況下被觸發、引爆，就可能造成較大的損失。典型的地雷包括，客戶提出的需求在技術上根本無法實現，或者成本很高，或者會嚴重拖滯工期，軟體設計和程式碼中存在著嚴重的質量缺陷 ... 等等。我們應該根據各種地雷/炸彈的“殺傷力”進行排序。

在軟體開發中，最怕的是 Fail Last/Blast Last，也就是 99% 的地面似乎都檢查過了，而最後就剩下那麼一丁點兒的地方下面，有那麼一顆威力巨大的地雷沒被檢查到，它偏偏是在部隊通過的時候發生爆炸，即便沒有導致專案的徹底失敗，也會讓其遭受嚴重的挫折。

在經典軟體工程教材中，有很多這樣的案例。而在過去的 10 多年中，張恂耳聞目睹的國內類似事例也不在少數。

所以，軟體工程希望 Fail Early/Blast Early，希望威力大、有殺傷力的地雷都能在專案的早中期能夠儘早被發現、引爆和排除掉，讓部隊能安然順利通過。在這 1 平方公里的地面下沒有地雷當然最好，即便有，也希望它們早點炸，在人們有所防備、對其後果有所控制的情況下發生，以把損失減少到最小。

對付隱蔽地雷的手段

那麼，作為擔負重要使命的軟體工程專案的工兵，我們應該如何快速有效地排雷、掃雷呢？

當代軟體工程有許多有效的應對和防範風險的舉措，T 型開發、迭代開發、用例（Use Case）分析、OOAD*UML 建模等等都是被實踐證明行之有效的手段，而它們也是張恂在過去 10 多年來在學習 U3（Use Case、UML、UP）和敏捷迭代開發、敏捷專案管理的過程中所掌握的風險防範技術，這些技術對於我們完成工兵掃雷使命具有哪些好處，下面我打算逐一向大家作個簡單的介紹。

T 型開發

我們知道，在使用者需求裡面埋藏著專案地雷，我們希望儘快、有效地把雷區的範圍、分佈情況摸查清楚，這就需要廣度和深度的結合 —— T 型開發。T 的一橫代表廣度，T 的一豎代表深度。首先是廣度，然後是深度。

不管需求分析還是架構設計，其實都需要 T 型開發，做到廣度和深度的結合。

為什麼必須要有廣度？前面提到，如果 99% 的地面你都檢查過了，沒問題，沒什麼風險，那麼萬一漏掉的 1% 下面有地雷，而且正好有人從上面走過，怎麼辦？所以，理論上應該全部都摸查一遍，至少要大致地掃描一下。

掃雷的時候還必須要有深度，不能光看表面的浮雷、絆雷，必須要拿起掃雷儀對地下幾米深的地方進行探測（如果你要過大型裝備，比如坦克），而且發現地雷、炸彈之後，還要馬上採取措施解除它們的危險，人工切斷引信，用掃雷車/坦克引爆或移走地雷等等。這代表著，在軟體開發中我們不能光做表面的抽象模型的分析設計（用來探查、發現風險和地雷），還應該編寫出實際可執行的架構程式碼和測試程式，有時候這些程式碼涉及到很多深度的關鍵技術細節，只有它們執行和測試通過了才算數（真正地排除了地雷，解決了隱患問題）。

演進式的用例分析

由於軟體需求分析是軟體專案的上游工作，需求錯誤就會導致下游的設計、編碼和測試工作出現錯誤和返工，因此需求風險往往是軟體專案中最主要的風險。

工兵掃雷這個比喻意味著，我們在做使用者需求分析的時候一定要細緻和全面。想一想，如果漏掉了關鍵的需求，可能會有什麼後果？這與掃雷不徹底相當。

Use Case 與傳統的特性（Feature）/使用者故事等其他簡略、簡易的需求描述方法相比，有許多優勢，最大的差別在於由於用例採用了系統化、結構化的分析技術，它在需求分析的完備性、準確性和精度方面都明顯要優於其他方法，因而也能幫助我們更好地發現需求風險。

在用例分析中，我們採用格式模版，除了描述基本流之外，還要分析、探查專案風險地雷常常隱匿之處，包括擴充套件條件、擴充套件流、約束、假定等各種意外和特殊情況，以及與用例繫結或公共的非功能需求等等，顯然這是一種非常有效的防範需求風險的做法。

遺憾的是，據張恂觀察，多年來國內許多本土的軟體研發組織和機構在需求分析的細緻、全面性方面一直做得不太好，他們所作的需求分析結果，在粒度、精度和準確度等方面常常是不夠的，加上傳統上軟體測試工作在國內也是一個薄弱環節，因而存在著很多的需求漏洞和專案風險/地雷。

當然，在迭代敏捷開發中，用例分析也是通過多次迭代、測試，根據風險優先順序，逐步完成的，達到全面、細緻的要求，這是演進式的需求分析，與國內許多人所熟知的傳統瀑布軟體工程的瀑布式需求分析階段做法有著顯著不同，在迭代敏捷開發模式中，我們取消了“需求階段”或“需求分析階段”，不再有這樣的稱謂。

（待續）

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13633641/viewspace-331177/，如需轉載，請註明出處，否則將追究法律責任。