值得收藏！萬字長文詳解用戶故事拆分流程和方法 | IDCF

用戶故事拆分是敏捷交付團隊的日常做法。但是以我的經(jīng)驗，執(zhí)行起來真的很困難。在本文中，我將所學(xué)到的有關(guān)故事拆分的所有內(nèi)容匯總在一起。

這會是一篇很長的文章，所以您可能要在開始之前先喝杯熱騰騰的茶。

我認為用戶故事是范圍的單位，是交付的單位。

重要的是，用戶故事向他人傳遞了有用的（或有價值的）信息。在IT環(huán)境中，“他人”通常指的是使用系統(tǒng)的人（盡管有時是另一個利益相關(guān)者，想以某種方式限制用戶，例如保護系統(tǒng)免受未經(jīng)授權(quán)的訪問）。

因此，通常從用戶角度以“作為……我可以……以便于……”格式描述用戶故事，從而迫使交付團隊始終專注于用戶正在試圖達成的目標及其原因。

注意：術(shù)語“用戶故事”通常用于兩個有微妙差異的場景。

• 如上所述，我通常用它來表示要交付的范圍單位，例如“我們已經(jīng)在此Sprint中交付了故事X，Y和Z”。

• 但是，它也廣泛地被用來指代這些范圍單位的描述 -“ 盡可能……我可以……如此……”范式。

在本文中，我使用術(shù)語用戶故事來指代范圍本身，而術(shù)語用戶故事描述則指的是這些范圍單元的說明。當我談?wù)摴适虏鸱謺r，我說的是將范圍項拆分為較小的范圍項，而不是將范圍項的描述拆分為較小的說明！

1.1 用戶故事的屬性和INVEST準則

根據(jù)INVEST 準則https://en.wikipedia.org/wiki/INVEST_(mnemonic)，用戶故事應(yīng)為：

• 獨立 - 不依賴其他故事
• 可協(xié)商 - 并非一成不變，可以進行討論
• 有價值 - 對某些利益相關(guān)者（通常是最終用戶）
• 可估計的 - 足夠清晰，交付團隊可以很好地知道它有多大
• 足夠小 - 小到足以在一個sprint /迭代中傳遞多個故事
• 可測試 - 如果無法測試，則顯然對任何用戶都無濟于事

以我的經(jīng)驗，這通常沒有那么簡單 -  拆分故事以使它們“足夠小”通常會在故事之間引入依賴關(guān)系，而單個故事往往本身并沒有價值，只有一定數(shù)量的相關(guān)故事一起，它們才有價值去交付。

因此，我傾向于將INVEST屬性視為準則，而不是無可爭議的法律。一些屬性更適用于史詩（大故事），而另一些屬性更適用于小故事。

對于所有故事而言，我的一條規(guī)則是：無論故事多大，它們都必須提供用戶可見的內(nèi)容。這等同于垂直故事切分，后面會詳細介紹。

拆分故事最典型的原因是將它們分成幾小塊 - 足夠小以在一次沖刺中交付其中的幾個。你怎么吃大象？一次一小塊。

我認為，還有另一個原因同等重要（如果不是更重要的話），并且可能不太為人理解，就是與帕累托原理（也稱為80:20法則，https://en.wikipedia.org/wiki/Pareto_principle）有關(guān)。

80:20法則基本是說你可以在20％的時間內(nèi)完成80％的工作。換句話說，完成最后20％的工作需要80％的時間。它反映了一個事實，即大多數(shù)工作都涉及許多“花哨的工作”，這些工作需要很長時間才能完成，因此盡管感覺您快要完成了，但實際上并不是。

在軟件交付領(lǐng)域，工作的最后20％通常代表替代流程 - 異常，意外或錯誤情況。通常，這些高付出的“怪異碎片”中的相當部分都是價值很低的 - 它們處理的神秘場景通常會在藍色月光下偶爾出現(xiàn)一次。

拆分故事使我們有機會將高價值的東西與低價值（高付出）的東西分開。一旦故事被拆分，并且子故事被放置在產(chǎn)品待辦事項列表中，則在重新確定優(yōu)先級的對話期間，低價值故事會自然地過濾到待辦事項列表的底部。

這樣做的好處是，我永遠不需要與產(chǎn)品負責人就是否應(yīng)該處理某個特殊情況爭論不休。我可以將其放在待辦事項列表上，并讓他們相應(yīng)地對其進行優(yōu)先級排序。項目發(fā)起人遲早會花費時間在項目時間分配上，低價值的東西將永遠無法交付（也稱為“修剪尾巴”）。

拆分故事時，我會盡量牢記這兩個目標：將它們縮小，然后剝離低價值的部分。

通常會將大型故事稱為史詩。

我的經(jīng)驗是，可能有必要對史詩（大故事）進行多次拆分，然后才能找到適合開發(fā)團隊的“大小適中”的故事。這取決于原始（史詩）故事的大小，開發(fā)團隊希望這些故事的大小，以及我需要拆分多少次才能分離出所有低價值內(nèi)容。

