SlideShare una empresa de Scribd logo
1 de 31
Descargar para leer sin conexión
Agile Tour Hsinchu / Taichung
User Story 的那些人與那些事
Yiching
Agile Tour Hsinchu / Taichung
2017
Agile Tour Hsinchu / Taichung
為何需要說「故事」
● 科技帶來大量的資訊,因此需要將資訊轉換成
容易理解的「故事」,幫助我們傳達資訊,以及
幫助自己做出選擇。
● 影響他人最有利的手段,就是讓他親身體驗。
一個故事就是一個「重新想像的體驗」,因此要
聚焦在具有影響力和改變人們觀念的故事。
● 故事思維能夠幫助你和不同想法的人溝通自
如,讓人們保持相同的看法。
Agile Tour Hsinchu / Taichung
Agenda
● 什麼是 User Story
● 如何描述 User Story
● 何謂好的 User Story
● 非開發團隊對撰寫 / 管理 User Story 的問題
● 開發團隊對導入 User Story 的問題
● Q & A
Agile Tour Hsinchu / Taichung
什麼是 User Story ?
● 卡片 ( Card ):
○ 用一張卡片的大小 簡短描述用戶需求
● 交談 ( Conversation ):
○ 重點在於透過 User Story 作為溝通基底,而非直接交棒
● 確認 ( Confirmation ):
○ 可透過 User Story ,透過用戶角度來進行驗收,看有沒有達到他們的需求
卡片並非 User Story 本身
真正的 User Story 包含在整個軟體開發流程的討論中
(在進 Sprint 前需要不斷 拆解/分析/更新)
Agile Tour Hsinchu / Taichung
User Story 是什麼 User Story 不是 什麼
需求端 跟 實作端 溝通的基底 清清楚楚、一次定案的文件
描述需求與價值的工具 描述詳細實作內容的 Spec
任何人都可以參與與撰寫的工具 專屬於 Agile Team 的溝通工具
客戶的聲音與潛在需求 PO 的許願池
Agile Tour Hsinchu / Taichung
任何人都可以撰寫 User Story ?
對,任何人
但要由負責人(PO)負責把關與排序
1. 非 Scrum 團隊的人更有機會接觸 User (ex: 業務、客服、研究人員等)
2. 開發團隊對產品有想法也可以透過 User Story 提出
3. 如果由 PO 當單一窗口,資訊量太大,而且沒有 write down 的東西容易不見
Agile Tour Hsinchu / Taichung
如何描述 User Story
As a <role>, I want to <do something>, so that I can <get value>.
身為一個<角色>,我想要<做某些事>,以至於我可以<有什麼價值>
角色
功能或
目標價值
Always starts from “User”
Main point of user story
Agile Tour Hsinchu / Taichung
可以不用套用公式嗎?
可以
但有前提!如下
1. 確定相關人員(Scrum Team, PO, Others)都能掌握需求與 Use Case
2. 確定溝通的「故事」內容可以驗收
3. 僅適用於短期內的快速迭代與需求釐清,不然討論的脈絡容易遺忘,又沒有依照
公式寫下來, 長期累積會是很重的資訊負擔。
Agile Tour Hsinchu / Taichung
“User” First 才是 User Story
已知的 User (實際用戶) 假想的 User (Persona)
Agile Tour Hsinchu / Taichung
三步驟建立 Persona
1. 內部先假想一個 proto-persona
2. 針對幾個 Persona ,透過 User Research
蒐集相關資料
3. 蒐集 Persona 時可關注的內容
a. 主要關注:動機、痛點、需求、目標
b. 次要關注:能力、Life Style、個性、社經地位
c. 以上可依照產品特性調整
4. 整理分析資料,並修正 Persona
a. 大幅更動:親合圖(Affinity Diagram)
b. 小部分修正:修正 Diagram 並記錄
5. Persona 不會完美,因此要不斷輪迴
Proto-Persona
User ResearchUpdate Persona
Agile Tour Hsinchu / Taichung
User Research 方法
http://www.uisdc.com/tencent-user-research-method
研究人員常用方法 非研究人員常用方法
● 相似產品的產品/商模解構
● 相似產品線上討論串分析
● 客服人員檔案紀錄
● 第一線人員的二手資料(業務、行銷)
● 跟第一線人員出門取得一手資料
● 其他...
p.s. 任何可以取得用戶 / 潛在用戶的
行為
想法
痛點
需求
都是可行的方法
Agile Tour Hsinchu / Taichung
範例:卡片管理系統
User:Product Owner、Developer、Scrum Master、User Agents (Sales, Account
Service, UX, QA, other stackholders...)
● 身為一個 Sales,我想要在再次接觸 User 前知道需求什麼時候會被實現,以至於我面對 User 時能夠給合適的答覆。
● 身為一個 Product Owner,我想要清楚地透過卡片看到產品全貌,以至於我可以掌控產品的進程。
● 身為一個 Developer,我想要在 Sprint 開始之前確認此 Sprint 的產出,以至於我在這 Sprint 可以專心衝刺。
● 身為一個 Scrum Master,我想讓 PO 透過 User Story 開需求,以至於讓 Team Member 確認實作此張卡片的價值。
若是 User 是 Persona,PO 需代表這位 User 被詢問
PO 要使用者上身
Agile Tour Hsinchu / Taichung
何謂好的 User Story (INVEST)
https://www.linkedin.com/pulse/20140914070127-13798802-scrum-developing-epic-s-and-user-stories
Agile Tour Hsinchu / Taichung
很難撰寫好 User Story 的原因
● 非開發團隊 很難理解需求是否獨立
● 撰寫時落入 Spec 細節,不易進行討論
● 通常是假設性的,因此不確定此價值是否存在
● 非開發團隊 很難理解何謂『可估計』的大小
● 非開發團隊 很難確認此需求是否『小』
● 非開發團隊 很難理解何謂『可測試』(此項目可由
Story 的相關資料補充,非 User Story 本身)
Agile Tour Hsinchu / Taichung
但通常需求都來自 非開發團隊
如果 PO 也是非開發團隊(背景)的話,上述問題會更頻繁
Agile Tour Hsinchu / Taichung
非開發團隊對撰寫/管理 User Story 的問題...
● 不知道該怎麼樣寫,故事大小才適合
○ 如何切分 Story
● 故事之間有相依性,不知道怎麼管理這些需求
○ 如何管理 Story 的相依性
● 不知道該怎麼樣把 User Story 轉換成工程師可以實作的設計或 Spec
○ 如何將 Story 轉換為 Spec
● Story 越來越多,還有 Bug 要修,不知道該怎麼管理這亂無雜章的需求
○ Theme, Story, Task, Bug 如何統合管理
● 如果是底層優化的情況下,如何撰寫 User Story
○ 產品架構或效能該如何寫成 Story
Agile Tour Hsinchu / Taichung
如何切分 Story 的大小
● 根據 INVEST 原則
● 雖然撰寫卡片時通常是闡述「一個價值」
,但以開發來說可以是以一個 Output 為
原則,因此商業上的「一個價值」,對開發
來說可能是好幾張卡片
● 一個 Output 範例:
○ 一個 Process
○ 一個 API
○ User 操作一個行為的結束
● 若一個 Output 估點太大,可以再細拆為
Task 估點
Agile Tour Hsinchu / Taichung
如何管理 Story 的相依性
● User Story 不應該有相依性,但有時
候不得不有相依性,例如:
○ 使用者新增帳號 / 管理員凍結帳號
● 視為一個帳號生命週期管理的 Story
● 透過管理工具標註相依性。
○ 例如後置卡片放在 Pending List 並且標註前置
卡片的狀態或連結。有相依管理的工具
● 相依性規模大的,先使用 UML 圖例
說明。除了電子化管理工具外,建議
使用實體化視覺管理。
Agile Tour Hsinchu / Taichung
如何將 Story 轉換為 Spec
● Story 跟 Spec 是完全不同的東西,Story 闡述價值,而 Spec 闡述實作內容,一
定要先有 Story (闡述商業價值) 才會有 Spec (有價值才做)。
● 通常 Spec 也就是 Acceptance Criteria (驗收標準),必須要可被測試
● 從 Story 當中可以聞到需要產出的 Output 類型,不同的 Output 類型有不同的
Spec,大致可分為 Process, API, UI 三種類型,各別的 Spec 可以是:
○ Process:流程圖、結果文件
○ API:Input parameter + type / Output parameter + content
○ UI:UI Flow
○ 簡單且通用的 Acceptance Criteria 可用:Given-When-Then BDD Method(又是大題目XD)
Agile Tour Hsinchu / Taichung
Epic, Story, Task, Bug 如何統合管理
工具 創意 透明 利害關係人管理
● 用適合的工具管理不同的需求
● 工具是不完美的,要靠自己的創意使管理更流暢 +方便
● 在管理需求的同時,要讓大家知道目前這些 ”待辦事項”的現況
● 管理你的需求來源,避免不必要的紛爭(很重要 XD)
Agile Tour Hsinchu / Taichung
產品架構或效能該如何寫成 User Story
● User Story 是 User 觀點,若單純是技術或架構議題可另外寫 “Technical Story”
● Technical Story 可用於很多不同地方,例如:
● Technical Story 沒有一定的寫作格式,但大部分會有驗收標準。
● Technical Story 不一定會 Demo Story,但會有額外的分享會。
http://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how
Product Infrastructure
Team Infrastructure
Refactoring
Bug Fixing
Spikes
Agile Tour Hsinchu / Taichung
Q:怎麼知道卡片是 Epic, Story 還是 Task ?
● Epic 沒有明確的 Output
● Story 是 end-to-end 的一個 Output (動作/流程/API)
● Task 是完成上述 Output 的工程步驟
● 如果不熟 User Story 也不一定需要 Fit Level,只要可以知道怎麼驗收即可。
Q:有需要將卡片拆小來符合一個 Sprint 的長度嗎?
● 以 Scrum 的方式來說,是。
● 以一般專案管理角度,如果卡片的範圍不能拆小,那就是 Time Box 要拉長。
Q:拆解後的卡片怎麼做如上圖的階層對應關係?
● 以方法來說,User Story Mapping 可幫助大型系統的 Epic - Story 對應。
● 以工具來說,目前看到最完整的應該是 Agile for Jira。但操作很複雜。
● 沒有標準的 Scrum,也就沒有標準的管理卡片方式,也就沒有最適合又好用的工具,最好自己寫一個 XD。
Q:如果 Story 實作起來很複雜,該怎麼拆分為 Task?
● 如果是底層不完善造成實作複雜,先獨立出 Technical Story。
● 如果是 Story 的實作功能影響範圍很廣,拆 Task!
● 如果是 Story 本身功能很大,拆成小 Story!
想像的一些其他問題...
Agile Tour Hsinchu / Taichung
開發團隊對導入 User Story 的問題...
● 如何讓 PO 願意寫 User Story
○ 如何讓 PO 願意 / 學會寫 User Story ?
● 如何彰顯 User Story 的價值(關注在需求價值而非規格)
○ 如何讓其他人確信 User Story 有幫助
● 如何避免直接寫 Spec,關注在需求與價值上
○ 如何讓 非開發團隊 撰寫好 User Story
● 無法很持久的寫 User Story,最後都只寫想要的功能
○ 如何讓 非開發團隊 撰寫好 User Story
● 如何協助 PO 管理需求
○ Scrum Master 如何導入 Agile 需求管理
Agile Tour Hsinchu / Taichung
如何讓 PO 願意寫 / 學會寫 User Story
如果 不是 真 PO(代PO)
It’s hard for himself / herself
如果 是 真 PO
It’s hard for you
Agile Tour Hsinchu / Taichung
代 PO 篇
● 代 PO 的困難點
○ 他自己不是需求來源,所以不一定能完全傳達 Story 的價值
○ PO 如果是由 Project Manager 轉任,還停留在 Scope-Resource-Time 的管理,而非產品成敗
○ PO 如果是由 RD Team Leader 擔任,但該 Team 不是 Project Driven,而是 Functional Team
● 如何幫助 他/她
○ 可以請 PO 嘗試寫下 User Story,幫助 Scrum 團隊運轉,並學習 PO 思考模式
○ 讓這個 User Story 放在真 PO 看得到的地方,並適時邀請他參與會議
○ 基本上需要 Empower PO,但這是組織轉型議題,已遠遠超出今天的 內容 Orz
Agile Tour Hsinchu / Taichung
真 PO 篇
● 你的困難點
○ 傳統 SDLC 的 PM 習慣直接寫 Spec,User Story 不能直接交棒會沒有安全感
○ 解釋 How 比解釋 Why 容易多
○ Agile 精神還未萌芽,沒有 Iteration 的概念,停留在傳統 SDLC 只有 Spec 沒有 Story 處境
○ 真 PO 如果是老闆不太可能請他自己寫 Orz
● 可以怎麼做
○ 這是軟體開發流程的改變,基本上也是組織轉型議題,已遠遠超出今天的 內容 Orz
○ 如果真 PO 很遙遠,可以請窗口佔代 PO,寫出 User Story
○ 灌輸真 PO User Story 的價值,並且手把手教他寫
Agile Tour Hsinchu / Taichung
如何讓其他人確信 User Story 有幫助
● User Story 需要被團隊成員檢視,並給予回饋
● 需求端撰寫 User Story 時,可以將該需求的 來由 附註上去,以便共同討論
● 最好把 PO 的老闆(或 sponsor)也拉進來,共同檢視該 User Story 的價值
● 當該 Story 在被處理時,要告知需求端,以增強他下次開卡的動機
● 強烈要求『 沒有 Story 就沒有 Spec 』
Agile Tour Hsinchu / Taichung
如何讓 非開發團隊 撰寫好 User Story
初級階段:
1. 由開發團隊蒐集需求並撰寫,撰寫完請 Owner 確認
a. 雖然書上都說這樣不好,但在推廣階段 SM 很常做這件事
b. User Story 實際上散佈在各個會議中,開發團隊需要有窗口去打探需求們
2. 他們願意寫就謝天謝地了,不逼迫、不強求,有寫總比沒寫好 (這是真的!)事後再由開發團隊修改並
請 PO 確認
a. 『可溝通』都是好 Story,不打擊他人士氣,協助引導撰寫更優秀的 Story
b. 使用『comment』而非修改 ; 多以『鼓勵』取代『訂正』
進階階段:
1. 安排顧問(通常是 SA)為技術窗口,協助非開發團隊撰寫 User Story,或確認 User Story 合適性
a. 前提是 非開發團隊 已習慣撰寫 User Story 這個工作
b. 如果 PO 對產品實作不熟,此時 SA 需與 PO 緊密合作,讓 PO 升級
終極階段: PO 可以自行分析並撰寫 User Story ,協助轉換其他人的需求並排序(完美的 PO存在)
Agile Tour Hsinchu / Taichung
Scrum Master 如何導入 Agile 需求管理
● PO 最重要的工作,是「開需求」與「需求排序」,但是讓 User Story 適合進入細節
討論之前要先做 Story 的檢視跟拆解
● 如果 PO 對 Story Board 管理不熟,SM 要時常由共同會議幫助 PO 疏理 Story
Board,Backlog Refinement Meeting 是好時機
● SM 要時常提醒 PO 撰寫 User Story,並且自己要時常關注每個 Story 的狀態
● 適時將 Story Board 的管理交棒給 PO 本人,SM 作為支持角色
Agile Tour Hsinchu / Taichung
Q:Story 無法估點怎麼辦?
● 不知道怎麼實作:先來個 spike 研究看看
● 不確定實作過程會不會有問題:依照以前的經驗粗估,學習到之後下次就會估了 XD
Q:Story 的驗收標準(Acceptance Criteria)由誰寫?
● 一般來說是 PO 確認(Scrum Team Support),但如果是 Technical Story ,由 RD Lead 或 SA 寫
Q:要怎麼確認 PO 開的需求是真的?
● 可以在 User Story 的卡片內附註為何有這個需求,用來確認是否該問題可以用該 Story 來解決
● Scrum 的 Concept 基本上一切要「相信 PO」,有疑慮可以請他們提出一些證明
● 產品成敗 PO 扛,所以不相信 PO 的話就請老闆施以壓力,或換團隊 ...
Q:要怎麼樣練習寫 User Story,而不會開成 Spec?
● 目前的 User Story 撰寫方式的確很容易開成 Spec,以至於忽略其他可能的實現方法
● 可以將 I want to <do something> 改為 I want to <get my goal>,另在驗收標準中討論實現方式
○ Spec => 身為一個求職者,我想在搜尋篩選器多一個學歷的選項,以至於我可以篩選出符合我學歷的工作。
○ Story => 身為一個求職者,我想要找到符合我學歷的工作,以至於我可以縮小合適的職缺範圍。
想像的一些其他問題...
Agile Tour Hsinchu / Taichung
Q & A

