〇、完整研发流程：从需求线索到版本效果
阅读方式：本章说明需求与规划；快速上手串联单任务操作；第二章明确开工准备；第三至八章展开实施、审查、发布和治理；第十章用于核对，附录 A 提供模板，附录 B 说明公开方法依据。全文可独立阅读。流程状态、角色分工和检查要求是本文的综合建议，须经团队采纳并接入实际机制后生效。
0.1 全流程与责任分工
研发从识别问题开始，以交付后的效果核验形成反馈。需求发现可以与当前迭代的交付并行；新证据可以使条目退回澄清、重新排序或取消，不要求所有需求一次性完成设计。
| 环节 | 主责与参与者 | 最小产物 | 转入下一步的条件 |
|---|---|---|---|
| 收集、分类与初审 | 产品负责人或具名需求负责人；业务、客服、研发提供线索 | 需求条目及来源 | 问题、对象、归属可辨认；紧急事项已分流 |
| 需求澄清 | 需求负责人牵头；设计、领域专家、研发参与 | 问题证据、范围、验收草案、未决项 | 能说明为何做、如何判断有效，以及还不知道什么 |
| 排序与取舍 | 产品或业务负责人决定价值顺序；技术负责人说明风险与依赖 | 有序候选队列及取舍理由 | 已区分必备条件、普通收益与待验证假设 |
| 迭代与版本规划 | 交付团队评估容量；负责人确认目标与对外承诺 | 迭代计划、版本计划 | 依赖、资源、审查与验证时间可安排；不超售容量 |
| 研发与验收 | 执行 Agent、研发、独立审查者及领域责任人 | 实现、审查结论、受测证据 | 满足该切片及目标环境的完成条件 |
| 发布与效果评估记录 | 发布负责人、运维负责人、需求负责人 | 部署回执、效果记录、后续需求 | 发布事实与业务效果分别核验，剩余问题有归属 |
同一人可承担多个角色，但仍须遵守现有独立审查、权限和审批要求。Agent 可以整理反馈、检索证据、提出排序及估算建议；不得编造访谈、使用量或收益，也不得自行代表团队承诺发布日期。
0.2 需求收集：统一入口，保留原始证据
建立一个可检索的需求池，复用团队已有 Issue、任务系统或文档索引，不要求另购工具。每条线索先记录“谁遇到什么问题”，再讨论实现方案。需求发现应持续结合用户问题、业务目标和反馈，而非只在开发前做一次需求交接。方法依据：Atlassian Product discovery
| 需求来源 | 最少记录的信息 | 常见误判 |
|---|---|---|
| 用户访谈、客服反馈、实际操作观察 | 来源链接、日期、用户角色、触发场景、影响及现有替代操作方式 | 把某位用户提出的按钮或页面直接当成最终方案 |
| 业务目标与对外承诺 | 目标、责任人、期限依据、未完成的后果 | 把期望日期写成已经确认的交付承诺 |
| 故障、安全或账务问题 | 可核查的现象、影响范围、复现或运行证据、处置状态 | 把未经验证的推测直接写成已确认根因 |
| 研发与运维技术债 | 失败记录、人工成本、阻塞的能力、现有权威条目 | 只按 todo!() 数量或代码行数判断欠账轻重 |
| 技术探索与新机会 | 待验证假设、潜在价值、验证成本、停止条件 | 把技术可行或模型演示成功等同于用户需要 |
原始反馈、合并后的需求、实施任务与目标版本保留关联；同一需求可拆成多个任务，多个任务也可共同支撑一个版本。发现问题不成立时可以关闭条目，无需为关闭而进入开发。
每条需求至少包含：稳定 ID、问题描述、受影响对象、来源、需求负责人、当前状态、关联目标、期限及其依据、已知依赖、下次处理动作。合并重复项时保留原来源；敏感客户材料只留受控引用。
分类与初审后可进入“待澄清、候选、待决策、暂缓、拒绝”等状态。暂缓与拒绝须说明理由；暂缓项还应注明复查日期或触发条件。生产事故和已确认的紧急风险按现有应急流程处理，不等待普通需求评审；应急处置仍须保留任务与证据记录。
0.3 需求澄清：把问题转成可验证的交付目标
对准备进入近期规划的条目，补齐以下信息；远期想法只保留足够判断是否继续投入的材料。
- 问题与证据：当前行为是什么，影响谁，发生频率或影响量如何，证据有哪些局限。
- 目标与效果：希望用户或业务获得什么结果；记录可观测指标、当前基线、目标值及观察窗口。暂无基线时先安排采集，不填猜测数值。
- 范围与非目标：本次支持的角色、环境、业务路径及明确不包含的内容；涉及界面时说明用户流程、交互状态与无障碍要求。
- 验收与约束：成功、失败、权限和恢复场景；金额、隐私、资源或性能边界。
- 未决与依赖：需要由谁作出决策、依赖哪些接口或外部资源；阻塞的是哪一部分。
不确定性较大时，先安排限时调研、原型或技术验证，写清预算、问题和退出条件。验证结果应能支持继续、调整或停止；涉及新交互流程时，可通过原型或可用性测试验证方案。原型须经过正式设计、审查与验收后，才能作为生产实现交付。
进入实现的准备条件：需求负责人明确、目标与验收可判定、关键决策有效、阻塞依赖已解决或有可执行安排、验证入口与环境可获得。它是本文建议的开工检查，不是 Scrum Guide 规定的统一“Definition of Ready”，也不要求每项探索都提前写完完整规格。进入编码后，按 §2.3 与快速上手六步法执行。
0.4 优先级排序：先判断约束，再比较收益
优先级、变更风险和准备状态是三个独立维度。 L3 决定审查与验证深度，不自动等于“马上做”；高收益也不能覆盖安全红线或绕过依赖。编号、评分和排列顺序均不能代替正式业务决策。
建议按以下顺序讨论候选队列，具体紧急等级沿用项目定义：
| 类别 | 排序依据 | 需要留下的记录 |
|---|---|---|
| 紧急处置与硬性期限 | 已确认的事故影响、约束或承诺期限，以及延迟的后果 | 事实依据、负责人、处置时限、被挤出的计划 |
| 当前目标的必备条件 | 不完成就无法验收或发布的能力、必须先完成的决策和满足的依赖 | 被阻塞的目标、前置链、最小可交付范围 |
| 普通功能与改善 | 用户价值、覆盖范围、证据强度、总投入及维护成本 | 比较口径、估算依据、最终取舍 |
| 探索与远期机会 | 不确定性、潜在价值、获得新证据的成本 | 验证预算、复查条件、是否进入近期队列 |
对同类、可比较的普通需求，可选用 RICE：覆盖范围 × 影响程度 × 置信度 ÷ 投入。覆盖范围使用相同统计窗口，影响针对同一目标，投入采用相同单位；置信度应来自证据，不能直接取模型自评。Intercom 明确指出，依赖项和必备能力可以先于高分项，分数不应成为僵硬的执行规则。方法依据：Intercom RICE
本文建议：缺少可比数据时使用说明理由的序数排序，不制造精确小数；对投入区间做敏感性检查，若轻微调整就改变排名，应先补证据。需求负责人记录最终顺序及偏离评分的原因；待决策项安排澄清动作，不让执行 Agent 靠猜测解除阻塞。
0.5 迭代排期：按完整交付容量承接工作
排期回答的是“在本轮可用资源下，能够完成哪个结果”。采用固定迭代或持续流动均可，但应明确规划周期、进度检查和重排时机。Scrum Guide 将迭代预测与历史表现、即将可用的容量和完成标准联系起来；这不等于按人数平均分配任务。方法依据：Scrum Guide，Sprint Planning
本指南建议按以下步骤编排：
- 确定本轮目标：用一句用户或业务结果表达，避免只列文件或提交数量。
- 盘点真实容量：列出人员可用时间、值班与请假、领域审查窗口、测试环境、CI 及外部服务约束。编码、评审、修复、集成和发布准备均计入；同一开销不得重复扣减。
- 按依赖选择切片：先安排阻塞关键路径的工作；确认依赖允许、责任明确且资源不冲突的切片才并行。跨仓工作明确契约提供方、消费方、联合验收责任人和集成节点。
- 给出估算区间与假设：区分工作量与日历时长。没有历史数据时先交付小批次建立基线，不用 Agent 数量、Token 预算或生成速度直接推算工期。
- 限制在制工作：按实际瓶颈设置开发、审查、验证的在制上限。评审或测试积压时优先疏通，不继续大量开新任务。DORA 的 WIP 方法强调看见从分析到运行的全部工作，而非只限制编码列。方法依据：DORA WIP limits
- 保留变更空间：依据历史插单、返工与运行支持负荷留出容量，比例由团队实际数据决定，不统一规定一个百分比。
迭代开始后，持续记录剩余工作、阻塞及新增证据。插入紧急项时同时说明移出或延期什么；若目标失效，由有权负责人决定重排或终止。普通计划调整不降低质量门槛，也不自动修改业务规格。
迭代结束时，分别记录已实现、已验证、已合入、已部署和未完成内容。未完成项根据剩余工作与最新优先级重新评估，不默认为下一轮必做，也不把部分完成计作验收通过。复盘至少选出一项可执行改进，明确负责人、验证方式和复查时间。
0.6 版本规划：分清方向、目标窗口与发布事实
| 规划层次 | 回答的问题 | 建议记录的内容 |
|---|---|---|
| 产品路线图 | 接下来先解决哪些问题 | Now / Next / Later 或较粗时间窗口、目标、依赖、信心与变更原因 |
| 版本计划 | 哪个交付组合面向哪些用户和环境 | 版本目标、必备范围、可调整范围、非目标、目标窗口、退出条件与责任人 |
| 迭代计划 | 本轮能完成什么 | 可用容量、已选切片、依赖顺序、验证与审查安排 |
| 发布清单与回执 | 实际验收并发布了什么 | 受测 SHA、制品摘要、配置和迁移组合、部署结果及剩余范围 |
Atlassian 建议路线图保持对目标和策略的关注，可使用月度、季度窗口或 Now / Next / Later，避免把远期探索过早写成精确日期承诺。方法依据：Atlassian Agile roadmaps
本文建议区分“探索中的方向、基于当前信息的预测、已确认的外部承诺”，记录承诺主体和依据。有固定日期约束时先划定必备范围，再调整可选项；有固定范围约束时，应让时间预测反映真实容量和依赖。无法兼顾时公开取舍，不以压缩验证或隐藏 OPEN 项维持表面进度。
版本计划至少说明：
- 发布对象与环境：内部演示、受控试用、staging 或生产；面向谁开放哪些能力。
- 范围与退出条件：必备能力、可调整项、明确非目标，以及各项业务和运行验收。
- 版本组合与依赖：涉及的仓库、接口与消费者兼容关系、迁移顺序、配置及运行时前提；多仓允许不同版本号，但组合必须可追溯。
- 窗口与责任：目标窗口、预测依据、最迟决策点、发布负责人及运维负责人。
- 停止与恢复：何种结果阻止发布，何种运行异常触发停止或恢复，谁作出判断。
- 效果观察：发布后何时、由谁核对需求目标，使用什么数据及指标。
研发中维护的是可调整计划；发布准入时按第七章固定 Release Manifest，发布后记录实际回执。一个版本可以跨多个迭代，一个迭代也可以产生多个可发布增量；迭代结束不自动证明版本可发布。
0.7 发布后的效果验证与需求回流
工程验收说明实现是否符合约定，效果验证说明约定的方案是否解决了问题，两者分别记录。对每个主要版本目标，核对发布前基线、观察窗口、目标用户覆盖、实际使用与失败情况；样本不足或归因不清时写“尚不能判断”，不能只凭发布前后的数值变化归因。
未达目标时，由需求负责人结合用户反馈、使用数据和运行问题，决定继续观察、改善、缩小范围或退出。研发复盘发现的测试、契约、工具和运维技术债进入同一候选队列，与功能需求一起接受取舍；事故修复仍按既有紧急机制执行。已部署但尚在观察中的需求可以关闭工程交付子项，同时保留效果评估项及负责人。纯文档、工具等无需部署的成果，在使用或交接后核对其目标；不适用的运行指标注明理由。退出已发布能力时，按 §7.4 处理使用方、数据与资源的收尾。
建议按约定周期复查需求池，关闭已失效或重复的条目，并通知相关提出方；涉及通知动作时，Agent 遵守现有授权范围。本节规定的是工作记录方式，不要求 Agent 自动向外部系统发消息。
0.8 采纳方式与状态衔接
本指南描述完整流程，团队可按风险、规模和实际交付形态裁剪。首次采纳时明确负责人、状态含义、验证入口和例外处理；已有等价机制可直接映射，无需额外建立一套台账。重要信息可以集中在同一份任务或设计文档的不同章节，不要求每种记录各建一个文件。
| 记录对象 | 建议区分的状态或信息 | 不能据此推断的结论 |
|---|---|---|
| 需求 | 待澄清、候选、待决策、已选入、暂缓、拒绝或关闭；记录理由与下一步 | 已选入不代表承诺发布日期 |
| 决策与规格 | 草案、已接受、当前有效、已替代；保留适用范围和替代关系 | 已接受不代表实现或验证完成 |
| 实施任务 | 待开始、进行中、受阻、待验收、已完成；同时记录切片范围 | 某切片完成不代表整个需求完成 |
| 工程交付 | 已实现、已验证、已合入、已部署分别记录版本与证据 | 合入不代表发布，发布不代表业务目标达成 |
| 版本 | 规划中、候选、准入通过、发布中；结果区分成功、失败、部分完成与结果未知，恢复状态单独记录 | 计划窗口不代表实际发布时间 |
| 效果评估 | 未观察、观察中、已达目标、未达目标或尚不能判断 | 样本不足不能记为成功 |
上述状态描述不同对象，不能混成一条线性进度条。团队可以沿用自己的名称，但须明确转入、退出条件和决定人。OPEN 表示尚未解决的事项，不是风险豁免；每项应记录影响、负责人、后续动作及是否阻断当前验收或发布。仅非阻断事项可在有权负责人接受后留待后续处理。
本文统一使用以下术语：候选源码版本标识待审查的代码；受测输入摘要覆盖源码、配置、夹具、契约等实际验证输入；发布制品组合标识准备部署的不可变产物及配套配置、迁移；部署回执记录实际执行结果。这四者相互关联，不能相互替代。