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

使用者故事拆分是敏捷交付團隊的日常做法。但是以我的經驗，執行起來真的很困難。在本文中，我將所學到的有關故事拆分的所有內容彙總在一起。

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

我認為使用者故事是範圍的單位，是交付的單位。

重要的是，使用者故事向他人傳遞了有用的（或有價值的）資訊。在IT環境中，“他人”通常指的是使用系統的人（儘管有時是另一個利益相關者，想以某種方式限制使用者，例如保護系統免受未經授權的訪問）。

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

注意：術語“使用者故事”通常用於兩個有微妙差異的場景。

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

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

在本文中，我使用術語使用者故事來指代範圍本身，而術語使用者故事描述則指的是這些範圍單元的說明。當我談論故事拆分時，我說的是將範圍項拆分為較小的範圍項，而不是將範圍項的描述拆分為較小的說明！

1.1 使用者故事的屬性和INVEST準則

根據INVEST 準則(mnemonic)，使用者故事應為：

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

以我的經驗，這通常沒有那麼簡單 -  拆分故事以使它們“足夠小”通常會在故事之間引入依賴關係，而單個故事往往本身並沒有價值，只有一定數量的相關故事一起，它們才有價值去交付。

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

對於所有故事而言，我的一條規則是：無論故事多大，它們都必須提供使用者可見的內容。這等同於垂直故事切分，後面會詳細介紹。

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

我認為，還有另一個原因同等重要（如果不是更重要的話），並且可能不太為人理解，就是與帕累託原理（也稱為80:20法則，）有關。

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

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

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

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

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

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

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

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

一些團隊/方法/工具定義了故事的分類法，在層次結構中具有固定數量的級別。例如：

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

我不喜歡這種方式。我的經驗是，故事層次結構並不總是整齊地落入固定的層級，因此團隊需要花太多時間思考，“這個故事是史詩級的還是僅僅是功能性？”事實上是哪個層級並沒有關係。

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

一個史詩 是一個使用者故事，感覺大到足以進行分割，或已經被分割。

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

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

我的經驗是，這取決於你的交付團隊以及衝刺週期。最近，我一直在兩週一個衝刺的團隊中工作，開發人員希望故事小到可以在每個衝刺中交付8-12個故事。他們希望能夠最多用幾天來釋出一個故事。

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

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

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

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

我需要大小適中的故事來進入下一個衝刺/增量。或者，如果我正在用看板，則只需要大小適中的故事來讓所有開發人員忙起來。

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

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

（順便感謝Ken Rubin的圖：）

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

5.1 首先做一些分析

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

實際上，我有一個相當結構化的流程來進行分析工作。實際上，它是如此結構化，我給它起了一個名字：Business Analysis Designer Method（BADM。）。下圖總結了這一過程：

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

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

• 在“定義”階段，BA業務分析師會識別利益相關者，瞭解機會空間，提出建議如何實現機會並與產品所有者PO和其他利益相關者達成共識。BA還會在適當的情況下將故事拆分為子故事。

• 子故事將被新增到產品待辦事項列表中，並對其進行優先順序排序，該方法將在子故事上持續進行迭代，直到它們“足夠小”為止。

• 最後，在“設計”階段，BA交付所需的更詳細的分析 - 接受標準和/或行動方案（又稱用例），線框（或UI原型），資料模型等。

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

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

這才是問題所在。當出現“太大”的使用者故事時，開發團隊的第一個直覺通常是按照體系結構劃分，一名開發人員進行資料庫架構更改，另一個編寫中間層業務或控制器邏輯，第三個人變更使用者介面。

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

• 在所有相關故事完成之前，你看不到明顯的使用者收益
• 在所有相關故事完成之前，我們無法測試系統
• 在所有相關故事完成之前，我們不會發現任何體系結構問題
• 我們錯過了將高強度，低價值的部分分割出來留作未來交付的機會

因此，首選的方法是“垂直”分割故事，每個故事透過每個（相關）架構層傳遞一小段變更。這樣，我們在每個故事交付後都有一些（較小的）使用者收益，我們可以測試每個故事，並且可以更快地確定任何體系架構問題。

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

• 某些故事可能僅影響表示層（例如，更改欄位或按鈕標籤），而不是對所有架構層進行切片。
• 有些故事會更改系統介面，而不是使用者介面。它們仍然是“使用者可見的”，但是在這種情況下，系統的使用者是另一個系統，而不是人類使用者。
• 一些故事是無功能的，例如效能或安全性增強。沒關係，響應時間的改善是使用者可見的。
• 有些故事是事件觸發的（批處理）過程，它們會影響系統狀態（即它們會更改資料庫中的資料），但在發生時卻無法透過任何使用者或系統介面看到（儘管稍後會看到其效果，下次查詢資料）。這是“使用者可見”規則的一個特殊例外，允許使用者佩戴X射線眼鏡以觀察系統狀態的變化！同樣，故事是可以測試的，但是測試人員需要在資料庫中探測一下才能看到更改。

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

