【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].北京：人民郵電出版社。

點擊關注，第一時間瞭解華爲雲新鮮技術~