拒絕再寫無效規格，來學學實例化需求！ (Agile Summit TW 2023) on 2023/06/16

1. Fong Liou
拒絕再寫無效規格，
來學學實例化需求！
團隊協作規格與測試來建置正確的軟體

2. Overview
• 無效的規格與解⽅
• 建立實例化需求流程與有效規格
• 梳理⽬前流程
• 實例化需求規格流程
• 實戰經驗與常⾒問題

3. • 劉鳳軒 (Fong)
• Appier Senior Engineer
• Kanban Master in my Team
• DDDTW 核⼼志⼯
• 鐵⼈賽 2018 Web 組冠軍、
2019 Software Development 組優
勝
About Me

4. I.
無效的規格與解⽅
- 何謂有效規格與實例化需求規格 -

5. 你喜歡寫或讀規格⽂件嗎？
太多太長？架構混亂？考慮不周？細節太多？沒有更新？

6. ⽤⼀個例⼦來解釋為什麼規格很難寫/讀
44?

7. QA 跳出來：答案是不⼀定！
要先定義適⽤範圍，同時邊界值、特殊狀況都需要被考量
⽣⽇過了嗎？
有考慮時區嗎？
Sister 還活著？
虛歲？

8. ── Alberto Brandolini
It is not the domain expert’s knowledge that goes
into production, it is the developer’s assumption of
that knowledge that goes into production …
“

9. 規格是⼀種傳遞知識的溝通⼯具，
⽤於同步領域專家跟開發⼈員間的認知。
當知識無法有效傳遞、反⽽製造更多的困惑時，
就是無效規格！

10. 無效規格的特徵
範圍不明確
(Scope Creep)
規則過於抽象
沒有上下⽂
內容組織混亂

11. 無效規格是由於開發流程與成員⼼態導致
單向的資訊流，知識在不斷轉譯與再創造過程中被扭曲誤解
流程中不注重品質、
直到最後才開始測試
團隊成員各⾃爲政

12. 當最終產品無法順利驗證時就會導致交付的失敗
模糊的需求加上
知識的「再轉譯」容易
產⽣誤會
直到交付前無法取得
使⽤者的 Feedback
過期的⽂件
Dev 與 QA 認知不⼀致
或是規格修改
導致需要不斷重⼯

13. 即使快速迭代可以更快發現錯誤，但不能避免錯誤

14. 團隊容易陷入究責的困境
為什麼時程⼜ delay、bug ⼜多！
客⼾已經等不及了！
誰叫規格的漏洞這麼多、⼜⼀直修改！
你不知道技術債很重嗎？
等等！有算入 QA 時間嗎？
當初說好⼀週可以測怎變成兩天...

15. 回顧 Agile 宣⾔
個⼈與互動 重於 流程與⼯具
可⽤的軟體 重於 詳盡的⽂件
與客⼾合作 重於 合約協商
回應變化 重於 遵循計劃

16. 有效的規格能幫助我們減少重⼯與錯誤並
正確解決客⼾需求。
⽽有效的規格必須是團隊協作下的共識，
需要有良好的流程配套以及每個⼈重視品質的⼼態！
問：那如何有效取得共識？

17. 舉例，是⼀種最原始卻最有效的⽅式之⼀！
規格的⽬標就是滿⾜規則，⽽好的範例幫助我們了解規則
Scenario 我 姐姐 Now Answer
今年的⽣⽇都已過了 1982/1/1 1980/3/1 2022/4/1 42
我的過了、姐姐的尚未 1982/1/1 1980/3/1 2022/2/1 41
我的尚未、姐姐的過了 1982/3/1 1980/1/1 2023/2/1 43
兩個⼈今年都還沒過⽣⽇ 1982/5/1 1980/5/1 2023/4/1 42
姐姐在國外 (時區) 1982/2/1
1980/2/1
(now:GMT-8)
2022/2/1 42
姐姐英年早逝 😢 1982/1/1
1980/3/1
(🪦1990/3/1)
2022/4/1 10

18. 這些實例可以進⼀步成爲規格、測試甚⾄是⽂件。
協作討論 + ⽤舉例解釋規格 =
實例化需求規格 (Specification by Example)

19. 產出有效規格的第⼀步：找⿑團隊成員討論需求規格

20. 實例化需求規格的好處
⚠ 注意：實例化需求規格不是要遵循某個框架或⼯具，⽽是從協作開始！
提升產品品質 提升效率、
減少重⼯
團隊共識與
向⼼⼒

21. II.
建立實例化需求流程與有效規格
- 梳理既有流程以及導入-

22. 改變開始：先梳理既有的流程