Más contenido relacionado

La actualidad más candente

從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)
從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)
從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)William Yeh
 
User Story Mapping Workshop
User Story Mapping WorkshopUser Story Mapping Workshop
User Story Mapping WorkshopDana Pylayeva
 
A crash course to user story mapping
A crash course to user story mappingA crash course to user story mapping
A crash course to user story mappingFrances Place
 
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキTakao Oyobe
 
如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致Jen-Chieh Ko
 
Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法Hidehisa Matsutani
 
User Story Mapping, Discover the whole story
User Story Mapping, Discover the whole storyUser Story Mapping, Discover the whole story
User Story Mapping, Discover the whole storyJeff Patton
 
How to Organize a User Story Writing Workshop
How to Organize a User Story Writing WorkshopHow to Organize a User Story Writing Workshop
How to Organize a User Story Writing WorkshopJeff Lopez-Stuit
 
敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊William Yeh
 
User Story Slicing - easy way to split user stories
User Story Slicing - easy way to split user stories  User Story Slicing - easy way to split user stories
User Story Slicing - easy way to split user stories Arto Eskelinen
 
Workshop - Writing Good User Stories
Workshop - Writing Good User Stories Workshop - Writing Good User Stories
Workshop - Writing Good User Stories Easy Agile
 
Writing Effective User Stories
Writing Effective User StoriesWriting Effective User Stories
Writing Effective User StoriesJaneve George
 
