摘要：這篇文章主要解決因為不能很好地理解需求而估算做不好的問題，在這裡可以瞭解下如何利用使用者故事瞭解需求。

背景

很多團隊在應用敏捷開發時，對估算經常感到困惑。這裡所說的估算是指產品列表條目（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].北京：人民郵電出版社。

點選關注，第一時間瞭解華為雲新鮮技