# 15. 项目与交付常识

这一章讲把事从想法送到线上的通行做法：怎么选交付方式、怎么管住范围和变更、怎么排期应对不确定、怎么上线和复盘。它关心的是「事情能不能稳定地做出来」。

条目按从最基础到进阶排列。

---

### 1. 瀑布与迭代各自适合什么条件
- 定义：瀑布式按需求、设计、开发、测试、上线的顺序推进，前期把范围定死；迭代式把工作切成多个小周期，边做边调整范围。前者适合需求稳定、变更代价高的项目，后者适合需求不确定、需要快速拿到反馈的场景。
- 说人话：盖楼适合先画完图纸再施工；做个没人见过的新功能，不如先做一小版给用户试，错了改起来便宜。
- 什么时候用：选交付方式时，先判断需求稳不稳、变更贵不贵、要多久才能拿到反馈。
- 常见误区：把「敏捷」当口号，需求天天变却仍按固定范围承诺日期；或不管场景一律要求先写全文档。
- 证据等级：B
- 来源：Winston Royce（瀑布模型）；敏捷宣言

### 2. 敏捷宣言的四条价值观与常见误用
- 定义：敏捷宣言强调：人和协作重于流程和工具，可用的软件重于完备的文档，客户合作重于合同谈判，响应变化重于遵循计划。右项也有价值，只是更看重左项。
- 说人话：不是不要文档、不要计划，而是别让它们压过「把事情真正做出来、做对」。
- 什么时候用：团队把站会、看板当成仪式却不见成果时，回到这四条看偏离在哪。相关验证思路见第 10 章第 2 条。
- 常见误区：把敏捷等同于「没有计划、随时改」；用每日站会、故事点这些形式，替代了对交付和反馈的追求。
- 证据等级：B
- 来源：敏捷宣言（Agile Manifesto）

### 3. 需求管理与变更控制
- 定义：需求管理指把需求记录下来、追踪其状态和来源；变更控制指改动要走约定流程：说清为什么改、影响多大、谁批准、什么时候进。
- 说人话：不是不许改，而是改了要留痕、要评估代价、要有人点头，避免需求在口头之间悄悄变形。
- 什么时候用：项目进行中频繁插入新需求，或各方对「当时说好的是什么」各执一词时。
- 常见误区：把变更控制做成层层审批的负担，团队干脆绕过流程私下改；或完全没有记录，最后无人说得清原委。
- 证据等级：C
- 来源：行业通行做法（需求管理与变更控制）

### 4. 估算与故事点的意义
- 定义：估算给出「大概要多久、多难」的判断；故事点用相对大小表示工作量，而不是绝对人天，目的是让团队对复杂度形成共识、提高估算的稳定性。
- 说人话：故事点像给任务标「比那个大两倍」，衡量的是相对大小；硬报人天，来自不同的人一凑就打架。
- 什么时候用：团队要排期、分派任务，或发现估算总是不准时。
- 常见误区：把故事点换算成固定人天去考核；把估算当承诺，谁估得准谁吃亏，导致集体往高里估。
- 证据等级：C
- 来源：行业通行做法（相对估算与故事点）

### 5. 排期与缓冲
- 定义：排期把工作落到时间上；缓冲是针对不确定性预留的时间，用来吸收估算误差、依赖延迟和突发问题，而不是给偷懒留空间。
- 说人话：路上总会堵车，按平均速度算路程必然迟到；留一点余量，才不至于一出意外就全线崩。
- 什么时候用：制定对外承诺的日期、面对多方依赖，或做首次尝试的新任务时。
- 常见误区：把缓冲当成可以随意消耗的余量；或反过来一分不留，对外承诺最乐观的日期。
- 证据等级：C
- 来源：行业通行做法（排期与缓冲）

