什麼是使用者故事？

什麼是使用者故事？

使用者故事是一則筆記，記錄了使用者在工作過程中所做的事情或需要完成的事。每個使用者故事都包含一段以使用者角度撰寫的簡短描述，使用自然語言。與傳統的需求收集方式不同，使用者故事著重於使用者的需求，而非系統應交付的功能。這為進一步討論解決方案留下了空間，並產生能真正融入客戶業務流程的系統，解決其運營問題，最重要的是為組織創造價值。

3C原則

3C指的是優秀使用者故事的三個關鍵面向。這個概念由使用者故事實踐的共同發明者羅恩·傑弗里斯提出。如今，當我們談論使用者故事時，通常指的是由這三個面向組成的使用者故事。

1. 卡片 – 使用者故事以卡片形式撰寫。每張使用者故事卡片包含一句簡短的文字，內容足夠提醒所有人該故事的重點。
2. 對話 – 需求透過客戶與開發團隊在整個軟體專案期間持續對話來發現與釐清。重要的想法與決策將在利益相關者會議中被發現並記錄下來。
   
3. 確認 – 也稱為使用者故事的接受標準。在需求討論過程中，客戶不僅會告訴分析師自己想要什麼，還會確認在何種條件與標準下，可運作的軟體將被接受或拒絕。所定義的情境會以確認方式書寫。需要注意的是，確認著重於驗證對應使用者故事工作的正確性，而非整合測試。
   

如何識別使用者故事？

使用者故事應與利益相關者共同識別，最好透過面對面會議進行。使用者故事是一種需求發現過程，而非事前需求分析過程。在傳統的需求收集方法中，系統分析師試圖理解客戶需求，然後詳細撰寫系統的需求規格。這並非使用者故事方法的運作方式。與文件化過程不同，使用者故事的識別更像是一種筆記過程。透過與使用者的討論，我們傾聽並理解他們的問題與需求，同時將其需求寫成使用者故事。這些使用者故事將成為需求的來源。細節可於需要時即時填補，為團隊在整個專案開發過程中提供「恰到好處」的需求參考。

以使用者故事映射業務流程

BPMN 是業務分析與建模中最強大的工具之一。我們不僅可以利用它來進行流程改善，還能透過以下步驟從預期自動化的流程中識別使用者故事：

1. 僅需使用 BPMN 業務流程圖簡單地模擬使用者的工作流程。
2. 與使用者一起走過流程模型。
3. 接著分析問題的業務活動，並識別與需自動化的流程相關的使用者故事，這也稱為業務流程至使用者故事的映射。

如何撰寫使用者故事？

撰寫使用者故事時，試著以使用者的語氣撰寫，格式如下（至少要確保你所撰寫的內容符合以下陳述）：

作為 <角色>，我希望 <業務目標>，以便 <業務價值/原因>。

例如：作為客戶，我希望在商品到達時收到簡訊以便我能夠去把它拿回來.

地點：

1. <角色>代表將與即將實現的系統互動以達成目標的個人、系統、子系統或任何其他實體。他或她將透過與系統互動獲得價值。
2. <商業目標>代表使用者透過與系統互動所能達成的期望。
3. <商業價值>代表與系統互動背後所蘊含的價值。

這不是一條規則，而是一項指導原則，幫助你透過考慮以下事項來思考使用者故事：

1. 使用者故事將為某人或特定方帶來價值（例如：客戶）。
2. 使用者故事滿足使用者的需求（例如：物品到達時收到簡訊）
3. 有理由支持執行此使用者故事（例如：客戶可以去領取她購買的物品）

每個使用者故事都應為某人帶來價值。但有時僅閱讀商業目標便足以看出價值。將價值寫入敘述中會顯得繁瑣。在此情況下，我們將直接省略。以下為幾個範例：

作為一位客戶，我希望可以使用信用卡支付以便我能在線上購物時使用我的信用卡.

作為一位使用者，我希望可以輸入朋友的名字來進行搜尋以便我可以用她的名字找到她.

無論你如何撰寫使用者故事，有兩件事你必須牢記在心。第一，使用者故事必須從使用者的角度撰寫。第二，保持描述「恰到好處」。避免在軟體專案初期加入過多細節。後續你將有機會進一步精煉並詳述使用者故事，使其成為開發人員在設計與實作時可使用的內容。