因此，我將故事拆分視為一種迭代活動 – 一個大故事拆分為兩個或多個子故事，然后可以進一步將每個子故事拆分為多個子故事，依此類推，直到每個故事都變得足夠小為止。這并不是說我需要事先拆分所有的故事。我只在適當?shù)臅r候拆故事，以后在需要時再拆。關(guān)鍵是最終會有故事的層次結(jié)構(gòu)，層次結(jié)構(gòu)可以有很多層，并且并非所有分支都具有相同的深度。例如：

一些團隊/方法/工具定義了故事的分類法，在層次結(jié)構(gòu)中具有固定數(shù)量的級別。例如：

• 第1級：史詩 Epic
• 第2級：功能 Feature
• 第3級：能力 Capability
• 第4級：故事 Story

我不喜歡這種方式。我的經(jīng)驗是，故事層次結(jié)構(gòu)并不總是整齊地落入固定的層級，因此團隊需要花太多時間思考，“這個故事是史詩級的還是僅僅是功能性？”事實上是哪個層級并沒有關(guān)系。

我更喜歡遵從邁克·科恩（Mike Cohn）的建議（https://www.mountaingoatsoftware.com/blog/you-dont-need-a-complicated-story-hierarchy）：一切都是故事。如果我分解一個故事，我會得到……一些故事。如果我有一個故事，感覺有點大，可以拆分，或者已經(jīng)拆分了，可以將其稱為史詩，但這仍然是一個故事。

一個史詩 是一個用戶故事，感覺大到足以進行分割，或已經(jīng)被分割。

重要的是，如上所述，無論故事大小如何，它仍然提供用戶可見且對利益相關(guān)者有用的內(nèi)容，因此我仍可以用“作為……我可以……這樣……”的格式來編寫其摘要。

您如何知道故事“足夠小”？

我的經(jīng)驗是，這取決于你的交付團隊以及沖刺周期。最近，我一直在兩周一個沖刺的團隊中工作，開發(fā)人員希望故事小到可以在每個沖刺中交付8-12個故事。他們希望能夠最多用幾天來發(fā)布一個故事。

較小的故事可以提高工作效率和動力 – 團隊成員可以一次專注于一件小事，并很快完成它 – 每天回家時都可以完成某件事，或者是有希望結(jié)束。小的故事還有助于更好地進行資源計劃 - 故事可以更輕松地在團隊成員之間分配，并且更容易解決團隊成員的缺席/離開。

將故事拆到如此程度通常意味著將其分解到可以被視為或者是獨立的，或者是對最終用戶有價值的程度 – 用戶價值通常只有在交付了許多相關(guān)的、相互依賴的故事時才能得到。正如我上面提到的，很難讓一個故事同時具備所有INVEST屬性。

在我工作的每個團隊中，我們都通過反復(fù)試驗找到了理想的故事大小。方法如下：我會準備一些故事（已經(jīng)有了BDD草案，并在適當?shù)膭?chuàng)建了一些線框或HTML原型）。我會安排一次三方會議，與團隊一起逐一地過故事。對于每個故事，在我要求他們進行估算之前，我先詢問他們是否認為故事足夠小。如果沒有，我們會去找一種拆分方法。經(jīng)過幾次這樣的討論后，我會感覺到什么是一個故事的“合適大小”，并且通常會以適當大小的故事進入三方會談。具有諷刺意味的是，隨著團隊的成熟和工作效率的提高，他們有時會覺得現(xiàn)在的故事太小了，最終可能會合并以前拆開的故事！

對此的簡單答案是：Just In Time。

我需要大小適中的故事來進入下一個沖刺/增量?；蛘?，如果我正在用看板，則只需要大小適中的故事來讓所有開發(fā)人員忙起來。

我按優(yōu)先順序分析故事，包括拆分。因此，如果故事的優(yōu)先級較低，那么它可能仍然很大，因為我尚未對其進行任何分析。

因此，我希望產(chǎn)品積壓的頂部附近的故事很小，而底端附近的故事會較大。我的待辦事項應(yīng)如下所示：

（順便感謝Ken Rubin的圖：https://innolution.com/）

其實真實情況并非如此。請記住，我拆分故事的動機之一是拆分低價值的，并讓它們過濾到待辦事項的底部。每次我分解一個故事時，重要的是要將子故事與其余待辦事項重新排序，請確保這種過濾效果的真實發(fā)生。因此，在我的待辦列表底部可能還會有一些小故事 – 這些是我已經(jīng)分解的那些低優(yōu)先級故事。

5.1 首先做一些分析

在分解故事之前，我首先需要做一些分析工作來理解這個故事。否則，我對它的了解不足以支撐如何拆分它。

實際上，我有一個相當結(jié)構(gòu)化的流程來進行分析工作。實際上，它是如此結(jié)構(gòu)化，我給它起了一個名字：Business Analysis Designer Method（BADM。http://www.its-all-design.com/business-analyst-designer-method/）。下圖總結(jié)了這一過程：

不要上當，BADM 不是瀑布方法。相反，每個階段依次針對要傳遞的單個故事執(zhí)行。

• 在“請求”階段，需要一個故事，但是在那個階段，我們還不知道目標是什么，或者實現(xiàn)目標的最佳方法是什么。

• 在“定義”階段，BA業(yè)務(wù)分析師會識別利益相關(guān)者，了解機會空間，提出建議如何實現(xiàn)機會并與產(chǎn)品所有者PO和其他利益相關(guān)者達成共識。BA還會在適當?shù)那闆r下將故事拆分為子故事。

