如何使用 INVEST 原則編寫有效的用戶故事？ - IT 觀察者隨筆

Table of Contents hide

一個好的用戶故事除了要有規範的格式和完整的元素外，還應該遵循INVEST原則： 1.我依賴；2.面議；3 、有價值的；4.E估計；5 、 S商城；6.可測試。

1.獨立——讓一個用戶故事盡可能獨立於其他用戶故事是很重要的。保持用戶故事之間的獨立性不僅有利於優先級和對齊，使發布和迭代計劃更容易，有利於獨立理解、跟踪、實施、測試和頻繁交付，而且使用戶故事大小估計的範圍更清晰，從而估計偏差更小。

2.可協商——用戶故事的內容是可協商的；用戶故事不是合同。用戶故事只是對用戶故事的簡短描述，沒有太多細節；具體細節是在溝通階段產生的。太多細節的用戶故事實際上限制了用戶、團隊的想法和溝通。

3.有價值——每個故事都必須對客戶有價值（無論是用戶、買家還是公司內部角色）。用戶故事對最終用戶很有價值，因此應該從用戶的角度來編寫，描述功能而不是任務。

此功能有助於團隊的開發和測試成員從傳統的基於指令的工作方式轉變為以自我驅動的價值導向的工作方式，讓團隊中的每個人都知道他們每天所做工作的價值。

4.可估計（可評估）——計劃會議中一個非常重要的部分是對故事點的估計。它實際上是對要開發的用戶故事的粗略估計，以便團隊可以了解此用戶故事的複雜性（工作量）。

重點是根據該用戶故事的接收條件和團隊定義的DoD（completion criteria）是否可以在當前迭代中完成該用戶故事，如果不能完成，給出原因和PO決定是拆分還是重新設計用戶故事。

使開發人員難以估計故事的問題來自：缺乏對領域的了解（在這種情況下需要更多的溝通），或者故事太大（在這種情況下需要將其切割成更小的部分）。

5.小——一個好的故事在工作量上應該盡可能短，最好不超過10個理想人/天，至少要保證一次迭代完成。用戶故事越大，調度、工作量估計等方面的風險就越大。

6.可測試（ testable）——一個用戶故事應該是可測試的，以確認它可以完成。如果用戶故事不可測試，那麼您無法知道它何時會完成。不可測試的用戶故事的一個例子：軟件應該易於使用。

當遵循 INVEST 原則時，用戶故事基本上就是一個好的用戶故事。然後我們關註三個指導方針，以幫助在製作用戶故事時更好地遵守這些原則。

這三個準則是：一個用戶、完整的價值和無依賴關係。

1.一種類型的用戶——只包括一種類型的用戶，因為多個用戶通常有細微差別。它通常是一個典型的用戶，通常有某種共同的需求。

2.完整的價值——完整地交付客戶價值。一個完整的用戶故事意味著當這個故事完成時，用戶可以達到一個明確而有意義的目標。

3.非依賴——三種常見的依賴類型是：重疊、順序和包含。

一般來說，要避免故事之間的重疊功能點；順序關係是現實的，在大多數情況下可以通過某種方式解決；和包含關係對複雜系統很有幫助，對需要注意的調度發布和迭代計劃有影響。

重疊依賴

重疊依賴是最容易引起麻煩的依賴形式，尤其是當多個用戶故事包含多個不同的重疊部分時。很難找到一組用戶故事來代表該最小可行產品的一組功能，它應該包含並且只包含一次需要的功能。

解決方案

將重疊部分剝離為單獨的用戶故事。
合理拆分用戶故事並將重疊部分保留在最具凝聚力的用戶故事之一中。
使用 Scrum 開發模型。

順序依賴

順序依賴意味著為了完成一個用戶故事，必須在它之前完成一個或多個其他用戶故事。順序依賴通常是無害的，並且有一些方法可以減輕這種依賴。

從敏捷開發的角度來看，整個系統從最初的最小可行產品逐漸演變為強大的產品，之後的每一步都建立在之前的產品之上。

但從另一個角度來看，不必要的順序依賴使得排序和優先級變得更加困難，進而影響發布和迭代計劃的製定，也使得估計用戶故事的規模變得更加困難。

解決方案

使迭代中的用戶故事盡可能地擺脫內在依賴。
在迭代之間只保留單向依賴關係，從後期迭代中的故事到早期迭代中的故事在時間上只有單向依賴關係（前向依賴關係）。
將核心依賴項剝離為單獨的故事，而不是在一個故事中混合依賴和非依賴的需求。

包含依賴項

包含依賴是指在組織用戶故事時使用分層管理，例如常見的兩級特徵故事管理，其中一個特徵包含多個用戶故事，從而構成該特徵對其下級故事的包含依賴。

解決方案

用戶故事級別用於迭代規劃，避免了粗粒度迭代規劃與特性級別，可用於發布規劃。

功能級別也可以拆分，直到達到最低可銷售功能的級別，並且它包含的用戶故事可以單獨分組到新拆分的功能中。

遵循最小可行產品概念，在多個用戶故事的多次迭代中實現一個功能，每個用戶故事都可以產生潛在的可交付成果或提供內部或外部反饋。

參考