用戶故事的故事

2 評論 3527 瀏覽 15 收藏 16 分鐘

編輯導語:用戶故事在軟件開發過程中被作為描述需求的一種表達形式;為了規范用戶故事的表達,便于溝通,包含角色、活動、價值三個要素;本文作者分享了關于用戶故事的故事,解答一些用戶故事最常見的問題,我們一起來看一下。

一、開篇

我將給你講述用戶故事的故事,并回答一些用戶故事最常見的問題;我們將談論用戶故事,從來源到實踐,并學習一些技巧來幫助我們。

敏捷開發指南對用戶故事只字未提,有一段時間我還在想去哪里找關于用戶故事的可靠信息。

待辦事項列表是否應該只由用戶故事組成?如果不用 “作為用戶,我想…,以便…” 的模板,是不是就不是用戶故事了?那么那些寫著 “作為開發者…” 或者 “作為產品經理…” 等等的故事呢?

我的目的是對用戶故事進行全新演繹,澄清一些圍繞用戶故事的誤解,并為你指出那些對用戶故事進行最好闡釋的人。

二、基礎篇

1. 用戶故事的故事

我將解釋用戶故事的來源,因為這對我來說是理解用戶故事和澄清誤解的最好方法。

用戶故事來自于90年代,Kent Beck在他的《Extreme Programming Applied》一書中開始討論用戶故事。

這個想法來自一個用戶告訴他的一個關于新產品的故事:“我輸入郵編,它就會自動填入城市和州,不需要我觸碰按鈕!”

如果你能講述軟件可以做什么的故事,并在聽眾心中產生動力、興趣和愿景,那么為什么不在制作軟件之前講故事呢?Kent問自己,為什么不能在構建產品之前就產生這種對產品的愿景呢?關于誰會使用這個產品,它將做什么,以及為什么?我們應該通過對話來幫助我們思考問題。

《User Story Mapping》一書的作者Jeff Patton堅持認為:“故事的名字來自我們如何使用它們,而不是如何寫它們?!?/p>

2. 模板

后來Connextra公司的Rachel Davis發明了我們今天使用的模板,它是這樣的:“作為一個用戶,我想… 以便…”

她試圖幫助同事有條不紊地在小卡片上寫故事,模板提醒我們最重要的三件事:誰要、要什么、為什么。

站在用戶的立場上,從他們的角度思考他們的需求,比如說:

作為一個手機用戶,我想查看所在位置的天氣預報,以便我不用每次去一個新地方都要查天氣預報。

同樣,你寫在卡片上的內容應該只是一個起點,用以推動新想法的第一次對話??ㄆ母拍顏碜訰on Jeffries的3Cs:卡片,對話,確認。

你把你的想法寫在一張卡片上,其實目前是寫在一個軟件跟蹤工具中,或者是一張便利貼上,然后你和將建立它的人(開發團隊)就它進行對話,然后你有一個確認;你把結果寫在一個文檔或者是跟蹤工具中,這樣你就可以很容易地回憶起對話,并且知道如何驗證這個故事是否已經完成。

你可以在Mike Cohn的《User Stories Applied》一書中讀到這一切,Mike Cohn是 “用戶故事” 領域的偉大實踐者和專家。

所以這就是我們如何從Kent Beck的故事中走來,并得出我們今天使用的用戶故事。

在故事中加入 “用戶” 這個詞,有助于讓我們的注意力集中到用戶身上,這可以說明為什么 “作為開發者,我想要” 的模板只有在我們的最終用戶是開發者的情況下才是準確的。

這就是用戶故事的故事。

它是把講故事引入到你的產品創作中,故事可以使用模板寫下來,以確保我們不會錯過任何重要的信息,但當然,這是可選的;最重要的是,產品負責人和將建立產品的開發團隊,對他們想要實現的目標有一個共同的理解。

三、實踐篇

1. Ron Jeffries的3Cs

Ron的3Cs:卡片、對話、確認;我們現在就通過這三件事來看看實踐中創建用戶故事的過程。

1)卡片

