為什麼需求總是被誤解？實例化需求可能是缺少的拼圖 🧩

TSMC IT Community Meetup (Taichung) #6
https://tsmcitcommunitymeetup.kktix.cc/events/tsmc-it-meetup-taichung-06

開發團隊信心滿滿地交付了新功能，但使用者卻一臉茫然？測試團隊發現大量"bug"，但開發團隊堅稱那是"feature"？產品上線後，才發現與商業目標南轅北轍？

"實例化需求 (Specification by Example)" 可能是一個解決方式!

簡單來說，就是用具體例子來描述抽象的需求，來讓所有人達成真正的共識。召集跨職能團隊：產品、開發、測試一起參與，從 User Story 出發，列舉各種可能的場景，為每個場景寫出具體的例子，包括輸入、過程和預期結果，最後將確認後的例子轉化為可執行的測試案例，再將案例可直接轉化為自動化測試，直接變為一個可參考的線上文件

本議程將來介紹這個 Process Pattern，讓產品交付更為順暢

Transcript

1. 為什麼需求總是被誤解？實例化需求可能是缺少的拼圖 TSMC IT Community Meetup #6 2024-09-05 Kyle Shen
2. Hello! I am Kyle, 一個走進設計學院的工程師 任職過軟體、教育、物流產業, 於新創打滾多年, 目前於製造業擔任 SRE Manager STUDY4 核心成員，HiSKIO 特約講師, 現任微軟最有價值專家 曾於許多大型研討會擔任講者，包含 Microsoft DevDays Asia、 .NET Conf、Global Azure Bootcamp 2
3. 我們日常生活都在試圖理解對方的需求 老婆：「下班路上幫忙買一個西瓜，如果遇到柳丁，買十個」 結果，身為工程師的老公買了十個西瓜回來。 氣急敗壞的老婆發問，老公一臉無辜地說： 「是妳自己說的阿！買一個西瓜， 但如果遇到柳丁，西瓜就要改買十個」
4. 你畫我猜
5. 所以敏捷要小週期的發現錯誤，但 … 都在產生大便
6. 團隊針鋒相對，成為喪屍敏捷團隊 症狀1 對於 Stakeholder 需求一無所知 即喪屍歡躲避人群，對於價值鏈的上下游漠不關心，互 不溝通, 但一直很忙, 只忙著設計，忙著分析，忙得寫程 式, 持續交付著無價的使用者的功能 症狀2 無法快速交付 無法讓 Stockholder 能真的使用系統驗證，Demo 只能 淪為簡報截圖，或技術討論，整個會議缺乏互動，沒有 人表達意見，沒有人提出建議或討論新想法 症狀3 無法持續改善 對於 Sprint 的失敗或成功毫無反應，保持麻木空洞的神情， Sprint Backlog 理所當然的被挪到下一個 Sprint 症狀4 無法透過自組織克服阻礙 無法自己做出關鍵決策，任何事都得請求授權, 沒實際產品的 形塑過程，也不會關心產品的成功與否
7. 有沒有一種方式, 可以讓需求更明確一點? “
8. 多問一句: 您可以 舉例 嗎? “
9. 實例化需求(Spec. by example) “
10. 例子 測試 需求 成為 驗證 澄清
11. 從目標收斂範圍 協作制定需求規格 規格舉例說明 提煉需求規格 不動規格及自動化測試 頻繁驗證 持續演變為文件系統
12. 需求怎麼收斂成 Product Backlogs ? - 理解產品階段 Source: 產品生命週期，如何延續？以iPhone為例，企業這樣找「衝刺新品的最佳時機」 - 商業思維學院 (bizthinking.com.tw) 建立產品價值 用戶忠誠度
13. 需求怎麼收斂成 Product Backlogs ? - 導入期~成長期 用黃金圈理論勾產品願景與使命 What Why How 影響力地圖奠定基礎策略 目標 角色 角色 影響 影響 影響 方法 方法 方法 方法 方法 “由上而下收斂需求” 在 30s 內說清楚願景 - 電梯簡報 (Elevator Pitch) Why? Who? How? What? 假設 假設 假設
14. 需求怎麼收斂成 Product Backlogs ? - 穩定期~衰退期 Focus Group 避免太自我的創新「走出辦公室」 跟顧客面對面！ “由上而下收斂需求”
15. 但需求這麼多? 要怎麼排? - User Story Mapping Must Have Should Have Nice To Have
16. Product Owner 負責對 Product Backlog 進行有效的管理 - Scrum Guide
17. 從目標收斂範圍 協作制定需求規格 規格舉例說明 提煉需求規格 不動規格及自動化測試 頻繁驗證 持續演變為文件系統
18. 協作制定需求規格 視團隊大小有不同的工作坊 大型團隊可以在 Scrum Refine Meeting 小型團隊可以分組甚至在座位上日常溝通 理解價值從何而來，為誰而做？ 詢問「為什麼」，直到答案開始牽扯金錢或成本 事前做好足夠的分析，理解本次會議產出 產出 User Story with Acceptance Criteria，且列出 Examples 以利達成需求的共識 Product Owner Scrum Master Designer Developer QA
19. 7 Whys
20. Example Mapping 便利貼說明 • Story - 主要功能或需求 • Rule - Acceptance Criteria by Product Owner • Example – 具體場景及業務測試案例 • Question – 未解決的疑問或不確定性 目的 協作式探索需求技術，細化 User Story 淺在的業務邊界情況 Story Rule Rule Rule Example Example Example Example
21. Example Mapping - 舉例 買水果 都買不到 怎麼辦? 下班 路上購買 預設 購買西瓜 遇到柳丁 買柳丁 拿得動嗎? 走路 開車 買10個 順路 10個 騎車 不順路 0個 看到柳丁 沒看到西瓜
22. Example Mapping - 舉例 買水果 都買不到 怎麼辦? 下班 路上購買 預設 購買西瓜 遇到柳丁 買柳丁 拿得動嗎? 走路 開車 買10個 順路 10個 騎車 不順路 0個 看到柳丁 沒看到西瓜
23. Example Mapping - 舉例 買水果 下班 路上購買 預設 購買西瓜 遇到柳丁 買柳丁 還會有預算 限制嗎? 走路 開車 買10個 順路 10個 騎車 不順路 0個 介於 50~60元 介於 15-20元
24. Example Mapping - 舉例 買水果 下班 路上購買 預設 購買西瓜 遇到柳丁 買柳丁 非功能性需 求? 走路 開車 買10個 順路 10個 騎車 不順路 0個 介於 50~60元 介於 15-20元 盡量避免出現是非題 – 買幾個? 量化避免用非範圍的定義 – 預算多少? 要了解是否有替代方案? - 買不到怎麼辦? 功能性 / 非功能性需求? – 幾點回家? 盡量用真實資料 – 明確指定水果類型 幾點回家?
25. 這會議協作結束，大概完成以下內容 User Story (100%) Acceptance Criteria (90%) Examples (70%) As a 妻子， I want to 丈夫下班路上幫忙買水果 So that 晚餐或家庭聚餐 • 購買西瓜1個, 柳丁10個 • 如果回家路上都沒有就都不要買 • 18:00 前到家趕上晚餐 • 西瓜價錢請控制在 50-60 之間 • 柳丁價錢請控制在 15-20 之間 • 商店只有西瓜 -> 1顆西瓜, 0顆柳丁 • 商店有西瓜跟柳丁 -> 1顆西瓜, 10顆柳丁 • 商店只有柳丁 -> 10顆柳丁 • 都沒有 -> 0顆西瓜, 0顆柳丁 • 有西瓜, 但超出預算為 100 元 -> 打給老婆確認 • ….
26. Example Mapping Workshop 購物車 可以添加 書籍 可以移除 書籍 可以更改 數量 做為一名線上書店的顧客， 我希望能夠使用購物車功能， 以便我可以收集想買的書籍並一次性完成購買
27. 從目標收斂範圍 協作制定需求規格 規格舉例說明 精煉需求規格 不動規格及自動化測試 頻繁驗證 持續演變為文件系統
28. 精煉需求規格 用統一的格式來撰寫 使用 Given When Then (Gherkin) 格式來撰寫，或者是表格式 實例要精確可測 可讀性高且精確的文件, 為開發和測試明確指引 一些可能要注意的壞味道 … • Example != Test Case • 過於強調技術實作與 UI 的細節 • 案例不宜過多，如過多代表 Story 沒收斂
29. Structured way to write example – Give/When/Then 場景: 增加書籍到購物車 Given 使用者的購物車是空的 When 使用者將一本價格為 100 元的書加 入到購物車 Then 購物車應顯示 1 本書， 總價應為 100 元
30. Structured way to write example - Table 場景 初始狀態 操作 預期結果 加入書籍 空購物車 加入一本 100 元的書 購物車顯示 1 本書，總價 100 元 移除書籍 購物車有 2 本書，總價 200 元 移除一本 80 元的書 購物車顯示 1 本書，總價 120 元 更改數量 購物車有 1 本 50 元的書 將數量改為 3 本 購物車顯示 3 本書，總價 150 元 達到免費送貨 購物車總價 490 元 加入一本 20 元的書 總價 510 元，顯示“免運" 超出容量限制 購物車有 19 本書 嘗試加入第 21 本書 顯示錯誤消息，保持 19 本書 缺貨處理 購物車有 1 本庫存為 1 的書 另一使用者買走最後一本， 當前使用者進行結帳 通知缺貨，提供移除或等待選項
31. 會議後的精煉，會完成以下內容 User Story (100%) Acceptance Criteria (100%) Examples (100%) As a 妻子， I want to 丈夫下班路上幫忙買水果 So that 晚餐或家庭聚餐 • 購買西瓜1個, 柳丁10個 • 如果回家路上都沒有就都不要買 • 18:00 前到家趕上晚餐 • 西瓜價錢請控制在 50-60 之間 • 柳丁價錢請控制在 15-20 之間 • Given 上班順路 When 商店只有西瓜 Then 買1顆西瓜, 0顆柳丁 • … Flow & UI Detail (100%) • Figma: https://.... • User Journey: https://.... Product Owner Designer Developer QA
32. 從目標收斂範圍 協作制定需求規格 規格舉例說明 精煉需求規格 不動規格及自動化測試 頻繁驗證 持續演變為文件系統
33. 持續自動化測試 這時的 Dev … 依據實例化需求去產生單元測試 規格即文檔 將驗收標準轉化為可執行的測試，實現即時的文檔， 確保規格始終與程式碼同步，減少維護成本 這時的 QA … 依據實例化需求去產生測試策略和測試案例 Live Document Unit Test Test Case
34. SpecFlow with Azure DevOps livingDoc
35. 如何開始改變?
36. 敏捷無用？ 避免用這種 buzzword 去跟老闆報告，"轉化" 名詞會好一點… 不要說："我們需要導入敏捷方法論" 改說："我有個提高團隊效率和適應力的想法" 不要說： "我們要執行 Scrum Events" 改說："我們可以嘗試更頻繁的小型會議，來快速驗證想法" 不要說："我們需要進行Daily Standup" 改說："每天花15分鐘幫助我們更快發現並解決問題，降低風險"
37. 以 Spec. by Example 當作驗收測試來推銷 推行 SBE 的改變機會點 太依賴最後的 User Acceptance Test 改以 SBE 頻繁及短週期驗證 互不關心的喪屍敏捷團隊 團隊合作定義需求. 建立一個隨產品發展而更新的文件，讓所有人 隨時了解最新狀況 工具只是輔助這個過程的手段，而不是目的 團隊合作定義需求，減少誤解，提高開發效率和產品質量
38. 改變三原則 - 守破離 想大刀闊斧改革團隊？先慢下來... • 遵守規則 理解比改變更重要，只有充分了解現狀，才能提出真正有價值的改 進方案 • 靈活運用 改革不是一蹴而就的，通過漸進式的小改變， 既能提高效率，又能贏得團隊的信任 • 數據驅動 最有說服力的不是你的直覺，而是堅實的數據支持，讓數據為你的 改革背書，更容易獲得團隊的認同和配合。
39. Thanks! Kyle Shen 39 linkedin.com/in/kyleshen-net kyleap.github.io kyleap.github.io speakerdeck.com/kyleshen threads.net/@shenkyle