企业官网建设流程全解析

1. 从一份需求文档说起：软件开发生命周期到底在解决什么问题

干了十几年软件这行，我有个很深的体会：很多项目翻车，翻的不是技术，而是过程管理。代码写得再漂亮，需求理解偏了、交付节奏乱了、团队协作散了，照样白搭。软件开发生命周期（SDLC）这套东西，本质上就是把"从想法到上线"这件事拆成有章法的流程，让团队知道什么时候该干什么、怎么干、干到什么程度算完。

刚入行的头两年，我其实挺烦这些流程的。当时觉得写代码才是本事，什么生命周期、模型、方法论，都是项目经理拿来开会用的。直到有一次，我们团队用瀑布模型吭哧吭哧做了八个月的项目，最后客户看了成品说"这不是我要的"，那一刻我才意识到，流程不是束缚，而是保命的。

这篇文章我想把软件开发生命周期的演进路径好好捋一遍，重点放在瀑布模型和敏捷Scrum的对比与实践上。不管你是刚入行的开发、带团队的组长，还是被老板逼着"转敏捷"的PM，这篇文章都能给你一些能直接用的东西。我会把我自己踩过的坑、见过的成功和失败案例，都摊开来讲。

2. 瀑布模型：规矩是好事，但规矩太死就是灾难

2.1 瀑布的核心逻辑：一步走完，再走下一步

瀑布模型（Waterfall Model）是1970年由Winston Royce提出的，虽然老爷子当年提出的时候还特意强调了迭代的重要性，但后人把它简化成了最经典的线性流程。整个生命周期被切成六个阶段：需求分析、设计、实现（编码）、测试、部署、维护。每个阶段都有明确的产出物，上一阶段的产出是下一阶段的输入，就像水从高处一层层往下流，所以叫"瀑布"。

这套模型的设计哲学其实非常清晰：先想清楚，再动手做。需求阶段把所有业务规则写成需求规格说明书，设计阶段画出架构图和数据库模型，编码阶段照着设计文档写代码，测试阶段验证功能是否符合需求。每个阶段结束时有一个里程碑评审，评审通过才能进入下一个阶段。

我当年参与过一个政府信息化项目，就是这个套路。需求调研做了三个月，光需求文档就写了四百多页，每一条需求都有编号、有优先级、有验收标准。设计阶段又花了一个半月，数据库字段精确到每个字段的长度和是否允许为空。说实话，那种状态下写代码的确很踏实，因为设计方案定死了，你不需要做太多决策，照着写就行。

2.2 瀑布的好处与适用场景：不是一无是处

必须承认，瀑布模型在特定场景下仍然是非常好用的。它的最大优势是结构清晰、文档完备、可控性强。因为每个阶段都有明确产出物，管理层可以清楚地知道项目进行到哪一步了，预算和进度也好估算。对于需求极其稳定、技术方案明确的项目，瀑布模型能够提供很高的开发效率——不用来回折腾。

举个典型的例子，银行核心系统的很多模块，监管要求极其明确，业务流程几十年不变，需求在项目启动前就能被完整描述。这种情况下，瀑布模型反而是最安全的选择。还有一次我参与一个嵌入式设备的底层驱动开发，硬件规格已经定死，接口协议是行业标准，需求根本不会变，用瀑布走一遍非常顺畅。

另外，瀑布模型对文档的强调也带来了一个隐性好处：人员流动时知识传递成本低。新人来了，翻需求文档和设计文档就能快速上手，不依赖"老员工口头传授"。这在人员流动性高的行业里，是实实在在的价值。

2.3 瀑布的致命伤：反馈太晚，变更成本太高

但瀑布模型的问题同样致命。最大的痛点是反馈循环太长。需求阶段写完文档，要等到编码完成、系统集成之后，客户才能看到真正能跑的东西。这个过程动辄几个月甚至一年。等客户终于看到成品，说"这不是我想要的"的时候，修改的代价已经高得离谱——需求阶段改一句话可能只要一小时的工时，到了测试阶段改一个需求可能牵扯到数据库、接口、前端、测试用例全部重来。