• 子故事將被添加到產(chǎn)品待辦事項列表中，并對其進行優(yōu)先級排序，該方法將在子故事上持續(xù)進行迭代，直到它們“足夠小”為止。

• 最后，在“設(shè)計”階段，BA交付所需的更詳細的分析 - 接受標準和/或行動方案（又稱用例），線框（或UI原型），數(shù)據(jù)模型等。

我并不是建議每個人都應(yīng)該使用BADM，但是在拆分故事之前花一些時間來理解故事的范圍絕對是一個好主意。

如上所述，我僅有一個分割故事的黃金法則。當我拆分故事，每個子故事都必須提供一些用戶可見的內(nèi)容。當我說“用戶可見”時，我的意思是在系統(tǒng)的一個用戶或系統(tǒng)界面上可以觀察到（一個用戶當然可以是另一個系統(tǒng)）。

這才是問題所在。當出現(xiàn)“太大”的用戶故事時，開發(fā)團隊的第一個直覺通常是按照體系結(jié)構(gòu)劃分，一名開發(fā)人員進行數(shù)據(jù)庫架構(gòu)更改，另一個編寫中間層業(yè)務(wù)或控制器邏輯，第三個人變更用戶界面。

這個故事被“水平地”切分到了架構(gòu)的各個層次。這種方法存在一些問題：

• 在所有相關(guān)故事完成之前，你看不到明顯的用戶收益
• 在所有相關(guān)故事完成之前，我們無法測試系統(tǒng)
• 在所有相關(guān)故事完成之前，我們不會發(fā)現(xiàn)任何體系結(jié)構(gòu)問題
• 我們錯過了將高強度，低價值的部分分割出來留作未來交付的機會

因此，首選的方法是“垂直”分割故事，每個故事通過每個（相關(guān)）架構(gòu)層傳遞一小段變更。這樣，我們在每個故事交付后都有一些（較小的）用戶收益，我們可以測試每個故事，并且可以更快地確定任何體系架構(gòu)問題。

垂直切片故事時，請注意：

• 某些故事可能僅影響表示層（例如，更改字段或按鈕標簽），而不是對所有架構(gòu)層進行切片。
• 有些故事會更改系統(tǒng)界面，而不是用戶界面。它們?nèi)匀皇恰坝脩艨梢姷摹?，但是在這種情況下，系統(tǒng)的用戶是另一個系統(tǒng)，而不是人類用戶。
• 一些故事是無功能的，例如性能或安全性增強。沒關(guān)系，響應(yīng)時間的改善是用戶可見的。
• 有些故事是事件觸發(fā)的（批處理）過程，它們會影響系統(tǒng)狀態(tài)（即它們會更改數(shù)據(jù)庫中的數(shù)據(jù)），但在發(fā)生時卻無法通過任何用戶或系統(tǒng)界面看到（盡管稍后會看到其效果，下次查詢數(shù)據(jù)）。這是“用戶可見”規(guī)則的一個特殊例外，允許用戶佩戴X射線眼鏡以觀察系統(tǒng)狀態(tài)的變化！同樣，故事是可以測試的，但是測試人員需要在數(shù)據(jù)庫中探測一下才能看到更改。

還要注意，一旦故事“足夠小”，開發(fā)團隊可能仍會決定將其分為“水平”部分：數(shù)據(jù)庫變更，UI修改等。這完全沒問題，將故事分解為任務(wù)  （特別是開發(fā)任務(wù)），有些團隊會在沖刺計劃時這樣做，以幫助他們估算故事的工作量和/或在團隊成員之間分配工作。不同之處在于，你需要理解并且有預(yù)期，除非所有開發(fā)任務(wù)都完成，故事才算完成（甚至才能進行測試）。范圍或交付的單位是故事，而不是任務(wù)。

我只在這里提供了垂直故事切片的摘要。有很多非常好的文章更詳細地進行了介紹，例如Ned Kremic撰寫的這篇文章：http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake/。

如上所述，垂直故事切片就是將故事分成越來越小的用戶可見的更改。每個故事，無論多么小，都會為用戶帶來有價值的東西，這有助于他們實現(xiàn)某些目標。垂直故事切片的另一種方法是用戶目標分解。通過拆分故事，我將用戶目標拆分為子目標。

我們用一個例子來說明。假設(shè)我有一個用戶故事，如下所示：

• 注冊
• 作為不需要的東西的所有者，
• 我可以注冊在線拍賣網(wǎng)站
• ，以便可以出售不需要的東西

該故事的用戶目標是 注冊在線拍賣網(wǎng)站。好處是  賣掉我的東西。但是這個故事太大了，我想把它分開。所以我這樣分割它：

• 注冊–輸入詳細信息
• 作為不需要的物品的所有者，
• 我可以輸入我的注冊詳細信息（姓名，電子郵件地址等）
• 以便可以注冊在線拍賣網(wǎng)站
• 注冊–提交詳細信息
• 作為不需要的物品的所有者，
• 我可以提交我的注冊詳細信息
• ，以便可以注冊在線拍賣網(wǎng)站