我只在這裡提供了垂直故事切片的摘要。有很多非常好的文章更詳細地進行了介紹，例如Ned Kremic撰寫的這篇文章：。

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

我們用一個例子來說明。假設我有一個使用者故事，如下所示：

• 註冊
• 作為不需要的東西的所有者，
• 我可以註冊線上拍賣網站
• ，以便可以出售不需要的東西

該故事的使用者目標是 註冊線上拍賣網站。好處是  賣掉我的東西。但是這個故事太大了，我想把它分開。所以我這樣分割它：

• 註冊–輸入詳細資訊
• 作為不需要的物品的所有者，
• 我可以輸入我的註冊詳細資訊（姓名，電子郵件地址等）
• 以便可以註冊線上拍賣網站
• 註冊–提交詳細資訊
• 作為不需要的物品的所有者，
• 我可以提交我的註冊詳細資訊
• ，以便可以註冊線上拍賣網站

我建立了兩個子目標– 輸入我的註冊詳細資訊並提交我的註冊詳細資訊。在這種情況下，後者取決於前者-我必須輸入我的詳細資訊，然後才能提交它們。更重要的是，一旦我同時達到了兩個子目標，我就實現了我的初衷– 註冊線上拍賣網站。然後，我可以進一步細分子故事，直到我的故事“足夠小”為止。我最終會得到故事的層次結構和目標的層次結構。

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

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

• 作為<使用者>，
• 我可以<目標>
• ，以便<更高階別的目標>

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

由於使用者目標的層次結構可能是無限的（向上和向下），因此確實存在迷失的風險。Alistair Cockburn 在其最出色的著作《寫作有效用例》（）中很好地解釋了目標分解，尤其是他透過識別和命名三個特定的目標等級來建立了隱喻錨。他在書中談的是用例，但該理論同樣適用於使用者故事。

• 最重要的目標級別是使用者目標級別，也稱為海平面或藍色。在此級別上，一個使用者可以在單個活動中實現（或未能實現）單一目標，例如“列出要出售的商品”。您可以透過詢問目標是否透過“咖啡時間測試”來檢查這個目標是否為使用者目標：實現目標後，您是否有足夠的理由來休息一下喝杯咖啡？
• 高於使用者目標級別的是摘要級別，也稱為雲/風箏級別或白色。摘要級別的使用者目標是相關使用者級別目標的集合，例如“管理視窗小部件”細分為“建立視窗小部件”，“檢視視窗小部件”，“編輯視窗小部件”和“刪除視窗小部件”。
• 低於使用者目標級別的是子功能級別，也稱為水下級別或靛藍。子功能級別的目標本身對使用者無直接的價值，它們是實現使用者級別目標的步驟，例如，“輸入商品名稱”是“列出待售商品”的子目標。“登入”是常見的子功能級別目標，登入本身並不能實現任何目的，它通常是實現其他目標的前提。

Cockburn非常有意地選擇了海平面/雲層/水下隱喻。天空很高，海洋很深，相應地有許多巢狀級別的雲層目標和水下目標（並且有許多白色陰影和許多靛藍陰影）。但是隻有一個海平面——使用者目標是使用者目標，應該非常清晰地定義。需要澄清的是，我並不是在提倡三層固定的使用者故事層次結構，我早些時候已經對此表示了反對。我只是說，識別海平面在使用者故事層次結構中的位置對於跟蹤交付使用者價值很有用。

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

開始了…

技術1：拆分NFRs

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

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

以下是您可以考慮推遲來關注的NFR列表：

• 效能：延遲使其快速
• 可擴充套件性：推遲使其支援大量併發使用者或大量資料
• 併發：推遲使其支援多個併發使用者（資料鎖定，競爭條件等）
• 可用性：推遲使其具有高可用性和容錯能力
• 安全性：推遲保護其免受攻擊
• 可用性/可訪問性：推遲使其易於使用（適用於所有人）
• UX：推遲使其美觀
• 跨瀏覽器/平臺：推遲使其適用於各種客戶端裝置
• 國際化：推遲支援多種語言/本地約定

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

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

最終，對於每個後續故事，我們可能會將相關的NFR納入“完成的定義”中。但這是另一篇文章要說明的事情。

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

技術2：按使用者介面通道拆分

