Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

User Story 的那些人與那些事

1.277 visualizaciones

Publicado el

How to conduct user stories in real case.

Publicado en: Diseño
  • Sé el primero en comentar

User Story 的那些人與那些事

  1. 1. Agile Tour Hsinchu / Taichung User Story 的那些人與那些事 Yiching Agile Tour Hsinchu / Taichung 2017
  2. 2. Agile Tour Hsinchu / Taichung 為何需要說「故事」 ● 科技帶來大量的資訊,因此需要將資訊轉換成 容易理解的「故事」,幫助我們傳達資訊,以及 幫助自己做出選擇。 ● 影響他人最有利的手段,就是讓他親身體驗。 一個故事就是一個「重新想像的體驗」,因此要 聚焦在具有影響力和改變人們觀念的故事。 ● 故事思維能夠幫助你和不同想法的人溝通自 如,讓人們保持相同的看法。
  3. 3. Agile Tour Hsinchu / Taichung Agenda ● 什麼是 User Story ● 如何描述 User Story ● 何謂好的 User Story ● 非開發團隊對撰寫 / 管理 User Story 的問題 ● 開發團隊對導入 User Story 的問題 ● Q & A
  4. 4. Agile Tour Hsinchu / Taichung 什麼是 User Story ? ● 卡片 ( Card ): ○ 用一張卡片的大小 簡短描述用戶需求 ● 交談 ( Conversation ): ○ 重點在於透過 User Story 作為溝通基底,而非直接交棒 ● 確認 ( Confirmation ): ○ 可透過 User Story ,透過用戶角度來進行驗收,看有沒有達到他們的需求 卡片並非 User Story 本身 真正的 User Story 包含在整個軟體開發流程的討論中 (在進 Sprint 前需要不斷 拆解/分析/更新)
  5. 5. Agile Tour Hsinchu / Taichung User Story 是什麼 User Story 不是 什麼 需求端 跟 實作端 溝通的基底 清清楚楚、一次定案的文件 描述需求與價值的工具 描述詳細實作內容的 Spec 任何人都可以參與與撰寫的工具 專屬於 Agile Team 的溝通工具 客戶的聲音與潛在需求 PO 的許願池
  6. 6. Agile Tour Hsinchu / Taichung 任何人都可以撰寫 User Story ? 對,任何人 但要由負責人(PO)負責把關與排序 1. 非 Scrum 團隊的人更有機會接觸 User (ex: 業務、客服、研究人員等) 2. 開發團隊對產品有想法也可以透過 User Story 提出 3. 如果由 PO 當單一窗口,資訊量太大,而且沒有 write down 的東西容易不見
  7. 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. 8. Agile Tour Hsinchu / Taichung 可以不用套用公式嗎? 可以 但有前提!如下 1. 確定相關人員(Scrum Team, PO, Others)都能掌握需求與 Use Case 2. 確定溝通的「故事」內容可以驗收 3. 僅適用於短期內的快速迭代與需求釐清,不然討論的脈絡容易遺忘,又沒有依照 公式寫下來, 長期累積會是很重的資訊負擔。
  9. 9. Agile Tour Hsinchu / Taichung “User” First 才是 User Story 已知的 User (實際用戶) 假想的 User (Persona)
  10. 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. 11. Agile Tour Hsinchu / Taichung User Research 方法 http://www.uisdc.com/tencent-user-research-method 研究人員常用方法 非研究人員常用方法 ● 相似產品的產品/商模解構 ● 相似產品線上討論串分析 ● 客服人員檔案紀錄 ● 第一線人員的二手資料(業務、行銷) ● 跟第一線人員出門取得一手資料 ● 其他... p.s. 任何可以取得用戶 / 潛在用戶的 行為 想法 痛點 需求 都是可行的方法
  12. 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. 13. Agile Tour Hsinchu / Taichung 何謂好的 User Story (INVEST) https://www.linkedin.com/pulse/20140914070127-13798802-scrum-developing-epic-s-and-user-stories
  14. 14. Agile Tour Hsinchu / Taichung 很難撰寫好 User Story 的原因 ● 非開發團隊 很難理解需求是否獨立 ● 撰寫時落入 Spec 細節,不易進行討論 ● 通常是假設性的,因此不確定此價值是否存在 ● 非開發團隊 很難理解何謂『可估計』的大小 ● 非開發團隊 很難確認此需求是否『小』 ● 非開發團隊 很難理解何謂『可測試』(此項目可由 Story 的相關資料補充,非 User Story 本身)
  15. 15. Agile Tour Hsinchu / Taichung 但通常需求都來自 非開發團隊 如果 PO 也是非開發團隊(背景)的話,上述問題會更頻繁
  16. 16. Agile Tour Hsinchu / Taichung 非開發團隊對撰寫/管理 User Story 的問題... ● 不知道該怎麼樣寫,故事大小才適合 ○ 如何切分 Story ● 故事之間有相依性,不知道怎麼管理這些需求 ○ 如何管理 Story 的相依性 ● 不知道該怎麼樣把 User Story 轉換成工程師可以實作的設計或 Spec ○ 如何將 Story 轉換為 Spec ● Story 越來越多,還有 Bug 要修,不知道該怎麼管理這亂無雜章的需求 ○ Theme, Story, Task, Bug 如何統合管理 ● 如果是底層優化的情況下,如何撰寫 User Story ○ 產品架構或效能該如何寫成 Story
  17. 17. Agile Tour Hsinchu / Taichung 如何切分 Story 的大小 ● 根據 INVEST 原則 ● 雖然撰寫卡片時通常是闡述「一個價值」 ,但以開發來說可以是以一個 Output 為 原則,因此商業上的「一個價值」,對開發 來說可能是好幾張卡片 ● 一個 Output 範例: ○ 一個 Process ○ 一個 API ○ User 操作一個行為的結束 ● 若一個 Output 估點太大,可以再細拆為 Task 估點
  18. 18. Agile Tour Hsinchu / Taichung 如何管理 Story 的相依性 ● User Story 不應該有相依性,但有時 候不得不有相依性,例如: ○ 使用者新增帳號 / 管理員凍結帳號 ● 視為一個帳號生命週期管理的 Story ● 透過管理工具標註相依性。 ○ 例如後置卡片放在 Pending List 並且標註前置 卡片的狀態或連結。有相依管理的工具 ● 相依性規模大的,先使用 UML 圖例 說明。除了電子化管理工具外,建議 使用實體化視覺管理。
  19. 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. 20. Agile Tour Hsinchu / Taichung Epic, Story, Task, Bug 如何統合管理 工具 創意 透明 利害關係人管理 ● 用適合的工具管理不同的需求 ● 工具是不完美的,要靠自己的創意使管理更流暢 +方便 ● 在管理需求的同時,要讓大家知道目前這些 ”待辦事項”的現況 ● 管理你的需求來源,避免不必要的紛爭(很重要 XD)
  21. 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. 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. 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. 24. Agile Tour Hsinchu / Taichung 如何讓 PO 願意寫 / 學會寫 User Story 如果 不是 真 PO(代PO) It’s hard for himself / herself 如果 是 真 PO It’s hard for you
  25. 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. 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. 27. Agile Tour Hsinchu / Taichung 如何讓其他人確信 User Story 有幫助 ● User Story 需要被團隊成員檢視,並給予回饋 ● 需求端撰寫 User Story 時,可以將該需求的 來由 附註上去,以便共同討論 ● 最好把 PO 的老闆(或 sponsor)也拉進來,共同檢視該 User Story 的價值 ● 當該 Story 在被處理時,要告知需求端,以增強他下次開卡的動機 ● 強烈要求『 沒有 Story 就沒有 Spec 』
  28. 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. 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. 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. 31. Agile Tour Hsinchu / Taichung Q & A

×