敏捷開發模式下需求分析崗 BA

傳統的瀑布開發模式下需求分析崗是必不可少的。那麼敏捷專案沒有需求分析嗎?在很多人的印象中，敏捷軟體開發是種類似黑客行為的過程，是程式設計師最愛的勾當。不寫文件，不作需求分析，沒有專案經理，做什麼東西完全是程式設計師自己的行為。他們認為這樣的過程無法滿足真正大型專案和複雜專案的需要，因此在經過考慮後，放棄了敏捷方法。

思考：敏捷開發過程是否存在完整需求分析？ 敏捷過程到底是如何做需求分析?   使用者故事和用例有什麼區別?  敏捷過程如何去管理需求的?

這些是一些想要實踐敏捷的人一直在困惑的事情。 我們常常看到書中講，程式設計師拿到一個使用者故事後，怎麼計劃，怎麼分解，怎麼寫

敏捷專案中誰來做需求分析?

在敏捷的團隊中，作一個敏捷程式設計師確實是非常舒服的事情。從程式設計師的角度來看，只需要選擇一張他感興趣的故事卡片，瞭解清楚該卡片的需求，開始從功能測試寫程式碼，等通過了所有測試就完工。基本上不需要考慮太多的事情，非常輕鬆愉快。但程式設計師向誰去問清楚需求?故事卡片是怎樣寫出來的呢?讓我們來關注開發前發生的事情。 瞭解敏捷過程的人都知道，Kent Beck在XP過程中提到了現場客戶，如果一個敏捷團隊能夠有現場客戶，這當然是最棒的事情。但多數情況下，客戶都是很忙碌的，很難全力投入到軟體開發過程中。這時候，我們就需要商務分析師

敏捷專案中如何進行需求分析?

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

       在這個目標下，商務分析師開始進行需求的分析：我們到底是否真的需要這個需求?有沒有更好的解決方案?有沒有簡單並且低廉的方式?換一種形式是不是也能達到這樣的需求?這個需求有多少地方涉及到以前的軟體變更? 搞清楚這些事情後，就可以寫出使用者故事。使用者故事的書寫遵循一定的原則，一般包括三部分："作為(系統的一個涉眾)，我想要(做一件事)，從而(達到一個商業價值)"。在書寫的時候格式比較隨意，可以在故事卡背面寫上註釋或疑問，甚至畫上介面原形圖。 舉一個最常見的使用者故事例子，“作為一個普通使用者，我希望能夠用使用者名稱和密碼登入，以便我能享受到個性化的服務”。其中，使用者是系統涉眾，登入是他想要做的事情，而他的目標是獲得個性化的服務。 從這個例子我們可以想象到，這個頁面可能存在兩個文字框，用於輸入使用者名稱和密碼，有一個按鈕來登入，並且不登入就不能看到個人資料，另外，如果使用者輸入錯誤需要提示“登入失敗請重試”。這就是可見性，也可以稱為可測試性。我們可以根據這樣的可見性寫出功能測試，從而驅動這個使用者故事的開發，這被稱為 Acceptance Driven Development。

使用者故事和用例有什麼區別?

        使用者故事的作用有兩個，一個是作為進度跟蹤的依據，一個是作為與人交談的備忘錄。使用者故事卡片並不是很精確的需求，因此不需要把事情描述的非常清楚。將需求的詳細分析推遲到實現前夕來完成，這是敏捷需求分析的精華所在。 不少人對使用者故事和用例的區別感到疑惑。使用者故事的作用是備忘功能，而不是文件。而用例需要詳細的描述其操作步驟，以及每個異常路徑，因而起到了文件的作用。使用者故事是可見的商業價值，而不是功能描述。每個使用者故事的粒度和工作量都相差不多，這和用例有很大的區別。使用者故事是小粒度的，可測試的，可見的，並且是有價值的。 如下

【敏捷專案需求分析案例】 公司有個專案組作的是一個網遊物品交易平臺。該平臺是典型的網際網路專案，在開工的時候客戶對功能需求還不明確，但需要快速推出搶佔市場，正是最適合敏捷過程的專案。 在專案伊始，商務分析師和客戶做了深入的談話，瞭解他的商業構想，他的盈利模式，搞清楚巨集觀的結構，然後思考並整理獲得的結果，花1-2天時間將客戶需求大略整理為幾十個使用者故事。這些使用者故事並不完善，不足以做好整個系統。但對於我們開始專案的前一陣，已經足夠了。我們可以從這裡開始專案。敏捷方法希望快速交付可用的軟體。實現軟體的快速交付是通過迭代來完成。在迭代開始前，由一組有經驗的開發人員大致評估一下使用者故事，標記出不同的難度和風險，並提出問題供商務分析師來獲得更詳細的資訊，商務分析師會和相關涉眾去討論。然後商務分析師將推薦優先順序最高的一組使用者故事給客戶來挑選，客戶可以選擇這些使用者故事，或者指出從他的視角看到的優先順序更高的使用者故事。這些將成為下一個迭代的內容。 專案經理圈子客戶看到每個迭代交付的可執行的軟體後或者得到使用者反饋後，常常會有新的想法冒出來。有些想法是好的，有些想法就屬於看到別家網站有這個功能，不假思索的提出的功能。這些不同的需求都需要經過認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實現的。 有一次和客戶談話時，他說到希望增加拍賣功能。那麼，我們為什麼需要拍賣呢?客戶說希望讓使用者拍賣物品以獲得最高價格。經過考慮，我們發現網遊物品的實時性和唯一性決定了系統不適合使用拍賣機制。拍賣的時效性無法滿足實時交易的要求，因此，使用者最終放棄了這個特性。 另一次，客服人員提出增加一個查詢使用者交易的功能，而此時我們有其他更加重要的功能需要先去考慮，查詢使用者交易功能可以由技術人員臨時通過資料庫直接代為查詢，因為專案運營初期交易不是很多，暫時還不需要專門的後臺功能來支援客服的工作。所以把這個需求卡片一直貼在牆壁上，始終沒有排到最高的優先順序。 客戶一開始也不是很能夠接受敏捷需求中強調商業價值和優先順序的做法。但經過幾個月的磨合，客戶也逐漸適應了許多敏捷思想，甚至我在和客戶討論時，偶然提起了後期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。

敏捷過程如何去管理需求的?

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

          每個迭代內分析好恰好足夠下一個迭代開發的需求，就是商務分析師每個迭代的主要工作內容。商務分析師的需求分析工作在上一個迭代完成，包括需求的瞭解，分析，評估和排列優先順序。 在每個迭代開始的時候，由商務分析師主持召開迭代計劃會議，在會議上向所有的程式設計師解釋這個迭代要完成的使用者故事，然後由程式設計師自由提問，知道他們能夠獲得足夠開始實現該功能的資訊。 在程式設計師完成一個使用者故事後，商務分析師還要來代表客戶做功能驗收測試，檢視是否完成了預計的功能，是否有程式設計師還沒有想到的異常情況。如果存在問題需要退回給程式設計師繼續完成。這在一定程度上保證了系統完成的需求不偏離客戶的要求。當然，更多的測試還需要QA來完成。

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