另外一个我亲身经历的教训是，瀑布模型假设"需求可以被完整、准确地预先获取"，但这个假设在大多数现实项目中根本不成立。用户往往不知道自己想要什么，或者看到了实物才明白自己不要什么。有一次做电商后台的订单模块，业务方在需求评审会上信誓旦旦地说订单状态流转就是这个逻辑，结果做到一半，新的业务规则出来，订单要有拆分和合并功能，整个数据库设计推倒重来。

还有一点容易被忽略：瀑布模型下团队的心态是"各扫门前雪"。开发的只管实现，测试的只管找bug，交付之后运维的接管。每个人的KPI是"完成自己阶段的任务"，没有人对最终产品真正负责。这种割裂感在大型项目里尤其明显，出了问题互相甩锅是常态。后来敏捷思想出来，核心就是要把这种割裂打碎。

3. 为什么要变：软件行业被逼出来的敏捷

3.1 行业环境变了，瀑布撑不住了

进入21世纪，软件行业的游戏规则发生了根本性变化。互联网产品要快速迭代、快速试错，市场需求变化快到按周甚至按天算。你花半年做出来的功能，可能上线时市场窗口已经关闭了。传统的瀑布模型越来越撑不住这种节奏。

我自己在2012年左右从传统软件公司跳到互联网公司，感受特别深。传统软件公司一个版本半年发一次，互联网公司两周一个迭代还嫌慢。老板们要的是"快速上线、收集反馈、再快速调整"。瀑布模型那种"憋大招"的打法，在互联网语境下基本等于自杀。

而且随着软件系统越来越复杂，需求方、开发方、测试方、运维方之间的信息传递链路越来越长。瀑布模型靠文档传递信息，但文档是静态的，写下来之后业务方又变了，文档又没更新，信息失真就开始了。到最后开发人员手里的文档跟客户的真实需求可能已经完全是两个东西。

3.2 敏捷宣言：四个价值观和十二原则

2001年，17位软件行业的大佬聚在雪鸟滑雪场，吵了几天之后发布了敏捷软件开发宣言。核心就四句话：个体和互动高于流程和工具；可工作的软件高于详尽的文档；客户合作高于合同谈判；响应变化高于遵循计划。

很多人把敏捷理解为"不写文档、不做计划"，这完全是误解。敏捷宣言强调的是"高于"，而不是"取代"——文档和流程仍然有价值，但不能凌驾于人和可工作的软件之上。敏捷是一种价值观和原则的集合，强调的是持续交付价值、拥抱变化、团队自组织和持续改进。

敏捷宣言的十二条原则里，我印象最深的是这几条：

• 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
• 欢迎对需求提出变更，即使是在项目开发后期。敏捷过程利用变更为客户创造竞争优势。
• 业务人员和开发人员在整个项目期间每天一起工作。
• 面对面的交流是传递信息最有效的方式。
• 团队定期地反思如何能提高效率，并相应地调整行为。

这些原则放在二十多年后的今天看，依然非常犀利。它把"响应变化"从瀑布模型里的"灾难"变成了"竞争优势"，这个认知转变是革命性的。

3.3 从XP到Scrum：敏捷实践的百花齐放

敏捷宣言发布之后，各种敏捷实践方法如雨后春笋般冒出来。极限编程（XP）强调工程实践，比如结对编程、测试驱动开发、持续集成，解决的是"怎么把代码写好"的问题。Scrum则更侧重于项目管理层面，关注的是"怎么组织团队、怎么规划迭代、怎么持续改进"。还有一些方法比如看板（Kanban）、精益开发（Lean）、特性驱动开发（FDD），各有各的侧重点。

为什么Scrum最终成为最主流的选择？我自己观察下来，原因是Scrum很"轻"。它只规定了三个角色、三个工件、五个事件，剩下的都由团队自己决定。这种极简的框架给了组织很大的灵活度，不管是10个人的小团队还是几百人的大部门，都能找到适配方式。相比之下，XP的工程实践要求很高，很多团队做不到；看板虽然灵活，但对流程改进的推动力不如Scrum强。

