（本文發表于程序員雜志2006年第4期）

在很多人的印象中，敏捷軟件開發是種類似黑客行為的過程，是程序員最愛的勾當。不寫文檔，不作需求分析，沒有項目經理，做什么東西完全是程序員自己的行為。所以他們認為這樣的過程無法滿足真正大型項目和復雜項目的需要，因此在經過考慮后，放棄了敏捷方法。

真的是這樣嗎？敏捷過程到底是如何做需求分析？用戶故事和用例有什么區別？敏捷過程如何去管理需求的？這些是一些想要實踐敏捷的人一直在困惑的事情。

我們常常看到書中講，程序員拿到一個用戶故事后，怎么計劃，怎么分解，怎么寫單元測試，怎么小步前進，怎么持續集成。這是典型的程序員視角。事實上，敏捷方法分為三部分，敏捷項目管理，敏捷需求分析，敏捷軟件開發。上述書中提到的完全是敏捷開發中的實踐，很多人了解到的敏捷，只是敏捷的三分之一。

在敏捷的團隊中，作一個敏捷程序員確實是非常舒服的事情。從程序員的角度來看，只需要選擇一張他感興趣的故事卡片，了解清楚該卡片的需求，開始從功能測試寫代碼，等通過了所有測試就完工。基本上不需要考慮太多的事情，非常輕松愉快。但程序員向誰去問清楚需求？故事卡片是怎樣寫出來的呢？讓我們來關注開發前發生的事情。

了解敏捷過程的人都知道，Kent Beck在XP過程中提到了現場客戶，如果一個敏捷團隊能夠有現場客戶，這當然是最棒的事情。但多數情況下，客戶都是很忙碌的，很難全力投入到軟件開發過程中。這時候，我們就需要商務分析師這個角色，來充當客戶的角色。

我在ThoughtWorks的團隊中擔任的就是商務分析師這個角色。商務分析師最重要的職責就是與客戶交談，了解和分析需求，將其制作成用戶故事并將需求轉述給程序員。同時，商務分析師也要代替客戶負責功能驗收測試。

敏捷思想的核心是人與交流。需求問題實際上是一個交流問題。商務分析師要和客戶交流，搞清楚客戶到底需要什么，到底為什么需要這些東西。商業價值是商務分析師關注的最終目標。有了目標的指向，就可以不迷失方向。和客戶進行交流，最終目的就是挖掘出客戶的商業目標。可能大家會經常有這樣的經驗，客戶說，我要這個功能，我想要怎么怎么樣。這時候要特別注意，他說的這些東西并不是真正的需求。商務分析師需要詳細的問客戶為什么，挖掘出他真正的目標。

在這個目標下，商務分析師開始進行需求的分析：我們到底是否真的需要這個需求？有沒有更好的解決方案？有沒有簡單并且低廉的方式？換一種形式是不是也能達到這樣的需求？這個需求有多少地方涉及到以前的軟件變更？

搞清楚這些事情后，就可以寫出用戶故事。用戶故事的書寫遵循一定的原則，一般包括三部分："作為（系統的一個涉眾），我想要（做一件事），從而（達到一個商業價值）"。在書寫的時候格式比較隨意，可以在故事卡背面寫上注釋或疑問，甚至畫上界面原形圖。

舉一個最常見的用戶故事例子，"作為一個普通用戶，我希望能夠用用戶名和密碼登錄，以便我能享受到個性化的服務"。其中，用戶是系統涉眾，登錄是他想要做的事情，而他的目標是獲得個性化的服務。

從這個例子我們可以想象到，這個頁面可能存在兩個文本框，用于輸入用戶名和密碼，有一個按鈕來登錄，并且不登錄就不能看到個人資料，另外，如果用戶輸入錯誤需要提示"登錄失敗請重試"。這就是可見性，也可以稱為可測試性。我們可以根據這樣的可見性寫出功能測試，從而驅動這個用戶故事的開發，這被稱為 Acceptance Driven Development。

用戶故事的作用有兩個，一個是作為進度跟蹤的依據，一個是作為與人交談的備忘錄。用戶故事卡片并不是很精確的需求，因此不需要把事情描述的非常清楚。將需求的詳細分析推遲到實現前夕來完成，這是敏捷需求分析的精華所在。任何提前做好的東西都會導致浪費，敏捷過程提倡足夠就好，避免浪費。

