软件开发生命周期与研发流程概览
【摘要】 软件开发生命周期与研发流程概览从一句话想法到稳定上线，软件到底要经过哪些环节？本文给出一张可落地的全流程地图，适合用来统一团队认知、给新人做入职第一课。 一、生命周期的六个阶段阶段核心问题主要产出常见角色需求要解决谁的什么问题PRD、用户故事、验收标准产品、业务方设计怎么解决、代价多大技术方案、接口契约、表结构架构师、前后端实现把设计变成可运行的代码代码、单元测试、MR / PR开发验证是...
软件开发生命周期与研发流程概览
从一句话想法到稳定上线，软件到底要经过哪些环节？本文给出一张可落地的全流程地图，适合用来统一团队认知、给新人做入职第一课。
一、生命周期的六个阶段
| 阶段 | 核心问题 | 主要产出 | 常见角色 |
|---|---|---|---|
| 需求 | 要解决谁的什么问题 | PRD、用户故事、验收标准 | 产品、业务方 |
| 设计 | 怎么解决、代价多大 | 技术方案、接口契约、表结构 | 架构师、前后端 |
| 实现 | 把设计变成可运行的代码 | 代码、单元测试、MR / PR | 开发 |
| 验证 | 是不是真的解决了问题 | 测试报告、缺陷清单 | 测试、产品 |
| 发布 | 如何安全地交给用户 | 发布单、回滚预案、变更记录 | 运维、开发 |
| 运维 | 上线后是否健康 | 监控告警、复盘文档 | 全体 |
关键认知：阶段不是瀑布式的闸门，而是每轮迭代都会完整走一遍的循环。一个两周的迭代里，六件事都会发生，只是粒度更小。
二、两种主流流程模型
Scrum（迭代式）：固定时长冲刺（通常 1~2 周）、角色固定（PO / SM / 团队）、仪式固定（计划会、站会、评审、回顾）。适合需求会变、需要频繁看反馈的产品。
看板（流动式）：不设固定迭代，用「待办 → 开发中 → 评审中 → 测试中 → 已完成」的泳道拉动，核心约束是在制品数量（WIP Limit）。适合运维、缺陷修复、需求持续涌入的团队。
| 对比项 | Scrum | 看板 |
|---|---|---|
| 节奏 | 固定冲刺 | 持续流动 |
| 变更 | 冲刺内尽量不改 | 随时可插入 |
| 度量 | 速率（Velocity） | 前置时间、吞吐量 |
| 主要风险 | 冲刺塞太满 | WIP 失控、任务堆积 |
现实里多数团队是混合体：用 Scrum 管版本节奏，用看板管日常缺陷流。
三、每个阶段的「退出条件」
没有明确退出条件的流程，最后都会变成「差不多就发吧」。建议写成可勾选的定义：
Definition of Ready（可以开工）
[ ] 验收标准已写明，且可被测试
[ ] 依赖方 / 接口契约已确认
[ ] 需要的数据、权限、环境已就绪
Definition of Done（可以完成）
[ ] 代码已合入主干，CR 通过
[ ] 单元测试通过，覆盖率不低于约定值
[ ] 自测通过，无 P0/P1 缺陷
[ ] 配置、SQL 变更、发布说明已入发布单
[ ] 监控与日志埋点已补齐
四、常见坑与对策
| 坑 | 表现 | 对策 |
|---|---|---|
| 需求口头传达 | 「你懂我意思吧」 | 一切落文档，验收标准必须可验证 |
| 大批量发布 | 一月一次，一次几十个变更 | 缩小批次、提高频率，隔离回滚单元 |
| 测试排在最后 | 开发完才给测试，时间被挤掉 | 测试左移：评审阶段就写用例 |
| 无回滚预案 | 上线出问题靠现场改代码 | 每次发布先写「怎么退回去」 |
| 复盘变成甩锅会 | 只追问谁写的 | 聚焦系统性改进项，产出行动人 + 时间 |
五、落地检查清单
- [ ] 团队有一份书面的 DoR / DoD，且被真实执行
- [ ] 每个需求都能追到对应的代码提交与发布记录
- [ ] 发布单包含变更清单、SQL、配置、回滚步骤
- [ ] 线上问题有复盘文档，改进项有跟踪
- [ ] 迭代周期内有固定的回顾仪式，且能真正删减流程
六、小结
流程的价值不是「显得规范」，而是把隐性共识变成显性约束，让问题在便宜的阶段暴露。需求阶段改一句话的成本，和上线后改一次数据库的成本，通常差两到三个数量级。团队规模越小，越应该只保留必要的三件事：可验证的验收标准、代码评审、可回滚的发布。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）