提起使用者故事拆分，我們聽得最多的就是INVEST原則（關於INVEST原則可以參考文章“使用者故事等於需求說明”——你一定沒有寫好使用者故事），但很多人面臨的問題是拿到一個較大的使用者故事時，該如何拆分才能使得它滿足Small的原則呢？接下來，就和大家一起討論一下如何拆分使用者故事。
首先，拆分可以參考以下流程：評估待拆分使用者故事-按方法拆分-評估拆分結果。（文末有彩蛋，不要錯過）
評估待拆分使用者故事
拆分前，我們需要知道手中的使用者故事是否需要拆分，就是目前是否已經符合了Small的原則。我們推薦一個使用者故事在1-2天內能完成，最多不超過3天，則符合Small原則。有些地方給出的說法是1/5-1/10團隊速率，這個演算法和你每個迭代天數以及團隊成員數有關係，所以我個人還是喜歡簡單的說，1-2個工作日能完成算Small。在這種情況下如果你的使用者故事已經符合了INVEST其他原則的話，那就沒必要拆成多個使用者故事了，因為再拆就增加了管理成本（這裡不包括拆成多個task，task可以再多拆分的）。
好，當你已經根據上面評估了使用者故事，發現依舊需要拆分的話，那麼可以按下面方法進行拆分。
按方法拆分
目前業界比較好的方法是Richard Lawrence的方法，原文請參考https://agileforall.com/patterns-for-splitting-user-stories/，下圖為已官方翻譯的中文版本。
原文裡有作者的切分方式，這裡我只根據我的理解選擇更熟悉的例子，同時合併了其中一些方法。
方法一：按流程拆分
作為有愛心的有財力的中國人，我可以從國外進口口罩捐給武漢。
這個使用者故事涉及的過程就很多了，需要找到國外可靠的口罩供應商，然後付款，運回國內，再送到武漢捐給指定醫院等等。我們可以先分析整個使用者故事成一個一個連續的流程，如果每個小流程作為一個使用者故事，能對使用者有價值，那我們就先這麼拆開。結果比如下面
-
作為有愛心的有財力的中國人，我可以尋找個國外的朋友幫忙尋找可靠的口罩來源。
-
作為有愛心的有財力的中國人，我可以在這個來源付款購買指定數量的口罩。
-
作為有愛心的有財力的中國人，我可以將口罩從外國運回國內。
-
作為有愛心的有財力的中國人，我可以將口罩從國內某地送到武漢捐給醫院。
方法二：按操作種類劃分
作為有愛心的中國人，我可以在口罩購買平臺上操作以完成購買。
如果是一個業務更簡單的系統的話，對應的就是增刪改查動作。這裡的操作會複雜些，把每個操作拆分成一個使用者故事即可。
-
作為有愛心的中國人，我可以在口罩購買平臺上購買。
-
作為有愛心的中國人，我可以在口罩購買平臺上退貨。
-
作為有愛心的中國人，我可以在口罩購買平臺上查詢。
-
作為有愛心的中國人，我可以在口罩購買平臺上賣貨。
方法三：拆出主要的工作
作為有愛心的中國人，我可以購買N95/KN95/醫用外科三種口罩進行捐贈。
整個購買捐贈流程就很複雜了，還要買不同種類的口罩，明顯這三種口罩可以拆成三個故事，同時考慮一點，就是無差別的完成購買一個口罩進行捐贈的故事後，剩下的兩種需要的工作量就會很少了，同時這裡如果沒有區分三種口罩的優先順序的話，我們可以先拆出一個作為主要工作，再看剩下的兩個是合到一起還是繼續拆分。
比如拆成如下
-
作為有愛心的中國人，我可以購買其中一種（N95/KN95/醫用外科）口罩進行捐贈。（3個故事點）
-
作為有愛心的中國人，我可以購買另外一種（N95/KN95/醫用外科）口罩進行捐贈。（1個故事點）
-
作為有愛心的中國人，我可以購買最後一種（N95/KN95/醫用外科）口罩進行捐贈。（1個故事點）
如果後兩個都比較小，合道一起也沒問題的話，也可以拆成如下
-
作為有愛心的中國人，我可以購買其中一種（N95/KN95/醫用外科）口罩進行捐贈。（3個故事點）
-
作為有愛心的中國人，我可以購買另外兩種（N95/KN95/醫用外科）口罩進行捐贈。（2個故事點）
方法四：業務規則分類
作為有愛心的中國人，我可以購買三十萬個口罩捐贈給武漢。
這裡購買的口罩可以選擇多種型別，價格不一樣，效果不一樣，這就是我們要區分的不同的業務規則，拆分後可能如下
-
作為有愛心的中國人，我可以購買三十萬個最貴的口罩捐贈給武漢。
-
作為有愛心的中國人，我可以購買三十萬個口罩捐贈給武漢，不區分口罩種類。
-
作為有愛心的中國人，我可以購買三十萬個口罩捐贈給武漢，只要N95和KN95級別的。
方法五：簡單到複雜
作為有愛心的中國人，我可以購買口罩捐贈給武漢。
簡單一句話，涉及的業務可以是購買何種口罩，如何捐贈，給什麼機構等，明顯不能作為一個故事進行交付，需要拆分。但是業務太複雜，一開始無法全都想清楚，可以先做最基本的，然後再根據方法四的業務規則分類進行擴充套件。
-
（簡單）作為有愛心的中國人，我可以購買口罩捐贈給武漢。
-
（複雜）在XXX日期購買。
-
（複雜）通過不同的運輸通道送到武漢。
-
（複雜）捐贈給XXX不同的醫院。
方法六：推遲效能實現
作為有愛心的中國人，我可以明天購買口罩捐贈給武漢。
明天這個效能太高了，實現起來可能比較困難，我們先實現購買和捐贈，不考慮哪天能完成，再考慮明天這個效能要求。
-
作為有愛心的中國人，我可以購買口罩捐贈給武漢。
-
作為有愛心的中國人，我可以明天購買口罩並完成捐贈給武漢。
方法七：探針
作為有愛心的中國人，我可以明天購買口罩捐贈給武漢。
這個可能對我來說太複雜了，完全不知道該買什麼型別的口罩，買30萬個大概多少錢，渠道買比較靠譜，怎麼捐贈，給哪個機構，如果現在就強行做計劃的話，可能最後發現，我手上的錢是不夠的，或者週期太長，到最後才發現的話，會損失很多。所以一般都是先去探探路。
-
調查市場上口罩型別、價格、渠道。
-
調查捐贈方式，靠譜的接受機構。
-
實施捐贈（需要等前面的工作完畢後重新評估）
評估拆分結果
拆分完畢後，再用INVEST原則進行評估，如果符合，那就沒問題了。但是有的時候會不符合其中某些原則，比如獨立性，但是實際業務就只能這樣。比如上面提到的方法三的拆分，這個是必然有關係的，不可能先做第二個使用者故事後做第一個。這時只能選擇不符合獨立性原則。
彩蛋
看了上面這麼多拆分方法，是否迷糊了？是否每次拆分都要對照上面的方法一個一個的試？其實不需要的，根據經驗，拆分使用者故事最重要的是，先捋清楚整個業務(劃重點，這個最重要，之前很多例子你感覺切分的不如作者好，都是因為對舉例的業務不熟悉)，然後按照最重要的原則-縱著切即可。如下圖所示。
縱著切的意思是，每個切分出來的需求是個單獨對使用者有價值的，就像上圖中切出來的一塊蛋糕，是獨立的個體，包括這一塊蛋糕的所有層次以及上面的小人。對比的橫著切的意思是所有的需求放一起將前臺、後臺、資料庫操作這樣切分出來，結果就是先用幾個迭代將所有的需求前臺工作做完了，再開發後臺的，這樣無法儘早交付有價值的需求，比如先將蛋糕上上所有的小人都切下來了。
如果業務比較複雜，那麼就以MVP的思想，先交付一個簡單的端到端的業務，再慢慢擴充套件複雜程度。如果過於複雜，就嘗試探針方法。
如果捋清楚了需求，嘗試縱著切，發現很難下手，這時候再來看上面提到的Lawrence的七個方法，尋求幫助。
