四份規則正本,各自列出要對著需求議題回答的檢查項,回答不出來的就是一個要問 使用者的問題。每份末尾都交代「問題怎麼問」——檢查項只說要查什麼,不說怎麼把 它變成一句能收斂的提問,那才是實際卡住的地方。 四份各自點出一個最該先問的:架構問落點與循環相依,邏輯問既有功能是不是已經 做過同一件事(這條能整個取消工作),資料問 schema 與遷移(答案通常不在議題裡), 時程問未知數最大的一項(它決定整體估算的可信度)。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.1 KiB
1.1 KiB
時程可行性檢查
問的是「要多久、哪一段最可能爆炸」。
檢查項
- 相依鏈最長路徑 — 把工作依相依關係排開,最長的那一條有多長? 那條路徑上的每一項都非做不可嗎?
- 未知數最大的一項 — 哪一項的估算最沒把握?它為什麼沒把握——是不熟的技術、 不明的既有程式碼,還是等別人回覆?
- 可平行的部分 — 哪些工作彼此沒有相依、可以同時進行?
- 外部相依 — 有沒有卡在別的團隊、別的服務、或需要權限開通的事? 那些事的前置時間是多久?
- 可切分性 — 這個需求能不能先交付一部分就對使用者有價值? 若能,第一刀切在哪裡?
- 驗證成本 — 做完要怎麼驗?驗證本身要花多少時間(需要造資料、需要別人配合)?
問題怎麼問
先問「未知數最大的一項」,因為它決定整體估算的可信度。 把每一項的人天估算記下來,之後 sdlc-report 會拿它跟實際工時比對。