User story concept for agiletourkaohsiung
User story concept for agiletourkaohsiung User story concept for agiletourkaohsiung
User story concept for agiletourkaohsiung Jen-Chieh Ko
 
User story and splitting workshop
User story and splitting workshopUser story and splitting workshop
User story and splitting workshopBrian Sjoberg
 
Story maps and personas an intro
Story maps and personas   an introStory maps and personas   an intro
Story maps and personas an introMark Kilby
 
User story mapping workshop slideshare
User story mapping workshop slideshareUser story mapping workshop slideshare
User story mapping workshop slidesharePankaj Kanchankar
 
API Token 入門
API Token 入門API Token 入門
API Token 入門Andrew Wu
 

La actualidad más candente (20)

敏捷式創意活動-樂高遊戲
敏捷式創意活動-樂高遊戲敏捷式創意活動-樂高遊戲
敏捷式創意活動-樂高遊戲
 
從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)
從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)
從限制理論角度談敏捷導入階段 (Agile transition: a TOC perspective)
 
User Story Mapping Workshop
User Story Mapping WorkshopUser Story Mapping Workshop
User Story Mapping Workshop
 
A crash course to user story mapping
A crash course to user story mappingA crash course to user story mapping
A crash course to user story mapping
 
Proto-persona workshop UX Scotland 2016
Proto-persona workshop UX Scotland 2016 Proto-persona workshop UX Scotland 2016
Proto-persona workshop UX Scotland 2016
 
