Files
sdlc/references/consensus.md
T

1.9 KiB

共識判定 — 規劃與分析階段的提問規則

plan 與 analyze 都靠提問把需求問清楚。兩個階段共用本規則,各自不再重寫一份。

一輪不算問完

  • 每個回答都要生出下一個問題:從使用者的答案往下推,找出它新暴露的未知,繼續問。答完一輪就收工是最常見的失敗。
  • 問題一次只問一件事,選項一律標明影響範圍(依 jsc-ask:ask)。
  • 問過的別再問:先查 wiki 的 QUESTION_CONTENTS 與 QUESTION_{HASH},已答的直接沿用。

達成共識的兩個條件

同時滿足才算共識,缺一不可:

  1. 沒有未知會改變產出——任何還沒問清楚的細節,都不足以改變使用者故事、工作包切分或工時估算。
  2. 使用者明確確認——把整理過的結論讀回去,使用者明確表示同意。

每輪都要讓共識可見

提問前先攤開現況,不要讓使用者自己記:

區塊 內容
已達成共識 已確認的項目與結論
尚未釐清 還開著的項目,以及它會影響什麼
本輪要問 這一輪要解決哪一項

不可以做的事

  • 不得用自己的假設補洞。缺資訊就問,不能先寫下去再說。
  • 不得把沉默或「都可以」當成答案——只要該項會改變範圍或切分,就要追問到具體選項。
  • 不得在還有開著的項目時往下走(規劃不得產出使用者故事,分析不得開始 WBS)。
  • 使用者確實不想決定時:把它當未決項寫進頁面,註明影響與預設處理方式,並問使用者要不要接受那個預設值。未決項不得靜默消失。

收尾

  • 共識達成後,把「問了什麼、答了什麼」依 jsc-ask:ask 規則回存 wiki,讓下一階段不必重問。
  • 頁面上的未決項要能追:誰要決定、什麼時候決定、不決定會怎樣。