我創(chuàng)建了兩個子目標– 輸入我的注冊詳細信息并提交我的注冊詳細信息。在這種情況下，后者取決于前者-我必須輸入我的詳細信息，然后才能提交它們。更重要的是，一旦我同時達到了兩個子目標，我就實現(xiàn)了我的初衷– 注冊在線拍賣網(wǎng)站。然后，我可以進一步細分子故事，直到我的故事“足夠小”為止。我最終會得到故事的層次結(jié)構(gòu)和目標的層次結(jié)構(gòu)。

尤其要注意的是，子故事的“ so that”陳述（利益）就是原始故事的“ I can”陳述（目標）。換句話說，收益確實是更高層次的目標。一旦意識到這一點，編寫子故事的“so that”部分就變得容易得多，它們只是父故事（即父目標）的“I Can”部分。

最好這樣解釋用戶故事描述模板：

• 作為<用戶>，
• 我可以<目標>
• ，以便<更高級別的目標>

也可以得出結(jié)論，我最初目標的利益– 銷售我的東西  –實際上只是一個更高級別的目標。反過來，這又是更高級別目標的子目標，可以賺錢。反過來又是購買食物的一個子目標，然后是 供養(yǎng)我的家人，再然后 讓我的家人活著。依此類推，直到您最終陷入上一級目標的無限循環(huán)，或者陷入諸如“我們存在的意義是什么”這樣的哲學(xué)問題中……

由于用戶目標的層次結(jié)構(gòu)可能是無限的（向上和向下），因此確實存在迷失的風(fēng)險。Alistair Cockburn 在其最出色的著作《寫作有效用例》（https://www.amazon.co.uk/Writing-Effective-Crystal-Software-Development/dp/0201702258）中很好地解釋了目標分解，尤其是他通過識別和命名三個特定的目標等級來建立了隱喻錨。他在書中談的是用例，但該理論同樣適用于用戶故事。

• 最重要的目標級別是用戶目標級別，也稱為海平面或藍色。在此級別上，一個用戶可以在單個活動中實現(xiàn)（或未能實現(xiàn)）單一目標，例如“列出要出售的商品”。您可以通過詢問目標是否通過“咖啡時間測試”來檢查這個目標是否為用戶目標：實現(xiàn)目標后，您是否有足夠的理由來休息一下喝杯咖啡？
• 高于用戶目標級別的是摘要級別，也稱為云/風(fēng)箏級別或白色。摘要級別的用戶目標是相關(guān)用戶級別目標的集合，例如“管理窗口小部件”細分為“創(chuàng)建窗口小部件”，“視圖窗口小部件”，“編輯窗口小部件”和“刪除窗口小部件”。
• 低于用戶目標級別的是子功能級別，也稱為水下級別或靛藍。子功能級別的目標本身對用戶無直接的價值，它們是實現(xiàn)用戶級別目標的步驟，例如，“輸入商品名稱”是“列出待售商品”的子目標?！暗卿洝笔浅Ｒ姷淖庸δ芗墑e目標，登錄本身并不能實現(xiàn)任何目的，它通常是實現(xiàn)其他目標的前提。

Cockburn非常有意地選擇了海平面/云層/水下隱喻。天空很高，海洋很深，相應(yīng)地有許多嵌套級別的云層目標和水下目標（并且有許多白色陰影和許多靛藍陰影）。但是只有一個海平面——用戶目標是用戶目標，應(yīng)該非常清晰地定義。需要澄清的是，我并不是在提倡三層固定的用戶故事層次結(jié)構(gòu)，我早些時候已經(jīng)對此表示了反對。我只是說，識別海平面在用戶故事層次結(jié)構(gòu)中的位置對于跟蹤交付用戶價值很有用。

有許多久經(jīng)考驗的方式來垂直剖析故事。多年來，我注意到我傾向于按特定順序應(yīng)用各種技術(shù)。有些技術(shù)適用于較大的故事，而其他技術(shù)一旦當故事變小就變得更加趁手。因此，我將按通常應(yīng)用它們的順序來介紹各種技術(shù)。請注意，這不是一成不變的規(guī)則。對于給定的故事，并非所有技術(shù)都適用，并且不一定以相同的順序使用。我可能還會多次使用某一種技術(shù)。

開始了…

技術(shù)1：拆分NFRs

對于任何給定的故事，我想做的第一件事就是將其分為兩部分：一部分交付功能本身，另一部分交付該功能的NFR（非功能需求）。

拆分的主要目的是使團隊專注于交付功能，而不會被NFR分散注意力。在項目早期尤其重要，此時有很多尚未解決的架構(gòu)問題，事先讓他們都一一解答會讓事情變慢。

以下是您可以考慮推遲來關(guān)注的NFR列表：

• 性能：延遲使其快速
• 可擴展性：推遲使其支持大量并發(fā)用戶或大量數(shù)據(jù)
• 并發(fā)：推遲使其支持多個并發(fā)用戶（數(shù)據(jù)鎖定，競爭條件等）
• 可用性：推遲使其具有高可用性和容錯能力
• 安全性：推遲保護其免受攻擊
• 可用性/可訪問性：推遲使其易于使用（適用于所有人）
• UX：推遲使其美觀
• 跨瀏覽器/平臺：推遲使其適用于各種客戶端設(shè)備
• 國際化：推遲支持多種語言/本地約定

