這是鼎叔的第六十七篇原創文章。行業大牛和剛畢業的小白，都可以進來聊聊。
歡迎關注本公衆号《靈活測試轉型》，星标收藏，大量原創思考文章陸續推出。
對于Scrum和使用者故事實踐的最大難點，我相信是如何估算使用者故事的大小，如何拆解它？過大的使用者故事會帶來一系列的溝通複雜度和潛在品質風險，最好的使用者故事是不超過2-3開發人日就能夠完成的。本文重溫行業經典的估算和拆解方法，并從測試人員的角度思考它。
相關文章請看：聊聊使用者故事和測試啟發。
故事的大小
使用者故事從大到小，可以分類為Epic（史詩故事，需求梳理階段時的宏大目标），Feature（特性故事，疊代規劃的重點目标），User Story（使用者故事，疊代中要完成的具體價值點）。注意，也有些靈活書籍把Epic的規模放在Feature之下，鼎叔采用的是大規模靈活架構的定義，認為Epic規模更大。
常見的拆分模式
當使用者故事太大，無法放入一個疊代中，我們可以用各種手段進行拆分，確定拆分的每個使用者故事都有其價值，并可以獨立地端到端驗收。
以漸進的方式逐漸拆分故事，更小粒度的故事有利于團隊更準确地對工作量進行估算，更早傳遞解決方案中價值最高的那部分。
常見的9種使用者故事拆分方法，如下。
- 按工作流步驟拆分。哪怕隻是一部分工作流，對使用者也是有體驗感覺的，可以及時提供回報。如網上預定機票這個故事，可以拆分為：查找預定航班，生成訂單，擷取出票結果資訊，系統發送訂票成功短信等。
- 按業務規則變化拆分。如積分兌換這個故事，可以1 按積分兌換，2 按部分積分+現金兌換。
- 按主要/次要工作拆分。比如支援信用卡支付機票費用這個故事，可以先支援微信支付，再支援其他主要支付方式。
- 按業務簡單和複雜劃分。比如商品搜尋功能，可以1 按商品名稱搜尋，2 按其他商品屬性的進階搜尋。
- 按照處理資料變化來劃分。比如網站的内容管理功能，可以 1 支援中文，2支援英文，3 支援其他語言。
- 按照界面變化來劃分。比如先輸出最簡單的UI界面，再輸出精美配色的UI界面。
- 按照性能規格來劃分。先從慢速中把使用者價值做出來，再進行性能優化改進。如1 完成XX功能顯示， 2 在10秒内完成XX功能顯示。
- 按照操作邊界來劃分。例如資料的增删改查，1 完成資料的查詢，2 完成資料的增加和删除，3 完成資料的修改。
- 拆出一個探針故事。對于我們知之甚少的比較大的故事，我們先在一段時間内做一個探針實驗，得到初步的調查結論。
估算使用者故事的方法
估算使用者故事的大小是團隊協作的難點，基本的出發點是越小的故事，估算誤差越小，越大的故事，估算精度越低。就好像評估星球的體積大小。這就是我們經常利用斐波拉契數列來收斂估算結果的原因，如下圖，以最小星球體積為1，其他星球的大小隻能在這個序列中挑選估值：1，2，3，5，8，13，21，34... ...
使用者故事的大小估算方法，通常是集體評估的方式，隻做相對大小的評估，可利用斐波拉契撲克牌和T恤尺寸等方法進行估算。
開始估算故事之前，需要PO給大家閱讀或講解這個故事的目的，驗收标準，如果有互動原型等資訊更佳。成員可以針對這個故事進行提問，PO和技術leader可以解答。
成員集體估算是背靠背的，即同時攤開手中的牌，看大小是否一緻。先找一個最簡單的開發需求來做估算，看看能否對齊成員間的基準，對齊後再估算更大的故事。
發生估算分歧時，會讓雙方解釋原因，重新估算或投票，最多隻能估算三輪。
集體估算不是集體承諾，估算無需精确度量，目标是求穩，長期估算結果趨同即可，眼前有一些分歧很正常。整個過程，便于大家對于需求背後的價值和複雜度形成共識，互相學習。
我們可以預設一個故事點就是一個工程師人天可以完成的研發工作（包括設計，編碼，測試修複，研讨等），它并不是按沉浸式滿負荷工作時長（理想人日）來估計的，有一定的buffer(折扣，通常是10%或20%)，考慮到人員有臨時請假，團隊外會議和雜事打擾的事項。但是這個折扣如果過高就需要集體改進了。
技術團隊在一個疊代中的工作人日總數是已知的，即疊代工作日*人數，這就是“疊代速率”。
從行業經驗來看，史詩故事的大小範圍通常是55-144之間（按斐波拉契數列），特性故事點在13-55之間，使用者故事點在1-13之間。
注意：很多團隊預設測試人力不是瓶頸，是以估算故事點數隻考慮開發側工作量，人數也隻統計開發人員。
其他團隊的做法是，故事點數考慮所有測試工作，人數也包含了專職測試人員。
這兩類做法我認為都是正确的。
疊代開發速率的監控和改進
當團隊完成所有使用者故事的大小估算，将總故事點數除以疊代速率，就得到我們要幾個疊代才能完成所有傳遞計劃。
在未來的每個疊代，都度量我們實際完成了多少個故事點，就能判斷我們在疊代初期預估需求工作量的偏差率如何。注意，疊代中沒有完成的故事，相應的完成故事點就是0！
初期預估的疊代速率，後期調整優化後會穩定下來，然後随着靈活改進措施的實施可能會有一定程度的提升。
項目經理需要關注疊代中的工作燃盡圖表，分析是什麼原因導緻計劃中的測試任務完成過程不太符合預期，比如，測試任務為什麼遲遲沒有開始，前期測試程序為什麼被阻塞，測試工作量估算明顯和實際不符合，等等，這個分析過程對于未來的測試速率估算準确性，對于提高人員效率，将大有裨益。疊代燃盡圖如下所示，理想情況下，它是一個下降的曲線，随着剩餘工作的完成，燒盡至零。
下圖是産品需求的價值路線圖，完整的描述了産品從願景到釋出，整個生命周期的價值是如何實作的。
下面詳細解答使用者故事實踐中的幾個熱門問題。
傳遞故事點能用來績效考核麼？
建議不要用于績效考核。
之是以要團隊集體估算，就是減少對個人故事的追蹤，和個人績效挂鈎，會導緻個人在評估時降低要求，同時阻礙團隊内的互助合作。
從團隊角度看，也不建議通過傳遞故事點數來橫向考核團隊。每個團隊的人員成熟度和經驗不同，業務難度不同，都會形成一個适合自己的開發吞吐節奏，這個節奏越舒服，越有利于産能最大化和自主改進。
但是通過跨團隊的故事點實踐對比，故事點傳遞代碼規模小、品質相對低的團隊，可以像名額高的團隊學習，但還是要保持自身的穩定節奏和傳遞滿意度。
疊代規劃的故事優先級怎麼定？
既然一個疊代隻能排入一定大小的故事集合（不超過預期速率），那該排入哪些使用者故事呢？隻看産品負責人的優先級排序麼？
當然，産品負責人應該是最終拍闆者，但是技術團隊可以合作給出參考意見：
1 哪些故事對使用者的利益能産生最大化效果？每個故事都有使用者價值說明，PO或者團隊對使用者價值評估大小（即：給出相對價值點）
2 候選故事的成本。成本效益高的故事可以優先，即價值點/故事點的值最大的優先。
3 故事之間的内聚性如何？高内聚的故事集中完成，可能有利于提升研發效率和使用者體驗。
4 哪個故事的實作能支援近期釋出計劃？
針對每次計劃完成的使用者故事，我們可以用MoSCow規則來做優先級分類，即：Must 必須有，Should have 應該有，Could have 可以有，Won't have這次不會有。
如何判斷使用者故事是否要在本疊代完成，可以基于這幾個次元思考：如果不能完成，風險有多大？推遲這個故事，會給其他故事帶來什麼影響？基于目前産品架構，能幫使用者提高價值的故事可以提高優先級。
疊代中想變更傳遞需求怎麼辦？
靈活研發歡迎變化，當一個更緊急的需求插入本疊代時，先估算插入需求的故事點，再從疊代相對低優先級故事中，拿出同樣大小的故事集合即可。這種應對方式比傳統研發管控方法更靈活，更簡單，更準确。
備援需求是如何産生的？
縱觀傳遞滿意度低的團隊，除了需求太大，還經常有需求備援的問題。所謂備援，就是上線後使用者使用率很低的需求。據業界統計，64%的軟體特性從未被使用到。
靈活團隊在識别需求價值，拆解使用者故事和排期之前，PO（産品責任人）要關注這些備援現象，并積極溝通，思考降低需求備援的方法：
- 業務方代表擔心功能遺漏帶來的風險，要求把各種功能都加上。客戶缺乏安全感，通過加需求作為談判技巧。業務方/客戶圖省事，或者公司由麻煩的預算制度，是以一次性盡可能把需求都提上。之前分享過，和需求大小挂鈎付費的合同，功能足夠用就可以結束合同，這樣更有利于保障傳遞的效率，降低開發浪費。客戶溝通合作和建立信任，要高于事無巨細的合同談判。使用者故事不能再拆解了麼？使用者故事是需求價值傳遞的最小單元。但是，從研發分工的角度，使用者故事可以拆解為任務這個最小單元，完成一系列的任務後，使用者故事才算完成。具體任務可以是：設計，單測，系統測試，歸檔等等，可以在團隊的DoD（完成定義）中約定每個故事需要完成哪些類型的任務。在任務的跟進中要注意跟進的是團隊集體傳遞的結果，避免追蹤個人的進度。任務的評估耗時可以以理想小時為機關，建議一個任務卡不超過1理想人天，以便通過看闆及時更新。