5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ5分でわかった気になるインセプションデッキ
5分でわかった気になるインセプションデッキ
 
User Story Mapping
User Story MappingUser Story Mapping
User Story Mapping
 
如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致如何把看板和 Scrum 發揮到極致
如何把看板和 Scrum 發揮到極致
 
Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法Redmineでメトリクスを見える化する方法
Redmineでメトリクスを見える化する方法
 
User Story Mapping, Discover the whole story
User Story Mapping, Discover the whole storyUser Story Mapping, Discover the whole story
User Story Mapping, Discover the whole story
 
How to Organize a User Story Writing Workshop
How to Organize a User Story Writing WorkshopHow to Organize a User Story Writing Workshop
How to Organize a User Story Writing Workshop
 
敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊敏捷轉型:目標管理工作坊
敏捷轉型:目標管理工作坊
 
User Story Slicing - easy way to split user stories
User Story Slicing - easy way to split user stories  User Story Slicing - easy way to split user stories
User Story Slicing - easy way to split user stories
 
Workshop - Writing Good User Stories
Workshop - Writing Good User Stories Workshop - Writing Good User Stories
Workshop - Writing Good User Stories
 
Writing Effective User Stories
Writing Effective User StoriesWriting Effective User Stories
Writing Effective User Stories
 
User story concept for agiletourkaohsiung
User story concept for agiletourkaohsiung User story concept for agiletourkaohsiung
User story concept for agiletourkaohsiung
 
User story and splitting workshop
User story and splitting workshopUser story and splitting workshop
User story and splitting workshop
 
Story maps and personas an intro
Story maps and personas   an introStory maps and personas   an intro
Story maps and personas an intro
 
User story mapping workshop slideshare
User story mapping workshop slideshareUser story mapping workshop slideshare
User story mapping workshop slideshare
 
API Token 入門
API Token 入門API Token 入門
API Token 入門
 

Similar a User Story 的那些人與那些事

Conference Brochure Scrum Gathering Shanghai 2011
Conference Brochure Scrum Gathering Shanghai 2011Conference Brochure Scrum Gathering Shanghai 2011
Conference Brochure Scrum Gathering Shanghai 2011Shining Hsiong
 
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑Chang Shih-Chieh
 
Hoper 20111026 nctu-q_usability_dist
Hoper 20111026 nctu-q_usability_distHoper 20111026 nctu-q_usability_dist
Hoper 20111026 nctu-q_usability_distturtleknight
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & ScrumPicker Weng
 
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdfIvan Chiou
 
矽谷敏捷軟體開發
矽谷敏捷軟體開發矽谷敏捷軟體開發
矽谷敏捷軟體開發Wen Hsu
 
關於產品經理的角色與職責
關於產品經理的角色與職責關於產品經理的角色與職責
關於產品經理的角色與職責Cloud Chen
 
HP41- 令人迷惑的使用者研究方法 (蔡明哲)
HP41- 令人迷惑的使用者研究方法 (蔡明哲)HP41- 令人迷惑的使用者研究方法 (蔡明哲)
HP41- 令人迷惑的使用者研究方法 (蔡明哲)悠識學院
 
