使用者故事對照/地圖演講摘要 (User Story Mapping)

摘要：
「使用者故事地圖」是一種資訊架構。其目的是讓人們在設計的過程中更容易「透過溝通來建立共識、對系統有全盤理解」。結構的設計讓人可以持續修改、組織、引用、溝通設計的想法，重視呈現每個想法間的相互關係。是「便利貼技巧」+「使用者中心設計」+「敏捷開發」的整合運用。
—
講者：Jeff Patton, 來自敏捷的社群、當過軟體工程師、專案經理。

在當專案經理的時候，接觸到使用者故事 (user story)，當時覺得這個名字很蠢，為什麼要用這個字。過了十年之後才了解故事(story)的意義。故事地圖(story map)是一個說大故事的簡單方法、它把大故事分解成更小的部分。然後對每個部分，實作的人會加上更多的細節把產品做出來。


我從2000年就開始用故事 (story) 這個字。故事這個字從一開始就被誤解，我接下來會說明故事代表的意思。故事會解決軟體開發中兩個問題，但這兩個問題都不是寫更好的需求 (requirements)。

第一個問題：寫文件沒啥用 (Documents - just don’t work)
第二的問題：太多東西要做 (Too much to build)


想像一個簡單的電話對話。blah blah 講了光靠電話描述，麵包店做出了許多奇怪的蛋糕。類似事在軟體公司也經常發生。文件寫完之後，做出來的產品就是不對。這邊的問題是，當我們分享、同意和簽署的文件，我們只能相信每個人是理解的(意指每個人其實理解的都不同)。之後 Kent 就想出了解決文件問題的方法，那就是不要寫、不要交換文件。用「告訴我你的故事」取代：如果我們能直接討論這個，我們可以一起想辦法 (figure it out together)。

如果你想說什麼，寫在一張卡上。然後你會找到負責實作的人，一起討論、知道到底做出來會怎樣。用故事這個名字的原因來自「我們怎麼使用它」(how we use them) 而不是「我們怎麼寫它」。有多少人用 Scrum？backlog? 問題在現在的 Scrum 會議中，許多人來參加、許多人都在做自己的事，「故事」本來想要帶入的有效溝通早就被忽略了。常常的情況是幾個人會說話，大部分人就只是在聽、在發呆，沒有相互溝通每個人理解到的是什麼。因為每個人心中的思考是無法被觀察的，只有當我們說出自己的思考、畫些圖片，我們才能察覺到每個人思考的差異，這時候我們才能真的達成共識 (really get it)。如此在這個會議之後，當我們說到同樣的東西，才會代表同樣的意思、代表同樣的事情。不然會議中的共識，其實完全沒有達到共識。

光分享文件、並沒有分享理解 (Shared documents aren’t shared understanding)

透過文字、圖片的討論會讓每個人建立共同的理解。在 Atlassian，他們在牆上貼的不是工作列表，他們把那些放到 JIRA 軟體。他們貼在牆上的是一堆便利貼 / 草圖 / 線圖稿，每個都代表一個故事。他們討論故事。每個團隊，都有各自的故事們，然後做站立會議中，他們指著牆上的便利貼說，我今天做這個 JIRA Ticket。指的同時也指出了這個 JIRA Ticket 在整個大故事的位置，回憶起細節、為什麼現在要做它。那張便利貼就像一張在夏威夷的照片，你可以說出照片外的細節，因為便利貼是你們一起討論出來的。

第一個問題的解法：我們靠說故事 (story telling) 來建造共同理解 (shared understanding)

---
我們的工作不是建造軟體，我們的工作是改變這個世界。這聽起來也許有些誇張。但這邊我們講的不是世界和平、非洲的飢荒之類的事。這邊說的世界指的是我們身邊、我們有能力去改變的事。這個世界的邊界是我們的產品，透過看著會使用產品的人，我們有了新的想法，產生新的需求。需求 (requirements) 的目的就是我們背後有了好想法能夠幫助用產品的人。把現在的世界畫一個圈，有產品後的新世界的畫一個圈，我們要觀察現在世界的產出(output)、新世界有這個產出後的結果 (outcome)，像是產品的使用心得、影響 (Impact)。先前說的想法 (idea) 的問題是「每個人都有想法」。所以每個人的想法就會轉成越來越多的事情要做。我們的目標不是加快產生出垃圾(our job is not to build more crap faster)，我們的目標是做更少的產出 (our goal is to build less)。當你做更少的產出，你試圖最小化產出 (output) ，同時最大化結果 (outcome) 和影響 (Impact)。

