simple-sdd

Simple SDD

核心規矩只有一條：「動手寫程式之前，先把要做什麼寫清楚」。

通用規則

• 寫完要讓使用者確認，使用者同意了才開始寫。
• 每做完一小步就回報。
• 不要一次把所有東西做完。
• 不要一個對話想把所有功能做完；一次做一個就好。
• 不要自己加使用者沒要求的功能，也不要過度設計。
• 沒把握的地方就問使用者，不要用猜的。
• 整個流程分三個階段：提案 → 實作 → 歸檔。使用者會用這三個詞告訴你現在做哪一階段。

階段一：提案

當使用者說「提案」並描述一個需求時：

1. 幫這個需求取一個英文短名稱，小寫、用連字號連接，例如 add-todo、fix-login。
2. 判斷它是哪一種：新功能 / 修 bug / 重構，三選一。
3. 在目前的專案資料夾，也就是現在的工作目錄底下，建立檔案：sdd/<短名稱>/proposal.md，內容包含：
   • ## 為什麼做：這個需求想解決什麼問題
   • ## 要改什麼：會新增或改動哪些行為，用條列
   • ## 影響範圍：大概會碰到哪些檔案，包含新增的、要改的
4. 再建立檔案：sdd/<短名稱>/tasks.md，把工作拆成一條一條可以打勾的小步驟，每一條前面用 - [ ]。
   • 每一條要小到 1 小時內能做完。
   • 整份不要超過 10 條；如果超過，代表這個需求太大，提醒使用者先拆小一點。
5. 在 tasks.md 最後加一段 ## 驗收條件，用白話的「情境」描述「做完之後應該長怎樣」，格式如下：
   • 情境：當使用者點擊「新增」按鈕，就把輸入框的文字加到清單最下面
   • 情境：當輸入框是空的就按新增，就不新增，並提示「請先輸入內容」

這就是驗收標準，之後要照這個自我檢查。寫完這兩個檔案後，把重點貼給使用者看，然後停下來等使用者確認。除非使用者說「開始實作」，否則不要寫任何程式。

階段二：實作

當使用者說「實作」時：

1. 先讀 sdd/<短名稱>/proposal.md 和 tasks.md 這兩個檔案，搞清楚要做什麼。
2. 從上到下，一次只做 - [ ] 裡的一條任務。每做一條之前，先看看專案裡有沒有現成的東西可以重複使用，不要重複造輪子。
3. 做完一條之後，在打勾之前回頭再讀一次那條任務和「驗收條件」，確認真的做到了、沒有漏。確認沒問題就把該條的 - [ ] 改成 - [x]。改完後再看一眼 tasks.md，確認那一行真的從 - [ ] 變成 - [x] 了。
4. 每完成一條就簡短回報「第幾條完成」，然後做下一條。
5. 如果做到一半發現規格漏了東西或方向不對，停下來告訴使用者，等使用者決定，不要自己亂改規格、也不要硬幹。
6. 全部打勾後，告訴使用者「全部完成」，並請使用者驗收。

階段三：歸檔

當使用者驗收沒問題、說「歸檔」時：

1. 打開 sdd/<短名稱>/tasks.md，確認每一條都是 - [x]。如果還有沒打勾的，先告訴使用者，不要直接歸檔。
2. 確認都完成後，把整個 sdd/<短名稱>/ 資料夾移動到 sdd/archive/<今天日期>-<短名稱>/，日期格式 YYYY-MM-DD。
3. 回報歸檔完成，並用一句話總結這次做了什麼，方便使用者以後回頭查。