HPX 104.5 《使用者故事對照》導讀

1. 《使用者故事對照》導讀
A Glance at Agile, Scrum & User Story
Jenson Lee
May 7, 2019

2. 我是誰？
● Jenson Lee
● CSM（認證 Scrum Maser）
● CSPO（認證 Scrum Product OWner）
● 叫車吧 - 產品經理
Product Owner / ScrumMaster
● HPX 94.5 產品經理讀書會引導者
● 台灣敏捷社群志工
● 2018 Agile Tour Taipei「問題解決導向的用戶訪談工作坊」講師

3. Agile & Scrum
User Story Mapping

4. ⼤家知道的 Agile

5. 瀑布式開發法

6. ⽼闆都愛⽢特圖

7. 你的產品在哪裡︖

8. ⼀種迭代⽅法

9. 蓋⼀台⾞，或交通⼯具

13. 需求探索歷程

14. Agile & Scrum
User Story Mapping

15. The Wrong way to do Agile: Specifications

16. 客製化蛋糕
❖ 「您好，我想要訂個蛋糕。」 <——— 產品
❖ 「請幫我在上⾯寫下紫⾊的 <——— 需求描述
“So long, Alicia”」
❖ 「周圍再⽤⼀些星星點綴」 <——— 補充說明

20. 「我們產品的使用者應該是25
歲左右，喜歡逛街的女性，所以
我們應該增加女性購物專區。」

21. 「身為一個 25 歲、收入約
30k 以下小資女，我想要在網
站首頁有個女性專屬平價服飾
的區塊，這樣我可以更快速地
找到我想要買的衣服。」

22. As a [type of user],
I want to [do something]
so that I can [get some benefit]

24. From David Ko - user story mapping workshop

25. From David Ko - user story mapping workshop

26. 練習：線上訂房服務

29. 「採用使用者故事的目標
不是為了寫出更好的使用者故事」

30. 分享文件（shared docs）
不是分享共識（shard understanding）
「運用使用者故事的真正目標是達成共識」

31. Agile & Scrum
User Story Mapping

32. 推薦序
• 為什麼要導讀推薦序？
• Martin Fowler，「敏捷軟體開發宣言」17 位共同發起者之
一。
• Alan Cooper，Visual Basic 之父，「Persona」的發明者。
• Marty Cagan，Netscape VP Platform & Product，eBay
SVP Product & Design

33. Martin Fowler
• 敏捷開發帶來的潛在問題：失去整體概觀（big picture）
• User Story Mapping 是彌補此缺點的技術
• 整體圖像促進對話，幫助我們與使用者溝通，避免建造不
必要功能
• 充分溝通是團隊關鍵價值

34. Alan Cooper
• 開發者總是製造出科學怪人。
• 互動設計師與程式開發者各擅
勝場，卻缺乏共同語言。
• 敏捷開發並非好的設計工具。
• 透過 User Story Mapping 開
啟對話，保留敘事結構。

35. Marty Cagan
• Good Product Manager/Bad Product Manager by Ben
Horowitz https://www.evernote.com/l/AERyPcfK-
gdBuJvx4Nun7BmA6ulimXViPcM
• 好團隊與壞團隊的差別。
• 這⼀切都跟 Story Mapping 息息相關。

36. Why Should You Read This Book?
• 使⽤者故事聚焦建造⼩東西，看不⾒整體圖像。
• 何時結束︖交付什麼產品︖
• 對話過程中的討論與共識被遺忘。
• 沒有共識，導致影響時程。
• 使⽤者看不⾒的部份如何撰寫使⽤者故事。

37. Why Docs?
• 好⽂件就像度假照⽚。
• 對話與互動產出⽂件，才是⽂件的核⼼精神。
• 重要的不是什麼被寫下來、⽽是閱讀它時會記得什麼。
• 以⽂件幫助記憶。

38. 「產品開發的⽬標不是為了製造產品」

39. Change The World
• Now and Later
• ⼈們因為你建造的產品⽽
變得開⼼。
• Output(X) vs. Outcome(O)
• What about my company?
The Impact!

40. Build Less Stuffs
• 我們要建造的東西總是
超過我們擁有的時間。
• 輸出 (output) 最⼩化、
成果 (outcome) 與影響
(impact) 最⼤化。
• 提昇建造速度無法解決
問題。

41. Requirements
「需求」只是⽤來阻⽌我們針對⼈們以及要解決的問題進⾏對話。
你的任務不是實現需求、⽽是改變世界。

43. AgileCommunity.tw
https://www.facebook.com/AgileCommunity.tw/
Scrum Community in Taiwan
https://www.facebook.com/groups/179345672472/
台灣敏捷社群 ＠ Facebook

46. 延伸討論
• 我身邊的好團隊與壞團隊
• 我的公司 / 職位 / 領域適合使⽤ User Story Mapping 嗎︖
• 如何開始使⽤ User Story Mapping ︖
• 敏捷開發與 User Story Mapping 的關係︖
• ⽣活中的 output 與 outcome
• 為何要使⽤便利貼︖