卡片的概念來自我們在前互聯網時代用來尋找書籍的圖書館卡片,它們包含了作者、書名和簡短的摘要。

Ron認為類似的卡片可以用來寫一個軟件系統新功能的簡短摘要,卡片引發了對話,它可以包含 “作為用戶,我想,以便…” 這樣的模板,但最好給它一個簡短的自我說明的標題。

以免出現類似這樣的積壓:

積累的用戶故事都是相同的標題…更何況,你有沒有遇到過,在每天的工作中,有人用編號來指代用戶故事,而不是標題呢?

這時候我們就知道,我們扼殺了這個故事,不是嗎?這可能是因為標題太長,讓人摸不著頭腦(請看上圖),我們可以通過添加一個簡明扼要的標題來輕松解決。

對于我們基礎篇的例子:作為一個手機用戶,我想查看所在位置的天氣預報,以便我不用每次去一個新地方都要查天氣預報。

這個故事的標題可以是:當前位置查詢天氣預報。

2)對話

我們說過,上面的卡片可以作為產品負責人與開發團隊對話的起點,以實現對將要構建什么的共同理解。

所以他們見面后會講故事,講誰會使用這個產品,他們想要什么,為什么;首先,把注意力放在最重要的事情上,后面再討論實施細節。

首先我們為什么要構建它?想一想什么對你的業務影響最大,對用戶的結果最好。

用戶為什么需要它?而我們作為企業又為什么要讓他們使用它?對我們有什么好處,商業價值是什么?

有了這些,你就可以建立最小可行產品(MVP),來檢驗什么產品在市場上是最小的、有用的。

如果你心中有一個偉大的想法,你可以把目標、偉大的想法與團隊分享,并協同為它想出故事。

這些都可以在用戶故事地圖工作坊中完成,因為這是一個讓整個團隊參與產品創作的好方法;對于較小的想法,在對話之后,我們進入第3步。

3)確認

確認的作用是記錄談話過程中發現的問題,并商定如何驗證它的有效性;例如,在故事中加入驗收標準。

2. INVEST

我們如何確保我們的故事已經具備進入下一個沖刺的條件?

讓我們看一個簡單的技巧,它將確保我們的故事已經準備好了。

它叫INVEST,是一個縮寫,它定義了一個偉大故事的6個特征:

  • I – 獨立
  • N – 協商
  • V – 價值
  • E – 估算
  • S – 小型
  • T – 測試

讓我們看看另一個用戶故事的例子,檢查它是否符合這些特征:

作為一個彩民,我想在網站上輸入我的彩票號碼,以便檢查我是否中獎以及中了多少錢。

1)獨立

意味著它可以獨立完成 – 沒有阻塞依賴性;例如,我們不需要登錄系統來驗證我們的號碼是否中獎,這意味著它可以與我們已經在系統中的內容分開獨立工作。

2)協商

用戶故事中的內容并不是固定的,它是活的文檔;當我們在開發過程中發現更多的東西時,它可能會改變,然后開發團隊會和產品負責人協商。

3)價值

意味著為用戶提供價值。因此是 “作為用戶我想要”,而不是 “作為產品負責人我想要” 或者 “作為開發者我想要”;除非你是為產品負責人和開發者構建工具。

為了讓它變得有價值,我們要把故事想象成一個蛋糕,你想要切開蛋糕,嘗到所有層的味道,而不僅僅是鮮奶油;軟件開發也是一樣,你要讓用戶品嘗到所有平臺的味道,而不僅僅是后端或前端。

我們不會給用戶看一個假的按鈕,說 “檢查你是否中獎!” 如果背后沒有邏輯,這個按鈕沒有用。

我們需要問自己:我們如何為客戶提供價值就能在我們的故事完成后直接讓他們使用新功能?

4)估算

通常越小越容易估算,越可測試越容易估算。為什么要估算?

如果我們能估算一個故事,就說明我們對它有足夠的了解,它是可行的,我們不知道的事情就不去估算;如果我們不能估算我們的故事,它肯定需要更多的討論,更多的細節,或者更多的研究。

