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