所有這些事情都具有分散團隊注意力的可能，使他們無法快速交付簡單的東西（剛好可以正常工作），并且可以隨后基于（重構(gòu)）這些東西以在適當?shù)臅r候交付各種NFR。拆分NFR并對團隊說：“我們將研究NFR，但現(xiàn)在不必擔心它們”。也許我們甚至可以在不（正式地）考慮所有NFR的情況下提供MVP。這取決于我的MVP是公開發(fā)行還是有限定向用戶組的私人Beta版。

我通常一開始將NFR分解為一個單一的故事，稱為“ Project X NFR”或“ Feature X NFR”。在適當?shù)臅r候，當我們確實 需要更詳細地研究NFR時，我才可能將這個NFR故事進一步細分為各個NFR類別（性能，可用性，安全性等），并一一列舉，當然是按嚴格的優(yōu)先級順序。

最終，對于每個后續(xù)故事，我們可能會將相關(guān)的NFR納入“完成的定義”中。但這是另一篇文章要說明的事情。

恰好在“適當時候”發(fā)生，是一個很好的平衡。我們不想太早地在體系架構(gòu)上受挫，但是我們也不想太晚去考慮它，否則我們可能會承擔過多的技術(shù)債務(wù)，而且還要承擔體系架構(gòu)風(fēng)險。同樣的，判斷是伴隨經(jīng)驗而來的，從來不會有一個唯一簡單的答案，多年來，我見到的過度設(shè)計的系統(tǒng)和設(shè)計不完善的系統(tǒng)一樣多。

技術(shù)2：按用戶界面通道拆分

這是拆分NFR的特殊情況。我上面提到的NFR之一是跨瀏覽器/平臺的支持，如果我的系統(tǒng)具有用戶界面，并且打算支持多個渠道（例如，臺式機，平板電腦，移動設(shè)備）或多個平臺（例如，Windows，Mac，iOS，Android，各種智能電視），那么首先集中精力在這些渠道/平臺其中的一個是更有意義的，顯而易見應(yīng)該選擇我們認為大多數(shù)用戶擁有的渠道/平臺。

但是，與其他NFR一樣，這又是一個平衡：在項目中的什么時候開始考慮其他平臺？當然，沒有正確的答案，這取決于具體情況。

我從事的一些項目具有公司（或政府）標準的UI框架，該框架已經(jīng)被設(shè)計為可響應(yīng)的（即在多個平臺/設(shè)備上工作）。顯然，從一開始就使用標準框架是有意義的，前提是它相對穩(wěn)定并且不會增加過多的開銷或?qū)W習(xí)曲線。即使我們不選擇這樣做，我們?nèi)匀豢梢赃x擇推遲正式開始跨平臺的合規(guī)性。這里有一個細微的差異：推遲正式合規(guī)，是說我們還不會進行跨平臺系統(tǒng)測試?？缙脚_測試可能會非常耗費人力，通常最好在發(fā)布前不久進行一次，而不是在每個故事中都做一遍。我們的測試人員現(xiàn)在可以專注于功能測試，并且我們可以更快地進展。

技術(shù)3：按用戶類型拆分

一些故事服務(wù)于多樣化的用戶社群。我在這里沒有太多談?wù)搰H化，而是在考慮用戶類別。

例如，在最近的項目中，我們的用戶分為以下幾類：

• 英國用戶
• 歐盟用戶（但不包括英國）
• 歐盟以外的用戶（也稱為“第三國”用戶）

不要讓我開始聊英國脫歐，這是另一個故事（呵呵）。

要點是，這三個類別的功能都不相同。英國用戶必須采用一種方法進行注冊，歐盟用戶采用第二種方法進行注冊，第三國用戶則采用另一種方法進行注冊。

因此，我們決定首先關(guān)注英國用戶。然后我們發(fā)現(xiàn)了另一個分類：

• 英國個人
• 英國組織

同樣，每個類別的功能都不同。因此，我們決定首先關(guān)注英國組織。然后我們發(fā)現(xiàn)了另一個分類：

• 英國注冊公司
• 英國非法人公司
• 英國伙伴關(guān)系

信不信由你，這些子類別的注冊規(guī)則又再次不同。我們首先關(guān)注英國注冊公司，并為他們提供了完整的注冊過程（盡管我們用稍后將介紹的其他技術(shù)進一步簡化了注冊過程）。然后，我們開始按照業(yè)務(wù)優(yōu)先級順序添加其他用戶類型。再次回到英國脫歐——如果英國很快退出歐盟，我們將不會區(qū)分歐盟還是第三國用戶，因此我們將歐盟用戶放在優(yōu)先級較低的位置。

最后，我們將用戶群細分為大約15個用戶類型，并針對大約8個獨特的用戶旅程進行注冊。為第一種用戶類型交付功能需要大量工作，隨后添加的每種額外用戶類型變得越來越容易。但是，如果我們嘗試一次全部完成這些任務(wù)，我認為任務(wù)將是無法達成的。

技術(shù)4：將摘要目標分為用戶目標

到目前為止，我們已經(jīng)拆分了各種NFR，因此我們可以先關(guān)注功能，然后再按用戶類型進行拆分，以便專注于為單個用戶組提供服務(wù)。

