小P說

複雜需求使用者故事拆分可遵循3個原則、9種方法。

像惠普和中興通訊這樣的大型跨國公司都有規模龐大的研發組織，建立了敏捷教練團隊，並在研發組織中廣泛推廣敏捷專案管理。我曾經在這兩家公司參加了敏捷專案的諮詢和實施，接觸到的不少客戶是電信、金融、能源等大型企業。使用者需求往往非常複雜，掌握複雜需求使用者故事的拆分方法非常關鍵，這直接影響敏捷專案的成敗。具體說來，複雜需求使用者故事拆分可遵循3個原則、9種方法。

3個原則

INVEST原則

拆分使用者故事要遵循比爾·維克(Bill Wake)的INVEST原則，即一個合適的使用者故事應該是獨立的(Independent)、有價值的(Valuable)、可討論的(Negotiable)、小的(Small)、可估算的(Estimable)和可測試驗證的(Testable)。

二八原則

根據帕累託原則也就是二八原則，一個迭代80%的價值可能來自於其中20%的使用者故事。假如有兩種故事拆分方式，當第一種拆分方式將低價值部分拆分成獨立的故事，而另一種拆分方式沒有做到時，就意味著後一種方式把浪費隱藏到了每個小故事裡。此時，應當選擇前一種拆分方式，這樣可以把低價值的故事直接作廢或推遲實現。

二八原則的驗證方法是：在拆分後的一系列故事中，高價值、中價值、低價值的故事要一目瞭然，要能很明顯找到一個實現它可以得到高價值或能降低大部分風險的故事。

故事適中原則

故事太大不好。故事太大，裡面內容龐雜，頭緒太多，可能導致無處下手或在一個迭代內無法完成。“小”這一特性要求我們拆分大的故事。但拆分故事時依然要遵循INVEST原則。

故事太小也不好。比如有的敏捷團隊太過細分故事：對於資料庫建一個故事、對於UI建一個故事等，這樣雖可以滿足“小”這一特性，但它卻不是“獨立的”和“有價值的”。

故事應該要多小呢?建議每個迭代6~10個故事，當然故事拆分的顆粒度取決於專案團隊的生產效率。對很多團隊來講，當一個使用者故事龐大到8個甚至13個故事點的時候就需要進行拆分了。

建議每個迭代內的使用者故事的故事點數差別不宜太大，拆分後得到的故事最好規模差不多大。把一個8點的故事拆分成4個2點的故事比拆分成5點和3點的故事更有用，因為PO能更自由地編排優先順序。 

9種方法

理查德·勞倫斯(Richard Lawrence)和他的團隊總結出故事拆分的9種經典方法。

簡單/複雜

假如團隊正在討論的某個故事變得越來越大，我們可以停下來並提問：“可以工作的最簡單版本是什麼?”捕捉這一簡單版本作為一個單獨故事，然後把所有變體和複雜性拆解到它們各自的故事中。

例如，作為手機使用者，我希望在開機狀態下系統能儘可能地尋呼到我，以便我不錯過任何電話。故事1，……系統能記錄我最近活動過的小區進行尋呼……故事2，……系統能記錄我最近活動過的三個小區進行尋呼……故事3，……系統能記錄我之前所在MSC進行邊界尋呼……

推遲效能實現

不要太早考慮效能要求，我們常常忘了“讓它工作，然後讓它更快”這個原則。

比如我們會有這樣一個使用者故事：作為使用者，我希望能夠在1秒內獲取查詢結果。可能這個1秒的優化會花去我們很多時間，而且優化後由於其他模組的影響，查詢速度可能再次變慢，所以我們可以嘗試拆分成以下故事：故事1，作為使用者，我希望能夠獲取查詢結果。故事2，作為使用者，我希望查詢結果能夠在1秒內獲取。把故事1放入早期迭代，故事2可以儘量晚一些，在交付前完成，以排除其他模組可能帶來的影響。

基於工作流步驟進行拆分

識別出使用者為完成具體工作流採取的特定步驟，然後通過一些增量階段實現工作流。如果已經能畫出具體場景的流程，則可以先從工作流程拆分。該方法也叫作最簡路徑法，即先拆出最簡路徑，再基於最簡路徑新增步驟，直到覆蓋完整路徑。