這是拆分NFR的特殊情況。我上面提到的NFR之一是跨瀏覽器/平臺的支援，如果我的系統具有使用者介面，並且打算支援多個渠道（例如，桌上型電腦，平板電腦，移動裝置）或多個平臺（例如，Windows，Mac，iOS，Android，各種智慧電視），那麼首先集中精力在這些渠道/平臺其中的一個是更有意義的，顯而易見應該選擇我們認為大多數使用者擁有的渠道/平臺。

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

我從事的一些專案具有公司（或政府）標準的UI框架，該框架已經被設計為可響應的（即在多個平臺/裝置上工作）。顯然，從一開始就使用標準框架是有意義的，前提是它相對穩定並且不會增加過多的開銷或學習曲線。即使我們不選擇這樣做，我們仍然可以選擇推遲正式開始跨平臺的合規性。這裡有一個細微的差異：推遲正式合規，是說我們還不會進行跨平臺系統測試。跨平臺測試可能會非常耗費人力，通常最好在釋出前不久進行一次，而不是在每個故事中都做一遍。我們的測試人員現在可以專注於功能測試，並且我們可以更快地進展。

技術3：按使用者型別拆分

一些故事服務於多樣化的使用者社群。我在這裡沒有太多談論國際化，而是在考慮使用者類別。

例如，在最近的專案中，我們的使用者分為以下幾類：

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

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

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

因此，我們決定首先關注英國使用者。然後我們發現了另一個分類：

• 英國個人
• 英國組織

同樣，每個類別的功能都不同。因此，我們決定首先關注英國組織。然後我們發現了另一個分類：

• 英國註冊公司
• 英國非法人公司
• 英國夥伴關係

信不信由你，這些子類別的註冊規則又再次不同。我們首先關注英國註冊公司，併為他們提供了完整的註冊過程（儘管我們用稍後將介紹的其他技術進一步簡化了註冊過程）。然後，我們開始按照業務優先順序順序新增其他使用者型別。再次回到英國脫歐——如果英國很快退出歐盟，我們將不會區分歐盟還是第三國使用者，因此我們將歐盟使用者放在優先順序較低的位置。

最後，我們將使用者群細分為大約15個使用者型別，並針對大約8個獨特的使用者旅程進行註冊。為第一種使用者型別交付功能需要大量工作，隨後新增的每種額外使用者型別變得越來越容易。但是，如果我們嘗試一次全部完成這些任務，我認為任務將是無法達成的。

技術4：將摘要目標分為使用者目標

到目前為止，我們已經拆分了各種NFR，因此我們可以先關注功能，然後再按使用者型別進行拆分，以便專注於為單個使用者組提供服務。

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

一個非常常見的例子是將資料維護故事分為其CRUD元件，例如：

• 維護小部件

變成

• 建立小部件
• 檢視小部件
• 更新小部件
• 刪除小部件

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

• 作為部落格作者，我可以發表文章

可能成為：

• 作為部落格作者，我可以要求釋出我的文章
• 作為編輯，我可以批准發表文章

摘要級別目標還有無數其他型別，可以細分為使用者目標。

子故事通常遵循邏輯順序，你必須能夠建立一個小控制元件才能檢視它，並且您可能想先檢視一個小控制元件，然後再對其進行更新或刪除。您必須先請求發表文章才能獲得批准。但這並不一定意味著故事必須按順序交付，完全有可能透過後門來建立視窗小控制元件（透過直接資料庫載入），因此，如果檢視視窗小控制元件是價值最高的子故事，則可以這樣做。

技術5：按場景/流程劃分

到目前為止，我們的故事處於使用者目標級別：可以由一個使用者一次活動就可以實現。作為美好的一天，對我們的使用者來說一切都會很美好。他們將執行操作、輸入資料並實現他們的目標。這就是我們所說的Happy Path方案。會有許多方法來實現目標，因此可能會有多條快樂的路徑。

但是事情可能不會那麼順利，他們可能輸入了無效資料，或者他們執行了不適當的操作，或者他們找不到正在搜尋的資料，並且他們可能未達到目標。在任何情況下，事情都可能會出錯，因此我們將其稱為替代流程。

例如，

• 建立小部件

可能成為

• 建立小部件–成功
• 建立小部件–小部件名稱已存在

另一個例子：

• 登入

可能成為

• 登入–成功
• 登入–無效的登入詳細資訊
• 登入–失敗3次（鎖定帳戶）
• 登入–帳戶已鎖定

這裡的關鍵點是，某些替代流程的優先順序可能較低。例如，處理無效的使用者ID或密碼是高優先順序，但是在三次失敗嘗試後鎖定帳戶可能不是很高。

對於給定的使用者級別故事，並非總是很清楚所有替代流程是什麼。為了找到它們，為主要的歡樂路徑寫出相應的步驟是一個非常好的主意。例如：

