編寫使用者故事 (Writing user stories)

使用者故事簡要說明：

• 使用這個服務的人（角色）
• 這個人要用這個服務完成什麼事（描述）
• 為什麼這個使用者需要這個服務（目標）

使用者故事是敏捷工具很重要的一部分。利用這些使用者故事，可以把工作拆分成許多可以創造有形價值的區塊，也便於管理；而且這些區塊是各自獨立的，是可以讓我們來排列優先順序的。

使用者故事是否有用，仍需依賴敏捷方法中其他的環節，包括持續交付，以及與用戶代表面對面溝通等等。不是指派一個使用者代表就可以了，這個代表必須跟團隊待在同一個地方，並且為團隊保留足夠的時間。

使用者故事可以由任何人、在 sprint 的任何時間點加到產品備忘錄（product backlog）中。在每個衝刺週期開始時，由產品負責人來協調、排序，並選擇這個衝刺裡要實作的使用者故事。

在衝刺規劃會議之前，先與以下對象討論使用者故事：

• 相關的團隊成員
• 主題專家
• 利害關係人

使用者故事卡片

使用者故事可以用一張卡片來呈現，內容包含標題和幾行文字。

使用者故事卡可以是實體的，也可以是虛擬的。在一個大的產品/服務專案中，可以把所有使用者故事用電子格式保存，然後在衝刺規劃時印成實體卡片。

在撰寫使用者故事時，要確認這個故事是完整的。不要因為很難解釋為什麼需要這個服務，就忽略、跳過。

你可能要一張驗收標準清單。這可以當做備忘清單，在溝通時可以拿來測試或檢查，但不應該直接用來界定使用者故事的範疇。

如果故事太大，就要切割成更小的故事，這樣一來才更有機會能產出可交付、可使用的程式。

結構

使用者故事卡的標準結構：

• 標題
• 角色
• 描述
• 目標

不需要包含所有細節，但是應該在適當的時機針對這些使用者故事進行深入的討論。

姓名
角色：	身為一個	記者
描述：	我想要	看到我正在讀的新聞文章的相關聯絡訊息
目標:	因此我可以得到	我可以直接聯繫這篇新聞文章的新聞辦公室

透過設定目標，由外而內運作

打造有用的軟體系統是很難的，所以必須確保我們正在解決對的問題。

敏捷方法強調的是一個從外到內的方法 – 使用者想透過這服務得到什麼結果？如果我們埋頭於提供方案卻沒有先好好了解使用者，就有可能完全搞錯問題，或是做出來的解決方案對真實世界的使用者來說沒有用。這就是為什麼在一個使用者故事中，最重要的部分就是目標。

目標

透過建立目標，來讓我們決定一個故事怎樣才算完成。有完成使用者想達成的目標嗎？

在和開發團隊一起寫故事時，一定要先針對使用者的目標來思考、討論：

• 為什麼他們想要使用你的服務？
• 他們想要達到什麼目的？
• 是什麼需求，促使他們尋求這服務的幫忙？
• 他們在什麼情境使用這些服務 – 在家/工作/手機上/照顧孩子的時候？
• 他們多常使用？

蘇珊（Suzanne）和詹姆斯•羅伯遜（James Robertson）在這本《Mastering the Requirements Process》 （第3版）中提供了絕佳的建議。

角色

角色必須要明確，才能把每個互動切成符合邏輯的小塊。

有時這些角色是你的服務的使用者，有時是你組織中的系統管理員，技術人員或管理階層。

請確保在專案初期的工作中，或是透過以前的研究，你已經深入嘹解了你的使用者。如果還沒有進行的話，請先花些時間先去瞭解。

敘述

敘述是用來描述在使用者主要進行的互動，這互動屬於使用者經驗的一環。請記住，這個故事卡並不需要包含每一個細節。

改天吧 – 約好之後再詳述

敏捷式團隊更喜歡面對面的談話，而不是詳細的文件 。

面對面代表的是：

• 更快
• 比書面文件更精準
• 允許開發人員建立一個更詳細的心智模型，其中包括使用者的目標、工作流程、限制，以及構建軟體系統時，所必須考慮到的許多問題

故事卡只是預先留下一個空間，之後要在適當的時機進行討論。使用故事卡並簡單地討論一下，以便估計完成這個故事所需的時間，然後把它加到敏捷備忘錄（agile backlog）中。

當開發工作真正開始時，諮詢使用者或使用者代表來把故事細節填入。使用者故事是所有這些談話、草稿和白板圖表的總和 – 不只是使用者故事卡而已。你不需要把對話寫下來或是歸檔，而是直接轉換成能運作的程式碼以及自動執行的測試程式。

透過這種方式，可以避免在撰寫使用者故事時陷入“分析癱瘓”(analysis paralysis)，這個痛苦的狀態就是不斷試著去猜測一些還很遠的目標的細節。

使用者故事中的驗收標準

驗收標準用來定義怎樣算是完成一個故事。建立驗收標準的時機，是在開發者與使用者、使用者代表對話後，在開始寫程式之前。

如果團隊覺得以後可能會忘記一些關於使用者的假設，那麼可以把這些資訊寫在使用者故事卡的背面。當使用者或使用者代表不是隨時有空、或是並非總能面對面交談時，把驗收標準寫在使用者故事卡上就很有幫助。

使用者故事只對敏捷式開發團隊有用

使用者故事的成功，仰賴於開發者和使用者或使用者代表定期面對面地溝通。

你的服務經理和其他使用者代表必須每天排出一段時間給開發團隊，並且有足夠的時間來思考並回答問題。不要小看這項工作可能會花掉的時間！

如何獲得使用者故事

使用者故事可以來自很多地方，但最常見的來源包括：

• 使用者故事寫作工作坊 – 十分常見的情況，開發團隊和利害關係人在專案開始時聚一起寫故事。
• 訪談真實的使用者 – 理想情況下，應該召開使用者座談會，讓開發團隊可以常常瀏覽
• 團隊裡的使用者代表 – 可能是服務經理或產品負責人
• 觀察 – 看真正的使用者如何使用您的服務

請參考第四章：如何應用使用者故事 。

延伸閱讀

1. Mastering the Requirements Process，3rd Ed, Suzanne Robertson & James Robertson, 2012
2. Agile Alliance, “Agile – What is it?” http://www.jconne.com/agile1whatisit/ ，2013/7/1
3. Twelve Principles of the Agile Manifesto – http://agilemanifesto.org/principles.html
4. User Stories Applied, Mike Cohn, 2004. Free chapter:“Writing User Stories (編寫使用者故事) 可在此閱讀http://www.mountaingoatsoftware.com/books/user-stories-applied

譯者：
校稿：
原始出處：https://www.gov.uk/service-manual/agile/writing-user-stories