復雜需求用戶故事拆分可遵循3個原則、9種方法。
像惠普和中興通訊這樣的大型跨國公司都有規(guī)模龐大的研發(fā)組織，建立了敏捷教練團隊，并在研發(fā)組織中廣泛推廣敏捷項目管理。我曾經(jīng)在這兩家公司參加了敏捷項目的咨詢和實施，接觸到的不少客戶是電信、金融、能源等大型企業(yè)。用戶需求往往非常復雜，掌握復雜需求用戶故事的拆分方法非常關鍵，這直接影響敏捷項目的成敗。具體說來，復雜需求用戶故事拆分可遵循3個原則、9種方法。
3個原則
INVEST原則
拆分用戶故事要遵循比爾·維克(Bill Wake)的INVEST原則，即一個合適的用戶故事應該是獨立的(Independent)、有價值的(Valuable)、可討論的(Negotiable)、小的(Small)、可估算的(Estimable)和可測試驗證的(Testable)。
二八原則
根據(jù)帕累托原則也就是二八原則，一個迭代80%的價值可能來自于其中20%的用戶故事。假如有兩種故事拆分方式，當?shù)谝环N拆分方式將低價值部分拆分成獨立的故事，而另一種拆分方式?jīng)]有做到時，就意味著后一種方式把浪費隱藏到了每個小故事里。此時，應當選擇前一種拆分方式，這樣可以把低價值的故事直接作廢或推遲實現(xiàn)。
二八原則的驗證方法是：在拆分后的一系列故事中，高價值、中價值、低價值的故事要一目了然，要能很明顯找到一個實現(xiàn)它可以得到高價值或能降低大部分風險的故事。
故事適中原則
故事太大不好。故事太大，里面內(nèi)容龐雜，頭緒太多，可能導致無處下手或在一個迭代內(nèi)無法完成。“小”這一特性要求我們拆分大的故事。但拆分故事時依然要遵循INVEST原則。
故事太小也不好。比如有的敏捷團隊太過細分故事：對于數(shù)據(jù)庫建一個故事、對于UI建一個故事等，這樣雖可以滿足“小”這一特性，但它卻不是“獨立的”和“有價值的”。
故事應該要多小呢?建議每個迭代6~10個故事，當然故事拆分的顆粒度取決于項目團隊的生產(chǎn)效率。對很多團隊來講，當一個用戶故事龐大到8個甚至13個故事點的時候就需要進行拆分了。
建議每個迭代內(nèi)的用戶故事的故事點數(shù)差別不宜太大，拆分后得到的故事最好規(guī)模差不多大。把一個8點的故事拆分成4個2點的故事比拆分成5點和3點的故事更有用，因為PO能更自由地編排優(yōu)先級。
9種方法
理查德·勞倫斯(Richard Lawrence)和他的團隊總結(jié)出故事拆分的9種經(jīng)典方法。
簡單/復雜
假如團隊正在討論的某個故事變得越來越大，我們可以停下來并提問：“可以工作的最簡單版本是什么?”捕捉這一簡單版本作為一個單獨故事，然后把所有變體和復雜性拆解到它們各自的故事中。
例如，作為手機用戶，我希望在開機狀態(tài)下系統(tǒng)能盡可能地尋呼到我，以便我不錯過任何電話。故事1，……系統(tǒng)能記錄我最近活動過的小區(qū)進行尋呼……故事2，……系統(tǒng)能記錄我最近活動過的三個小區(qū)進行尋呼……故事3，……系統(tǒng)能記錄我之前所在MSC進行邊界尋呼……
推遲性能實現(xiàn)
不要太早考慮性能要求，我們常常忘了“讓它工作，然后讓它更快”這個原則。
比如我們會有這樣一個用戶故事：作為用戶，我希望能夠在1秒內(nèi)獲取查詢結(jié)果。可能這個1秒的優(yōu)化會花去我們很多時間，而且優(yōu)化后由于其他模塊的影響，查詢速度可能再次變慢，所以我們可以嘗試拆分成以下故事：故事1，作為用戶，我希望能夠獲取查詢結(jié)果。故事2，作為用戶，我希望查詢結(jié)果能夠在1秒內(nèi)獲取。把故事1放入早期迭代，故事2可以盡量晚一些，在交付前完成，以排除其他模塊可能帶來的影響。
基于工作流步驟進行拆分
識別出用戶為完成具體工作流采取的特定步驟，然后通過一些增量階段實現(xiàn)工作流。如果已經(jīng)能畫出具體場景的流程，則可以先從工作流程拆分。該方法也叫作最簡路徑法，即先拆出最簡路徑，再基于最簡路徑添加步驟，直到覆蓋完整路徑。
接口可變性
對于需求中業(yè)務流程和邏輯規(guī)則相同，僅涉及接口不同，也就是獲取數(shù)據(jù)的渠道和方式不同，我們可以基于接口的差異進行故事拆分。
例如，作為微信用戶，我可以添加好友以便擴大朋友圈。故事1，……我可以通過搖一搖方式添加好友……故事2，……我可以通過掃二維碼方式添加好友……故事3，……我可以通過手寫輸入方式添加好友……
主要投入
根據(jù)主要投入或工作量來拆分故事。有時一個故事可以分為幾部分,大部分的工作將用于實現(xiàn)第一個故事。
例如，一張信用卡處理的故事：作為一個用戶,我可以用維薩、萬事達、大來卡或美國運通支付航班費用。這個故事可以分成四個故事，每個卡型作為一個故事。但是首先實現(xiàn)第一種信用卡付費的工作量最大。一旦第一種信用卡能付費，再增加其他信用卡，其工作量就小很多。所以信用卡處理基礎設施應該以支持第一個故事為目的進行構(gòu)建，在以后添加更多的功能則相對簡單。
我們只需要拆為兩個用戶故事：故事1，……我可以使用一種信用卡付費(維薩、萬事達或美國運通中的一種)……故事2，……我可以使用所有三種信用卡付費(假定其中一種已經(jīng)支持了)……這兩個新的故事仍然不是獨立的，但要比為每個卡型寫一個故事依賴關系更清晰。
業(yè)務規(guī)則可變性
針對需求中固定的流程加載不同業(yè)務規(guī)則的情形，我們按照業(yè)務規(guī)則拆分故事。
例如，作為網(wǎng)站用戶，我希望A網(wǎng)站能提供熱門推薦以便我可以更快找到感興趣的內(nèi)容。故事1，……能根據(jù)帖子數(shù)量給出熱門頻道推薦……故事2，……能根據(jù)發(fā)帖數(shù)給出熱門作者推薦……故事3，……能根據(jù)回帖數(shù)量給出最多評論推薦……
業(yè)務操作
有些用戶故事使用了“管理”、“控制”等詞匯，它掩蓋了對故事執(zhí)行的多種操作，大的用戶故事可以基于不同類型的操作進行故事拆分。
例如，作為系統(tǒng)管理員，我希望能夠管理使用系統(tǒng)的用戶。通過與系統(tǒng)管理員溝通，了解到他希望能夠增加使用系統(tǒng)的用戶，也能夠?qū)⒉辉偈褂孟到y(tǒng)的用戶(如離職、更換部門等)刪除，那么我們可以將用戶故事拆分成下面幾個更小的故事：故事1，作為系統(tǒng)管理員，我希望能夠添加新用戶，使其能夠使用系統(tǒng)。故事2，作為系統(tǒng)管理員，我希望能夠查詢當前系統(tǒng)都有哪些用戶。故事3，作為系統(tǒng)管理員，我希望能夠修改用戶的信息，方便我管理用戶。故事4，作為系統(tǒng)管理員，我希望能夠刪除用戶，保證只有必要的人在使用系統(tǒng)。
數(shù)據(jù)多樣性
我們可以根據(jù)數(shù)據(jù)類別進行拆分。比如我的用戶故事是：作為用戶，我希望能夠查看系統(tǒng)的警告通知。我們系統(tǒng)警告通知有很多類型，各種警告的內(nèi)容差別很大，那么我們可以把這個大故事拆分成以下幾個小故事：故事1，作為用戶，我希望能夠查看系統(tǒng)的異常流量警告通知;故事2，作為用戶，我希望能夠查看系統(tǒng)的惡意代碼警告通知;故事3，作為用戶，我希望能夠查看系統(tǒng)的僵尸網(wǎng)絡警告通知。
故事穿刺
故事穿刺其實就是摸著石頭過河。一個故事比較大不一定因為它復雜，而是由于我們對實施知之甚少。在這種情況下,再多的討論也不能讓我們知道如何拆分它。我們可以在一定時間內(nèi)針對怎么實施，先做個探針試驗。試驗過后，知道了深淺，揭開了面紗，我們往往就可以知道如何拆分它了。
例如，作為用戶，我可以用信用卡支付。然后，把它分成：故事1，調(diào)查信用卡數(shù)據(jù)處理機制;故事2，實施信用卡處理。
探針模式放在最后，因為它應該是你的最后手段，所以在采取探針模式之前盡量去使用前八種方式。
結(jié)語
需要強調(diào)的是，面對龐雜的用戶需求，我們在拆分用戶故事時不能單純使用一種方法，而是應該綜合運用上述技巧。這些拆分方法需要多練多用，才能熟能生巧，運用之妙，存乎一心，最終達到庖丁解牛的境界。
閆林，現(xiàn)任中興通訊IT技術(shù)學院副院長。有20年豐富的IT技術(shù)與管理經(jīng)驗，包括敏捷咨詢經(jīng)驗。對云計算、大數(shù)據(jù)、ITIL、DEVOPS等亦有許多研究，曾編寫出版多部IT著作。
本期編輯 | 王興釗
內(nèi)容來源 | 《項目管理視點》2017年1-2月
薦讀▼
來點有用的書
