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
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 圖例
說明。除了電子化管理工具外,建議
使用實體化視覺管理。
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 => 身為一個求職者,我想要找到符合我學歷的工作,以至於我可以縮小合適的職缺範圍。
想像的一些其他問題...