20140816 工程師要如何準備一場成功的簡報!
20140816 工程師要如何準備一場成功的簡報!20140816 工程師要如何準備一場成功的簡報!
20140816 工程師要如何準備一場成功的簡報!Amigo 陳兆祥
 
進擊的UX - rapid prototyping @ 新北市企業產經大學
進擊的UX - rapid prototyping @ 新北市企業產經大學進擊的UX - rapid prototyping @ 新北市企業產經大學
進擊的UX - rapid prototyping @ 新北市企業產經大學伯方 蘇
 
初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)
初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)
初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)Shih-Hsiao Peng
 
從乙方PM的角度看敏捷
從乙方PM的角度看敏捷從乙方PM的角度看敏捷
從乙方PM的角度看敏捷KC Liu
 
Ppt演义——100%幻灯片设计密码
Ppt演义——100%幻灯片设计密码Ppt演义——100%幻灯片设计密码
Ppt演义——100%幻灯片设计密码zhguoq
 
就業經驗分享
就業經驗分享就業經驗分享
就業經驗分享景文 CIID
 
Bridging the Gap – Developers Meet Design
Bridging the Gap – Developers Meet DesignBridging the Gap – Developers Meet Design
Bridging the Gap – Developers Meet DesignConstance Tang
 
用户故事清单
用户故事清单用户故事清单
用户故事清单unruliness
 
用户故事清单V0.2
用户故事清单V0.2用户故事清单V0.2
用户故事清单V0.2unruliness
 
專案設計流程 x Prott 蹦出新滋味
專案設計流程 x Prott 蹦出新滋味專案設計流程 x Prott 蹦出新滋味
專案設計流程 x Prott 蹦出新滋味Joy Tsai
 
UXer 未來式:共創工作坊 X Service Design Canvas
UXer 未來式:共創工作坊 X Service Design CanvasUXer 未來式:共創工作坊 X Service Design Canvas
UXer 未來式:共創工作坊 X Service Design Canvas俐絜 王
 

Similar a User Story 的那些人與那些事 (20)

Conference Brochure Scrum Gathering Shanghai 2011
Conference Brochure Scrum Gathering Shanghai 2011Conference Brochure Scrum Gathering Shanghai 2011
Conference Brochure Scrum Gathering Shanghai 2011
 
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
以 PM 角度來看轉型 Agile 的歷程,與那些踩過的坑
 
Hoper 20111026 nctu-q_usability_dist
Hoper 20111026 nctu-q_usability_distHoper 20111026 nctu-q_usability_dist
Hoper 20111026 nctu-q_usability_dist
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
20231028 清大GDSC演講-何謂敏捷與PAIA如何透過敏捷組織企業與學生共融的開發團隊.pdf
 
矽谷敏捷軟體開發
矽谷敏捷軟體開發矽谷敏捷軟體開發
矽谷敏捷軟體開發
 
Growth 的基石 用戶行為追蹤
Growth 的基石   用戶行為追蹤Growth 的基石   用戶行為追蹤
Growth 的基石 用戶行為追蹤
 
關於產品經理的角色與職責
關於產品經理的角色與職責關於產品經理的角色與職責
關於產品經理的角色與職責
 
HP41- 令人迷惑的使用者研究方法 (蔡明哲)
HP41- 令人迷惑的使用者研究方法 (蔡明哲)HP41- 令人迷惑的使用者研究方法 (蔡明哲)
HP41- 令人迷惑的使用者研究方法 (蔡明哲)
 
20140816 工程師要如何準備一場成功的簡報!
20140816 工程師要如何準備一場成功的簡報!20140816 工程師要如何準備一場成功的簡報!
20140816 工程師要如何準備一場成功的簡報!
 
進擊的UX - rapid prototyping @ 新北市企業產經大學
進擊的UX - rapid prototyping @ 新北市企業產經大學進擊的UX - rapid prototyping @ 新北市企業產經大學
進擊的UX - rapid prototyping @ 新北市企業產經大學
 
初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)
初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)
初入敏捷測試的困境 (2019.09.26 Agile Neihu Sprint 28.1)
 
從乙方PM的角度看敏捷
從乙方PM的角度看敏捷從乙方PM的角度看敏捷
從乙方PM的角度看敏捷
 
Ppt演义——100%幻灯片设计密码
Ppt演义——100%幻灯片设计密码Ppt演义——100%幻灯片设计密码
Ppt演义——100%幻灯片设计密码
 
就業經驗分享
就業經驗分享就業經驗分享
就業經驗分享
 
Bridging the Gap – Developers Meet Design
Bridging the Gap – Developers Meet DesignBridging the Gap – Developers Meet Design
Bridging the Gap – Developers Meet Design
 
用户故事清单
用户故事清单用户故事清单
用户故事清单
 
用户故事清单V0.2
用户故事清单V0.2用户故事清单V0.2
用户故事清单V0.2
 
專案設計流程 x Prott 蹦出新滋味
專案設計流程 x Prott 蹦出新滋味專案設計流程 x Prott 蹦出新滋味
專案設計流程 x Prott 蹦出新滋味
 
UXer 未來式:共創工作坊 X Service Design Canvas
UXer 未來式:共創工作坊 X Service Design CanvasUXer 未來式:共創工作坊 X Service Design Canvas
UXer 未來式:共創工作坊 X Service Design Canvas
 

