根據INVEST原則，對用戶故事的要求是它必須“足夠小”或具有合適的大小。用戶故事應該足夠小，可以在沖刺中完成6-10個。當然這也取決于開發團隊的速度。為了原則上實現這一目標，必須相應地分割大型故事。在下文中，我想向您介紹Mike Cohn的簡單快速的SPIDR方法。他總結了五種技術，幾乎每個大型用戶故事都可以分為幾種。

釘鞋

Spike是敏捷軟件開發中使用的術語。尖峰是功能的小型原型實現，通常用于新技術的評估和可行性。

該方法涉及調查和建立知識。如果其他SPIDR方法效果不佳，則應該使用它。借助這些新獲得的知識，可以更好地理解一些故事，并可能更容易地分裂。然而，該方法相對抽象，因此比其余方法更難應用。

路徑

如果用戶故事中有多個可能的備用路徑，則一個選項是從這些路徑中的某些路徑創建單獨的用戶故事。為每條路徑寫一個故事并不是絕對必要的，只要它有意義。例如，讓我們看一個用戶想要在線商店購買的用戶故事。現在有兩種可能的途徑：使用信用卡付款或使用Paypal付款。理論上，信用卡付款可以進一步細分，但你需要權衡每種類型的信用卡是否有自己的故事。然而，支付購買的首要任務分為上述兩種備選方案。因此，新創建的故事更小，更容易估計。

接口

在該上下文中的接口可以是例如不同的設備或設備類型，例如由iOS或Android供電的智能電話。用戶故事也可以根據這種多樣性進行劃分。讓我們堅持使用不同操作系統的示例：例如，在項目中，可能存在僅與Android設備的使用相關的用戶故事，或者專注于Web瀏覽器的其他用戶故事。為了避免使故事過于龐大和全面，您應該問自己要開發哪些設備或接口。也許第一個開發結果應該只引用iOS設備，因為可能更大的目標組。

數據

當初始故事僅涉及相關數據的子范圍時，可以使用另一種用于分割用戶故事的技術。以一個旨在吸引游客到特定城市的網站為例。例如，如果它是以博物館而聞名的城市，那么第一個故事可能包括該地區不同博物館的信息。隨后的故事可能包括穿越城市的各種旅游，以及另一項戶外活動。

規則

業務規則或技術標準可能是另一個分裂因素。以在線購買電影票為例。通常存在約束，例如基于相應電影的業務要求，例如每個電子郵件地址最多五個票的在線購買限制。

有了這個故事，可以想象開發團隊省略了這個限制，允許每個訪客購買盡可能多的門票。然后可以在第二次迭代步驟中添加限制。像這樣的增量交付意味著初始故事不會立即完全實現，而是以幾個較小的步驟提供。有時忽略技術規范或業務規則是有意義的，如果通過這樣做，您可以更快地實現滿足用戶或客戶的可呈現結果。可以在以后檢索省略的故事。

小用戶故事 - 更容易實現

用戶故事分裂并不總是那么容易：許多初學者傾向于將他們的故事過于全面而且過于龐大。但是，當涉及到開發團隊的改進，并最終實現故事時，很快就會發現必須制作更小的故事。在我之前關于寫（好）用戶故事的博文中，我堅持認為故事應該是“可估計的”和“小的”。如果您知道如何分割大型故事，則更有可能發生這種情況。正如編寫用戶故事一樣，練習也是完美的。

---

敏捷軟件開發

• 什么是敏捷軟件開發？
• 什么是用戶故事？
• 什么是用戶故事映射？
• 用戶故事與敏捷軟件開發的使用案例

總結

以上是生活随笔為你收集整理的SPIDR - 完美分割用户故事的五种简单技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。