解讀敏捷需求分析五大關鍵因素

大多數學計算機語言的人都會有過這樣的感覺，過去一直認爲編程和架構是整個軟件生命週期裏最了不得的部分，但實際工做後纔會發如今商業產品裏，需求分析纔是一個商業軟件成功與否的關鍵。

放 眼望去，在當今軟件工程領域出現的許多問題，諸如缺陷及資源運用不當，都源於需求的不清晰，甚至有軟件人戲稱：「需求變動乃萬惡之源」，一時也得到了頗多 響應。時至現在，業務IT間需求分析過程當中存在的問題主要有哪些？什麼是敏捷需求分析？產品級和項目級需求有何異同？敏捷需求分析方法論中的五大關鍵點是 什麼？就以上熱點話題，雅各布森中國區總經理吳穹分享了他的見解。

 

三大症狀

在吳穹看來，兩份需求、合同式驗證、產品需求缺失成爲了當前需求溝通的三大症結。

兩 份需求——用戶（業務）需求和軟件需求。用戶需求由不熟悉IT的業務人員完成，大多歸於天馬行空的意識流，基本上是想起什麼寫什麼。而軟件需求由IT人員 編寫，通過技術思惟的過濾、梳理、增刪，包含進了算法、數據庫設計、架構之類的技術專業詞彙，業務人員每每已不知文檔內所云。

合同式驗證——業務人員和技術人員企圖在溝通後以合同形式將需求固化而且肯定下來，而沒有充分考慮到軟件開發過程當中可能出現的需求變動。

產品需求缺失——項目是片斷，產品是總量，二者的關係在於項目其實就是一個不斷完善產品的過程。因爲國內PMP（ProjectManagement Professional）和項目管理流行，更多IT需求都是以項目形式存在，而每每忽視了產品需求的積累，致使最後的結果可能是項目（需求）不少，但產品需求缺失。

項 目級和產品級需求的具體區別，若是放在幾年或十多年前並不明顯，對於全新產品而言，項目（需求）=產品（需求）。隨着時間推移，二者的區分逐步明朗，因爲 全新項目愈來愈少，更多的需求都是在維護和升級老的產品。以咖啡機爲例，從基本型升級到1.1版，或許是加入一個按鈕。此時和客戶溝通的時候就須要引導客 戶想清楚，須要的是項目級仍是產品級的需求，是作整個咖啡機的需求仍是僅僅只是新添按鈕的需求。若是將來再作1.2版，繼續添按鈕，這時候的需求又該如何 寫？新按鈕的需求，而後和之前的按鈕有些變化。若是不能明確兩種需求的差別，隨着項目需求的累積，到最後會發現全部的（需求）都是片斷的，都是增量而缺少 一個總的全景。

事 實上，業務IT需求形成現在的混亂情況，CMMI（Capability Maturity Model Integration，能力成熟度模型集成） 和國內企業對CMMI的僵化理解能夠說「功不可沒」。在對「兩份需求」的認識上，CMMI裏有明確分項，用戶需求和軟件需求。但值得一提的是，其實裏面並 未明確要求是兩份文檔或由兩部分人來寫，而只是表示需求細化的兩個階段。遺憾的是，不少國內CMMI認證企業也並無真正打算去了解它的內涵，只是僵化地 表現出本身是否有這樣的能力。

最近接觸到一些項目也出現了這樣的情形，你們先作了一份用戶需求，而後花費大量時間寫軟件需求，以知足認證的須要，但到頭來軟件需求根本沒人看，你們都只是應付，CMMI成爲了擺設。

 

需求貫穿於軟件開發測試全過程

在 吳穹看來，敏捷的最大貢獻在於它是對整個軟件工程的一次再認識。具體到敏捷需求分析領域，其實涉及到一個核心問題：是否認可（軟件）需求能夠在一開始就搞 清楚並肯定下來？敏捷的答案是No！而在傳統瀑布式開發中，更多的是合同式驗證的情形，大多數客戶的思想基礎都是基於需求最初就能肯定下來的。但事實上， 這在當前階段基本屬於「不可能完成的任務」，不符合軟件開發本質。在敏捷需求分析中，需求應是貫穿於整個軟件生命週期全過程當中並在其中不斷變動、迭代和完 善。