23. 建立對既有流程的共識！
召集團隊成員⼀起視覺化
既有流程
定義每個狀態的
「完成定義」 (DoD)
包含從功能設計到上線
的所有狀態
也可以重新定義流程中模糊的區塊，也可以標註常常出問題的地⽅！

25. 找到開發前可以協作規格的時間點！
https://www.functionize.com/blog/what-is-gherkin-how-do-you-write-gherkin-tests

26. The END (?)

27. 實例化需求規格流程

28. 1. 從⽬標中定義範圍
2. ⽤舉例的⽅式協作規格
3. 精煉需求規格
4. 驗證與測試的⾃動化
5. 演化成「活⽂件」
完整的實例化規格流程

29. 1 - 從⽬標中定義範圍

30. 交付正確的軟體的前提是明確且合理的責任範圍
• ⽬的：創造價值與減少浪費。
• 挑戰需求與解決⽅案：找到需求背後的商業⽬標與核⼼問題。
• 客⼾的需求並不直接等於解決⽅案。
• 時常質疑「為什麼要這麼做」、「這是要給誰⽤的」、「可以⽤其他解法嗎？」
• 與團隊成員協作制定交付範圍：
• 排序使⽤者的關注點、考量外⼒環境因素與⼯程資源，避免 Scope Creep
• 可以利⽤ User Story Mapping 來拆分 User Stories 並討論交付⽬標

31. • 適⽤於與團隊成員⼀起拆解 Epic
等級的功能並討論交付的策略與
範圍。
• 促進溝通和共識
• 理解使⽤者體驗探索產品功能
• 視覺化產品進展與應對變化
• 優先排序與 Release 順序
User Story Mapping

32. Step 1. 確認範圍：
確定使⽤者是誰、為什麼要⽤以及要做什麼
上班族 去上班 交通與過程

33. 起床
刷牙
洗臉
著衣
吃早餐
搭公⾞
轉捷運
進公司
下⾞
搭電梯
製作
早餐
查詢公⾞
時刻
買早餐
Step 2. 探索 User Story ：
列出使⽤者流程

34. Step 3. 歸類「使⽤者活動」：
將類似⽬的的故事聚集在⼀起
起床
刷牙
洗臉
著衣
吃早餐 搭公⾞
轉捷運 進公司
下⾞
搭電梯
製作
早餐
查詢公⾞
時刻
出⾨前
準備
通勤 進公司
今⽇
規劃

35. Step 4. 繼續探索更多可能性
起床
刷牙
洗臉
著衣
吃早餐 搭公⾞
轉捷運 進公司
下⾞
搭電梯
製作
早餐
查詢公⾞
時刻
出⾨前
準備
通勤 進公司
今⽇
規劃
買早餐 搭計程⾞
挑選
衣服
收拾
包包
冥想
喝⽔
跟同事打
招呼

36. Step 4. 根據⽬標切分不同交付策略
與範圍：考量系統外的因素！
起床
刷牙
洗臉
著衣
吃早餐
搭公⾞
轉捷運
進公司
下⾞
搭電梯
製作
早餐
查詢公⾞
時刻
出⾨前
準備
通勤 進公司
今⽇
規劃
買早餐
搭計程⾞
挑選
衣服
收拾
包包
冥想
喝⽔ 跟同事打
招呼
起床
儘快
從容
健康
MVP &
deadline
Release
2
Release
3

37. 規格 v1
User Story Requirement
As a Role,
I want to …
So that…
▌User Story
Background…
Epic
User
Story
User
Story
User
Story
▌Acceptance Criteria
• User can do XXX
• User cannot do XXX
• Changes & di
ff
erences
• Out-of-scope
注意可讀性。
保持 High-level 的活動與規則，
明確表⽰責任範圍並減少 UI 與技術細節

38. 2 - ⽤舉例的⽅式協作規格

39. 透過舉例釐清誤會與風險
• ⽬的：與團隊成員對規格建立「共識」並減少「模糊空間」
• 召集團隊成員進⾏ Requirement Workshop
• Three Amigos: PM, Dev, & Testers
• 不同⾓⾊可以提供不同⾓度的⾒解
• 實例可以作爲未來的規格與測試內容
• 不必過度舉例，主要是探索「Unknown knowns」

40. Example Mapping
• 探索「未知的已知」(“Unknown Knowns”) 知識！
• 提前解開誤解、挑戰認知並建立共識
• 可以協助估算時程以及建立測試範圍
• 好處：
• PM: 不必背負太⼤的壓⼒、提早討論
• Dev: 確實理解規格、及早提出問題
• QA: 可以及早跟 Dev 過過測試的範圍

41. Step 1.
挑選⼀張 User Story
或是 Use Case 貼上去
免運費