不少人對用戶故事和用例的區別感到疑惑。用戶故事的作用是備忘功能，而不是文檔。而用例需要詳細的描述其操作步驟，以及每個異常路徑，因而起到了文檔的作用。用戶故事是可見的商業價值，而不是功能描述。每個用戶故事的粒度和工作量都相差不多，這和用例有很大的區別。用戶故事是小粒度的，可測試的，可見的，并且是有價值的。

ThoughtWorks有個項目組作的是一個網游物品交易平臺。該平臺是典型的互聯網項目，在開工的時候客戶對功能需求還不明確，但需要快速推出搶占市場，正是最適合敏捷過程的項目。

在項目伊始，商務分析師和客戶做了深入的談話，了解他的商業構想，他的盈利模式，搞清楚宏觀的結構，然后思考并整理獲得的結果，花1-2天時間將客戶需求大略整理為幾十個用戶故事。這些用戶故事并不完善，不足以做好整個系統。但對于我們開始項目的前一陣，已經足夠了。我們可以從這里開始項目。

敏捷方法希望快速交付可用的軟件。實現軟件的快速交付是通過迭代來完成。在迭代開始前，由一組有經驗的開發人員大致評估一下用戶故事，標記出不同的難度和風險，并提出問題供商務分析師來獲得更詳細的信息，商務分析師會和相關涉眾去討論。然后商務分析師將推薦優先級最高的一組用戶故事給客戶來挑選，客戶可以選擇這些用戶故事，或者指出從他的視角看到的優先級更高的用戶故事。這些將成為下一個迭代的內容。
客戶看到每個迭代交付的可運行的軟件后或者得到用戶反饋后，常常會有新的想法冒出來。有些想法是好的，有些想法就屬于看到別家網站有這個功能，不假思索的提出的功能。這些不同的需求都需要經過認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實現的。

有一次和客戶談話時，他說到希望增加拍賣功能。那么，我們為什么需要拍賣呢？客戶說希望讓用戶拍賣物品以獲得最高價格。經過考慮，我們發現，網游物品的實時性和唯一性決定了系統不適合使用拍賣機制。拍賣的時效性無法滿足實時交易的要求，因此，用戶最終放棄了這個特性。

另一次，客服人員提出增加一個查詢用戶交易的功能，而此時我們有其他更加重要的功能需要先去考慮，查詢用戶交易功能可以由技術人員臨時通過數據庫直接代為查詢，因為項目運營初期交易不是很多，暫時還不需要專門的后臺功能來支持客服的工作。所以把這個需求卡片一直貼在墻壁上，始終沒有排到最高的優先級。

客戶一開始也不是很能夠接受敏捷需求中強調商業價值和優先級的做法。但經過幾個月的磨合，客戶也逐漸適應了許多敏捷思想，甚至我在和客戶討論時，偶然提起了后期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。

用戶故事的跟蹤和管理是由項目經理來進行。每個迭代跟蹤卡片的進展，是否已經開始實現？是否已經完成代碼開發？是否已經開始功能測試？不同的卡片在迭代前都會評估為不同的大小。我們一般分為大中小三級。等實踐過幾個迭代后，團隊的開發速度基本保持恒定，我們就可以很容易的知道每個迭代能做多少個用戶故事，這樣就可以安排下一迭代的開發。

每個迭代內分析好恰好足夠下一個迭代開發的需求，就是商務分析師每個迭代的主要工作內容。商務分析師的需求分析工作在上一個迭代完成，包括需求的了解，分析，評估和排列優先級。

在每個迭代開始的時候，由商務分析師主持召開迭代計劃會議，在會議上向所有的程序員解釋這個迭代要完成的用戶故事，然后由程序員自由提問，知道他們能夠獲得足夠開始實現該功能的信息。

在程序員完成一個用戶故事后，商務分析師還要來代表客戶做功能驗收測試，查看是否完成了預計的功能，是否有程序員還沒有想到的異常情況。如果存在問題需要退回給程序員繼續完成。這在一定程度上保證了系統完成的需求不偏離客戶的要求。當然，更多的測試還需要QA來完成。

我們的實踐充分表明了，敏捷過程并不是沒有需求分析，而是把需求分析過程分散到整個開發的過程中，讓開發和需求分析并行進行。這就是ThoughtWorks敏捷方法實施成功的秘訣之一。而商務分析師在這個過程中，起到了紐帶和橋梁的作用，是一個團隊不可缺少的角色。

原文：http://www.javaeye.com/topic/34957