第8章 项目启动之前
把项目启动视为需求学习、约束澄清、共同构建和反馈适应的过程。
学习目标
- 能把需求当作与用户共同学习的反馈过程，并识别未确认的假设与隐藏约束
- 能用结对协作、项目术语和小步交付让知识在工作中流动，而不是等待交接
- 能在边界需求、约束冲突和反馈失效时记录首个偏差、回退路径和适应性调整
为什么第8章项目启动之前值得单独学习
↡通过提问、样例、反馈和共同工作逐步确认用户真正需要什么，而不是把第一份需求文档当成最终真相。第8章项目启动之前把“需求”从一次性输入改成持续学习。提示 75 至 80 讨论人们未必能准确说出想要什么、程序员如何帮助澄清、需求如何从反馈循环中形成，以及策略和项目术语如何保持可变。
订单向导能暴露这个边界：用户说“支持保存草稿”，可能真正需要的是跨设备恢复、权限隔离、过期提示或可撤销提交。与其立即把一句话写成固定接口，不如先用最小可运行切片和真实用户反馈验证假设。
↡把事实、假设、资源、法规、时间和技术限制分开记录，并说明哪些条件可以改变、哪些条件必须接受。“找到框框”不是放弃创新，而是把不可变约束与自设限制分开。若团队不知道容量、隐私、期限和权限的来源，任何估算都只是精确的猜测。
先建立直觉：共同工作比事后移交更早暴露误解
↡让两名或多名参与者围绕同一个问题即时观察、提问和修改，使隐含知识在工作过程中流动。结对不等于固定座位或轮流敲键盘；它的价值在于让用户、开发者、测试者或领域专家共同看到假设如何变成可观察行为。
↡把观察、反馈、调整和再次验证组织成短周期，让团队在变化发生时修正方向。敏捷的本质不是仪式名称，而是缩短从决策到反馈的距离。反馈更快不代表价值更高，还要检查缺陷、用户结果和团队负担。
↡让团队对领域词、状态、动作和边界使用同一含义的共享词汇表，减少需求与实现之间的翻译损失。项目术语表不是文档装饰。它应记录一个词的含义、拥有者、例外和拒绝条件；当词义变化时，影响范围应能被追踪。
先预测：产品经理说“用户可以随时撤回订单”，开发者能否直接把它实现成一个按钮？不能。先确认撤回窗口、已付款状态、库存副作用、审计要求和用户提示，再用一条可运行反馈验证最小语义。
目录单元到教学证据
45 需求之坑
需求不是客户交给团队的一次性包裹。要记录提问、样例、反馈和决策如何改变当前模型；如果用户不能说出最终答案，团队的职责是帮助用户发现约束和选择，而不是假装已经得到完整规格。
46 处理无法解决的难题
面对看似无解的问题，先列出 Constraint Frame：事实、假设、资源、法规、期限和自设限制。改变可变条件、缩小范围或重新定义目标前，记录哪些边界不能被绕过。
47 携手共建
使用 Pairing 让需求、设计、实现和测试在同一工作流中互相校正。即时反馈应产生工件，例如样例、决策记录、失败日志或术语变化，而不是只留下“大家同意”的会议结论。
48 敏捷的本质
Adaptive Feedback 关注如何做事：小步交付、观察结果、调整假设。团队可以采用不同工具和节奏，但必须能说明反馈如何改变决策，以及哪些质量和用户价值边界不能被速度换走。
三步项目启动路径
先发现需求与约束
把用户目标写成可观察场景，区分事实、假设和 Constraint Frame；用一个失败样例暴露不能接受的状态，不急着承诺完整功能。
从需求到反馈的因果链
项目启动链是 目标探索 → 约束识别 → 共同工作 → 小步反馈 → 适应调整。每条边都要记录传递对象、所有者、进入条件和失败升级；只有箭头没有证据，无法说明某次调整究竟解决了什么。
反馈与边界
反馈循环要同时覆盖正常请求、边界状态和依赖不可用。若反馈更快但用户误解、缺陷或伦理风险增加，团队应缩小切片、改变假设或回退，而不是继续增加仪式。
专属案例：订单撤回需求
产品团队说“用户可以随时撤回订单”。先用 Requirement Discovery 询问撤回时点、支付状态、库存占用、发票和审计；再用 Constraint Frame 标记不可逆副作用。产品、开发和测试 Pairing 设计一个只覆盖待支付订单的切片，项目术语表明确“撤回”“取消”“退款”的区别。
case:
claim: 用户可以撤回订单
assumptions:
- 待支付订单可以释放库存
- 已支付订单需要退款流程
boundary: 已发货订单不允许直接撤回
feedback: 一条待支付订单的可运行撤回路径
evidence: 用户确认、状态日志、库存变化、审计记录
rollback: 发现库存或权限异常时关闭入口并恢复原状态这张记录把“需求”变成可验证假设。它不假装所有业务细节已经确定，而是让每次反馈明确改变了哪个状态、谁接收结果、哪些条件仍未覆盖。
选择与拒绝矩阵
| 评审问题 | 选择本章实践的证据 | 应拒绝当前做法的信号 |
|---|---|---|
| 需求 | 用户场景、假设和反馈变化可追踪 | 需求文档被当成永远不变的规格 |
| 约束 | Constraint Frame 区分事实、假设和自设限制 | 团队只说“无法做到”，没有约束来源 |
| 协作 | Pairing 产生样例、决策或失败工件 | 知识等到交接或评审才流动 |
| 反馈 | Adaptive Feedback 改变下一步决策 | 只测速度，不看缺陷、用户价值和安全 |
| 词义 | Project Glossary 记录状态和拒绝条件 | 同一个词在产品、代码和测试中含义不同 |
常见误区
本章回顾
掌握第8章项目启动之前的标志，不是记住“敏捷”这个词，而是能沿着“目标探索 → 约束识别 → 共同工作 → 小步反馈 → 适应调整”解释一个真实需求如何从假设变成证据。Requirement Discovery 发现真正目标，Constraint Frame 暴露限制，Pairing 让知识流动，Adaptive Feedback 让错误假设变便宜，Project Glossary 保护共同语义；任何环节缺少边界和回退，都应拒绝当前方案。
可验证练习
练习
问题 1： 用户说“随时撤回订单”，项目团队应先问哪些问题？
问题 2： 团队采用短周期交付后，反馈更快但线上缺陷增加，下一步怎么做？
问题 3： 产品、开发和测试对“取消”“撤回”“退款”的含义不同，如何处理？
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- Requirement Discovery
通过提问、样例、反馈和共同工作逐步确认用户真正需要什么的过程。
- Constraint Frame
区分事实、假设、资源、法规、时间和自设限制并标记可变性的记录框架。
- Pairing
让参与者围绕同一问题即时观察、提问和修改，使隐含知识在工作中流动。
- Adaptive Feedback
通过短周期观察、调整和再次验证来面对变化的反馈方式。
- Project Glossary
记录领域词、状态、动作、例外和拒绝条件的共享词汇表。
前后导航
来源与改写范围
- Pragmatic Programmer 作者页面：核对第 8 章主题与版本信息。
- 中文目录页面：核对第 8 章、Topic 45–48 与提示范围。
- 出版社书目信息：交叉核对中文译本出版信息与版本边界。