敏捷用戶故事的接受標準

我們如何確保用戶故事被正確完成並滿足客戶需求？這正是接受標準發揮作用的地方。接受標準是一份正式的要項清單，確保所有用戶故事都已完成，並考慮到所有情境。簡而言之，接受標準定義了用戶故事被視為完成的條件。明確且書面化的標準有助於開發團隊避免對客戶需求的模糊理解，並防止誤解。

因此，在撰寫用戶故事時，接受標準至關重要。它們能幫助你的團隊了解在功能開發過程中哪些是必須完成的，以及應專注於哪些方面。

讓我們深入探討接受標準。

什麼是接受標準？

接受標準讓你能夠定義用戶故事何時完成，以及是否具備滿足用戶需求的所有功能。

它們是一組用戶故事必須滿足的條件，才能被視為完成。它們提供了用戶故事的詳細範圍和所需內容，讓你的團隊理解當前的問題。這樣，每次發布新功能時，你都能確保其達到用戶應有的標準。

但在熱情地列出用戶故事應滿足的一系列功能標準之前，請考慮其他變數可能如何影響功能的品質，並將它們納入你的接受標準中。

接受標準可包含以下細節

  • 使用者體驗
  • 當前用戶故事對現有功能的影響
  • 關鍵性能，例如速度
  • 用戶故事的預期功能

因此，根據你正在開發的功能及其複雜程度，與團隊坐下來確定其應執行的最小功能子集及其行為方式。

如果它較為複雜，或是你產品的核心功能，你應盡可能撰寫盡可能多且詳細的接受標準，以幫助團隊避免任何混淆。

如何撰寫用戶故事的接受標準

1. 接受標準應從使用者的角度撰寫

接受標準是一種從客戶角度看待問題的方式。它們應在真實使用者體驗的背景下撰寫。畢竟，你是在為使用者打造產品，不是嗎？

2. 標準應清晰且簡明

接受標準不應與測試案例或文件混淆。保持標準盡可能簡單明確至關重要。

3. 每個人都必須理解你的接受標準

如果開發人員無法理解它們，你的標準就毫無用處。如果你對清晰度存疑，請花時間提問並調整，直到一切變得清晰為止。

4. 接受標準不是關於「如何」（如何？），而是關於「什麼」（為什麼？）

如同用戶故事，接受標準並非任務。它們是一種傳達用戶故事的方式。

5. 接受標準應具體，但不是另一層細節

以稅務申報軟體為例，最重要的要求是根據收入和支出正確計算應繳稅額。清楚吧？你也知道無法測試每種可能的組合——因為可能性幾乎無限。

因此，你對該用戶故事的接受標準將明確指出必須滿足的具體條件或要求。這意味著更為具體，而非增加另一層細節。這有助於你的團隊理解所需內容，並加快交付速度。當然，當你將當前的燃盡圖與以往的進行比較時，可能會看到一些改進。

6. 接受標準可以是從使用者角度對用戶故事的重新陳述

這僅適用於用戶故事並非過於複雜的情況。這裡有一個我所指的例子。

對於像這樣的用戶故事：「作為一名財務官員，我希望能夠接受發票，以便追蹤所有財務報表”

其接受標準可能是「當我執行接受操作時，發票將被接受（通過檢查發票記錄來驗證）”

給定/當/則 接受標準範本

為了讓生活更簡單，這裡有一個簡單的範本，你可以用來撰寫接受標準：

給定 [情境] 當 [執行特定操作] 時，則 [應產生一組後果]

接受標準範例

針對此用戶故事範例：

“作為一名撰稿人，我希望在其他人新增評論時收到通知，以便隨時掌握最新情況。”

以下是上述用戶故事的三個接受標準範例：

  1. 給定我的手機已鎖定當應用程式未開啟時，則我應該收到橫幅通知。
  2. 給定我正在撰寫文件當應用程式開啟時，則鈴鐺圖示應更新以顯示未讀通知及其數量。

範例 – 網站反饋提交

我們指定部落格評論功能的用戶故事和接受標準。登入用戶可以新增評論。「新增評論」功能的用戶故事如下：

作為一名已登入的使用者，
我希望能夠在部落格文章上留下評論，
以便能夠收到關於該主題的回饋。

此功能的接受標準如下：

情境：一名已登入的使用者在部落格文章上留下評論
假設我是一名已登入的使用者，
當我開啟包含特定部落格文章的頁面時，
系統會在部落格文章下方顯示「評論」區塊，並列出其他使用者所新增的評論。
系統會在「評論」區塊的頂端顯示「新增評論」欄位。
當我填寫「新增評論」欄位並點擊「提交」按鈕時，
系統會儲存我的評論。
系統會將我的評論顯示在「評論」區塊的最上方。
系統會在我的評論左側顯示我的使用者名稱和頭像。
系統會在我的評論對側顯示「刪除」和「編輯」圖示。

 

如你所見，撰寫接受標準對客戶與開發團隊而言實為雙贏：它不僅幫助團隊清楚理解必須完成的事項，也讓客戶能了解開發流程，並確認交付的軟體符合實際的商業需求。

 

Leave a Reply