4. Scrum落地的完整拆解：角色、工件、事件一个都不能少

4.1 三个角色：Product Owner、Scrum Master、开发团队

Scrum框架里只有三个角色，但每个角色都有严格的责任边界。Product Owner（产品负责人，简称PO）是唯一有权决定需求优先级的人，他的核心职责是管理Product Backlog，确保团队做的是最有价值的事。PO不是需求传话筒，他必须深刻理解业务，能拍板，能说出"这个功能这版不做"。

Scrum Master（敏捷教练，简称SM）是很多团队最容易搞错的一个角色。SM不是项目经理，不是团队领导，更不是管理层的眼线。SM的职责是确保Scrum流程被正确执行，帮助团队扫除障碍，推动团队自组织和持续改进。说白了，SM是团队的赋能者，不是发号施令的人。

开发团队是跨职能的、自组织的，一般5到9人。所谓跨职能，是指团队内部要具备把一个需求变成可用软件的所有技能——开发、测试、UI、运维等。不需要外部依赖，或者说尽量把外部依赖降到最低。自组织则意味着团队自己决定怎么完成工作，怎么拆分任务，谁来做什么。

我在很多公司见过"伪Scrum"，最常见的就是把原来的项目经理改名叫Scrum Master，原来的需求分析师改名叫Product Owner，然后继续用老一套的管理方式。这种换汤不换药的做法，起不到任何效果。真正的Scrum需要角色意识彻底转变：SM从"控制者"变成"服务者"，PO从"传话人"变成"决策者"，团队成员从"被安排"变成"自己安排"。

4.2 三个工件：Product Backlog、Sprint Backlog、Increment

Product Backlog（产品待办列表）是整个产品的需求池，里面包含了所有可能的特性、功能、改进和修复项。每个条目要有描述、要有优先级、要有估算。Product Backlog是活的，PO要持续对它进行梳理（Backlog Refinement），把大条目拆小，把模糊条目变清晰，根据市场反馈调整优先级。

Sprint Backlog（迭代待办列表）是团队在当前Sprint内承诺要完成的任务集合。它由团队在Sprint Planning上自己选择，把Product Backlog里的条目拆解成具体的开发任务。Sprint Backlog属于团队自己，整个Sprint期间只有团队能修改它。

Increment（增量）是Sprint结束时交付的可工作的产品功能总和，必须符合团队定义的"完成"（Definition of Done，DoD）标准。DoD是Scrum里极其重要但经常被忽视的概念。我见过的团队，对DoD的理解千差万别：有的团队认为代码写完就算完成，有的要求自测通过，有的要求代码评审过，有的要求自动化测试覆盖。DoD定义得越严，交付质量越有保障。

4.3 五个事件：从计划到回顾的完整闭环

Scrum定义了五个固定事件，形成了完整的PDCA循环。

Sprint Planning（迭代计划会）是每个Sprint的起点，通常每两周一个Sprint的话，计划会控制在2到4小时。会议要回答两个问题：这个Sprint要交付什么（选哪些Product Backlog条目），以及怎么交付（拆成哪些任务）。一个容易犯的错是计划会开成需求宣讲会，PO从头到尾讲需求，团队听完就散。好的计划会应该是团队主导，PO负责答疑和确认优先级，团队负责讨论实现方案和任务拆分。

Daily Standup（每日站会）每天固定时间，15分钟，站着开。三个问题：昨天做了什么、今天打算做什么、有什么阻碍。站会不是汇报会，不是给领导看的，是团队内部同步信息、识别风险的机会。很多团队站会开着开着就变成轮流念工作日志，这是最大的误区。好的站会应该有信息流动，有人说了之后其他人接话"这个我可以帮你看看"，或者SM当场记录一个阻塞项。