在接下來的拆分中，我們回到前面討論的“三個命名的目標級別”的概念。具體來說，我們希望將故事分解成可以通過“咖啡時間測試”的單個用戶目標（“海平面”目標），這些目標可以由一個用戶一次活動就可以實現(xiàn)，而完成后則可以享受咖啡時間。

一個非常常見的例子是將數(shù)據(jù)維護故事分為其CRUD組件，例如：

• 維護小部件

變成

• 創(chuàng)建小部件
• 查看小部件
• 更新小部件
• 刪除小部件

另一個常見的例子是一個涉及多個角色的故事。例如：

• 作為博客作者，我可以發(fā)表文章

可能成為：

• 作為博客作者，我可以要求發(fā)布我的文章
• 作為編輯，我可以批準發(fā)表文章

摘要級別目標還有無數(shù)其他類型，可以細分為用戶目標。

子故事通常遵循邏輯順序，你必須能夠創(chuàng)建一個小控件才能查看它，并且您可能想先查看一個小控件，然后再對其進行更新或刪除。您必須先請求發(fā)表文章才能獲得批準。但這并不一定意味著故事必須按順序交付，完全有可能通過后門來創(chuàng)建窗口小控件（通過直接數(shù)據(jù)庫加載），因此，如果查看窗口小控件是價值最高的子故事，則可以這樣做。

技術(shù)5：按場景/流程劃分

到目前為止，我們的故事處于用戶目標級別：可以由一個用戶一次活動就可以實現(xiàn)。作為美好的一天，對我們的用戶來說一切都會很美好。他們將執(zhí)行操作、輸入數(shù)據(jù)并實現(xiàn)他們的目標。這就是我們所說的Happy Path方案。會有許多方法來實現(xiàn)目標，因此可能會有多條快樂的路徑。

但是事情可能不會那么順利，他們可能輸入了無效數(shù)據(jù)，或者他們執(zhí)行了不適當?shù)牟僮?，或者他們找不到正在搜索的?shù)據(jù)，并且他們可能未達到目標。在任何情況下，事情都可能會出錯，因此我們將其稱為替代流程。

例如，

• 創(chuàng)建小部件

可能成為

• 創(chuàng)建小部件–成功
• 創(chuàng)建小部件–小部件名稱已存在

另一個例子：

• 登入

可能成為

• 登錄–成功
• 登錄–無效的登錄詳細信息
• 登錄–失敗3次（鎖定帳戶）
• 登錄–帳戶已鎖定

這里的關(guān)鍵點是，某些替代流程的優(yōu)先級可能較低。例如，處理無效的用戶ID或密碼是高優(yōu)先級，但是在三次失敗嘗試后鎖定帳戶可能不是很高。

對于給定的用戶級別故事，并非總是很清楚所有替代流程是什么。為了找到它們，為主要的歡樂路徑寫出相應(yīng)的步驟是一個非常好的主意。例如：

• 1.用戶要求登錄
• 2.系統(tǒng)詢問用戶其登錄詳細信息（用戶標識和密碼）
• 3.用戶輸入登錄詳細信息
• 4.系統(tǒng)驗證登錄詳細信息對現(xiàn)有帳戶有效
• 5.系統(tǒng)驗證帳戶未鎖定
• 6.系統(tǒng)登錄用戶并顯示主頁

步驟4提出了一個問題：如果登錄詳細信息無效，該怎么辦？我們找到了替代流程。

步驟5提出了一個問題：如果賬戶被鎖定怎么辦？我們找到了另一種替代流程。

如果您在想拆分替代流程時束手無策，絕對應(yīng)該閱讀 Alistair Cockburn的書。

技術(shù)6：鍍銅與鍍金

在技巧5中，我將故事分為個人流程 - 歡樂路徑和替代流程。我們很可能會先專注于交付主要的歡樂路徑。但是在我們這樣做之前，我將先看一下它，看看是否有我可以先做的更簡單的版本。

例如，假設(shè)我們正在構(gòu)建一個注冊功能，而我們想要捕獲的一個信息就是用戶的生日。我們可以將其實現(xiàn)為日期選擇器，并彈出一個漂亮的日歷。但是我們也可以將其作為一個簡單的文本輸入字段來完成，這可能會更快，更容易構(gòu)建。從而：

• 寄存器

變成

• 注冊– DOB的簡單日期字段
• 注冊– DOB日期選擇器

我有時稱其為“銅鍍層”，而不是“金鍍層”，對于MVP來說已經(jīng)足夠了。當然我們可以做得更好，如同前文闡述的，在待辦事項優(yōu)先級的驅(qū)動下，是否以及何時使它變得更好，取決于與其他的待辦事項相比，我們對日期選擇器的重視程度。

這是解決團隊內(nèi)部爭執(zhí)于如何準確交付特定功能的一個好技巧。您將流程分解為“最低限度的最低要求”（即MVP），然后為每個層次的要求分別建立一個故事。（產(chǎn)品負責人）可能會認為某些功能要求是必不可少的 - 沒問題，我們在MVP故事之后不久就做。其他人會將其放進待辦列表，以待日后完成，也許永遠不做。有趣的是，我被多次告知某項功能“必不可少”，僅僅是因為發(fā)現(xiàn)該功能在待辦列表的底部停留了六個月之久。顯然，它上面的所有內(nèi)容都更重要。

