第3章 一趟列车的完整旅程：从需求到发布

第 3 章 · 一趟列车的完整旅程：从需求到发布

章节摘要：选好运行图，本节跟着一趟具体的版本列车从始发站跑到终点站——需求怎么核对上车、设计怎么画车厢图纸、编码怎么装配、测试怎么联调试跑、发布怎么正点离站、上线后怎么运营返修。这是全书的主干线：前面两章的模型与角色，在这里变成具体的工程动作；后面三章的调度、安检、机务，都是为这段旅程保驾护航。每节都以"进出站条件"为骨架——前一环节交付什么，后一环节才有权开工，这是把"软件工程"从名词变成动词的地方。

学习目标

读完本章，你应当能够：

1. 写出一条合格的需求条目：有编号、有验收标准、可追溯，并说清它和"客户一句话"的差别。
2. 在概要设计与详细设计之间划分职责，用一张分层图表达模块边界与依赖方向。
3. 执行一次有记录的代码走查，列出走查清单上至少五个检查点。
4. 按测试金字塔分配用例，区分单元、集成、系统、验收四级试跑各自要回答的问题。
5. 编制一份发布检查单，设计灰度与回滚方案，说清"可回退"为什么优先于"不出错"。
6. 把线上缺陷按维护类型归类，估算一笔真实的维护预算。

核心概念速览

旅程的骨架是六站串行、每站有闸口。注意这不是瀑布的回归——无论按哪种运行图发车，一个功能从想法到上线都要走过这些站，敏捷只是把每站的停留时间切短了。

金句：每一站的出站条件，就是下一站的安全带——跳站的地方，就是事故埋进去的地方。

进出站条件是本章的钥匙。需求阶段的出站条件是冻结的货单（需求基线），设计的出站条件是评审通过的图纸，编码的出站条件是走查与自测通过的提交，测试的出站条件是一份有明确结论的试跑报告，发布的出站条件是检查单全绿。条件不必繁重，但必须白纸黑字——这是第 1 章原则里"阶段评审"的落地形态。

子章节导航

• 3.1 需求工程：发车前核对货单——需求怎么从客户言语变成带编号、带验收标准的基线，变更怎么走闸口。
• 3.2 软件设计：画好车厢与转向架——概要与详细两级设计、分层与模块边界、设计原则的取舍。
• 3.3 编码实现：车间装配与走查——编码规范、单元测试、代码走查的真实流程与记录样式。
• 3.4 软件测试：联调试跑——测试金字塔、用例设计方法、缺陷生命周期与试跑报告。
• 3.5 部署与发布：离站发车——环境分级、发布检查单、灰度与回滚设计。
• 3.6 维护与演化：运营返修与延寿——四类维护的成本分布、技术债管理、何时该大修或退役。

子章节之间的逻辑关系

六节是严格的接力关系，前一站的产物就是后一站的原料：需求基线是设计图纸的依据，图纸是编码的依据，代码是测试的对象，试跑报告是发布的凭据，线上运营暴露的问题又流回需求站形成下一班列车。理解这层依存，比记住每节的知识点更重要——流程的意义就是让每一站都对得起上一站交来的东西。

  需求基线 ──► 设计图纸 ──► 代码 ──► 试跑报告 ──► 线上版本
     ▲                                            │
     └────────── 新需求与缺陷回流 ◄────────────────┘
              （下一班列车的货源）
​

本章演练任务

本章最好的演练是把一次真实交付拉出来逐站体检。选一个你参与过的功能或版本，回答六个问题：它的需求条目有没有编号与验收标准；设计文档在哪、能指导接手的人吗；代码合入前走了怎样的走查；测试用例集中在金字塔哪一层、试跑报告有没有结论；发布有没有检查单与回退方案；上线后头一个月的缺陷最后归到了哪类维护。六个答案连起来，就是你团队的旅程体检单——哪一站答不上来，哪一站就是本册对应章节要重点补的课。

阅读提示：本章最容易读偏的两处

其一，把六站读成瀑布——本章的站点序列描述的是"一个功能从想法到上线要经过什么"，与按哪种运行图发车无关；敏捷团队也在走这六站，只是把每站的停留切成了小段。其二，把进出站条件读成文书负担——条件的本质是"下一站有权拒绝什么"，一张三行的检查清单与一本三百页的规格书可以是同等效力的条件，分量取决于它是否真的被用来放行与拦截。

前置知识与后续延伸

需要第 2 章选定的运行图作节奏背景（本章按最常见的小班次节奏叙述，瀑布读者把"班次"读成"阶段"即可）。学完本章可进入第 4 章调度台——旅程各站怎么排期、怎么监控，是项目管理的正题；第 5、6 章的安检与机务，也会反复引用本章的测试金字塔与走查记录。