Fong - 拒絕再寫無效規格，來學學實例化需求！

這是 Fong 在 Agile Summit 2023 分享的主題。

Fong 的議程對我來說是 Specification by Example 一書的導讀，以前讀過幾次，但總無法理解透徹。經過幾年工作經驗、LeSS in Action 的洗禮，這次再透過 Fong 系統性地串聯，讓我恍然大悟。

本文主要作為紀錄一些關鍵字的筆記，能讓我、或是有些參與者能夠回憶起，當然也參雜了一些我的想法與觀點。日後有機會再針對有感的部分寫成文章吧！

用一個例子來解釋為什麼規格很難讀/寫

• 姊姊大妹妹 4 歲，請問 20 年後他們差幾歲
  • 時區
  • 生日過了嗎
  • 虛歲
  • 姊姊還活著嗎？

規格是什麼

• 規格是傳遞知識的溝通工具，用於同步領域專家跟開發人員
• 無效規格
  • 特徵
    • 範圍不明確 (Scope Creep)
    • 沒有脈絡（上下文）
    • 規則過於抽象
    • 內容組織混亂
  • 原因：由於開發流程與成員心態導致
    • 即時快速迭代可以更快發現錯誤，但不能避免錯誤
      • 如果心態不正確，就算迭代再快，也只是從一大坨大邊，變成很多小顆的大便罷了。
    • 團隊容易陷入究責的困境
• 有效的規格能幫助我們減少重工與錯誤，並正確解決客戶需求
  • 而有效的規格必須是團隊協作下的共識
  • 如何取得共識？
  • 好的範例可以幫助我們了解規格
• 舉例是原始但有效的方式
  • 協作討論 + 用舉例解釋規格 = 實例化需求規格
  • Examples
  • Tests
  • Requirements

關鍵程序模式

從目標中獲取範圍

• 規格 v1
  • User Story
  • AC
• 確保可讀性，確保停在 High-Level，不要太快鑽進細節

協同制定需求規格、舉例說明

• 多出原本期待時，可以拆出新的 User Story
• Example Mapping
  • 探索未知的已知
    • Story
    • Rule
    • Example
    • Question
• 規格 v1.1
  • User Story
  • AC
  • Details & Example

提煉需求規格

• 常見格式
  • 條列式
  • Gherkin: Given-When-Then (流程)
  • 表格
• 規格 v2.
  • User Story
  • AC
  • UI Details
  • Details & Example

不需改需求規格的前提下自動化驗證

• 頻繁驗證

持續演變為說明文件系統

• 把規格書當作權威文件，任何修改都應該回歸到規格書
  • Dev: Details & Example -> Use Case
  • Q&A: TestCAse 文件 + 自動化 E2E 測試
• 規格 Final Version
  • User Story & Background：說明脈絡與原因
  • Acceptance Criteria：範疇，修改頻率最低
  • UI Details：設計相關資訊與設計稿
  • Details & Example：挑選 A.C. 較複雜的部分做實例解說
  • Notes：考量點、Checklist、技術細節、決策歷史、補充資料

是否要演化成活文件

• 反思：有長期價值，但短期要付出很多學習與維護成本