在很多人的印象中，靈活軟體開發是種類似黑客行為的過程，是程式員最愛的勾當。不寫文檔，不作需求分析，沒有項目經理，做什麼東西完全是程式員自己的行為。是以他們認為這樣的過程無法滿足真正大型項目和複雜項目的需要，是以在經過考慮後，放棄了靈活方法。
真的是這樣嗎？靈活過程到底是如何做需求分析？使用者故事和用例有什麼差別？靈活過程如何去管理需求的？這些是一些想要實踐靈活的人一直在困惑的事情。
我們常常看到書中講，程式員拿到一個使用者故事後，怎麼計劃，怎麼分解，怎麼寫單元測試，怎麼小步前進，怎麼持續內建。這是典型的程式員視角。事實 上，靈活方法分為三部分，靈活項目管理，靈活需求分析，靈活軟體開發。上述書中提到的完全是靈活開發中的實踐，很多人了解到的靈活，隻是靈活的三分之一。
在靈活的團隊中，作一個靈活程式員确實是非常舒服的事情。從程式員的角度來看，隻需要選擇一張他感興趣的故事卡片，了解清楚該卡片的需求，開始從 功能測試寫代碼，等通過了所有測試就完工。基本上不需要考慮太多的事情，非常輕松愉快。但程式員向誰去問清楚需求？故事卡片是怎樣寫出來的呢？讓我們來關 注開發前發生的事情。
了解靈活過程的人都知道，Kent Beck在XP過程中提到了現場客戶，如果一個靈活團隊能夠有現場客戶，這當然是最棒的事情。但多數情況下，客戶都是很忙碌的，很難全力投入到軟體開發過程中。這時候，我們就需要商務分析師這個角色，來充當客戶的角色。
我在ThoughtWorks的團隊中擔任的就是商務分析師這個角色。商務分析師最重要的職責就是與客戶交談，了解和分析需求，将其制作成使用者故事并将需求轉述給程式員。同時， 商務分析師也要代替客戶負責功能驗收測試。
靈活思想的核心是與人交流。需求問題實際上是一個交流問題。 商務分析師要和客戶交流，搞清楚客戶到底需要什麼，到底為什麼需要這些東西。商業價值 是商務分析師關注的最終目标。有了目标的指向，就可以不迷失方向。和客戶進行交流，最終目的就是挖掘出客戶的商業目标。可能大家會經常有這樣的經驗，客戶 說，我要這個功能，我想要怎麼怎麼樣。這時候要特别注意，他說的這些東西并不是真正的需求。商務分析師需要詳細的問客戶為什麼，挖掘出他真正的目标。 （可樂語：不加思考的接受是錯誤的，要深究其真正的目的和是否真正有價值 ）
在這個目标下，商務分析師開始進行需求的分析：我們到底是否真的需要這個需求？有沒有更好的解決方案？有沒有簡單并且低廉的方式？換一種形式是不是也能達到這樣的需求？這個需求有多少地方涉及到以前的軟體變更？
搞清楚這些事情後，就可以寫出使用者故事。使用者故事的書寫遵循一定的原則，一般包括三部分："作為（系統的一個涉衆），我想要（做一件事），進而（達到一個商業價值）"。在書寫的時候格式比較随意，可以在故事卡背面寫上注釋或疑問，甚至畫上界面原形圖。
舉一個最常見的使用者故事例子，"作為一個普通使用者，我希望能夠用使用者名和密碼登入，以便我能享受到個性化的服務"。其中，使用者是系統涉衆，登入是他想要做的事情，而他的目标是獲得個性化的服務。
從這個例子我們可以想象到，這個頁面可能存在兩個文本框，用于輸入使用者名和密碼，有一個按鈕來登入，并且不登入就不能看到個人資料，另外，如果用 戶輸入錯誤需要提示"登入失敗請重試"。這就是可見性，也可以稱為可測試性。我們可以根據這樣的可見性寫出功能測試，進而驅動這個使用者故事的開發，這被稱 為 Acceptance Driven Development。
使用者故事的作用有兩個，一個是作為進度跟蹤的依據，一個是作為與人交談的備忘錄。使用者故事卡片并不是很精确的需求，是以不需要把事情描述的非常清 楚。将需求的詳細分析推遲到實作前夕來完成，這是靈活需求分析的精華所在。任何提前做好的東西都會導緻浪費，靈活過程提倡足夠就好，避免浪費。
不少人對使用者故事和用例的差別感到疑惑。使用者故事的作用是備忘功能，而不是文檔。而用例需要詳細的描述其操作步驟，以及每個異常路徑，因而起到了 文檔的作用。使用者故事是可見的商業價值，而不是功能描述 。每個使用者故事的粒度和工作量都相差不多，這和用例有很大的差別。使用者故事是小粒度的，可測試的， 可見的，并且是有價值的。[注:此處存有争議，請讀者辨證閱讀，勿斷章取義]
（可樂語：無論是使用者故事還是用例都必須建立在與客戶的溝通上，獨自一人坐在辦公室裡拍拍腦袋寫出來的所謂需求規格說明書都是最終懶得更新的廢紙，即使你自認為對業務很熟，隻是在溝通交流過程，通過使用者故事可以有效的組織和過濾使用者需求資訊，并有助于提取其真實價值，并形成備忘，作為下一步編寫用例的基礎）
ThoughtWorks有個項目組作的是一個網遊物品交易平台。該平台是典型的網際網路項目，在開工的時候客戶對功能需求還不明确，但需要快速推出搶占市場，正是最适合靈活過程的項目。
在項目伊始，商務分析師和客戶做了深入的談話，了解他的商業構想，他的盈利模式，搞清楚宏觀的結構，然後思考并整理獲得的結果，花1-2天時間将 客戶需求大略整理為幾十個使用者故事。這些使用者故事并不完善，不足以做好整個系統。但對于我們開始項目的前一陣，已經足夠了。我們可以從這裡開始項目。
靈活方法希望快速傳遞可用的軟體。實作軟體的快速傳遞是通過疊代來完成。在疊代開始前，由一組有經驗的開發人員大緻評估一下使用者故事，标記出不同 的難度和風險，并提出問題供商務分析師來獲得更詳細的資訊，商務分析師會和相關涉衆去讨論。然後商務分析師将推薦優先級最高的一組使用者故事給客戶來挑選， 客戶可以選擇這些使用者故事，或者指出從他的視角看到的優先級更高的使用者故事。這些将成為下一個疊代的内容。
客戶看到每個疊代傳遞的可運作的軟體後或者得到使用者回報後，常常會有新的想法冒出來。有些想法是好的，有些想法就屬于看到别家網站有這個功能，不假思索的提出的功能。這些不同的需求都需要經過認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實作的。
有一次和客戶談話時，他說到希望增加拍賣功能。那麼，我們為什麼需要拍賣呢？客戶說希望讓使用者拍賣物品以獲得最高價格。經過考慮，我們發現，網遊物品的實時性和唯一性決定了系統不适合使用拍賣機制。拍賣的時效性無法滿足實時交易的要求，是以，使用者最終放棄了這個特性。
另一次，客服人員提出增加一個查詢使用者交易的功能，而此時我們有其他更加重要的功能需要先去考慮，查詢使用者交易功能可以由技術人員臨時通過資料庫 直接代為查詢，因為項目營運初期交易不是很多，暫時還不需要專門的背景功能來支援客服的工作。是以把這個需求卡片一直貼在牆壁上，始終沒有排到最高的優先 級。
客戶一開始也不是很能夠接受靈活需求中強調商業價值和優先級的做法。但經過幾個月的磨合，客戶也逐漸适應了許多靈活思想，甚至我在和客戶讨論時，偶然提起了後期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。
使用者故事的跟蹤和管理是由項目經理來進行。每個疊代跟蹤卡片的進展，是否已經開始實作？是否已經完成代碼開發？是否已經開始功能測試？不同的卡片 在疊代前都會評估為不同的大小。我們一般分為大中小三級。等實踐過幾個疊代後，團隊的開發速度基本保持恒定，我們就可以很容易的知道每個疊代能做多少個用 戶故事，這樣就可以安排下一疊代的開發。
每個疊代内分析好恰好足夠下一個疊代開發的需求，就是商務分析師每個疊代的主要工作内容。商務分析師的需求分析工作在上一個疊代完成，包括需求的了解，分析，評估和排列優先級。
在每個疊代開始的時候，由商務分析師主持召開疊代計劃會議，在會議上向所有的程式員解釋這個疊代要完成的使用者故事，然後由程式員自由提問，知道他們能夠獲得足夠開始實作該功能的資訊。
在程式員完成一個使用者故事後，商務分析師還要來代表客戶做功能驗收測試，檢視是否完成了預計的功能，是否有程式員還沒有想到的異常情況。如果存在問題需要退回給程式員繼續完成。這在一定程度上保證了系統完成的需求不偏離客戶的要求。當然，更多的測試還需要QA來完成。
我們的實踐充分表明了，靈活過程并不是沒有需求分析，而是把需求分析過程分散到整個開發的過程中，讓開發和需求分析并行進行。這就是ThoughtWorks靈活方法實施成功的秘訣之一。而商務分析師在這個過程中，起到了紐帶和橋梁的作用，是一個團隊不可缺少的角色。
（可樂語：疊代周期間的釋出、溝通、回報、調整以及疊代周期的長短都是極其重要的，如果被忽略，所謂的靈活也隻剩形式，不可能再靈活了）