# 迭代计划

Roles:

- Analyst
- Lead

## 意图

产品经理在迭代计划环节给出一个史诗（epic），作为本规程的输入。
Analyst 是产品分析师，Lead 是技术负责人。
提交之前，意图记录只以完整正文的形式出现在 Analyst 的报告中，不写入仓库；审查结束后，Analyst 把最新版本写入 specs/intents/，并在当前分支上提交为整个规程唯一的一个提交。
审查最多两轮：第一轮审查后若有发现，Analyst 修改后进入第二轮审查；第二轮审查后若仍有发现，Analyst 修改后直接写入并提交，不再审查。
Captain 以仓库效果回执作为该提交的权威标识，不以任何角色的文字为准。

## 外部行为

### sprint-plan-1

Analyst 若向产品经理提出问题，则等待回答，并带着回答继续本条目的起草。

当产品经理给出史诗时，Captain shall prompt Analyst:

> 产品经理为本迭代计划给出了下面的史诗。
> 先阅读 @specs/map.md、相关的规约包、specs/intents/ 中已有的意图记录和代码，理解现状以及史诗涉及的范围。
> 把史诗拆分为三到七个意图，每个意图都能在一个两周迭代内独立交付。
> 为每个意图起草一条意图记录，格式和文件命名遵循 @specs/meta.md 对意图记录的要求，状态为“待处理”，文件位于 specs/intents/ 下。
> 在“意图”一节写明目标和范围边界，范围边界同时说明包含什么、不包含什么。
> 在“验证”一节写出可观察的验收标准，每条都能由测试或演示判定是否满足。
> 按依赖顺序编号：被依赖的意图编号更小，编号接在 specs/intents/ 中已有的最大编号之后。
> 本步不写入或修改任何文件，不提交；意图记录只在你的报告中给出。
> 如果史诗的需求含糊到会改变拆分方式，或无法拆成三到七个意图，先向产品经理提一个问题并等待回答，再起草。
> 报告中按编号顺序给出每条意图记录的文件路径和完整正文，并说明它依赖哪些意图。
>
> > 史诗：<caller-input>

Results:
- `drafted`: Analyst 在报告中给出了全部意图记录的完整正文，没有修改仓库中的任何文件。Output shall include `analystOutput: <verbatim final text>`.

### sprint-plan-2

当 Analyst 起草完意图记录后，在第一轮审查中，Captain shall prompt Lead:

> 第一轮审查开始：产品分析师已把下面的史诗拆分为意图记录，记录的文件路径和完整正文见下方报告，尚未写入仓库。
> 阅读这些意图记录，必要时对照 specs/ 和代码，逐条检查：
> 每个意图能否在一个两周迭代内独立交付；
> 每条验收标准是否可观察、可测试；
> 拆分是否遗漏了史诗中的需求，或超出了史诗的范围；
> 编号是否符合依赖顺序。
> 只提出实质性问题，不提文风或同样可行的替代写法。
> 给出编号的发现；没有发现时明确说明审查完成、没有发现。
> 不修改文件，不提交。
>
> > 史诗：<caller-input>
> > 产品分析师报告：<analyst-output>

Results:
- `hasFindings`: Lead 提出了一条或多条发现。Output shall include `leadOutput: <verbatim final text>`.
- `noFindings`: Lead 明确报告审查完成且没有发现；进度汇报或稍后给出结果的承诺不支持任何审查结果。

### sprint-plan-3

当 Lead 在第一轮审查中提出发现时，Captain shall prompt Analyst:

> 技术负责人审查了你起草的意图记录，发现如下。
> 逐条决定接受或驳回；驳回时给出理由，并引用规约、代码或史诗原文作为依据。
> 对接受的发现修改意图记录；需要时可以合并、拆分或重新编号，但仍保持三到七个意图并按依赖顺序编号。
> 本步不写入或修改任何文件，不提交；修改后的意图记录只在你的报告中给出。
> 报告每条发现的处理结果和每条驳回的理由，再按编号顺序给出修改后全部意图记录的文件路径和完整正文。
>
> > 史诗：<caller-input>
> > 技术负责人发现：<lead-output>