42. Step 2.
列出所有的規則
免運費
VIP 5 本書
免運
10 本書
免運
…

43. Step 3.
⼤家腦⼒激盪將每個規則展開實例
免運費
VIP 5 本書
免運
10 本書
免運
…
< 10
⇨ X
VIP 4
⇨ V
VIP 5
⇨ V
…
≥ 10
⇨ V

44. ⚠ 注意 ⚠
1. 實例要盡可能真實，比如使⽤真實數字！
2. 每個實例最好有：
Context、Action、Outcome
3. ⼀個實例只解釋⼀個規則，不要跨規則解
釋。
免運費
VIP 5 本書
免運
10 本書
免運
…
9
⇨ X …
…
…
10
⇨ V

45. 10
⇨ V
Step 4.
針對規則或範例提出疑問
免運費
VIP 5 本書
免運
10 本書
免運
…
9
⇨ V
VIP 4
⇨ V
VIP 5
⇨ V
…
國際
貨運？
…

46. Step 5.
解決列出的問題，可能修改既有規則，也可
能長出新的實例或是規則
免運費
VIP 5 本書
免運
10 本書
免運
…
9
⇨ V
VIP 4
⇨ V
VIP 5
⇨ V
…
????
…
國際貨運都
不算
國際
貨運？
…

48. Example Mapping 經驗談
• 當所有問題都被解決時，就可以結束了。
• 不必堅持要窮舉所有實例（時間有限），重點是探索你不知道的東⻄
• 可以在進票前（確定即將要開發前）進⾏，每次 30-50 mins
• 當 Rules & Examples 多出原先的期待，可以考慮拆新的 User Story 並重新調
整時程
• 注意：⼩⼼過於發散，重點在解決疑問上。因此主持⼈要注意時間，可以⽤
Time Box 協助。

49. 規格 v1.1
User Story Requirement
As a Role,
I want to …
So that…
▌User Story
Background…
▌Acceptance Criteria
• User can do XXX
• User cannot do XXX
• Changes & di
ff
erences
• Out-of-scope
調整 Acceptance Criteria 以符合討論結果
▌Details & Examples
針對⼀些複雜的 AC 規則做補充
• Rule 1 details
• Rule 2 details
• Rule 3 details

50. 3 -精煉需求規格

51. 易維護的⽂件幫助我們聚焦與理解
• ⽬的：精煉初始實例以獲得可讀性⾼且精確的規格⽂件。
• 定義並使⽤「統⼀語⾔」來撰寫
• 簡潔 Example Mapping 的結果：
• 專注在規則解釋上，⽽非測試流程腳本
• 避免技術實作細節與減少 UI 細節
• 避免過度展開（所有排列組合）實例並注意可讀性，
• 如果忽略這⼀步，容易讓⽂件看起來很混亂。

52. 常⾒的三種格式
• 條列式⽂字
• 優點：好上⼿
• 缺點：容易混亂、沒有格式、可能不易閱讀
• Gherkin （Given-When-Then)
• 優點：明確的格式
• 缺點：不好上⼿、較難閱讀
• 表格
• 優點：好上⼿、好閱讀、適合規則組合展開
• 缺點：不適⽤於流程描述

53. 範例⽂件：訂單優惠的驗收測試
• 我們有 VIP 跟⼀般會員，購物會有運費 80 元。
• 如果 VIP 購買超過 1000 元，則有免運優惠
• 如果⼀般會員購買超過 3000 元，則有免運優惠
• 冷凍寄送商品不符合免運資格，需額外收取 100 元
• 會員下單後，會收到訂購成功的信件
• 如果⼀般會員每次消費超過 3000 元，就會得到積分 10 點，積分滿 50 點會變成
VIP

54. 精煉過程：⽤表格組合複雜的可能性
VIP 1000
Member
3000
…
…
冷凍
…
…
Member
Type
Items
Total
Shipping
Fee?
Total
VIP ⼿錶 $1001 No $1001
VIP 電鍋 $1000 Yes $1080
Member
腳踏⾞ $2800
⼿電筒 $201
Yes $3000
Member
電視 $30000
冰淇淋 $200
Yes (冷藏運輸) $30300

55. 精煉過程：⽤ Gherkin 表達預期⾏爲
Scenario：升級爲 VIP
Given Judy 是⼀名⼀般會員
And Judy 已經累積積分 40 點
When Judy 下單了 3000 元買了⼀臺腳踏⾞
Then 訂單下單成功
And Judy 收到了⼀封成功訂購的通知信
And Judy 積分變成 50 分
And Judy 升級爲 VIP 會員