5)小型

在敏捷開發中,它意味著適合一個沖刺,甚至更少;故事越小,越容易把握故事的內容,小的特征與有價值的特征關系非常密切。

如果你想把故事切成多個小故事,你需要確保所有的故事都能為用戶提供價值;就像一塊蛋糕,你在生日派對上為你的客人提供服務 – 所有的蛋糕都有所有層的味道,這就像我們的軟件平臺。

現在,想象一下,我們的彩票故事不適合在一次沖刺中完成。

我們可以做什么?也許可以分成2個小的故事,每個小的故事都可以為我們的用戶提供價值。

第1個故事會檢查是否中獎:作為一個彩民,我想在網站上輸入我的彩票號碼,以便檢查我是否中獎。

標題可以是:彩民可以查詢自己是否中獎。

第2個故事會查詢中了多少錢,前提條件是有中獎號碼:作為一個有中獎號碼的彩民,我想在網站上輸入我的彩票號碼,以便查詢我中了多少錢。

標題可以是:彩民可以查詢自己中獎號碼的獎金數額。

這樣我們就可以在第1個故事完成后,更快地為用戶提供價值;而且我們可以更快地了解有多少用戶對使用新功能感興趣。

6)測試

如果我們知道如何測試它,我們就會知道它何時完成。一個常見的做法是在故事中添加驗收標準;這些都是一些用例,可以確定軟件做的是它要做的事情。

驗收標準提供了功能場景,測試部分包括檢查邊緣用例、“悲傷路徑” 場景、非功能測試(如性能)等。

每個故事都有一些具體的驗收標準來幫助團隊把握新功能需要實現的目標;然后,是團隊一致同意的完成標準,它規定了每個用戶故事在上線前需要滿足的一些通用標準。

我們先給彩票例子中的第1個故事添加一些驗收標準:

作為一個彩民,我想在網站上輸入我的彩票號碼,以便檢查我是否中獎。

驗收標準可以是:

  • 如果這個號碼是中獎號碼,用戶應該看到一條信息:“今天是你的幸運日,你中獎了!”
  • 如果該號碼不是中獎號碼,用戶應該看到一條消息:“再試一次,我打賭下次你一定會贏!”

對于第2個故事:作為一個有中獎號碼的彩民,我想在網站上輸入我的彩票號碼,以便查詢我中了多少錢。

驗收標準如下:

  • 如果用戶中獎了,中獎金額應該以貨幣格式顯示。
  • 用戶只能查詢過去30天的中獎號碼等。

給定/當/然后是一種Gherkin語言格式,用于編寫驗收標準和自動化測試,它來源于行為驅動開發(BDD),例如:給定用戶一個中獎號碼,當用戶在網站上輸入該號碼,然后中獎金額就會以貨幣格式顯示。

如果你運行了一個帶有自動測試的工具,比如Cucumber,那就特別有用;同樣,就像用戶故事模板一樣,這種格式是可選的。

完成標準:如果我們的彩票頁面要求適配手機,并且有三種語言版本,這些通用要求可以作為我們完成標準的一部分。

四、總結篇

用戶故事是為了鼓勵團隊內關于產品的對話,這些對話集中在三個最重要的事情上:誰會使用產品,他們會用它做什么,以及為什么。

拆分用戶故事可能很復雜,但不用擔心,你可以通過實踐掌握它,有很多技巧也可以幫助你。

 

原文鏈接:

https://uxdesign.cc/the-story-of-user-stories-part-1-e1c8e4995f7f

https://uxdesign.cc/user-stories-in-practice-part-2-8b731566f8ca

原文作者:Maria Chec

譯者:產品俠,服務設計碩士在讀,產品經理實習生,英語愛好者;微信公眾號:產品俠

本文由 @產品俠 翻譯發布于人人都是產品經理。未經許可,禁止轉載

題圖來自 unsplash,基于 CC0 協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 很有針對性,用最簡單的話講明白了最核心的工作

    回復
  2. 竟然沒懂

    回復