Sprint Review（迭代评审会）在Sprint结束时开，团队向干系人演示这个Sprint做出来的Increment，收集反馈。注意，评审会不是验收会，不是走个流程说"完成了"，而是让干系人真正看到可工作的软件，并且基于反馈调整后续的Product Backlog。我见过最糟糕的评审会是PPT演示，连Demo都不做，这完全违背了"可工作的软件"这个敏捷的核心价值。

Sprint Retrospective（迭代回顾会）是我个人认为Scrum里最有价值的一个事件。团队回顾这个Sprint里的过程、工具、协作方式，找出做得好的和需要改进的，制定具体的改进行动。回顾会最怕走过场，每个人说两句"挺好的"就结束。好的回顾会需要营造安全的氛围，让大家敢于说出真实想法。我常用的方法是"Stop, Start, Continue"：停止做什么、开始做什么、继续做什么。每轮Sprint至少挑一个改进行动，下个Sprint去落实，回头看是否有效。

4.4 一次真实的Sprint是怎么跑通的

拿我最近带的一个电商中台项目举例。Sprint周期两周，团队8个人（1个PO、1个SM、4个后端、2个前端、1个测试，实际上测试在后面我调整为嵌入式到开发团队里）。

Sprint Planning第一天上午：PO先带大家过了一遍Product Backlog里优先级最高的条目，有用户故事、有验收标准。团队针对每个条目讨论技术方案、评估工作量，最后选了12个故事点放进Sprint Backlog。拆任务的时候，一个"订单导出"的功能拆成了后端接口开发、文件生成优化、前端页面、联调、测试用例编写五个任务。

Sprint期间每天10点站会。有一次前端同学说"接口联调一直报CORS错误"，后端同学当场说"我下午看一下，可能是网关配置问题"，当天就解决了。这就体现了跨职能团队的好处——问题在内部消化，不需要走工单流程。

第14天下午做Sprint Review，团队现场Demo了三个新功能，业务方当场说"导出功能我们希望支持CSV格式，现在只有Excel"，这个反馈直接进了下个Sprint的Product Backlog。

Review结束之后是Retrospective，有成员提出"测试环境部署太慢，每次手动操作要十分钟"，大家讨论后决定写一个自动化部署脚本，作为下个Sprint的一个技术任务。这个改进后来至少帮团队每天省了半小时。

说起来这套流程不复杂，但每个细节都有讲究。Sprint的长度，两周是最常见的，但也有团队用一周或三周。周期短反馈快，但会议开销占比高；周期长干扰少，但风险暴露慢。新团队建议从两周开始，跑几个Sprint再根据实际情况调整。

5. 落地Scrum最容易踩的坑：我见过的各种翻车现场

5.1 "伪敏捷"：用敏捷的壳，装瀑布的魂

这个坑我见过太多次了。公司说要敏捷转型，于是把流程改成了两周一迭代，但实际操作还是老一套：PO在Sprint中途不停加需求，SM还是项目经理的做派，每天审批各种任务，开发人员拿到的是已经拆好的任务单而不是自己去拆。测试还是在Sprint最后两天集中做，导致经常延期。

这种伪敏捷比不敏捷更糟糕，因为它让团队对敏捷方法论本身产生怀疑——"Scrum也就那样，跟瀑布没啥区别"。实际上问题不在Scrum，而在组织没有真正理解敏捷的精髓。敏捷的核心是信任团队、拥抱变化、持续改进，如果管理层还是用控制式的思维来管理团队，换什么框架都没用。

要破这个局，我建议从最小的单元开始。选一个试点团队，给充分的授权，让团队真正自己决定怎么干活，管理层只看结果指标（交付价值、质量、客户满意度），不看过程指标（工时、进度百分比）。试点跑出效果后，再逐步推广。不要搞"全公司一刀切转敏捷"，那是灾难。

5.2 站会变汇报会：信息同步变成了表演

站会是Scrum里最容易被做变形的活动。最常见的现象是：站会变成向SM汇报工作，每个人对着SM说"我昨天做了什么，今天做什么"，SM听完点点头说"好的"。其他人根本不关心，因为那些内容跟自己没关系。这种站会开一年，团队协作也不会变好。

