一、用戶故事，敏捷環(huán)境

將所有的需求拆解成用戶故事，從用戶角度對系統(tǒng)的某個功能模塊所做的簡短描述（需求文檔剛好相反，關(guān)注的是系統(tǒng)功能，很少會提及用戶場景）。一個好的用戶故事包括三個要素：

角色：誰要使用這個功能，

活動：需要完成什么樣的功能。

商業(yè)價值：為什么需要這個功能，這個功能能帶來什么樣的價值。

例：

作為信用卡客戶Jack

希望可以從取款機中用信用卡取現(xiàn)金

這樣能夠購買只能用現(xiàn)金購買的商品

二、驗收條件（Acceptance Criteria）

在對齊用戶故事的過程中，我們可以通過上圖的方向進行思考和提問，以達到澄清需求的目標。至于用戶故事的最終呈現(xiàn)形式，并不是那么的重要。

三、用戶故事地圖

如上圖，用戶故事地圖，就是一堵用戶故事墻，大級別的用戶故事排在第一列，根據(jù)優(yōu)先級，描述用戶需求。對第一排故事成縱向分解。通過地圖方式，可以讓團隊能夠有一個空間充分思考各類可行方案，從而找到一條可以最大化投入產(chǎn)出的路子?？梢宰尭鞣N干系人對功能需求有相對一致的理解和整體認識。同時，根據(jù)這些故事排列出每個迭代的用戶故事優(yōu)先級。

用戶故事地圖還可以傳送出很多的信息，比如它的橫縱坐標，其實是非常有意義的，橫軸代表了用戶的使用路線圖，縱軸代表了需求的優(yōu)先級。那幾條紅色的虛線，就代表了每個迭代需要做的基本內(nèi)容了，相當(dāng)于一個粗粒度的迭代待辦列表（Sprint Back log）。

注意：這個地圖是動態(tài)變化的。每經(jīng)過一段時間，團隊都應(yīng)該重新審視這張用戶故事地圖，看看我們的規(guī)劃是否發(fā)生了偏差？還有哪些需要補充的？有沒有更好的意見或者建議？是否有些功能是不必要的？

四、實例分享

內(nèi)部關(guān)于需求的管理方式，基于Confluence工具，模板如下圖：

通過下面這個文檔，我們可以很清晰的知道用戶故事的信息：在哪個迭代被研發(fā)，需求內(nèi)容是什么，如何去做驗收。

·需求說明

·工作流程

（泳道圖/交互圖等）

·驗收條件

GIVEN? ? ? ? ? ? ?WHEN? ? ? ? ? ? ? ? ? ? ?THEN? ? ? ? ? ? ? ? ? ? ? ? ?REMARK

·原型/UI設(shè)計

五、延伸：用戶故事的六個特性

好的用戶故事滿足INVEST原則

Independent? ?獨立性

Negotiable? ? ? 可協(xié)商

Valuable? ? ? ? ? 有價值

Estimable? ? ? ?可估算

Small? ? ? ? ? ? ? ?足夠小

Testable? ? ? ? ? 可測試性

獨立性：要盡可能地讓一個用戶故事獨立于其他的用戶故事。用戶故事之間的依賴使得制定計劃，確定優(yōu)先級，工作量估算都變得很困難。通常我們可以通過組合用戶故事和分解用戶故事來減少依賴性。

可協(xié)商性：一個用戶故事的內(nèi)容要是可以協(xié)商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節(jié)。具體的細節(jié)在溝通階段產(chǎn)出。一個用戶故事卡帶有了太多的細節(jié)，實際上限制了和用戶的溝通。

有價值：每個故事必須對客戶具有價值（無論是用戶還是購買方）。

可以估算性：開發(fā)團隊需要去估計一個用戶故事以便確定優(yōu)先級，工作量，安排計劃。通常讓開發(fā)者難以估計故事的問題來自：對于領(lǐng)域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

短小：一個好的故事在工作量上要盡量短小，最好不要超過3天的工作量（我們的實踐，具體可根據(jù)團隊自行定義），用戶故事越大，在安排計劃，工作量估算等方面的風(fēng)險就會越大。

可測試性：一個用戶故事要是可以測試的，以便于確認它是可以完成的。如果一個用戶故事不能夠測試，那你就無法知道它什么時候可以完成。

六、小結(jié)

在需求評審的階段，從用戶使用場景的角度出發(fā)，通過提問，把需求逐步澄清，并形成驗收條件，產(chǎn)、研、測三方共同確認，形成共識，以保證大家對需求的認知不發(fā)生偏差，為后續(xù)團隊正確的做事提供有價值的指導(dǎo)。根據(jù)用戶故事的基本特性，做到業(yè)務(wù)可驗收、研發(fā)可實現(xiàn)、測試可驗證、部署可交付。