SDLC

软件开发生命周期是把软件从想法到退役所经历的各个阶段归在一起的统称。不同方法论（Agile、瀑布、DevOps、持续交付）定义不同的阶段边界、以及在它们之间移动的不同方式。阶段本身大致不变：发现、设计、构建、测试、部署、运维、退役。

当作词汇用很有用，当作流程用就不一定。试图强推一套严格 SDLC 的团队，最后会堆出活不过第二个 Sprint 的文档开销。完全无视 SDLC 的团队，则会以痛苦的方式重新发现每个阶段（「我们没有部署计划就上线了」「我们从没想过怎么把这个系统下线」）。

人人都跳过的那个阶段，举个实际例子：一家初创公司两年里构建了三个内部服务、发布了、然后继续往前。没人负责「运维」，也没人规划「退役」。十八个月后，三个里有两个还在运行，没人记得为什么，唯一懂它们的那位工程师走了，而停掉任何一个可能会弄坏什么、也可能不会。那就是跳过生命周期后半段不开账单的成本。这件事前期做很便宜（指定一个负责人、写一份部署和拆除计划），事后发现则很贵。

你选的方法论主要决定阶段之间的边界有多刚。一套瀑布 SDLC 把它们严格按顺序跑、在每个门口签字确认；一套 Agile SDLC 把设计、构建、测试连续地交织，并随学习重访更早的阶段。无论哪种，阶段是同一组，这就是那个有用的洞见：争论「Agile 对瀑布」其实是在争论边界应该有多可渗透，而正确答案取决于你的需求还能变多少。

诚实的取舍与常见错误：创始人听到「SDLC」，要么把它过度形式化成一套门控、签字繁重、扼杀速度的流程，要么把它当作企业表演而跳过那些不光鲜的阶段。正确的姿态是把它当作一份「必须在某处发生的事」的清单，而不是一条要正步走过的序列。Wavect 偏好的形态：前面放一段付费的发现阶段，设计与构建在短周期里交织，从第一天起就有自动化的 TDD 和 CI/CD，运维有清晰归属，退役有书面化的迁移路径。