### 6. 关键路径与依赖管理
- 定义：关键路径是项目中最长的那条任务链，它决定最短完工时间；依赖指任务之间「谁必须先做」的关系，跨团队依赖是最常见的风险源。
- 说人话：一环拖了，整条链跟着拖；你这条早做完了也没用，因为要等别人先交东西。
- 什么时候用：排整体计划、判断「晚几天会不会影响上线」时，盯住关键路径和外部依赖。
- 常见误区：把注意力平均分给所有任务，忽略真正卡住工期的那条链；对跨团队依赖只在临近才去催。
- 证据等级：C
- 来源：行业通行做法（关键路径法 CPM）

### 7. 三类评审会（需求、设计、技术）
- 定义：需求评审确认「要做什么、为什么」；设计评审确认方案怎么呈现和交互；技术评审确认怎么实现、风险在哪、工期如何。三者关注点不同，不能合并成一次走过场。
- 说人话：需求会问「做的是对的事吗」，设计会问「用户看得懂吗」，技术会问「做得出来吗、贵不贵」，各问各的。
- 什么时候用：进入开发前逐层过一遍，越早发现分歧，返工代价越低。
- 常见误区：只开需求会就开工，把设计和技术的隐患留到开发中暴露；或只走流程不记录结论和待办。
- 证据等级：C
- 来源：行业通行做法（多类评审会分工）

### 8. 完成的定义（DoD）与质量门禁
- 定义：DoD（Definition of Done，完成的定义）是团队对「一个任务算做完」的统一标准，如通过测试、有文档、埋点到位；质量门禁是进入下一阶段前必须达成的检查项。
- 说人话：别等「我以为做完了」和「你没验收」互相扯皮，事先说好做完要满足哪几条。
- 什么时候用：团队对「完成」理解不一、频繁出现返工，或上线后才发现漏项时。
- 常见误区：DoD 写成一句「功能可用」的空话；或标准定得过高，小改动也要走全套，拖慢交付。
- 证据等级：C
- 来源：行业通行做法（Scrum 中的 DoD）

### 9. 上线与回滚
- 定义：上线是把新版本发布给用户；回滚是发现问题时退回旧版本。回滚预案（怎么退、退到哪、谁决策、多久能退）是上线方案的一部分，不是事后补的。
- 说人话：出门前先想好万一钥匙丢了怎么回家；上线前先想好万一出问题怎么退回去。
- 什么时候用：任何影响线上用户的发布，尤其是改动大、不易测试周全的时候。
- 常见误区：假设「这次应该没问题」而跳过回滚方案；或数据已经变更，才发现回滚会丢掉新产生的数据。
- 证据等级：C
- 来源：行业通行做法（发布与回滚预案）

### 10. 灰度发布
- 定义：灰度发布是先把新版本开放给一小部分用户，观察指标平稳后再逐步扩大范围，出现异常可以随时回退或停止。
- 说人话：先让一百个人用，看崩溃、留存、投诉有没有反常，没问题再扩到一成、一半，比一次全量上线安全得多。
- 什么时候用：改动影响面大、测试环境覆盖不到真实用户行为时。逐步放量的细节见第 10 章第 7 条。
- 常见误区：灰度只看有没有报错，不看核心指标；或放量节奏太慢，样本迟迟不够，白等一场。
- 证据等级：B
- 来源：行业通行做法（灰度发布）

### 11. 事故分级与无指责复盘
- 定义：事故分级按影响范围、严重程度和持续时间把故障分档，决定响应的紧急度和投入；无指责复盘（blameless postmortem）关注流程和系统哪里出了漏洞，而不是追究个人。
- 说人话：先定这次到底多严重，才知道要不要半夜拉起所有人；复盘的目的是下次别再犯，而不是找出一个人来背锅。
- 什么时候用：发生线上故障之后；以及团队因怕担责而隐瞒问题、复盘流于形式时。
- 常见误区：把复盘变成批斗会，结果大家越报越少；或只写「加强测试」这类空话，不落到具体改动。
- 证据等级：B
- 来源：行业通行做法（事故分级；无指责复盘 / blameless postmortem）