之前工作的時候，知道了下一次產品發行的需求列表後，去問他們「使用者是誰？解決了使用者什麼問題？」。得到的答案是：「這些是需求 (requirements)」，當時我就知道需求還有另外一個意思 — 那就是閉上嘴 (shut up)。他們真的以為需求列表，就真的如同字典上的意思代表了必須要做的事。實際上它們並不是... 因為不可能實作所有的需求，光只有需求沒法最小化產出、最大化結果。故事是需求 (requirements) 的解毒劑。

引用 Kent：「軟體開發已經被需求 (requirement) 這個字導入的錯誤的方向，這個字在字典裡被定義為需要做的事 (something mandatory or obligatory)。這個字帶有絕對和永久的一役、抑制了擁抱變化。需求 (requirements)這個字完全是個錯誤」 

我們要說誰做什麼、怎麼做、為什麼做 (talk about who doing what and why)。討論和協作要專注在誰會用這個產品和他們拿到這個產品之後會怎麼使用它。基本上，你必須要想通整件事。舉了一個漂亮的嬰兒形狀蛋糕的例子，蛋糕看起來很漂亮，但要吃的時候就必須把嬰兒切開，這應該是沒有把事情想通的做法。


第二個問題的答案是：透過理解產品是為了誰、做什麼、為什麼這樣做，來最小化產出。


如果正確的使用故事，就可以解決這兩個問題。

但我們會碰到一個問題，很多很棒的想法，怎麼轉變成 scrum 中開發的故事裡 (1~3天可完成、可被估計、可測試、可被展示...)。這邊講一個故事，Rachel 是90年代的一個專案經理，當他去跟工程師問說每個的工作項目是為了誰、為什麼要這樣做的同時？發現工程師瞬間就開始說這個東西好像不是一定要做、也許在別的地方做會更好。很多人根本就沒把事情想通。於是，Rachel 就寫了一個聰明的溝通小卡：

標題：寫一個好的故事
As (who) to (do what) so that (why) 的例子，當作一個容易開始討論的起點 (conversation starter)

就這樣定義出了常見使用者故事的格式(story template)，但如果用這個格式當作 scrum 中的 backlog 項目，應該會覺得有些卡卡的，因為這個格式本來不是拿來這樣子用的。它本來是在探索階段，拿來引導討論那些大的好想法的，那些要被分成更多 backlog 的項目。

這邊舉了一個 Gray 用敏捷開發流程開發音樂服務網站的例子，Gray 把所有要做的代辦事項排序之後，就從最優先的事情開始做，進度一直都有進展，但一段時間過去，開始覺得事情做不完，而且無法估計什麼時候整個系統可以上線完成。Gray 這時候就問了，有沒有其他不用敏捷開發流程的方法。這是我碰到他當時的情況。我們一見面談的不是開發方法，而是討論定義想法(Frame the idea)、為什麼要做這個產品、對使用者的了解、使用者的目標是什麼。開始討論想法，寫下想法在便利貼上、移動想法、組織想法。討論使用者一整天會怎麼使用這個產品。Gray 說、然後我用便利貼紀錄下來，這是 Gray 第一次看到整個產品看起來會是怎樣子。之後才開始探索細節，分成更多步驟、替代方法、UI的設計、技術細節。之後就可大概估時間，挑出核心的部分來做，發現這些核心都是之前用待辦事項開發幾個月沒做的部分！！！之後這個產品就順利上線了～

以上是影片前55分鐘的摘要，後來開始用影片舉例子，還是直接看影片吧~
你會看到許多使用者故事地圖開發的過程和樣子。後來還有說 MVP 的概念，提早驗證、提早學會。把 MVP 分成數個階段，讓每個階段都能透過驗證來學習、改變產品方向。和一些其他秘訣... 像是油畫草稿和 protyotyping和迭代的重要性。

作者的總結：
1. 改變你工作的方式：跟別人說故事，而不只是寫故事
2. 用簡單的視覺化去代表你說的故事
3. 要把整個故事都放到地圖上，來找出最重要的部分
4. 把事情想通：減少產出、增加結果和影響
5. 建立最小可行產品測試，來學到什麼是市場中最小的和可行的
6. 用疊代和漸進的(原型 / 草稿式)的方式來建造產品

有效率的故事們能幫助每個人朝向產品成功而工作

Q & A 從一小時二十分開始
—
就結構來說是把敏捷開發流程中的待辦事項列表用一個某種可變網狀系統資訊結構取代。