敏捷需求分析認爲，需求應創建在以用例爲中心的需求文檔體系，採起協做式而非合同式的溝通方式之上。具體可分爲五個關鍵點：

• 用例；
• 協做；
• 迭代，即需求不是一次最終肯定，而是先完成主要框架，再經過迭代逐步精化；
• 整個過程當中以分析爲支撐，作需求同時也在作分析，分析模型的輸出結果應跟需求分開；
• 把用例分解到用戶故事，在整個軟件生命週期過程當中來驅動開發和測試。

 

業務/技術溝通頻現「兩份需求」

同 時還要考慮到的是，將兩份需求改成一份文檔，而沒必要死摳CMMI概念區分出用戶和軟件需求。首份需求稿將由SA（系統分析師）來牽頭完成，負責各方協調和 溝通的工做。理想的狀況下，整個團隊在項目開始前就應搭建完畢，包括客戶、開發測試人員都參與的寫做和迭代，而不是以往的由技術人員對用戶進行里程碑式的 教輔。一般來講，一個項目裏一名SA同時對應5~9名開發人員是比較合適的。

 

需求文檔化與敏捷的平衡點

至 於用例和用戶故事。按照敏捷大師Martin博客中的說法，二者都是組織需求的方式，只是目的不一樣而已，用例的目的是爲了把需求描述清楚，而用戶故事的目 的是把需求分解成可用於迭代計劃的單元。對應到產品級和項目級文檔，用例是產品級，例如作咖啡機，無論有多少不一樣版本，有些核心功能是不改變的，這些都是 產品級需求。而用戶故事則是項目級，屬於作完就扔的「拋棄型」。

進 一步理解的話，用戶故事實際上是一個或多個完整的業務場景，而用例是場景的抽象，一個用例裏能夠包含成百上千個場景。用戶故事是基於開發思想的，不光要考慮 業務，還要考慮如何實現包括工做量大小、任務分配、項目風險以及架構風險等多重因素。有人認爲寫用戶故事是極簡單的事，但在吳穹看來，如今有不少人都還在 用功能點套用用戶故事，顯得不三不四，而沒有理解到用戶故事的精髓。

以 ATM取款爲例，正常流程是插卡、取錢、把錢拿走。這個看似簡單的場景其實工做量很大，能夠在整個流程中作一些必要的簡化。有人認爲既然用戶故事是一個場 景，那就把它變成一個場景步驟吧，因而就成了功能點。其實他們忽略了一點，用戶故事仍是一個簡化了但還保證完整業務價值的場景。ATM取款創建用戶故事會 涉及哪些因素呢？取款是否須要輸入密碼？小額取款時可否取消密碼輸入的步驟？取錢後打印帳單，查詢餘額等，在這裏面哪些功能是風險級別高的，哪些須要與銀 行核心數據通訊？這不只涉及（功能）優先級的問題，還能夠根據原則簡化用戶故事。例如能夠考慮作一個用戶故事，儲戶用不需驗密的卡，限額是一千塊，取幾百 塊錢的時候，把去銀行驗證的過程取消掉。這種情形下不少時候都要考慮到帳戶的風險狀況，這些都須要多方溝通。相似的用戶故事簡化的情形有不少，但這時必定 基於黑盒方式來作簡化。而在簡化的過程當中，考慮如何實現如何合理調整工做量提升效率，這些都是找（用戶）故事的過程，也是一個白盒的過程。

在 實現上，除了強調快速交付或生命週期很短、業務模式高度可變的互聯網、網遊等項目，能夠採用純用例的模式，現階段讓（大型）企業IT項目全面接納需求徹底 無文檔化仍是不現實的，更實際的解決辦法是在文檔化和敏捷需求分析之間找到一個平衡，一份需求用例加上用戶故事，而後驅動開發這種方式，目前看來，這是現 階段更適合大型企業的敏捷需求實踐模式。

 

（本文來自《程序員》雜誌10年07期）