Results:
- `revised`: Analyst 处理完全部发现，并在报告中给出了修改后全部意图记录的完整正文，没有修改仓库中的任何文件。Output shall include `analystOutput: <verbatim final text>`.

### sprint-plan-4

当 Analyst 处理完第一轮发现后，在第二轮审查中，Captain shall prompt Lead:

> 第二轮审查开始：产品分析师已处理你在第一轮提出的发现，处理结果和修改后意图记录的完整正文见下方报告，尚未写入仓库。
> 确认被接受的发现已正确解决，并对每条驳回接受或反驳。
> 同时按原有标准检查是否出现新问题：每个意图能否在一个两周迭代内独立交付；每条验收标准是否可观察、可测试；拆分是否遗漏史诗中的需求或超出其范围；编号是否符合依赖顺序。
> 只提出实质性问题，沿用第一轮的编号，新发现接着编号。
> 给出编号的发现；没有发现时明确说明审查完成、没有发现。
> 不修改文件，不提交。
>
> > 史诗：<caller-input>
> > 产品分析师报告：<analyst-output>

Results:
- `hasFindings`: Lead 提出或保留了一条或多条发现。Output shall include `leadOutput: <verbatim final text>`.
- `noFindings`: Lead 明确报告审查完成且没有发现；进度汇报或稍后给出结果的承诺不支持任何审查结果。

### sprint-plan-5

Captain 以仓库效果回执作为该提交的权威标识，不以任何角色的文字为准。

当 Lead 在第二轮审查中仍提出发现时，不再审查，Captain shall prompt Analyst:

> 这是最后一轮修改：技术负责人第二轮审查的发现如下，修改后直接写入并提交，不再审查。
> 你上一版意图记录的完整正文见下方产品分析师报告。
> 逐条决定接受或驳回；驳回时给出理由，并引用规约、代码或史诗原文作为依据。
> 对接受的发现修改意图记录，仍保持三到七个意图并按依赖顺序编号。
> 把修改后的全部意图记录写入 specs/intents/，不改代码。
> 然后在当前分支上把这些意图记录提交为一个新提交，只暂存这些意图记录文件，遵循 @specs/packages/git.md；不改写任何已有提交。
> 向产品经理报告每条发现的处理结果、提交哈希，以及按顺序排列的意图编号列表。
>
> > 史诗：<caller-input>
> > 产品分析师报告：<analyst-output>
> > 技术负责人发现：<lead-output>

Results:
- `committed`: Analyst 把全部意图记录写入 specs/intents/ 并提交为一个新提交；规程就此结束，向产品经理返回该提交和按依赖顺序排列的意图编号列表。Output shall include `latestCommit: <commit identity>` and `intentNumbers: <按依赖顺序排列的意图编号列表>`.

### sprint-plan-6

Captain 以仓库效果回执作为该提交的权威标识，不以任何角色的文字为准。

当 Lead 在第一轮或第二轮审查中没有发现时，Captain shall prompt Analyst:

> 技术负责人审查通过，没有发现。
> 把下方产品分析师报告中最新版本的全部意图记录，按其中给出的文件路径和完整正文原样写入 specs/intents/，不改代码。
> 然后在当前分支上把这些意图记录提交为一个新提交，只暂存这些意图记录文件，遵循 @specs/packages/git.md；不改写任何已有提交。
> 向产品经理报告提交哈希，以及按顺序排列的意图编号列表。
>
> > 史诗：<caller-input>
> > 产品分析师报告：<analyst-output>

Results:
- `committed`: Analyst 把全部意图记录写入 specs/intents/ 并提交为一个新提交；规程就此结束，向产品经理返回该提交和按依赖顺序排列的意图编号列表。Output shall include `latestCommit: <commit identity>` and `intentNumbers: <按依赖顺序排列的意图编号列表>`.
