故事點估算，這真的是問題嗎？
用戶故事的估算總是不準確的，這是估算的第一要義。正因為此，我們才不能在故事估算上耗費太多時間。估算不應該由個人來進行，團隊的 Planning Game 不可缺少。在估算用戶故事時，不應該估算時間，而應該估算用戶故事的規模。同時，在團隊進行估算時，團隊應對“Done”的定義達成一致。
我把這稱為用戶故事估算的四要素。——然而，即便你掌握了估算的要素與原則，掌握了正確的估算方法，就一定能解決故事估算的問題么？
“故事的估算是按照時間來的，這是一個大問題！”我的一名咨詢客戶有些心急火燎，迫不及待想要我幫助她解決這個麻煩。可在我看來，這根本不是什 么問題。即便是按照時間進行估算，只要團隊成員足夠了解用戶故事，并以團隊形式開展估算，得出的工作量仍然可行。在“估算總是不準確的”大前提下，我們只 需要讓計劃時間更接近實際工作時間即可。方法有很多，例如可以通過歷史數據對估算進行調整，以及事先識別可能存在的風險等多種措施來做到這一點。
但是客戶并不這樣認為。——好吧，我需要實地調研。
問題是起點，如果你只看表面，繞了一圈，你還是會回到起點；只有深度挖掘背后的起因，你才能走到問題解決的終點。
當我看到用戶故事
當我拿到客戶編寫的用戶故事時，我忽然明白問題所在了。用戶故事的編寫顯然是照貓畫虎描出來的。用戶故事的所有要素它都具備了，然而卻只得其形，卻未得其神。用戶故事如下：
as 一名顧客
I want to 進入商品清單后
So that 進行查詢
<p> - </p> <p> Given 顧客 </p> <p> When 進入商品查詢頁面 </p> <p> Then 系統執行查詢 </p></blockquote>
用戶故事的末尾，則是一大段針對界面操作流程的描述。“知其然而不知其所以然”，對于許多敏捷實踐，我們就這般渾渾噩噩地推行著，以為這是更好的方法，卻從未有人去質問“為什么”。當問題暴露時，常常是頭痛醫頭，腳痛醫腳，直至病入膏肓，尚且不知病因究竟出在哪兒？
軟件開發本身就是一個生態系統，諸多方法與實踐其實并不能孤立去看待。這個系統的任何動作與活動，就像是蝴蝶扇動翅膀，飄飏起南美熱帶森林的季風，殊不知它卻掀起了印度洋的颶風。
為什么是用戶故事？
在傳統的軟件開發過程中，我們稱需求為功能點，而 Jacobsen 則將需求提煉為用例（Use Case），在 FDD（特性驅動開發）方法中，又將功能點稱為 Feature，至于 Scrum，則干癟癟地將其命名為 Backlog。但我，更喜歡以用戶故事名之。
描述需求就像講述故事一般的明白曉暢，甚至做到讓故事的讀者能夠身臨其境。雖然不要求將軟件需求寫得像古龍小說般精彩，但最好也要能做到像白居易詩一樣童叟可讀。其實簡單說來，就是要讓需求能夠讓人讀得懂，
講故事需要哪些基本要素？答案是 6W，即 Who、What、Why、When、Where 和 hoW。具備這六個要素，就能講述出一個活靈活現的故事了。6W 撐起了一個場景。戲臺的布景裝飾出景色，演員們身著戲服演繹著春秋，演繹著人生百態與喜怒哀愁。
寫用戶故事當然不能天馬行空。要學會取舍。高手當然可以信手拈來，若未深得其中精髓，就該退而求其次，遵循普遍被認可的模式為好，例如 as...I want to ... so that，又例如 given...when...then。
模式或許限制了你的自由發揮，但它的引導價值卻可以讓你快速上手。但首先你得明白這樣的模式背后隱藏的道理。之所以明確提出 as...I want to...so that... 就是希望需求分析師在分析用戶故事時，要思考功能的使用者是誰，要做什么，價值又是什么？這恰好對應了 6W 的 Who、What 和 Why。就像拍電影一樣，我們總是要從人的角度去講故事，去觀察世界，體察人與人之間的關系。而在最后的制作階段，則要從整部電影的風格、價值觀、故事著 手對內容進行裁剪。即使部分拍攝片段唯美而精彩，演員表演也極到位，若與整部電影發生沖突，導演也要忍痛割愛。需求分析師也需要站在用戶的角度去體驗需 求，尋找業務的價值。
Given...When...Then 的驅動力
許多敏捷實踐其實是諸多工程師千錘百煉得來的體驗。這些體驗如智者，一言一行，都別有深意。采用 Given...When...Then 模式，實則代表了接口設計的驅動力。這正是 ATDD 以及 TDD 的慣用手法。
Given 是什么？就像契約式設計一般，它等同于前置條件。從接口角度講，就是輸入數據。當滿足這些條件（無論是數據，還是狀態）后，就可以執行動作了。When 就是這個動作，其實就是我們需要開發的功能，又或者說，正是我們要驅動出來的接口。至于 Then，就是后置條件，也即是我們所謂的驗證。這就很好地與測試結合起來了。
在編寫 Given...When...Then 時，我們要注意，只有 Given 與 Then 可以通過 and 連接更多的內容。When 只能是一句話！
為什么？——讓我們回到場景。在編寫用戶故事時，需要從用戶角度出發，驅動出故事發生的場景。如果說故事是整部話劇，場景就應該是話劇的一個相 對完整的片段。在用戶故事級別，場景應盡可能保持小。就像 SRP（單一職責原則）講的那樣，最好一個場景只做一件事情。一旦發現在編寫 When 時，無法用一句話表達，就應該思考，是否需要對該場景進行進一步拆分。
場景又可分為正常場景與異常場景，正如 Use Case 中提出的正常流程與異常流程。例如，以查詢來說，正常場景就是查詢獲得了符合給定條件的記錄。異常場景則可能包括兩個。第一個是沒有符合條件的記錄；第二個則是查詢過程發生異常，從而導致查詢失敗。
場景還可分為主要場景與擴展場景，可以對應 Use Case 中的用例與擴展用例。還是以查詢為例，主要場景就是查詢獲得符合給定條件的記錄；擴展場景則是查詢結果默認以名稱進行升序排列，并允許用戶對指定字段重新進行排序。
用戶故事的 INVEST 原則
當我們按照場景去編寫用戶故事時，我們會自然而然地去思考故事的拆分。有些場景可能確乎屬于同一個故事，但當你發現一個故事包含了太多的場景 時，就可以考慮把這些場景分開。例如把正常場景與異常場景分開，把主要場景與擴展場景分開，皆可。那么，我們該怎么對用戶故事進行拆分？這就需要運用 INVEST 原則了。
只要了解用戶故事，多數人都知道 INVEST 原則，可惜卻沒能將這個原則用好。如下是 INVEST 原則的說明：
- I——Independent
- N——Negotiable
- V——Valuable
- E——Estimable
- S——Small
- T——Testable
我個人的理解是將這些原則分為幾個層次。首先是 Valuable，即判斷一個用戶故事是否為好的故事，關鍵在于它是否提供了價值。這個價值指的是業務價值。若一個用戶故事沒有業務價值，要么需要刪掉，要么就說明它不是故事，而應該是任務（Task）。
在滿足了V原則后，就需要判斷I。I是判斷用戶故事的獨立性。理想的故事拆分應保證故事之間不存在依賴。如果存在依賴，就需要去識別產生依賴的 原因。多數情況下，都是由于支撐性功能帶來的依賴。例如兩個用戶故事都需要發送郵件通知客戶。若完成了其中一個用戶故事，則另一個用戶故事就不必重復開發 郵件通知功能了。此時，我們可以考慮將郵件通知（可能還包括郵件模板）拆分為單獨的故事或任務。我們要盡量地保證用戶故事的獨立性，只有在無法繼續拆分以 隔離依賴的情況下，我們才能選擇妥協。
接下來再考慮N。我們希望用戶故事是描述清楚的，可以促進客戶與團隊以及團隊成員之間的溝通。故事描述最好沒有歧義。有時候，為了更好地說明故事，可以引入實例或者 UI 原型。基于這些故事，我們需要更好地與客戶協作，明確滿足客戶的需求。
有了明白曉暢的故事描述，再來判斷這個故事是否可測。故事是可測的，就意味著它定義了驗收標準。只有通過了驗收標準，故事才可以被標記為“Done”。若故事不具備可測試性，則用戶故事不過就是平鋪直敘的故事描述而已。畢竟，用戶故事不是小說。
最后，我們應該合起來看待E和S。因為一個用戶故事到底小不小，最直觀的判斷就是看它能不能被估算。如果很難估算，要么是故事沒有描述清楚，要 么是這個故事太大。太大的故事總是很難掌控，而功能點的疊加并不只是一加一那么簡單。無論何時，分而治之都是軟件開發的“不二法門”。
與其說 INVEST 是用戶故事的拆分原則，不如說它是衡量一個用戶故事好壞的驗收準則。
驗收條件（Acceptance Criteria）
在提及用戶故事的 Testable 原則時，我其實有些意猶未盡。這未盡的內容就是驗收條件。很多需求分析師都把它忽略了，又或者散亂地將這些驗收條件分散到需求描述中。其實，在傳統的制造 行業，在軟件開發的測試環節，我們一直都遵照著驗收條件來辦事。但是，對于多數需求分析師而言，他或者她可能更關注用戶體驗，功能細節，或者業務目標與范 圍，卻往往缺乏逆向的思維去思考驗收條件。這也是為什么我們提倡 BA 與 QA 結對編寫用戶故事的初衷。
驗收條件可以說是溝通的“契約”，使得我們的用戶故事能夠成為一個“閉環”。驗收條件意味著“照單驗收，立此存照。”
我們可以為用戶故事的每個場景編寫各自的驗收條件，也可以為整個用戶故事編寫一個整體的驗收條件。驗收條件必須簡單清楚，每條內容都應該是可驗證的。例如針對查詢功能而言，我們可以寫出如下驗收條件：
查詢結果默認以名稱升序排列；
當查詢結果超過 20 條時，應進行分頁考慮；
分頁條數的閾值可以進行設置；
如果沒有查詢結果，應提示“無滿足條件的結果集”。
如果查詢失敗，應彈出“查詢失敗”的錯誤框，并在錯誤框中給出錯誤原因。
……
只有編寫出好的符合 INVEST 原則的用戶故事，才談得上對用戶故事進行估算。估算并不能幫助你提升團隊的生產效率，更不能以估算的點作為團隊及團隊成員的量化指標。估算是天氣預報，它 唯一的作用就是提醒你明日出行帶傘還是不帶傘。如果帶了傘，卻沒有雨，你也不必抱怨；如果沒帶傘，卻下了雨，那就慢慢享受雨水的清涼吧。當然，若遇上大雨 傾盆，那就找個地兒歇歇吧。你總不能因為天氣預報讓你飽受了淋漓之苦，而視天氣預報為仇寇吧。
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！