這是您可以使用的其他一些鍍銅技巧：

• 手動與自動。可以很容易地假設(shè)，因為您正在構(gòu)建IT系統(tǒng)，所以一切都必須完全自動化，而有時手動處理可以用于處理少量任務(wù)或在MVP中使用。例如，除了webops團隊運行的手動數(shù)據(jù)庫腳本外，我當前正在使用的系統(tǒng)無法創(chuàng)建新的管理員用戶。這是一種痛苦，但這種情況不會經(jīng)常發(fā)生。
• 硬編碼與可配置。也許用戶必須選擇他們的標題（先生，太太等）。理想情況下，選項列表應(yīng)該可以從可配置列表填充，該列表可由管理員用戶輕松維護。但作為捷徑，該列表可以在頁面中硬編碼。
• 假設(shè)與要求。 與其允許用戶在你的博客應(yīng)用自行選擇頭像，你可以在第一個實例中自動為他們分配隨機模式，自定義頭像稍后再發(fā)布。
• 簡單與復(fù)雜的體系架構(gòu)。函數(shù)的某些部分可能需要復(fù)雜的體系架構(gòu)解決方案。例如，地址查找功能需要與第三方軟件集成，因此是否有一個更簡單的選項可以避免使用它，例如手動輸入地址？但是要小心，有時你想盡早解決架構(gòu)風(fēng)險，因此，如果該概念行不通，您可以“快速失敗”（請參閱下面的技術(shù)999）。當然這個問題沒有統(tǒng)一的答案。

技術(shù)7：分步進行

因此，到目前為止，我已經(jīng)為單個功能確定了一條快樂路徑，并且將其縮減為對MVP有意義的最低限度……

…但是我的開發(fā)團隊仍然希望將其分解成較小的功能進行交付，以便他們可以快速完成故事并查看進度。

這里的一種選擇是告訴開發(fā)人員，在繼續(xù)具有商業(yè)價值的同時，無法合理地分解故事。另一個選擇是將其進一步分解，以使有價值的故事一次累積一點。

重要的是，我們?nèi)匀幌Ｍ怪狈指罟适?，以便每個子故事都提供用戶可見的內(nèi)容。我們不想水平地分割故事，因為這只會給我們開發(fā)任務(wù)，而不是故事。

顯而易見的事情是將功能分解為各個步驟。在第一種情況下，如果該功能涉及用戶遍歷多個屏幕，則可以在每個屏幕上拆分一個故事。然后，您可以將其拆分，以便逐步交付每一個屏幕。您的工作量取決于開發(fā)團隊的偏好。我經(jīng)常發(fā)現(xiàn)當團隊還年輕時希望故事很小，而隨著他們的成熟，可以應(yīng)對更大的故事。

逐一步驟的一種變體是為該功能構(gòu)建一個“骨架”。你從具有起點和終點但中間沒有任何東西的功能開始。例如，一個“注冊”按鈕可通過“提交”按鈕將用戶帶到空白頁。當用戶單擊“提交”時，他們會收到一條消息，告知他們已成功注冊。但是實際上什么也沒發(fā)生。然后，逐個故事地填補空白，收集各種數(shù)據(jù)并實際創(chuàng)建注冊。關(guān)鍵是您可以采用多種不同的方式對其進行分解，而不必按順序進行。

骨架方法的另一個變體是先構(gòu)建前端用戶流，但不建立后端 - 所有后端調(diào)用都被插樁。這樣的好處是，它可以讓您盡早看到完整的用戶流，并在不起作用時對其進行調(diào)整（盡管另一種方法是構(gòu)建簡單的HTML原型）。

順便說一句，此技巧的另一種用途是將故事從用戶目標級別（海平面）拆分為子功能級別（水下平面）。

技巧999

Spike探針是一個旨在傳遞知識而不是交付生產(chǎn)的故事。當遇到大小和/或架構(gòu)不確定的故事時，團隊通常會“嘗試Spike”并花一些時間進行基本的研究，或者更可能是進行實際編碼，以便更好地了解大小或方法。

從表面上看，這似乎是個好主意，但我曾經(jīng)遇到過探針的問題：

• 目標不明確 - 與商業(yè)故事相比，探針故事不太可能具有明確的接受標準。
• 時間尺度不明確 – 理論上講，應(yīng)該對探針進行時間限制，但是如果任務(wù)未知，那么最簡單的就是說“好吧，讓我們看看它如何發(fā)展”。

范圍不確定和時間有限的結(jié)合，就像我認識的許多開發(fā)人員來說圣誕節(jié)早到一月 – 這是一個隨機探索并看看會發(fā)生什么的機會。即使是紀律嚴明的開發(fā)人員，也有被帶走的嚴重風(fēng)險。

例如，假設(shè)我們的團隊正在構(gòu)建API，并且我們決定使用RAML來說明那些API（RAML是目前非常流行的API標記語言）。我們希望在我們的網(wǎng)站上發(fā)布API文檔，并且我們決定一種較好的方法是構(gòu)建一個RAML到HTML的轉(zhuǎn)換工具。