正确的站会应该是一个信息同步和协作触发的场合。每个人说完之后，其他人要有回应，要么提供帮助，要么协调资源，要么指出风险。SM在站会上的角色不是听汇报，而是记录阻碍项、协调资源、推动问题解决。如果站会上有人说"我遇到一个问题"，其他人没有任何反应，说明这个团队的站会已经死了。

我也见过一些团队为了省时间把站会改成微信群打卡，效果更差。面对面的交流包含了语气、表情和即时的互动，这是文字消息替代不了的。敏捷宣言里有一条"面对面的交流是传递信息最有效的方式"，这是有道理的。

5.3 Sprint Backlog被无限变更：计划成了摆设

Scrum的思想是：在一个Sprint内，团队承诺的目标是神圣的。一旦Sprint开始，不应该往Sprint Backlog里加新内容，除非优先级实在太高，那就取消当前Sprint重新规划。但实际情况是，PO时不时就来一句"客户说这个功能很急，这周就要"，然后Sprint Backlog被不断追加，团队疲于奔命，最后什么都没做好。

这里的问题不全是PO的问题，SM和团队也有责任。如果PO经常在Sprint中途加需求，说明Product Backlog的梳理工作没做到位，或者PO对Scrum的理解没到位。SM应该主动跟PO沟通，解释"为什么要锁Sprint",同时帮助PO在Sprint Planning时把需求评估得更完整。

当然，计划不是死的，要有弹性。如果中途发现某个需求的实现难度远超预期，团队应该尽早暴露风险，跟PO商量是砍范围、调优先级还是延长时间。最怕的是团队闷头干活，到了评审会才发现做不完，那个冲击更大。

5.4 回顾会走过场：改进成了形式主义

Retrospective是Scrum里唯一一个专门用来"改进"的活动，但恰恰是它最容易被敷衍。很多团队开回顾会就是过一遍流程，每个人说句"这轮挺好的"或者"排期有点紧"，然后就没有然后了。下个Sprint还是老样子，问题继续存在。

要让回顾会真正产生价值，我总结了几点经验：第一，营造安全的氛围，让每个人都能说出真实想法，尤其是负面的。可以用匿名投票的方式收集意见，比如用"团队士气""交付效率""协作顺畅度"几个维度打分，低于一定分数的维度重点讨论。第二，改进项要具体、可执行、有负责人。不要写"提升代码质量"这种空话，要写"在前端代码库引入ESLint规则并跑通CI检查，负责人张三"。第三，下个Sprint的回顾会上，先跟进上轮的改进项是否落地、效果如何，形成闭环。

5.5 表格速查：瀑布与Scrum的适用场景对比

6. 从瀑布到Scrum：转型不是换个流程，是换大脑

6.1 文化和理念的转型是最难的

很多组织转敏捷，第一反应是找一套工具、改一套流程、做一轮培训，以为这样就完事了。但真正的转型难点在于文化和理念。

瀑布模式下，管理者的安全感来自"看得见"的控制——计划表、里程碑、周报、审批。而敏捷模式下，管理者的安全感应该来自"快速反馈"——即使方向错了，两周后就能发现并调整。这个转变对很多管理者来说是极其痛苦的，意味着他们要放弃"掌控感"，学会"信任团队"。

团队的转型同样痛苦。瀑布模式下，开发人员习惯了"我只要写代码就行"，不需要关心业务价值；敏捷模式下，每个人都要理解业务目标、参与规划、对结果负责。这不仅是技能要求的变化，更是心理状态的变化。我见过很多开发人员，刚开始对敏捷非常抵触，觉得"每天开站会、写任务看板，浪费时间"，但跑过几个Sprint之后，他们反而离不开这种节奏了——因为自己的工作成果很快就能被看到，成就感比以前强多了。

6.2 工具选型：Jira、Trello还是物理看板？