介面可變性

對於需求中業務流程和邏輯規則相同，僅涉及介面不同，也就是獲取資料的渠道和方式不同，我們可以基於介面的差異進行故事拆分。

例如，作為微信使用者，我可以新增好友以便擴大朋友圈。故事1，……我可以通過搖一搖方式新增好友……故事2，……我可以通過掃二維碼方式新增好友……故事3，……我可以通過手寫輸入方式新增好友……

主要投入

根據主要投入或工作量來拆分故事。有時一個故事可以分為幾部分,大部分的工作將用於實現第一個故事。

例如，一張信用卡處理的故事：作為一個使用者,我可以用維薩、萬事達、大來卡或美國運通支付航班費用。這個故事可以分成四個故事，每個卡型作為一個故事。但是首先實現第一種信用卡付費的工作量最大。一旦第一種信用卡能付費，再增加其他信用卡，其工作量就小很多。所以信用卡處理基礎設施應該以支援第一個故事為目的進行構建，在以後新增更多的功能則相對簡單。

我們只需要拆為兩個使用者故事：故事1，……我可以使用一種信用卡付費(維薩、萬事達或美國運通中的一種)……故事2，……我可以使用所有三種信用卡付費(假定其中一種已經支援了)……這兩個新的故事仍然不是獨立的，但要比為每個卡型寫一個故事依賴關係更清晰。

業務規則可變性

針對需求中固定的流程載入不同業務規則的情形，我們按照業務規則拆分故事。

例如，作為網站使用者，我希望A網站能提供熱門推薦以便我可以更快找到感興趣的內容。故事1，……能根據帖子數量給出熱門頻道推薦……故事2，……能根據發帖數給出熱門作者推薦……故事3，……能根據回帖數量給出最多評論推薦……

業務操作

有些使用者故事使用了“管理”、“控制”等詞彙，它掩蓋了對故事執行的多種操作，大的使用者故事可以基於不同型別的操作進行故事拆分。

例如，作為系統管理員，我希望能夠管理使用系統的使用者。通過與系統管理員溝通，瞭解到他希望能夠增加使用系統的使用者，也能夠將不再使用系統的使用者(如離職、更換部門等)刪除，那麼我們可以將使用者故事拆分成下面幾個更小的故事：故事1，作為系統管理員，我希望能夠新增新使用者，使其能夠使用系統。故事2，作為系統管理員，我希望能夠查詢當前系統都有哪些使用者。故事3，作為系統管理員，我希望能夠修改使用者的資訊，方便我管理使用者。故事4，作為系統管理員，我希望能夠刪除使用者，保證只有必要的人在使用系統。

資料多樣性

我們可以根據資料類別進行拆分。比如我的使用者故事是：作為使用者，我希望能夠檢視系統的警告通知。我們系統警告通知有很多型別，各種警告的內容差別很大，那麼我們可以把這個大故事拆分成以下幾個小故事：故事1，作為使用者，我希望能夠檢視系統的異常流量警告通知;故事2，作為使用者，我希望能夠檢視系統的惡意程式碼警告通知;故事3，作為使用者，我希望能夠檢視系統的僵屍網路警告通知。

故事穿刺

故事穿刺其實就是摸著石頭過河。一個故事比較大不一定因為它複雜，而是由於我們對實施知之甚少。在這種情況下,再多的討論也不能讓我們知道如何拆分它。我們可以在一定時間內針對怎麼實施，先做個探針試驗。試驗過後，知道了深淺，揭開了面紗，我們往往就可以知道如何拆分它了。　

例如，作為使用者，我可以用信用卡支付。然後，把它分成：故事1，調查信用卡資料處理機制;故事2，實施信用卡處理。

探針模式放在最後，因為它應該是你的最後手段，所以在採取探針模式之前儘量去使用前八種方式。 

結語

需要強調的是，面對龐雜的使用者需求，我們在拆分使用者故事時不能單純使用一種方法，而是應該綜合運用上述技巧。這些拆分方法需要多練多用，才能熟能生巧，運用之妙，存乎一心，最終達到庖丁解牛的境界。