GDS Digital Service Manual 中文翻譯網站 (beta)
by HPX-GOV 英國政府數位服務研究小組 GDS Study Group
Home » 英國政府數位服務設計手冊 » 敏捷方法 (Agile) » 編寫使用者故事 (Writing user stories)

編寫使用者故事 (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

1 則留言

  1. 標題:使用者故事只對敏捷式開發團隊有用Stories only work in an agile team
    從閱讀內文發現,意思像是說明使用者故事要如何被討論或交換意見,才能產生真正的效用。
    所以,「那些在敏捷式團隊才有作用的使用者故事」或類似意思的標題,是否比較貼切原文的意思

請留言

你的email信箱不會被發布出來. Required fields are marked *

*