转型过程中，工具选型是绕不开的一个话题。市面上有Jira、Trello、Asana、Ones、Tapd等各种项目管理工具，每个团队的情况不同，选型逻辑也不一样。

Jira功能最强，但上手难度也高，配置复杂，适合中大型团队。它支持完整的Scrum流程：Product Backlog、Sprint规划、看板、燃尽图、报告等。但是Jira也是被吐槽最多的工具，因为配置不当的话，会让团队陷入"为工具服务"的困境。我见过一个团队，每天花半小时在Jira上更新任务状态，完全违背了工具"提高效率"的本意。

Trello和看板类的工具轻量、直观，适合小团队快速上手。它们的缺点是统计和报表能力弱，不太适合需要向管理层汇报的团队。物理看板（就是一面墙加便签纸）反而是非常有效的方式，尤其在团队初期转型阶段——物理看板看得见、摸得着，天然促进团队交流，而且不会被工具流程束缚。

我的建议是：工具只是载体，不要迷信工具。初期用物理看板，把流程跑顺了，再考虑引入数字化工具。选工具的时候要看团队实际情况：团队规模多大、是否需要远程协作、管理层需要什么维度的数据。不要因为"大家都在用Jira"就盲目上Jira。

6.3 混合模式：瀑布和敏捷不是非此即彼

最后我想聊一个很多人纠结的问题：瀑布和敏捷是不是非得二选一？答案是：不一定。

现实世界里的项目往往是混合型的。比如一个大型系统集成项目，前期需求分析和架构设计阶段用瀑布的思路，把整体框架定清楚；进入开发阶段后，按模块拆成多个Sprint，用Scrum的方式快速迭代。又比如一个新产品，核心算法部分用瀑布，界面和交互部分用敏捷。

我参与过一个医疗系统项目，就是典型的混合模式。因为监管要求，系统架构、数据模型、安全方案必须提前评审，这部分用瀑布的思路锁死；但业务功能方面，客户自己也说不清楚具体流程，我们就用Scrum的方式，每两周交付一个可用的功能模块，让用户试用后提反馈，我再调整。

这种混合模式的关键是要明确界线和转换点：哪些部分是变化风险低、需要提前定死的；哪些部分是探索空间大、需要快速试错的。把这两类工作分开管理，各用各的方法论，反而能发挥两边的优势。

还有一个现实情况是，即便团队名义上在跑Scrum，有些"瀑布式"的元素依然有价值。比如在项目启动时做一个整体架构设计，比如关键技术的预研和原型验证，比如对核心模块的严格代码评审。这些做法本质上属于"任务级瀑布"，它们跟Scrum并不冲突，反而是Scrum能跑好的基础。敏捷不等于无序，Scrum框架给了团队足够的自由，但这种自由需要被专业能力和工程纪律来约束。

7. 最后再分享一点个人的体会

做了这么多年项目，我越来越觉得，方法论是死的，人是活的。瀑布模型不是洪水猛兽，敏捷Scrum也不是万能灵药，它们都只是工具，关键看你怎么用。

如果让我给出一条最核心的建议，那就是：永远从项目本身的实际情况出发去选择方法，而不是从方法论出发去套项目。需求明确、变更极少、交付节点固定的项目，用瀑布很合理；需求模糊、市场变化快、需要快速验证的项目，用Scrum更合适；大部分项目，可能需要两者结合。

还有个细节，我踩过无数次坑之后才总结出来的：无论是瀑布还是Scrum，都要重视"完成"的定义。瀑布阶段里的"设计完成"到底是画完图还是评审通过？Scrum里的"开发完成"到底是代码写完还是测试全过？这些问题如果不在项目启动时说清楚，后面全是扯皮。现在我问任何团队的负责人，第一件事就是确认他们怎么定义"完成"。

软件开发生命周期的演进，说到底是从"避免变化"走向"拥抱变化"的进化。技术会变、工具会变，但"持续交付价值"这个核心不会变。希望这篇文章能帮你少走一些弯路。