使用者故事的生命周期

廣義而言，在整個軟體專案中，每個使用者故事有六個主要狀態：

1. 待處理 – 透過使用者與專案團隊之間的溝通，發現使用者故事。在此狀態下，使用者故事僅包含使用者需求的簡短描述。尚未進行需求的詳細討論，也無系統邏輯或螢幕設計。事實上，目前使用者故事的唯一目的，僅是提醒各方未來討論此使用者故事（卡片）中所寫的使用者需求。未來有可能會放棄此使用者故事。
2. 待辦事項 – 透過不同利害關係人之間的討論，決定接下來幾週需處理的使用者故事，並將其放入稱為「衝刺」的時間區間內。這些使用者故事被稱為處於待辦事項狀態。在此狀態下尚未進行詳細討論。
3. 討論中 – 當使用者故事處於討論中狀態時，最終使用者將與開發團隊溝通，以確認需求並定義接受標準。開發團隊會將需求或任何決策以對話筆記的形式記錄下來。UX專員可能建立線框圖或故事板，讓使用者預覽所提出的功能在視覺模擬中的樣貌，並感受其效果。此過程稱為使用者體驗設計（UX設計）。
   
4. 開發中 – 在需求明確後，開發團隊將設計並實現功能以滿足使用者的要求。
5. 確認中 – 當開發團隊完成一個使用者故事後，使用者故事將由最終用戶確認。該使用者將獲得測試環境或半完成的軟體產品（有時稱為 alpha 版本）的存取權，以確認該功能。確認將根據撰寫使用者故事時所列的確認項目進行。在確認完成之前，使用者故事被視為處於確認中狀態。
6. 已完成 – 最終，功能被確認已完成，使用者故事即被視為已完成狀態。通常，這就是使用者故事的結束。若使用者有新的需求，無論是關於新功能，或是對已完成使用者故事的增強，團隊都將為下一個迭代創建新的使用者故事。

詳細說明使用者故事 – 何時以及為什麼？

使使用者故事與傳統需求收集方法不同的關鍵在於，使用者故事方法將問題與解決方案的識別分為兩個步驟，分別在軟體專案的不同階段進行。雖然問題與使用者需求的初步理解是在軟體專案初期發現的，但系統需求的細節僅在設計與實作開始前才被確定。這種安排具有以下優點：

1. 能夠回應最新的使用者需求，因為需求是在即將實作前才詳細釐清，而非在開始時就全部決定。
2. 更容易識別正確的需求，因為問題與解決方案都將經過詳細討論。在傳統方法中，由於所有需求的細節必須在專案初期就全部找出，因此「前期需求」可能隨時間改變，導致大量分析資源的浪費。
3. – 另一方面，若發現使用者故事無效，可輕易捨棄。你不會在前期研究與文件編製上浪費太多時間。

如何有效使用使用者故事？

與許多其他軟體開發方法類似，若你在軟體專案中正確應用使用者故事，將能產出高品質的軟體系統，並贏得客戶的信任與滿意。使用使用者故事時，需注意以下幾點：

1. 保持使用者故事的描述簡短。
2. 撰寫使用者故事時，應從最終使用者的角度思考。
3. 一個（UML）用例代表一個業務目標。能夠將使用者故事歸類於用例之下，可確保使用者故事滿足業務目標，換句話說，它們共享相同的系統目標。這可作為一個佔位符，讓你更有效地管理、排程與優先處理使用者故事。
4. 確認項目必須在開發開始前定義
5. 在實作前估算使用者故事，以確保團隊的工作負荷在可控範圍內。
6. 需求應與最終使用者共同發現，而非僅由最終使用者或開發團隊單方面決定。與最終使用者保持良好關係，將對雙方都是互利的結果。
7. 溝通在理解最終使用者需求時始終至關重要。

Visual Paradigm 提供您在 敏捷軟體開發 中所需的所有工具，包括 UML 用例圖工具, （敏捷） 使用者故事, 迭代, 故事板 和 線框圖 用於使用者體驗設計，任務管理工具，等等