Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1.9 KiB
1.9 KiB
共識判定 — 規劃與分析階段的提問規則
plan 與 analyze 都靠提問把需求問清楚。兩個階段共用本規則,各自不再重寫一份。
一輪不算問完
- 每個回答都要生出下一個問題:從使用者的答案往下推,找出它新暴露的未知,繼續問。答完一輪就收工是最常見的失敗。
- 問題一次只問一件事,選項一律標明影響範圍(依
jsc-ask:ask)。 - 問過的別再問:先查 wiki 的
QUESTION_CONTENTS與QUESTION_{HASH},已答的直接沿用。
達成共識的兩個條件
同時滿足才算共識,缺一不可:
- 沒有未知會改變產出——任何還沒問清楚的細節,都不足以改變使用者故事、工作包切分或工時估算。
- 使用者明確確認——把整理過的結論讀回去,使用者明確表示同意。
每輪都要讓共識可見
提問前先攤開現況,不要讓使用者自己記:
| 區塊 | 內容 |
|---|---|
| 已達成共識 | 已確認的項目與結論 |
| 尚未釐清 | 還開著的項目,以及它會影響什麼 |
| 本輪要問 | 這一輪要解決哪一項 |
不可以做的事
- 不得用自己的假設補洞。缺資訊就問,不能先寫下去再說。
- 不得把沉默或「都可以」當成答案——只要該項會改變範圍或切分,就要追問到具體選項。
- 不得在還有開著的項目時往下走(規劃不得產出使用者故事,分析不得開始 WBS)。
- 使用者確實不想決定時:把它當未決項寫進頁面,註明影響與預設處理方式,並問使用者要不要接受那個預設值。未決項不得靜默消失。
收尾
- 共識達成後,把「問了什麼、答了什麼」依
jsc-ask:ask規則回存 wiki,讓下一階段不必重問。 - 頁面上的未決項要能追:誰要決定、什麼時候決定、不決定會怎樣。