• 1.使用者要求登入
• 2.系統詢問使用者其登入詳細資訊（使用者標識和密碼）
• 3.使用者輸入登入詳細資訊
• 4.系統驗證登入詳細資訊對現有帳戶有效
• 5.系統驗證帳戶未鎖定
• 6.系統登入使用者並顯示主頁

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

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

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

技術6：鍍銅與鍍金

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

例如，假設我們正在構建一個註冊功能，而我們想要捕獲的一個資訊就是使用者的生日。我們可以將其實現為日期選擇器，並彈出一個漂亮的日曆。但是我們也可以將其作為一個簡單的文字輸入欄位來完成，這可能會更快，更容易構建。從而：

• 暫存器

變成

• 註冊– DOB的簡單日期欄位
• 註冊– DOB日期選擇器

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

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

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

• 手動與自動。可以很容易地假設，因為您正在構建IT系統，所以一切都必須完全自動化，而有時手動處理可以用於處理少量任務或在MVP中使用。例如，除了webops團隊執行的手動資料庫指令碼外，我當前正在使用的系統無法建立新的管理員使用者。這是一種痛苦，但這種情況不會經常發生。
• 硬編碼與可配置。也許使用者必須選擇他們的標題（先生，太太等）。理想情況下，選項列表應該可以從可配置列表填充，該列表可由管理員使用者輕鬆維護。但作為捷徑，該列表可以在頁面中硬編碼。
• 假設與要求。 與其允許使用者在你的部落格應用自行選擇頭像，你可以在第一個例項中自動為他們分配隨機模式，自定義頭像稍後再發布。
• 簡單與複雜的體系架構。函式的某些部分可能需要複雜的體系架構解決方案。例如，地址查詢功能需要與第三方軟體整合，因此是否有一個更簡單的選項可以避免使用它，例如手動輸入地址？但是要小心，有時你想盡早解決架構風險，因此，如果該概念行不通，您可以“快速失敗”（請參閱下面的技術999）。當然這個問題沒有統一的答案。

技術7：分步進行

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

…但是我的開發團隊仍然希望將其分解成較小的功能進行交付，以便他們可以快速完成故事並檢視進度。

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

重要的是，我們仍然希望垂直分割故事，以便每個子故事都提供使用者可見的內容。我們不想水平地分割故事，因為這隻會給我們開發任務，而不是故事。

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

逐一步驟的一種變體是為該功能構建一個“骨架”。你從具有起點和終點但中間沒有任何東西的功能開始。例如，一個“註冊”按鈕可透過“提交”按鈕將使用者帶到空白頁。當使用者單擊“提交”時，他們會收到一條訊息，告知他們已成功註冊。但是實際上什麼也沒發生。然後，逐個故事地填補空白，收集各種資料並實際建立註冊。關鍵是您可以採用多種不同的方式對其進行分解，而不必按順序進行。

骨架方法的另一個變體是先構建前端使用者流，但不建立後端 - 所有後端呼叫都被插樁。這樣的好處是，它可以讓您儘早看到完整的使用者流，並在不起作用時對其進行調整（儘管另一種方法是構建簡單的HTML原型）。

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

技巧999

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

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

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

範圍不確定和時間有限的結合，就像我認識的許多開發人員來說聖誕節早到一月 – 這是一個隨機探索並看看會發生什麼的機會。即使是紀律嚴明的開發人員，也有被帶走的嚴重風險。

例如，假設我們的團隊正在構建API，並且我們決定使用RAML來說明那些API（RAML是目前非常流行的API標記語言）。我們希望在我們的網站上釋出API文件，並且我們決定一種較好的方法是構建一個RAML到HTML的轉換工具。

因此，我們進行探針，構建了一個RAML到HTML的轉換工具。一個開發人員被分配到這個探針，然後開始。他們每天在站會上報告進展，應該很快能夠完成。幾周後，進展順利，而且是個好訊息 – 它完全符合RAML 1.0，並且可以從任何有效的RAML檔案生成HTML！

但是，當我們檢視實際想要構建的API時，我們發現我們只需要使用RAML 1.0的子集，他構造的一半是浪費的精力。

這個例子基於一個真實的故事，但實際上並沒有那麼糟糕。在構建的過程中，我們更改了方法。我們沒有繼續“ RAML到HTML轉換器工具”的介紹，而是開始定義面向業務的故事，為真實的API提供實際文件，而我們專注於一次建立一點點RAML到HTML的轉換，僅構建我們實際需要的。透過這種方法，我們避免瞭解決方案的過度設計，並且還更快地交付了一些實際的業務價值。

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

• 小心探針。

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

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

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

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

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

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

參考文獻

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

作者：Tony Heap

原文地址：

譯者：姚冬