Scrum - 使用者故事

---

---

如您所知，使用者故事通常用於描述產品功能，並將成為 Scrum 工件的一部分 – **產品待辦事項** 和 **衝刺待辦事項**。

使用者故事

在軟體開發中，產品功能起著至關重要的作用。終端使用者希望在最終產品中使用這些功能。在一般術語中，它們被稱為需求。軟體開發專案的成功在於準確地理解使用者需求，並將其適當地實施到最終產品中。因此，開發專案團隊需要充分了解需求或產品功能。

1999 年，Kent Beck 提出了使用者故事這一術語來描述產品功能。他描述了使用者故事是從使用者的角度敘述的，關於他或她想要什麼，而不是系統能為他做什麼。因此，視角完全從產品轉向了使用者，使用者故事成為了所有敏捷框架中需求的事實標準。

在 Scrum 專案中，產品待辦事項是使用者故事的列表。這些使用者故事會被優先順序排序，並在衝刺計劃會議中納入衝刺待辦事項。

估算也基於使用者故事，產品的大小以使用者故事點數進行估算。

使用者故事結構

使用者故事結構如下：

作為 <使用者型別>，

我想要 <執行某些任務>，

以便 <我能夠實現某些目標/收益/價值>。

讓我們來看一下如何為銀行客戶從 ATM 取款的場景構建使用者故事。

使用者故事：客戶取款

作為 客戶，

我想要 從 ATM 取款，

以便 我不用在銀行排隊等候

使用者故事驗收標準

每個使用者故事都定義了驗收標準，以便透過基於驗收標準的驗收測試來確認使用者故事實現的正確性。

以下是客戶取款使用者故事示例的驗收標準樣本。

驗收標準 1

如果賬戶信用良好

• 並且卡片有效
• 並且出鈔機有現金，

當客戶請求取款

則確保賬戶被扣款

• 並且確保現金被髮放
• 並且確保卡片被退回。

驗收標準 2

如果賬戶透支

• 並且卡片有效

當客戶請求取款

則確保顯示拒絕訊息

• 並且確保現金未被髮放
• 並且確保卡片被退回。

編寫使用者故事

產品負責人負責產品待辦事項，因此也負責使用者故事。但這並不意味著只有產品負責人才能編寫使用者故事。Scrum 團隊中的任何人都可以編寫使用者故事，並且隨著需求的完善和新功能的新增，該活動可以在整個專案中展開。

使用者故事中的非功能性需求

也可以將非功能性需求納入使用者故事中。在給定的 ATM 示例中，ATM 需要 24x7、365 天全天候可用，這是一個非功能性需求，可以用用例來描述。

管理使用者故事

使用者故事在產品待辦事項中進行管理。使用者故事按優先順序排序。優先順序最高的使用者故事會被細化到粒度級別，而優先順序最低的使用者故事則保持較低的細節級別。對於每個衝刺，都會將優先順序最高，因此粒度更高的使用者故事納入衝刺待辦事項。如果要向產品待辦事項新增使用者故事，則首先確定其優先順序，並根據其優先順序將其放置到相應的位置。使用者故事可以隨時重新排序。如果需要，也可以刪除任何使用者故事。

使用者故事的優勢

• 使用者故事的主要優勢在於其以使用者為中心的定義本身。這是因為，最終，使用者將在相關的使用者場景中使用該產品。它將終端使用者與團隊成員聯絡起來。

• 使用者故事的語法本身確保捕獲使用者想要實現的目標、收益或價值。

• 由於驗收標準本身是使用者故事的一部分，因此這對 Scrum 團隊來說將是一個額外的優勢。

• 可以在專案執行過程中對使用者故事進行更改。如果使用者故事的範圍變得很大，則需要將其拆分為較小的使用者故事。驗收標準中的條件也可以更改。

• 由於在每個衝刺結束時都會向用戶交付可工作的產品增量，因此 Scrum 團隊可以在衝刺評審會議中獲得使用者的反饋。這使得能夠持續將反饋納入產品中。

結論

Scrum 的使用者故事將使用者與 Scrum 團隊聯絡得更緊密，並防止出現最後一刻的意外。