【DevCloud·敏捷智庫】如何利用用戶故事了解需求
摘要：這篇文章主要解決因為不能很好地理解需求而估算做不好的問題，在這裡可以了解下如何利用用戶故事了解需求。
背景
很多團隊在應用敏捷開發時，對估算經常感到困惑。這裡所說的估算是指產品列表條目（PBI, Product Backlog Item）的估算 。比如，估算以什麼標準進行？開發、測試的工作量都要估算進去嗎？又比如，估算出了預計工時，但是實際工作中這個預計工時經常不準，為什麼還要估算這個預計工時呢？還有，做估算管理時，實際工時也會經常被使用，但很多團隊成員不按實際情況做實際工時的更新，它的意義何在？
問題分析
為什麼做估算呢？在規劃和管理產品開發過程中，我們需要回答一些重要的問題，例如：「將要完成多少個特性？」「我們什麼時候做完？」在使用敏捷時，為了能回答這些問題，我們需要估算產品的工作量大小並測算工作速率。有了這些信息，用特性集的估值除以團隊速率，我們就能推算出產品開發的持續周期了。
從小目標來講，做好了估算也可以很好的理解需求，幫助團隊成員認領任務。換句話說，團隊成員通過估算過程（持續溝通、確認）達成對需求的理解一致，明確完成定義是最重要的。
團隊之所以做不好估算，首先是因為沒有足夠細化需求，更不了解敏捷估算的幾個重要核心概念 ，即：「團隊估算」、「估算不是承諾」、「要準確，而不是精確」和「使用相對值，而不是絕對值」。其次是不了解估算的正確方法 。這篇文章主要解決因為不能很好地理解需求而估算做不好的問題，在這裡可以了解下如何利用用戶故事了解需求。
解決措施
估算有這麼些重要的意義，以下關於估算的內容是針對認可估算有意義，但是做不好的情況下給予的估算解決方案。
如何更清楚的了解和細化需求是第一步，細化需求和估算是一對兒不能拆分的「鴛鴦」。然後再學習準確的估算，解決估算的各種困惑。
要想準確的估算，先要了解和細化需求，同時了解需求很好的一種描述方法，即User Story。然後了解故事點以及什麼是估算及估算的核心概念。基於以上了解後再研究估算方法的實踐，最後選擇適合的估算方法完成估算活動。可以參考如下示意圖便於理解。本篇主要介紹如何了解和細化需求，後面幾篇會分別介紹估算核心概念、故事點、估算實踐方法和完成估算等內容,即：《如何估算第一篇：利用用戶故事了解需求》、《如何估算第二篇：估算的核心》、《如何估算第三篇：估算故事點》和《如何估算第四篇：常見估算方法》。
如何了解和細化需求，要先從用戶故事開始聊起。什麼是用戶故事？用戶故事是可用於陳述業務價值的一種簡便格式，適合各種PBI,特別是特性。用戶故事的製作方式旨在幫助業務人員和技術人員雙方都能更好的理解需求。
一個編寫良好的用戶故事是敏捷開發的基礎。編寫用戶故事的過程就是了解需求，一點點細化需求的過程。需求了解清楚了，一定程度上講估算的工作就已經完成了一大半，在不了解需求的情況下，估算也是沒有意義的。需求的了解是漸近明細的，很多情況下用戶的角度看是一種情況，開發人員角度看是另一種情況，這種誤解在需求了解階段經常出現，如下圖。
我們一起看看，為什麼說用戶故事寫好了就了解需求了呢？一個良好的用戶故事應該是相對獨立的、詳情應該是便於開發者和用戶溝通的、應該對用戶是有價值的、應該對於開發者來說儘可能的清晰以便進行估算的、應該短小的、通過預定義測試用例的使用確保它是可以測試的。以上的特點具備了，相信寫出來的用戶故事是在了解了用戶最初的需求基礎之上。其實，這些特點有一個名稱「INVEST原則」，是極限編程（英語簡寫XP,是敏捷開發方法之一）中對用戶故事拆分的指導原則。INVEST原則用於評估用戶故事，也就是說，好的用戶故事應該具備INVEST特性：即獨立的（Independent）、可協商的（Negotiable）、有價值的（Valuable）、可估算的（Estimatable）、大小適合的（Small）和可測試的（Testable）。
用戶故事究竟是什麼呢,如何才能寫好用戶故事？極限編程（XP）的創始人之一Ron Jeffries給出一個簡單有效的方法來幫助我們理解用戶故事。他將它描述為3C：卡片、會話和確認。了解了3C也就大概清楚了怎麼樣才能寫好一個用戶故事，以及為工作量估算做好基礎準備工作。
1.卡片
卡片非常簡單，最初可以寫在便利貼上，有一個通用的格式，如下面用戶故事模板圖，即寫明用戶種類（即用戶角色）、這類用戶想要達成什麼（目標）以及用戶為什麼想達成目標（收益）。
用戶故事標題的命名也是有講究的，在輔導團隊過程中發現有些團隊的用戶故事名稱不統一，容易對團隊造成困擾。例如，有的名稱太長，甚至是長長的一段話；有的太短，不能清晰的識別用戶核心內容是什麼；有的沒有價值，就是普通的任務（Task）。建議採用統一的動賓短語寫出較好的用戶故事標題：
- 用戶角度
描述從用戶角度看到的功能。例如，查看詳細信息、新增查詢、刪除貨品等。
- 系統角度
描述從待開發的系統的角度要實現的功能。例如，推送合同信息、發送用戶訂閱信息等。
當然，你也許會有個疑問。這些標題都沒有主語，好像也不太能快速識別用戶故事的核心內容。Of course，如果你想更清楚表達，也是可以加上主語的。比如，新註冊用戶查看詳細信息、庫存管理員查詢商品號、HR系統群發助手發送訂閱信息等。不過，更想說的是，更詳細的信息建議在卡片內容中說明，因為裏面寫明了用戶種類（即用戶角色）、這類用戶想要達成什麼（目標）以及用戶為什麼想達成目標（收益）。用戶故事標題還是以簡單、明了為主。
2.對話
在對話中討論需求細節。開發團隊、產品負責人（PO, Product Owner）利益干係人在對話中發現並探討需求的細節。用戶故事僅僅是進行此對話的承諾。用戶故事的一大好處就是它能把關注點從寫作轉移到會話。對話開啟了一個更豐富的信息交換與協作形式，從而確保正確描述需求並使每個人都能理解需求。對話不僅僅是靠口頭交流，還可以而且經常藉助於文檔，也可得出可以記下來的一張用戶界面草圖或業務規則的一份詳細闡述。
3.確認
用戶故事還要包含確認信息，也就是我們常說的接收標準（AC, Acceptance Criteria）。有了接收標準，開發團隊才更清楚要構建和測試什麼，產品負責人也可以確認用戶故事的實現是否符合預期。這些定義的接收標準也可以看作是高一級的接收測試。當然，開發故事的時候不會只有這幾個測試，這些與故事掛鈎的接收測試之所以存在，是因為從產品負責人的角度看，它們是捕獲及溝通信息、確定故事是否已經正確實現的重要方式之一。
我們了解了用戶故事和它的3C原則，現在來看看怎麼寫一個好的用戶故事，來更好地分析和理解需求。
我們知道了用戶故事的模板內容，看着非常簡單，然而越簡單的東西，反而越容易讓人放鬆警惕，然後照着模板內容寫出來的並不是一個很好的能夠理解需求的故事。舉例，一個餐飲點評網站的用戶故事可能會這樣寫：
作為一個用戶，我希望看到某個地址附近的餐館的公正的評論，這樣可以決定去哪裡吃飯。
其實，這就是一個典型的質量不高的用戶故事。寫出高質量的用戶故事的關鍵在於是否能夠準確地描述用戶希望獲取的價值。這個觀點只對了一部分，就像上面的故事一樣。大家可能會問，既然用戶希望獲取的價值都描述清楚了，為什麼客戶還不接受呢？主要原因是你高估了自己的理解能力和表達能力，同時也高估了客戶的理解能力和表達能力。如上面提到過的理解需求誤區圖，客戶的角度看需求是「6」，需求調研人員角度理解的是「9」，這也是常見的需求理解問題。
再來看另外一個例子：
作為一個在國貿工作，午休時間短，又追求健康飲食的公司白領，我希望看到某個地址附近的餐館的客觀的評論，這樣可以決定去哪裡吃飯。
可見，第二個故事中，感覺好多了。仔細看看差在哪裡呢？熟悉需求調研的夥伴兒們都知道，需求調研是從了解客戶是誰開始的，需要弄清楚產品需要獲得什麼樣的客戶的認可和接受，利用「對話」原則，充分溝通。這個故事描述了用戶的特徵，站在用戶角度思考，更能夠提升最終交付物為客戶接受的可能性。同時，還要定義清楚什麼是「接收標準」，與客戶確認清楚具體的條件。這個故事的接收標準可以參考接收標準參考內容圖：
現在可以了解怎麼寫好用戶故事，以及如何更好地理解客戶需求了。對需求有了更好的理解，接下來需要再了解一下估算的核心，《如何估算第二篇：估算的核心》以便更好地完成估算。
作者：華為雲社區專家｜黃藥師
參考附錄
1. Kenneth S. Rubin. Scrum精髓[M].北京：清華大學出版社。
2. Mark C. Layton. 敏捷項目管理[M].北京：人民郵電出版社。