56. 規格 v2
User Story Requirement
As a Role,
I want to …
So that…
▌User Story
Background…
▌Acceptance Criteria
• User can do XXX
• User cannot do XXX
• Changes & di
ff
erences
• Out-of-scope
加上 UI 畫⾯與細節邏輯補充
▌Details & Examples
挑選出複雜的規則，⽤⽂字、表格或是
Gherkin 來舉例表達
• Rule 1 details
• Rule 2 details
• Rule 3 details
▌UI Details
Given…
When…
Then
• Link: https://
fi
gma…
• User steps
• Component interaction

57. 4 - 驗證與⾃動化測試

58. 取得共識下的測試變得清晰⼜容易！
• ⽬的：讓最終的交付產物符合規格的需求與使⽤者的期待
• 把規格書當作知識的「權威來源」，任何修改都應該回歸到規格書中
• Dev 根據實例化需求去長出單元測試
• QA 根據實例化需求去設計測試策略與寫出 Test Cases
• 進入 Testing 的 DoD
• Dev 要把規格上的規則都驗證過
• Dev 要 review 過 QA 的測試⽂件

59. DEV : 把實例化規格當作單元測試
▌Details & Examples
• Rule 1 details
• Rule 2 details
• Rule 3 details
Given…
When…
Then

60. QA : Test Cases ⽂件 + ⾃動化 E2E 測試
Source: https://www.swtestacademy.com/wp-content/uploads/2020/01/
img_5e2ae0f39a85e.png

61. 規格 Final version
• User Story & Background： 列出使⽤者故事與⽬的，以及適量的背景解說
(why)
• Acceptance Criteria：交付範圍、使⽤者可以或不可以做什麼、 High Level 規
則、Migration 策略。簡潔、修改頻率低。
• UI Details：UI 畫⾯與細節、元件動畫
• Details & Examples：挑選複雜的規則做實例解說。最常被修改。
• Notes：考量點 Checklist、技術細節、補充資料、決策歷史

62. 最後是否要演化成「活⽂件」?
反思：維護活⽂件有長期價值，但短期要付出很多學習與維護成本。
我們⽬前的策略：實例化需求規格 + DDD 設計 + 單元測試 + 部分探索性測試

63. ⼩結
• 取得共識
• 更合理的交付範圍與估算
• 及早發現可能的風險
• 建立品質
• 測試左移

64. III.
常⾒問題與實戰經驗
- 那些年踩過的坑 -

65. 常⾒問題
• 有推薦哪些技術框架嗎？
⇨ 建議先從協作與流程下⼿，再去找適合的⼯具
• 如果需求還是⼀直變動怎麼辦？
⇨ 在範圍確定的情況下，實例化需求反⽽更能擁抱細節的改動，
• 會不會前期浪費太多時間最終專案還是 delay?
⇨ 就看你是要前⾯花時間還是後⾯浪費時間
• 那些 Workshop (USM, EM) 是否是必須的？
⇨ Workshop 是⼀個⾼效討論且有產出的會議，即使很考驗主持⼈功⼒但仍推薦⼀試

66. 實戰經驗分享 - 1 建立團隊的規格模板
• 規格模板是團隊共識的產物，重點不是多詳細與精美，⽽是⼤家都會⽤！
• 建立第⼀版規格模板後，可以搭配多次 Retro 會議改善。可以在模板最後放⼀
個 checklist 提醒⼤家要去考慮常出錯的地⽅。
• 反省：曾經規定成員每個規則都要搭配 Gherkin，結果耗時且品質不⼀、事後⼜
沒什麼⼈回去看。重點是配合⼤家的習慣再漸進改變
• 可以⽤「回頭率」來評估規格的有效性

67. 實戰經驗分享 - 2 ⼯程師前期的參與
• 前期與 PM 溝通交付範圍非常重要，可以及早管理期待值並 (可能) 降低架構改
變的風險。（翻譯：不要加班）
• 同時，進⾏到舉例 Example 環節時，可以更精準評估功能⼤⼩，並再次與 PM
確認期待值。
• 溝通時注意使⽤「統⼀語⾔」，同樣的事物要⽤⼀致的名詞去表達。
• 由⼯程師來負責精煉需求規格雖然辛苦但有價值，可以及早發現問題並加速後
續開發。
• 但⼩⼼不是每個⼈都願意嘗試

68. 實戰經驗分享 - 3 投資單元測試
• 有了實例化需求規格後，撰寫單元測試是非常值得投資的⼯具。
• 優先撰寫⾼價值的測試，並確保成品符合需求。⾏有餘⼒再去補細項的測試。
• 測試成爲⼀種程式的規格⽂件，不但加速 Code Reivew 也讓未來的修改更安
全！
• 我通常會先把所有測資都列出來再⼀⼀實作

69. References

70. Thank You