早期用戶故事寫在卡片上，只需一個句子。隨著越來越多的系統和產品采用敏捷開發，對于有些復雜長生命周期的系統和產品而言，用戶故事的內容值得積累，以便后續追查和修改。另外一個情形是為了確保用戶故事真的完成，需要在前期就明確其驗收條件（也翻譯為接收條件），因此曾幾何時開始，用戶故事的寫法成了 用戶故事經典句式+驗收條件。
在https://blog.versionone.com/agile-acceptance-criteria/ 上提供了如下一個故事的樣例。

As an executive, I want to be able to filter the dashboard by department so that I can isolate data by a specific department.【翻譯：作為一個高層管理者，我想要根據部門來查看儀表板，這樣我區分不同部門的表現。】

Acceptance Criteria:【驗收條件】
● Given the Executive Dashboard default view, when I select the department drop-down, I have the ability to select a specific department to so only that data throughout the dashboard. 【給定：在高管儀表板缺省視圖上，當：我選擇部門下列列表時，然后：我可以選擇一個指定的部門，這樣只有這個部門的數據呈現到儀表板】
● Given the department drop-down, when I select a specific department, the entire dashboard filters to display only that department data.【給定：部門下拉列表，當：我選擇一個部門，整個儀表板只顯示這個部門數據】

遺留需討論的問題有
1. “Hey Product Owner, does the Executive need to be able to Multi-select several departments?”
2. “How about grouping by division?”
3. “who can access the Executive Dashboard”

以上的故事正文就是故事經典句式所帶來的一句話，加入了2個GWT。
利用上述格式，如果各類情況出現多的話，就會需要許多條GWT。

筆者綜合用例規約寫法，認為采用講故事方法可以帶來更好的故事表達方式。方法是把功能性驗收條件采用正常步驟和異常步驟組合來表達，把非功能性驗收條件作為非功能性要求來表達。具體而言，采用如下的故事格式。
故事標題：考慮卡片尺寸
故事簡要說明：采用經典的故事一句話說明
故事起點：說明故事從哪里開始，其上下文
正常步驟：
1，采用流水號編號
2，此為示例
異常步驟：
1a，根據正常步驟編號來說明哪個正常步驟出現異常。
非功能性要求： 這里說明非功能性要求，功能性要求在上述步驟中說明

按照筆者的故事敘述方法（也稱為講故事方法，Story telling），試著來改寫下以上故事，看看兩個不同方法的比較。【此括號為說明，不是故事的內容】
Title標題： filter the dashboard by department
根據部門來查看儀表板
【簡短的故事標題有利于看板展現和交流】
Brief 簡介：
As an executive, I want to be able to filter the dashboard by department so that I can isolate data by a specific department.
作為一個高層管理者，我想要根據部門來查看儀表板，這樣我區分不同部門的表現。

Start Point 故事起點： the dashboard is shown
儀表板已經得到展現。【明確整個故事的起點，有利于展開后續的故事情節】
Normal Steps 正常步驟：
【這下面的步驟是達成故事成功進行的，達成故事的目的】
1. executive select the department drop-down
2. system list all departments in drop-down
3. executive choose a specific department
4. the entire dashboard filters to display only that department data.
○ 4.1 department data is grouped by division(@furture，此標記意味著本次不包括，未來再考慮).
1，高管選擇部門列表
2，系統列出所有部門名稱
3，高管選擇某個部門
4，儀表板只顯示這個部門的數據
4.1 根據大區分組來查看部門數據（@未來）
Abnormal Steps：異常步驟：
【這下面的步驟是上述正常步驟中可能碰到的異常步驟，3a意味在是第3步正常步驟出現的第1個異常情況】
● 3a executive choose 2+ departments by shift click or multi-selection, only first department will be choosen
3a，高管通過shift click或者多選，選擇了2+個部門，系統只處理被選中的第1個部門

對于who can access the Executive Dashboard這個問題，本用戶故事的起點是dashboard is shown，因此這個問題不在這個用戶故事的范圍之內，應當是在show dashboard那個故事當中。

綜上，新的故事寫法就說明完成了。需要說明的是雖然模仿了用例規約的寫法，但與用例規約最大的差別是故事敘述不強制要求全面完整，而是按照敏捷擁抱變化的思想，在過程中按需補充。
這樣做法明顯的好處有：
1，對比GWT寫法，所用文字更加簡練，而且按步驟閱讀，可讀性更好
2，在WIKI類工具支持下，可以非常方便的向下分解，可以容易地把大故事拆分成小故事。

總結

以上是生活随笔為你收集整理的让用户故事真的像故事那样的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。