因此，我們進行探針，構(gòu)建了一個RAML到HTML的轉(zhuǎn)換工具。一個開發(fā)人員被分配到這個探針，然后開始。他們每天在站會上報告進展，應(yīng)該很快能夠完成。幾周后，進展順利，而且是個好消息 – 它完全符合RAML 1.0，并且可以從任何有效的RAML文件生成HTML！

但是，當我們查看實際想要構(gòu)建的API時，我們發(fā)現(xiàn)我們只需要使用RAML 1.0的子集，他構(gòu)造的一半是浪費的精力。

這個例子基于一個真實的故事，但實際上并沒有那么糟糕。在構(gòu)建的過程中，我們更改了方法。我們沒有繼續(xù)“ RAML到HTML轉(zhuǎn)換器工具”的介紹，而是開始定義面向業(yè)務(wù)的故事，為真實的API提供實際文檔，而我們專注于一次建立一點點RAML到HTML的轉(zhuǎn)換，僅構(gòu)建我們實際需要的。通過這種方法，我們避免了解決方案的過度設(shè)計，并且還更快地交付了一些實際的業(yè)務(wù)價值。

我的母親總是告訴我不要用尖銳的鉛筆四處走動，原因是如果我絆著而摔倒，可能會導(dǎo)致嚴重的事故并最終住院。換一種說法：

• 小心探針。

通常，我會盡量避免探針。相反，我花時間與開發(fā)人員一起了解架構(gòu)不確定性所在的位置，并嘗試將一個故事分解為一些子故事，這些故事使他們可以一次了解一點兒架構(gòu)，同時仍能始終提供業(yè)務(wù)價值。

將這項技巧編號為999，有兩個原因。首先，這是不得已的方法，必須在所有其他技術(shù)之后使用；其次，（在英國）這是您撥打的呼叫救護車的電話號碼，這似乎很適合使用具有潛在危險性的技術(shù)！

當我著手撰寫本文時，我并沒有意識到會需要多長時間。具有諷刺意味的是，我寫了一篇有關(guān)將史詩分解成故事的本身就是史詩的文章。

這篇文章的長度可以說明問題 - 故事拆分很復(fù)雜，以我的經(jīng)驗來說，做起來很難。我已經(jīng)做了很多年了，但我仍在學(xué)習(xí)新的技巧。這是通過實踐和經(jīng)驗而能變得更好的技能之一，因此，如果您在掙扎中，請不要放棄！

自從您開始閱讀本文以來，可能已經(jīng)過去了幾十年，值得快速回顧一下：

• 拆分故事不僅是要使故事變小，而且還要拆分低價值、高投入的部分，以便它們可以沉在待辦事項底部。
• 拆分故事是迭代的，并且沒有固定的迭代次數(shù)，因此定義固定的層次結(jié)構(gòu)“史詩/功能/故事/其他”是沒有意義的。
• 你編寫的故事多小取決于你的團隊是否滿意。
• 故事應(yīng)“及時”拆分，但只有在進行足夠的分析以便充分理解故事后，才能進行。定期重新確定優(yōu)先級，以確保低價值的事項確實壓在艙底。
• 故事應(yīng)垂直分割，即將用戶目標分解為子目標。
• Cockburn的三個命名目標級別對于跟蹤你的目標非常有用，尤其是“海平面”目標，這可以由單個用戶在單個會話中實現(xiàn)，因此可以在此后喝咖啡慶祝。
• 有許多故事分解技術(shù)，而且我發(fā)現(xiàn)可以有一個一致的順序來應(yīng)用它們 - 隨著故事從大到小。
• 故事拆解很難！

參考文獻

• 比爾·韋克（Bill Wake）的文章，其中有很多關(guān)于如何拆分故事的想法，是為數(shù)不多的幾篇文章之一讓你認識到主要是為了將高價值的東西與低價值的東西分開。http://xp123.com/articles/twenty-ways-to-split-stories/ 
• 理查德·勞倫斯（Richard Lawrence）的這篇文章也贊成80:20規(guī)則 – 并且它也有一些很好的模式來拆分故事。http://agileforall.com/patterns-for-splitting-user-stories/ 
• 邁克·科恩（Mike Cohn）關(guān)于故事就是故事這一事實的文章。https://www.mountaingoatsoftware.com/blog/you-dont-need-a-complicated-story-hierarchy
• Rachel Davies的一些更出色的模式，他還談到了推遲低價故事的想法。http://agilecoach.typepad.com/agile-coaching/2010/09/ideas-for-slicing-user-stories.html
• 由Alistair Cockburn 撰寫的有效用例 – 描述了三個命名的目標級別，并列出了替代流程的停滯。
• 敏捷和業(yè)務(wù)分析：Lynda Girvan和Debra Paul撰寫的IT專業(yè)人員實用指南 – 特別是第8章，它討論了目標分解，也感謝Lyn提供了關(guān)于目標分解的更多見解。
• 對故事拆分技術(shù)的很好描述，以及很好的深入解釋Christiaan Verwijs的垂直故事切片。http://blog.agilistic.nl/10-useful-strategies-for-breaking-down-large-user-stories-and-a-cheatsheet/

作者：Tony Heap

原文地址：http://www.its-all-design.com/how-to-split-user-stories/

譯者：姚冬