User Story 的那些人與那些事

  • 1. Agile Tour Hsinchu / Taichung User Story 的那些人與那些事 Yiching Agile Tour Hsinchu / Taichung 2017
  • 2. Agile Tour Hsinchu / Taichung 為何需要說「故事」 ● 科技帶來大量的資訊,因此需要將資訊轉換成 容易理解的「故事」,幫助我們傳達資訊,以及 幫助自己做出選擇。 ● 影響他人最有利的手段,就是讓他親身體驗。 一個故事就是一個「重新想像的體驗」,因此要 聚焦在具有影響力和改變人們觀念的故事。 ● 故事思維能夠幫助你和不同想法的人溝通自 如,讓人們保持相同的看法。
  • 3. Agile Tour Hsinchu / Taichung Agenda ● 什麼是 User Story ● 如何描述 User Story ● 何謂好的 User Story ● 非開發團隊對撰寫 / 管理 User Story 的問題 ● 開發團隊對導入 User Story 的問題 ● Q & A
  • 4. Agile Tour Hsinchu / Taichung 什麼是 User Story ? ● 卡片 ( Card ): ○ 用一張卡片的大小 簡短描述用戶需求 ● 交談 ( Conversation ): ○ 重點在於透過 User Story 作為溝通基底,而非直接交棒 ● 確認 ( Confirmation ): ○ 可透過 User Story ,透過用戶角度來進行驗收,看有沒有達到他們的需求 卡片並非 User Story 本身 真正的 User Story 包含在整個軟體開發流程的討論中 (在進 Sprint 前需要不斷 拆解/分析/更新)
  • 5. Agile Tour Hsinchu / Taichung User Story 是什麼 User Story 不是 什麼 需求端 跟 實作端 溝通的基底 清清楚楚、一次定案的文件 描述需求與價值的工具 描述詳細實作內容的 Spec 任何人都可以參與與撰寫的工具 專屬於 Agile Team 的溝通工具 客戶的聲音與潛在需求 PO 的許願池
  • 6. Agile Tour Hsinchu / Taichung 任何人都可以撰寫 User Story ? 對,任何人 但要由負責人(PO)負責把關與排序 1. 非 Scrum 團隊的人更有機會接觸 User (ex: 業務、客服、研究人員等) 2. 開發團隊對產品有想法也可以透過 User Story 提出 3. 如果由 PO 當單一窗口,資訊量太大,而且沒有 write down 的東西容易不見
  • 7. Agile Tour Hsinchu / Taichung 如何描述 User Story As a <role>, I want to <do something>, so that I can <get value>. 身為一個<角色>,我想要<做某些事>,以至於我可以<有什麼價值> 角色 功能或 目標價值 Always starts from “User” Main point of user story
  • 8. Agile Tour Hsinchu / Taichung 可以不用套用公式嗎? 可以 但有前提!如下 1. 確定相關人員(Scrum Team, PO, Others)都能掌握需求與 Use Case 2. 確定溝通的「故事」內容可以驗收 3. 僅適用於短期內的快速迭代與需求釐清,不然討論的脈絡容易遺忘,又沒有依照 公式寫下來, 長期累積會是很重的資訊負擔。
  • 9. Agile Tour Hsinchu / Taichung “User” First 才是 User Story 已知的 User (實際用戶) 假想的 User (Persona)
  • 10. Agile Tour Hsinchu / Taichung 三步驟建立 Persona 1. 內部先假想一個 proto-persona 2. 針對幾個 Persona ,透過 User Research 蒐集相關資料 3. 蒐集 Persona 時可關注的內容 a. 主要關注:動機、痛點、需求、目標 b. 次要關注:能力、Life Style、個性、社經地位 c. 以上可依照產品特性調整 4. 整理分析資料,並修正 Persona a. 大幅更動:親合圖(Affinity Diagram) b. 小部分修正:修正 Diagram 並記錄 5. Persona 不會完美,因此要不斷輪迴 Proto-Persona User ResearchUpdate Persona
  • 11. Agile Tour Hsinchu / Taichung User Research 方法 http://www.uisdc.com/tencent-user-research-method 研究人員常用方法 非研究人員常用方法 ● 相似產品的產品/商模解構 ● 相似產品線上討論串分析 ● 客服人員檔案紀錄 ● 第一線人員的二手資料(業務、行銷) ● 跟第一線人員出門取得一手資料 ● 其他... p.s. 任何可以取得用戶 / 潛在用戶的 行為 想法 痛點 需求 都是可行的方法
  • 12. Agile Tour Hsinchu / Taichung 範例:卡片管理系統 User:Product Owner、Developer、Scrum Master、User Agents (Sales, Account Service, UX, QA, other stackholders...) ● 身為一個 Sales,我想要在再次接觸 User 前知道需求什麼時候會被實現,以至於我面對 User 時能夠給合適的答覆。 ● 身為一個 Product Owner,我想要清楚地透過卡片看到產品全貌,以至於我可以掌控產品的進程。 ● 身為一個 Developer,我想要在 Sprint 開始之前確認此 Sprint 的產出,以至於我在這 Sprint 可以專心衝刺。 ● 身為一個 Scrum Master,我想讓 PO 透過 User Story 開需求,以至於讓 Team Member 確認實作此張卡片的價值。 若是 User 是 Persona,PO 需代表這位 User 被詢問 PO 要使用者上身
  • 13. Agile Tour Hsinchu / Taichung 何謂好的 User Story (INVEST) https://www.linkedin.com/pulse/20140914070127-13798802-scrum-developing-epic-s-and-user-stories
  • 14. Agile Tour Hsinchu / Taichung 很難撰寫好 User Story 的原因 ● 非開發團隊 很難理解需求是否獨立 ● 撰寫時落入 Spec 細節,不易進行討論 ● 通常是假設性的,因此不確定此價值是否存在 ● 非開發團隊 很難理解何謂『可估計』的大小 ● 非開發團隊 很難確認此需求是否『小』 ● 非開發團隊 很難理解何謂『可測試』(此項目可由 Story 的相關資料補充,非 User Story 本身)
  • 15. Agile Tour Hsinchu / Taichung 但通常需求都來自 非開發團隊 如果 PO 也是非開發團隊(背景)的話,上述問題會更頻繁
  • 16. Agile Tour Hsinchu / Taichung 非開發團隊對撰寫/管理 User Story 的問題... ● 不知道該怎麼樣寫,故事大小才適合 ○ 如何切分 Story ● 故事之間有相依性,不知道怎麼管理這些需求 ○ 如何管理 Story 的相依性 ● 不知道該怎麼樣把 User Story 轉換成工程師可以實作的設計或 Spec ○ 如何將 Story 轉換為 Spec ● Story 越來越多,還有 Bug 要修,不知道該怎麼管理這亂無雜章的需求 ○ Theme, Story, Task, Bug 如何統合管理 ● 如果是底層優化的情況下,如何撰寫 User Story ○ 產品架構或效能該如何寫成 Story
  • 17. Agile Tour Hsinchu / Taichung 如何切分 Story 的大小 ● 根據 INVEST 原則 ● 雖然撰寫卡片時通常是闡述「一個價值」 ,但以開發來說可以是以一個 Output 為 原則,因此商業上的「一個價值」,對開發 來說可能是好幾張卡片 ● 一個 Output 範例: ○ 一個 Process ○ 一個 API ○ User 操作一個行為的結束 ● 若一個 Output 估點太大,可以再細拆為 Task 估點
  • 18. Agile Tour Hsinchu / Taichung 如何管理 Story 的相依性 ● User Story 不應該有相依性,但有時 候不得不有相依性,例如: ○ 使用者新增帳號 / 管理員凍結帳號 ● 視為一個帳號生命週期管理的 Story ● 透過管理工具標註相依性。 ○ 例如後置卡片放在 Pending List 並且標註前置 卡片的狀態或連結。有相依管理的工具 ● 相依性規模大的,先使用 UML 圖例 說明。除了電子化管理工具外,建議 使用實體化視覺管理。
  • 19. Agile Tour Hsinchu / Taichung 如何將 Story 轉換為 Spec ● Story 跟 Spec 是完全不同的東西,Story 闡述價值,而 Spec 闡述實作內容,一 定要先有 Story (闡述商業價值) 才會有 Spec (有價值才做)。 ● 通常 Spec 也就是 Acceptance Criteria (驗收標準),必須要可被測試 ● 從 Story 當中可以聞到需要產出的 Output 類型,不同的 Output 類型有不同的 Spec,大致可分為 Process, API, UI 三種類型,各別的 Spec 可以是: ○ Process:流程圖、結果文件 ○ API:Input parameter + type / Output parameter + content ○ UI:UI Flow ○ 簡單且通用的 Acceptance Criteria 可用:Given-When-Then BDD Method(又是大題目XD)
  • 20. Agile Tour Hsinchu / Taichung Epic, Story, Task, Bug 如何統合管理 工具 創意 透明 利害關係人管理 ● 用適合的工具管理不同的需求 ● 工具是不完美的,要靠自己的創意使管理更流暢 +方便 ● 在管理需求的同時,要讓大家知道目前這些 ”待辦事項”的現況 ● 管理你的需求來源,避免不必要的紛爭(很重要 XD)
  • 21. Agile Tour Hsinchu / Taichung 產品架構或效能該如何寫成 User Story ● User Story 是 User 觀點,若單純是技術或架構議題可另外寫 “Technical Story” ● Technical Story 可用於很多不同地方,例如: ● Technical Story 沒有一定的寫作格式,但大部分會有驗收標準。 ● Technical Story 不一定會 Demo Story,但會有額外的分享會。 http://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how Product Infrastructure Team Infrastructure Refactoring Bug Fixing Spikes
  • 22. Agile Tour Hsinchu / Taichung Q:怎麼知道卡片是 Epic, Story 還是 Task ? ● Epic 沒有明確的 Output ● Story 是 end-to-end 的一個 Output (動作/流程/API) ● Task 是完成上述 Output 的工程步驟 ● 如果不熟 User Story 也不一定需要 Fit Level,只要可以知道怎麼驗收即可。 Q:有需要將卡片拆小來符合一個 Sprint 的長度嗎? ● 以 Scrum 的方式來說,是。 ● 以一般專案管理角度,如果卡片的範圍不能拆小,那就是 Time Box 要拉長。 Q:拆解後的卡片怎麼做如上圖的階層對應關係? ● 以方法來說,User Story Mapping 可幫助大型系統的 Epic - Story 對應。 ● 以工具來說,目前看到最完整的應該是 Agile for Jira。但操作很複雜。 ● 沒有標準的 Scrum,也就沒有標準的管理卡片方式,也就沒有最適合又好用的工具,最好自己寫一個 XD。 Q:如果 Story 實作起來很複雜,該怎麼拆分為 Task? ● 如果是底層不完善造成實作複雜,先獨立出 Technical Story。 ● 如果是 Story 的實作功能影響範圍很廣,拆 Task! ● 如果是 Story 本身功能很大,拆成小 Story! 想像的一些其他問題...
  • 23. Agile Tour Hsinchu / Taichung 開發團隊對導入 User Story 的問題... ● 如何讓 PO 願意寫 User Story ○ 如何讓 PO 願意 / 學會寫 User Story ? ● 如何彰顯 User Story 的價值(關注在需求價值而非規格) ○ 如何讓其他人確信 User Story 有幫助 ● 如何避免直接寫 Spec,關注在需求與價值上 ○ 如何讓 非開發團隊 撰寫好 User Story ● 無法很持久的寫 User Story,最後都只寫想要的功能 ○ 如何讓 非開發團隊 撰寫好 User Story ● 如何協助 PO 管理需求 ○ Scrum Master 如何導入 Agile 需求管理
  • 24. Agile Tour Hsinchu / Taichung 如何讓 PO 願意寫 / 學會寫 User Story 如果 不是 真 PO(代PO) It’s hard for himself / herself 如果 是 真 PO It’s hard for you
  • 25. Agile Tour Hsinchu / Taichung 代 PO 篇 ● 代 PO 的困難點 ○ 他自己不是需求來源,所以不一定能完全傳達 Story 的價值 ○ PO 如果是由 Project Manager 轉任,還停留在 Scope-Resource-Time 的管理,而非產品成敗 ○ PO 如果是由 RD Team Leader 擔任,但該 Team 不是 Project Driven,而是 Functional Team ● 如何幫助 他/她 ○ 可以請 PO 嘗試寫下 User Story,幫助 Scrum 團隊運轉,並學習 PO 思考模式 ○ 讓這個 User Story 放在真 PO 看得到的地方,並適時邀請他參與會議 ○ 基本上需要 Empower PO,但這是組織轉型議題,已遠遠超出今天的 內容 Orz
  • 26. Agile Tour Hsinchu / Taichung 真 PO 篇 ● 你的困難點 ○ 傳統 SDLC 的 PM 習慣直接寫 Spec,User Story 不能直接交棒會沒有安全感 ○ 解釋 How 比解釋 Why 容易多 ○ Agile 精神還未萌芽,沒有 Iteration 的概念,停留在傳統 SDLC 只有 Spec 沒有 Story 處境 ○ 真 PO 如果是老闆不太可能請他自己寫 Orz ● 可以怎麼做 ○ 這是軟體開發流程的改變,基本上也是組織轉型議題,已遠遠超出今天的 內容 Orz ○ 如果真 PO 很遙遠,可以請窗口佔代 PO,寫出 User Story ○ 灌輸真 PO User Story 的價值,並且手把手教他寫
  • 27. Agile Tour Hsinchu / Taichung 如何讓其他人確信 User Story 有幫助 ● User Story 需要被團隊成員檢視,並給予回饋 ● 需求端撰寫 User Story 時,可以將該需求的 來由 附註上去,以便共同討論 ● 最好把 PO 的老闆(或 sponsor)也拉進來,共同檢視該 User Story 的價值 ● 當該 Story 在被處理時,要告知需求端,以增強他下次開卡的動機 ● 強烈要求『 沒有 Story 就沒有 Spec 』
  • 28. Agile Tour Hsinchu / Taichung 如何讓 非開發團隊 撰寫好 User Story 初級階段: 1. 由開發團隊蒐集需求並撰寫,撰寫完請 Owner 確認 a. 雖然書上都說這樣不好,但在推廣階段 SM 很常做這件事 b. User Story 實際上散佈在各個會議中,開發團隊需要有窗口去打探需求們 2. 他們願意寫就謝天謝地了,不逼迫、不強求,有寫總比沒寫好 (這是真的!)事後再由開發團隊修改並 請 PO 確認 a. 『可溝通』都是好 Story,不打擊他人士氣,協助引導撰寫更優秀的 Story b. 使用『comment』而非修改 ; 多以『鼓勵』取代『訂正』 進階階段: 1. 安排顧問(通常是 SA)為技術窗口,協助非開發團隊撰寫 User Story,或確認 User Story 合適性 a. 前提是 非開發團隊 已習慣撰寫 User Story 這個工作 b. 如果 PO 對產品實作不熟,此時 SA 需與 PO 緊密合作,讓 PO 升級 終極階段: PO 可以自行分析並撰寫 User Story ,協助轉換其他人的需求並排序(完美的 PO存在)
  • 29. Agile Tour Hsinchu / Taichung Scrum Master 如何導入 Agile 需求管理 ● PO 最重要的工作,是「開需求」與「需求排序」,但是讓 User Story 適合進入細節 討論之前要先做 Story 的檢視跟拆解 ● 如果 PO 對 Story Board 管理不熟,SM 要時常由共同會議幫助 PO 疏理 Story Board,Backlog Refinement Meeting 是好時機 ● SM 要時常提醒 PO 撰寫 User Story,並且自己要時常關注每個 Story 的狀態 ● 適時將 Story Board 的管理交棒給 PO 本人,SM 作為支持角色
  • 30. Agile Tour Hsinchu / Taichung Q:Story 無法估點怎麼辦? ● 不知道怎麼實作:先來個 spike 研究看看 ● 不確定實作過程會不會有問題:依照以前的經驗粗估,學習到之後下次就會估了 XD Q:Story 的驗收標準(Acceptance Criteria)由誰寫? ● 一般來說是 PO 確認(Scrum Team Support),但如果是 Technical Story ,由 RD Lead 或 SA 寫 Q:要怎麼確認 PO 開的需求是真的? ● 可以在 User Story 的卡片內附註為何有這個需求,用來確認是否該問題可以用該 Story 來解決 ● Scrum 的 Concept 基本上一切要「相信 PO」,有疑慮可以請他們提出一些證明 ● 產品成敗 PO 扛,所以不相信 PO 的話就請老闆施以壓力,或換團隊 ... Q:要怎麼樣練習寫 User Story,而不會開成 Spec? ● 目前的 User Story 撰寫方式的確很容易開成 Spec,以至於忽略其他可能的實現方法 ● 可以將 I want to <do something> 改為 I want to <get my goal>,另在驗收標準中討論實現方式 ○ Spec => 身為一個求職者,我想在搜尋篩選器多一個學歷的選項,以至於我可以篩選出符合我學歷的工作。 ○ Story => 身為一個求職者,我想要找到符合我學歷的工作,以至於我可以縮小合適的職缺範圍。 想像的一些其他問題...
  • 31. Agile Tour Hsinchu / Taichung Q & A