溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
用戶故事拆分是敏捷交付團隊的日常做法。但是以我的經驗，執行起來真的很困難。在本文中，我將所學到的有關故事拆分的所有內容匯總在一起。
這會是一篇很長的文章，所以您可能要在開始之前先喝杯熱騰騰的茶。
一、什么是用戶故事
我認為用戶故事是范圍的單位，是交付的單位。
重要的是，用戶故事向他人傳遞了有用的（或有價值的）信息。在IT環境中，“他人”通常指的是使用系統的人（盡管有時是另一個利益相關者，想以某種方式限制用戶，例如保護系統免受未經授權的訪問）。
因此，通常從用戶角度以“作為……我可以……以便于……”格式描述用戶故事，從而迫使交付團隊始終專注于用戶正在試圖達成的目標及其原因。
注意：術語“用戶故事”通常用于兩個有微妙差異的場景。
如上所述，我通常用它來表示要交付的范圍單位，例如“我們已經在此Sprint中交付了故事X，Y和Z”。
但是，它也廣泛地被用來指代這些范圍單位的描述 -“ 盡可能……我可以……如此……”范式。
在本文中，我使用術語用戶故事來指代范圍本身，而術語用戶故事描述則指的是這些范圍單元的說明。當我談論故事拆分時，我說的是將范圍項拆分為較小的范圍項，而不是將范圍項的描述拆分為較小的說明！
根據INVEST 準則https://en.wikipedia.org/wiki/INVEST_(mnemonic)，用戶故事應為：
以我的經驗，這通常沒有那么簡單 - 拆分故事以使它們“足夠小”通常會在故事之間引入依賴關系，而單個故事往往本身并沒有價值，只有一定數量的相關故事一起，它們才有價值去交付。
因此，我傾向于將INVEST屬性視為準則，而不是無可爭議的法律。一些屬性更適用于史詩（大故事），而另一些屬性更適用于小故事。
對于所有故事而言，我的一條規則是：無論故事多大，它們都必須提供用戶可見的內容。這等同于垂直故事切分，后面會詳細介紹。
二、為什么要拆分故事？
拆分故事最典型的原因是將它們分成幾小塊 - 足夠小以在一次沖刺中交付其中的幾個。你怎么吃大象？一次一小塊。
我認為，還有另一個原因同等重要（如果不是更重要的話），并且可能不太為人理解，就是與帕累托原理（也稱為80:20法則，https://en.wikipedia.org/wiki/Pareto_principle）有關。
80:20法則基本是說你可以在20％的時間內完成80％的工作。換句話說，完成最后20％的工作需要80％的時間。它反映了一個事實，即大多數工作都涉及許多“花哨的工作”，這些工作需要很長時間才能完成，因此盡管感覺您快要完成了，但實際上并不是。
在軟件交付領域，工作的最后20％通常代表替代流程 - 異常，意外或錯誤情況。通常，這些高付出的“怪異碎片”中的相當部分都是價值很低的 - 它們處理的神秘場景通常會在藍色月光下偶爾出現一次。
拆分故事使我們有機會將高價值的東西與低價值（高付出）的東西分開。一旦故事被拆分，并且子故事被放置在產品待辦事項列表中，則在重新確定優先級的對話期間，低價值故事會自然地過濾到待辦事項列表的底部。
這樣做的好處是，我永遠不需要與產品負責人就是否應該處理某個特殊情況爭論不休。我可以將其放在待辦事項列表上，并讓他們相應地對其進行優先級排序。項目發起人遲早會花費時間在項目時間分配上，低價值的東西將永遠無法交付（也稱為“修剪尾巴”）。
拆分故事時，我會盡量牢記這兩個目標：將它們縮小，然后剝離低價值的部分。
三、故事層次和史詩
通常會將大型故事稱為史詩。
我的經驗是，可能有必要對史詩（大故事）進行多次拆分，然后才能找到適合開發團隊的“大小適中”的故事。這取決于原始（史詩）故事的大小，開發團隊希望這些故事的大小，以及我需要拆分多少次才能分離出所有低價值內容。
因此，我將故事拆分視為一種迭代活動 – 一個大故事拆分為兩個或多個子故事，然后可以進一步將每個子故事拆分為多個子故事，依此類推，直到每個故事都變得足夠小為止。這并不是說我需要事先拆分所有的故事。我只在適當的時候拆故事，以后在需要時再拆。關鍵是最終會有故事的層次結構，層次結構可以有很多層，并且并非所有分支都具有相同的深度。例如：
一些團隊/方法/工具定義了故事的分類法，在層次結構中具有固定數量的級別。例如：
我不喜歡這種方式。我的經驗是，故事層次結構并不總是整齊地落入固定的層級，因此團隊需要花太多時間思考，“這個故事是史詩級的還是僅僅是功能性？”事實上是哪個層級并沒有關系。
我更喜歡遵從邁克·科恩（Mike Cohn）的建議（https://www.mountaingoatsoftware.com/blog/you-dont-need-a-complicated-story-hierarchy）：一切都是故事。如果我分解一個故事，我會得到……一些故事。如果我有一個故事，感覺有點大，可以拆分，或者已經拆分了，可以將其稱為史詩，但這仍然是一個故事。
一個史詩 是一個用戶故事，感覺大到足以進行分割，或已經被分割。
重要的是，如上所述，無論故事大小如何，它仍然提供用戶可見且對利益相關者有用的內容，因此我仍可以用“作為……我可以……這樣……”的格式來編寫其摘要。
四、要拆多小
您如何知道故事“足夠小”？
我的經驗是，這取決于你的交付團隊以及沖刺周期。最近，我一直在兩周一個沖刺的團隊中工作，開發人員希望故事小到可以在每個沖刺中交付8-12個故事。他們希望能夠最多用幾天來發布一個故事。
較小的故事可以提高工作效率和動力 – 團隊成員可以一次專注于一件小事，并很快完成它 – 每天回家時都可以完成某件事，或者是有希望結束。小的故事還有助于更好地進行資源計劃 - 故事可以更輕松地在團隊成員之間分配，并且更容易解決團隊成員的缺席/離開。
將故事拆到如此程度通常意味著將其分解到可以被視為或者是獨立的，或者是對最終用戶有價值的程度 – 用戶價值通常只有在交付了許多相關的、相互依賴的故事時才能得到。正如我上面提到的，很難讓一個故事同時具備所有INVEST屬性。
在我工作的每個團隊中，我們都通過反復試驗找到了理想的故事大小。方法如下：我會準備一些故事（已經有了BDD草案，并在適當的創建了一些線框或HTML原型）。我會安排一次三方會議，與團隊一起逐一地過故事。對于每個故事，在我要求他們進行估算之前，我先詢問他們是否認為故事足夠小。如果沒有，我們會去找一種拆分方法。經過幾次這樣的討論后，我會感覺到什么是一個故事的“合適大小”，并且通常會以適當大小的故事進入三方會談。具有諷刺意味的是，隨著團隊的成熟和工作效率的提高，他們有時會覺得現在的故事太小了，最終可能會合并以前拆開的故事！
五、何時拆分故事
對此的簡單答案是：Just In Time。
我需要大小適中的故事來進入下一個沖刺/增量。或者，如果我正在用看板，則只需要大小適中的故事來讓所有開發人員忙起來。
我按優先順序分析故事，包括拆分。因此，如果故事的優先級較低，那么它可能仍然很大，因為我尚未對其進行任何分析。
因此，我希望產品積壓的頂部附近的故事很小，而底端附近的故事會較大。我的待辦事項應如下所示：
（順便感謝Ken Rubin的圖：https://innolution.com/）
其實真實情況并非如此。請記住，我拆分故事的動機之一是拆分低價值的，并讓它們過濾到待辦事項的底部。每次我分解一個故事時，重要的是要將子故事與其余待辦事項重新排序，請確保這種過濾效果的真實發生。因此，在我的待辦列表底部可能還會有一些小故事 – 這些是我已經分解的那些低優先級故事。
在分解故事之前，我首先需要做一些分析工作來理解這個故事。否則，我對它的了解不足以支撐如何拆分它。
實際上，我有一個相當結構化的流程來進行分析工作。實際上，它是如此結構化，我給它起了一個名字：Business Analysis Designer Method（BADM。http://www.its-all-design.com/business-analyst-designer-method/）。下圖總結了這一過程：
不要上當，BADM 不是瀑布方法。相反，每個階段依次針對要傳遞的單個故事執行。
在“請求”階段，需要一個故事，但是在那個階段，我們還不知道目標是什么，或者實現目標的最佳方法是什么。
在“定義”階段，BA業務分析師會識別利益相關者，了解機會空間，提出建議如何實現機會并與產品所有者PO和其他利益相關者達成共識。BA還會在適當的情況下將故事拆分為子故事。
子故事將被添加到產品待辦事項列表中，并對其進行優先級排序，該方法將在子故事上持續進行迭代，直到它們“足夠小”為止。
最后，在“設計”階段，BA交付所需的更詳細的分析 - 接受標準和/或行動方案（又稱用例），線框（或UI原型），數據模型等。
我并不是建議每個人都應該使用BADM，但是在拆分故事之前花一些時間來理解故事的范圍絕對是一個好主意。
六、垂直故事切片
如上所述，我僅有一個分割故事的黃金法則。當我拆分故事，每個子故事都必須提供一些用戶可見的內容。當我說“用戶可見”時，我的意思是在系統的一個用戶或系統界面上可以觀察到（一個用戶當然可以是另一個系統）。
這才是問題所在。當出現“太大”的用戶故事時，開發團隊的第一個直覺通常是按照體系結構劃分，一名開發人員進行數據庫架構更改，另一個編寫中間層業務或控制器邏輯，第三個人變更用戶界面。
這個故事被“水平地”切分到了架構的各個層次。這種方法存在一些問題：
因此，首選的方法是“垂直”分割故事，每個故事通過每個（相關）架構層傳遞一小段變更。這樣，我們在每個故事交付后都有一些（較小的）用戶收益，我們可以測試每個故事，并且可以更快地確定任何體系架構問題。
垂直切片故事時，請注意：
還要注意，一旦故事“足夠小”，開發團隊可能仍會決定將其分為“水平”部分：數據庫變更，UI修改等。這完全沒問題，將故事分解為任務 （特別是開發任務），有些團隊會在沖刺計劃時這樣做，以幫助他們估算故事的工作量和/或在團隊成員之間分配工作。不同之處在于，你需要理解并且有預期，除非所有開發任務都完成，故事才算完成（甚至才能進行測試）。范圍或交付的單位是故事，而不是任務。
我只在這里提供了垂直故事切片的摘要。有很多非常好的文章更詳細地進行了介紹，例如Ned Kremic撰寫的這篇文章：http://www.deltamatrix.com/horizontal-and-vertical-user-stories-slicing-the-cake/。
七、用戶目標分解
如上所述，垂直故事切片就是將故事分成越來越小的用戶可見的更改。每個故事，無論多么小，都會為用戶帶來有價值的東西，這有助于他們實現某些目標。垂直故事切片的另一種方法是用戶目標分解。通過拆分故事，我將用戶目標拆分為子目標。
我們用一個例子來說明。假設我有一個用戶故事，如下所示：
該故事的用戶目標是 注冊在線拍賣網站。好處是 賣掉我的東西。但是這個故事太大了，我想把它分開。所以我這樣分割它：
我創建了兩個子目標– 輸入我的注冊詳細信息并提交我的注冊詳細信息。在這種情況下，后者取決于前者-我必須輸入我的詳細信息，然后才能提交它們。更重要的是，一旦我同時達到了兩個子目標，我就實現了我的初衷– 注冊在線拍賣網站。然后，我可以進一步細分子故事，直到我的故事“足夠小”為止。我最終會得到故事的層次結構和目標的層次結構。
尤其要注意的是，子故事的“ so that”陳述（利益）就是原始故事的“ I can”陳述（目標）。換句話說，收益確實是更高層次的目標。一旦意識到這一點，編寫子故事的“so that”部分就變得容易得多，它們只是父故事（即父目標）的“I Can”部分。
最好這樣解釋用戶故事描述模板：
也可以得出結論，我最初目標的利益– 銷售我的東西 –實際上只是一個更高級別的目標。反過來，這又是更高級別目標的子目標，可以賺錢。反過來又是購買食物的一個子目標，然后是 供養我的家人，再然后 讓我的家人活著。依此類推，直到您最終陷入上一級目標的無限循環，或者陷入諸如“我們存在的意義是什么”這樣的哲學問題中……
八、三個命名的目標級別
由于用戶目標的層次結構可能是無限的（向上和向下），因此確實存在迷失的風險。Alistair Cockburn 在其最出色的著作《寫作有效用例》（https://www.amazon.co.uk/Writing-Effective-Crystal-Software-Development/dp/0201702258）中很好地解釋了目標分解，尤其是他通過識別和命名三個特定的目標等級來建立了隱喻錨。他在書中談的是用例，但該理論同樣適用于用戶故事。
Cockburn非常有意地選擇了海平面/云層/水下隱喻。天空很高，海洋很深，相應地有許多嵌套級別的云層目標和水下目標（并且有許多白色陰影和許多靛藍陰影）。但是只有一個海平面——用戶目標是用戶目標，應該非常清晰地定義。需要澄清的是，我并不是在提倡三層固定的用戶故事層次結構，我早些時候已經對此表示了反對。我只是說，識別海平面在用戶故事層次結構中的位置對于跟蹤交付用戶價值很有用。
九、故事分割順序
有許多久經考驗的方式來垂直剖析故事。多年來，我注意到我傾向于按特定順序應用各種技術。有些技術適用于較大的故事，而其他技術一旦當故事變小就變得更加趁手。因此，我將按通常應用它們的順序來介紹各種技術。請注意，這不是一成不變的規則。對于給定的故事，并非所有技術都適用，并且不一定以相同的順序使用。我可能還會多次使用某一種技術。
開始了…
十、拆分用戶故事的技術
技術1：拆分NFRs
對于任何給定的故事，我想做的第一件事就是將其分為兩部分：一部分交付功能本身，另一部分交付該功能的NFR（非功能需求）。
拆分的主要目的是使團隊專注于交付功能，而不會被NFR分散注意力。在項目早期尤其重要，此時有很多尚未解決的架構問題，事先讓他們都一一解答會讓事情變慢。
以下是您可以考慮推遲來關注的NFR列表：
所有這些事情都具有分散團隊注意力的可能，使他們無法快速交付簡單的東西（剛好可以正常工作），并且可以隨后基于（重構）這些東西以在適當的時候交付各種NFR。拆分NFR并對團隊說：“我們將研究NFR，但現在不必擔心它們”。也許我們甚至可以在不（正式地）考慮所有NFR的情況下提供MVP。這取決于我的MVP是公開發行還是有限定向用戶組的私人Beta版。
我通常一開始將NFR分解為一個單一的故事，稱為“ Project X NFR”或“ Feature X NFR”。在適當的時候，當我們確實 需要更詳細地研究NFR時，我才可能將這個NFR故事進一步細分為各個NFR類別（性能，可用性，安全性等），并一一列舉，當然是按嚴格的優先級順序。
最終，對于每個后續故事，我們可能會將相關的NFR納入“完成的定義”中。但這是另一篇文章要說明的事情。
恰好在“適當時候”發生，是一個很好的平衡。我們不想太早地在體系架構上受挫，但是我們也不想太晚去考慮它，否則我們可能會承擔過多的技術債務，而且還要承擔體系架構風險。同樣的，判斷是伴隨經驗而來的，從來不會有一個唯一簡單的答案，多年來，我見到的過度設計的系統和設計不完善的系統一樣多。
這是拆分NFR的特殊情況。我上面提到的NFR之一是跨瀏覽器/平臺的支持，如果我的系統具有用戶界面，并且打算支持多個渠道（例如，臺式機，平板電腦，移動設備）或多個平臺（例如，Windows，Mac，iOS，Android，各種智能電視），那么首先集中精力在這些渠道/平臺其中的一個是更有意義的，顯而易見應該選擇我們認為大多數用戶擁有的渠道/平臺。
但是，與其他NFR一樣，這又是一個平衡：在項目中的什么時候開始考慮其他平臺？當然，沒有正確的答案，這取決于具體情況。
我從事的一些項目具有公司（或政府）標準的UI框架，該框架已經被設計為可響應的（即在多個平臺/設備上工作）。顯然，從一開始就使用標準框架是有意義的，前提是它相對穩定并且不會增加過多的開銷或學習曲線。即使我們不選擇這樣做，我們仍然可以選擇推遲正式開始跨平臺的合規性。這里有一個細微的差異：推遲正式合規，是說我們還不會進行跨平臺系統測試。跨平臺測試可能會非常耗費人力，通常最好在發布前不久進行一次，而不是在每個故事中都做一遍。我們的測試人員現在可以專注于功能測試，并且我們可以更快地進展。
一些故事服務于多樣化的用戶社群。我在這里沒有太多談論國際化，而是在考慮用戶類別。
例如，在最近的項目中，我們的用戶分為以下幾類：
不要讓我開始聊英國脫歐，這是另一個故事（呵呵）。
要點是，這三個類別的功能都不相同。英國用戶必須采用一種方法進行注冊，歐盟用戶采用第二種方法進行注冊，第三國用戶則采用另一種方法進行注冊。
因此，我們決定首先關注英國用戶。然后我們發現了另一個分類：
同樣，每個類別的功能都不同。因此，我們決定首先關注英國組織。然后我們發現了另一個分類：
信不信由你，這些子類別的注冊規則又再次不同。我們首先關注英國注冊公司，并為他們提供了完整的注冊過程（盡管我們用稍后將介紹的其他技術進一步簡化了注冊過程）。然后，我們開始按照業務優先級順序添加其他用戶類型。再次回到英國脫歐——如果英國很快退出歐盟，我們將不會區分歐盟還是第三國用戶，因此我們將歐盟用戶放在優先級較低的位置。
最后，我們將用戶群細分為大約15個用戶類型，并針對大約8個獨特的用戶旅程進行注冊。為第一種用戶類型交付功能需要大量工作，隨后添加的每種額外用戶類型變得越來越容易。但是，如果我們嘗試一次全部完成這些任務，我認為任務將是無法達成的。
到目前為止，我們已經拆分了各種NFR，因此我們可以先關注功能，然后再按用戶類型進行拆分，以便專注于為單個用戶組提供服務。
在接下來的拆分中，我們回到前面討論的“三個命名的目標級別”的概念。具體來說，我們希望將故事分解成可以通過“咖啡時間測試”的單個用戶目標（“海平面”目標），這些目標可以由一個用戶一次活動就可以實現，而完成后則可以享受咖啡時間。
一個非常常見的例子是將數據維護故事分為其CRUD組件，例如：
變成
另一個常見的例子是一個涉及多個角色的故事。例如：
可能成為：
摘要級別目標還有無數其他類型，可以細分為用戶目標。
子故事通常遵循邏輯順序，你必須能夠創建一個小控件才能查看它，并且您可能想先查看一個小控件，然后再對其進行更新或刪除。您必須先請求發表文章才能獲得批準。但這并不一定意味著故事必須按順序交付，完全有可能通過后門來創建窗口小控件（通過直接數據庫加載），因此，如果查看窗口小控件是價值最高的子故事，則可以這樣做。
到目前為止，我們的故事處于用戶目標級別：可以由一個用戶一次活動就可以實現。作為美好的一天，對我們的用戶來說一切都會很美好。他們將執行操作、輸入數據并實現他們的目標。這就是我們所說的Happy Path方案。會有許多方法來實現目標，因此可能會有多條快樂的路徑。
但是事情可能不會那么順利，他們可能輸入了無效數據，或者他們執行了不適當的操作，或者他們找不到正在搜索的數據，并且他們可能未達到目標。在任何情況下，事情都可能會出錯，因此我們將其稱為替代流程。
例如，
可能成為
另一個例子：
可能成為
這里的關鍵點是，某些替代流程的優先級可能較低。例如，處理無效的用戶ID或密碼是高優先級，但是在三次失敗嘗試后鎖定帳戶可能不是很高。
對于給定的用戶級別故事，并非總是很清楚所有替代流程是什么。為了找到它們，為主要的歡樂路徑寫出相應的步驟是一個非常好的主意。例如：
步驟4提出了一個問題：如果登錄詳細信息無效，該怎么辦？我們找到了替代流程。
步驟5提出了一個問題：如果賬戶被鎖定怎么辦？我們找到了另一種替代流程。
如果您在想拆分替代流程時束手無策，絕對應該閱讀 Alistair Cockburn的書。
在技巧5中，我將故事分為個人流程 - 歡樂路徑和替代流程。我們很可能會先專注于交付主要的歡樂路徑。但是在我們這樣做之前，我將先看一下它，看看是否有我可以先做的更簡單的版本。
例如，假設我們正在構建一個注冊功能，而我們想要捕獲的一個信息就是用戶的生日。我們可以將其實現為日期選擇器，并彈出一個漂亮的日歷。但是我們也可以將其作為一個簡單的文本輸入字段來完成，這可能會更快，更容易構建。從而：
變成
我有時稱其為“銅鍍層”，而不是“金鍍層”，對于MVP來說已經足夠了。當然我們可以做得更好，如同前文闡述的，在待辦事項優先級的驅動下，是否以及何時使它變得更好，取決于與其他的待辦事項相比，我們對日期選擇器的重視程度。
這是解決團隊內部爭執于如何準確交付特定功能的一個好技巧。您將流程分解為“最低限度的最低要求”（即MVP），然后為每個層次的要求分別建立一個故事。（產品負責人）可能會認為某些功能要求是必不可少的 - 沒問題，我們在MVP故事之后不久就做。其他人會將其放進待辦列表，以待日后完成，也許永遠不做。有趣的是，我被多次告知某項功能“必不可少”，僅僅是因為發現該功能在待辦列表的底部停留了六個月之久。顯然，它上面的所有內容都更重要。
這是您可以使用的其他一些鍍銅技巧：
因此，到目前為止，我已經為單個功能確定了一條快樂路徑，并且將其縮減為對MVP有意義的最低限度……
…但是我的開發團隊仍然希望將其分解成較小的功能進行交付，以便他們可以快速完成故事并查看進度。
這里的一種選擇是告訴開發人員，在繼續具有商業價值的同時，無法合理地分解故事。另一個選擇是將其進一步分解，以使有價值的故事一次累積一點。
重要的是，我們仍然希望垂直分割故事，以便每個子故事都提供用戶可見的內容。我們不想水平地分割故事，因為這只會給我們開發任務，而不是故事。
顯而易見的事情是將功能分解為各個步驟。在第一種情況下，如果該功能涉及用戶遍歷多個屏幕，則可以在每個屏幕上拆分一個故事。然后，您可以將其拆分，以便逐步交付每一個屏幕。您的工作量取決于開發團隊的偏好。我經常發現當團隊還年輕時希望故事很小，而隨著他們的成熟，可以應對更大的故事。
逐一步驟的一種變體是為該功能構建一個“骨架”。你從具有起點和終點但中間沒有任何東西的功能開始。例如，一個“注冊”按鈕可通過“提交”按鈕將用戶帶到空白頁。當用戶單擊“提交”時，他們會收到一條消息，告知他們已成功注冊。但是實際上什么也沒發生。然后，逐個故事地填補空白，收集各種數據并實際創建注冊。關鍵是您可以采用多種不同的方式對其進行分解，而不必按順序進行。
骨架方法的另一個變體是先構建前端用戶流，但不建立后端 - 所有后端調用都被插樁。這樣的好處是，它可以讓您盡早看到完整的用戶流，并在不起作用時對其進行調整（盡管另一種方法是構建簡單的HTML原型）。
順便說一句，此技巧的另一種用途是將故事從用戶目標級別（海平面）拆分為子功能級別（水下平面）。
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，有兩個原因。首先，這是不得已的方法，必須在所有其他技術之后使用；其次，（在英國）這是您撥打的呼叫救護車的電話號碼，這似乎很適合使用具有潛在危險性的技術！
十一、故事拆分很難
當我著手撰寫本文時，我并沒有意識到會需要多長時間。具有諷刺意味的是，我寫了一篇有關將史詩分解成故事的本身就是史詩的文章。
這篇文章的長度可以說明問題 - 故事拆分很復雜，以我的經驗來說，做起來很難。我已經做了很多年了，但我仍在學習新的技巧。這是通過實踐和經驗而能變得更好的技能之一，因此，如果您在掙扎中，請不要放棄！
十二、結論
自從您開始閱讀本文以來，可能已經過去了幾十年，值得快速回顧一下：
作者：Tony Heap
原文地址：http://www.its-all-design.com/how-to-split-user-stories/
譯者：姚冬
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
