03 | 瀑布模型：像工厂流水线一样把软件开发分层化
请订阅文章所属专栏。
精选留言(46)
纯洁的憎恶我对瀑布模型感触颇多啊！首先瀑布模型把复杂的软件生产过程，按照时间线索，切分为若干较为独立和专业的部分，条理清晰。在每个阶段内只需要集中精力与阶段任务即可，不用胡子眉毛一把抓。每个节点有交付件，过程可控、权责清楚明白。破布模型特别符合我所在的大型央企的性格。但是我经手好几个项目，也被瀑布模型折腾的死去活来。比如我现在正在处理的项目。
首先，从可行性分析、立项、批预算、采购建设单位就花了一年多的时间。可行性分析做了1个月，立项流程走了不到1个月，批预算的时候，主管业务的领导变卦了，要求重新做可行性分析，于是我们又花了1个月。二次立项的时候，主管信息的大领导突然决定要把区块链和人工智能等热门技术加进去，于是又要求重新立项。但是我们要做的事情实在和区块链八竿子打不着，死去活来的找了个理由扯上关系了，来来回回又花了2个月，这就半年了。再次走到批预算的环节，主管领导发现原来的预算干不了这么多事情，又不同意增补预算，于是继续扯皮。经过多番协调，总算解决了，这时候叶子已经黄了。
我们立刻开展需求调研，但各个需求部门和最终用户都借口工作太忙不搭理我们，我们只好自己憋需求，简直是闭门造车。等需求憋出来了，大领导把需求部门都叫来议一议，结果被集体口诛笔伐。大领导怒了，强令需求部门专门抽时间参与需求调研，各部门也是不情不愿啊，效果可想而知。需求总算审查通过了，就在我们准备采购实施单位的时候，国资委一直红头文件下来，公司的采购流程发生重大调整，项目被硬生生搁置下来。眼看年根了。。。
第一年就这么过去了。等来年采购流程也屡的差不多了，预算又出问题了。去年批的预算只能去年用，不允许跨年。只好等到年中调整预算，又小半年过去了。采购流程走完，实施单位也很够意思，不等合同签订就投入工作。我们用极短的时间完成了软件设计，并且开始如火如荼的开发工作，此时又到了金秋。就在这时，新的纪检书记上任了，他对我们的系统设计很不满意，要求相关部门限期整改，于是需求大调整，可是这会儿编码已经进行了1/3啦。。。之后就是上线日期一推再推，从10月初推到10月底，再推到11月、12月，眼看又要跨年了。我们和实施单位连续半年997，总算看到上线的曙光，这时候公司一把手退休了。。。
新领导上任后对整个流程极不满意，否定了纪检书记的指示，于是我们又开始第2伦大调整。现在已经是项目的第三年了，我们依旧没能上线。整个团队都要累趴下了，全公司一点成果也没看见。作者回复: 很感动，写了这么长的留言。这是个很生动的案例。像这样的环境，虽然说根源不是瀑布模型造成的，但是瀑布模型确实加剧了问题。
对于这种开发模式，邹老师在《构建之法》中有精彩的论述：“老板驱动的流程：笔者在和中国一些企业的软件开发者交流的时候，听闻不少人提到开发流程事实上是由行政领导主导，或者由公司的老板驱动，我们姑且把它命名为老板驱动的流程。” 领导“有极大权力， 极小责任”的驱动方式。
这种项目可以考虑调整为快速迭代的模式（下一篇会提到，核心就是控制每次的需求），尽早上线核心功能，上了慢慢改，下个迭代改。就像老话说的：“生米先煮成熟饭”。
还有PM应该要能顶得住压力，在一个迭代中应该不改或者少改，才能继续推进。
另外，也能理解这种项目不是靠个人就能改变太多的，适当的时候提一些建议，改变能改变的，接受不能改变的。
最后，有具体问题也欢迎继续留言讨论，很乐意提供建议：）2019-02-28 34
西西弗与卡夫卡瀑布模型分解和识别出了软件开发过程中的几种主要活动，以及每种活动所关注的价值点，并从时间尺度上划分了对应的阶段。这几个阶段形成了一个环。现代的其他软件工程方法，举个不太恰当的比喻，就像是滚动更快的轮子。不管什么样的轮子，这几个阶段的功夫，我们都得练好作者回复: 你这个比喻很有意思的👍，下一篇关于衍生模型的很多例子完全适应你这个比喻。
敏捷开发的Scrum可能还是有点不一样，每个Sprint并不完全按照这个周期，但是在一个Sprint的某个用户故事的开发，其实也适用于这个环。
所以你说的关于这几个阶段的功夫，确实都得练好！2019-02-28 10
一路向北目前我们的开发模式还是以瀑布型的为主。之前也引进过敏捷开发模式，但是因为团队不大，每个人的分工比较清楚，甚至经常是每个人负责一个项目，所以也就没有按照敏捷的那一套流程走。
我的理解是，如果产品的需求变化不大，产品设计者的前瞻性和设计能力比较强，设计的框架的伸缩性强，是不是瀑布式的开发会优于敏捷开发呢？也就是说，产品经理的需求分析能力，抽象能力很重要，而实际的实现人员相对要求会低一些？
对于较大的项目，如果能做到合理的项目分割，划分，那么在分项目中再实行瀑布式开发，是不是效率也会挺高？作者回复: > “如果产品的需求变化不大，产品设计者的前瞻性和设计能力比较强，设计的框架的伸缩性强，是不是瀑布式的开发会优于敏捷开发呢？”
如果满足你说的前提，再加上没什么进度压力的话，瀑布模型像计划性、质量、过程控制都是很好的，是不是比敏捷开发好这个我不好随便下结论，因为敏捷开发理想情况下一样可以质量高。问题是绝大部分时候真的不是理想情况。
> 对于较大的项目，如果能做到合理的项目分割，划分，那么在分项目中再实行瀑布式开发，是不是效率也会挺高？
是的，你说的这种大的拆小的是下一篇会讲的迭代模型，基于瀑布模型，但是更小，也更高效。在再下一篇我还会对比迭代模型和敏捷开发，希望能帮助你更好的理解其中的差别。
很多人不愿意尝试其他瀑布模型之外开发模式，可能是因为已经对瀑布模型太熟悉了，多看看多学习一下其他模型好的地方，再尝试实践也是很好的。2019-02-28 6
王二宝我是非科班出身的程序员，工作第三年，真的觉得《软件工程》是门必须要掌握的学科。我们公司是几人小团队，很多流程都是自己摸索的，我今天才知道，原来我们平时的工作流程就是瀑布模型啊。让我想到了吴军的专栏中说，很多野路子探索了很久才恍然大悟，并以此骄傲的东西，对于有理论基础的人来说，这就是很平常的理论啊，甚至是觉得这东西，是与生俱来的。作者回复: 你这个总结的特别好👍
我以前不是科班的时候，就是怎么都想不明白大项目怎么开展，后来改专业到软件工程后，就觉得这是很自然而然的事情了。
而且虽然我们大学只讲了瀑布模型，但是后来再看迭代模型，马上就明白怎么回事了。当然也有科班也有问题，例如我刚开始对敏捷就有点不屑一顾，觉得瀑布模型就很好呀：）2019-03-01 5
tongmin_tsai老师，我经历不同的公司，因为在较传统的行业，基本都采用瀑布模型，但是不同的公司，在瀑布模型的流程上大体差不多，就是每个流程，像您里面说到的 问题的定义及规划 -》需求分析-》软件设计-》程序编码-》软件测试-》运行维护等阶段，输出产出不同的成果，大体就是不同的公司，每个阶段产出不一致，特别是问题的定义及规划 -》需求分析-》软件设计这些阶段，比如基本都是产出相应的文档，有些还产出如原型图，流程图或者一些UML相关的状态机图等等，不知道有没有业内比较好的实践模板可以提供参考的，有没有较为通用，符合中小型公司，或者对应中大型公司的模板，如果这些规范的较好，就不会造成有时文档五花八门的现象作者回复: 文档这部分，没有什么统一的模板。我的观点是，文档最关键的地方在于达到其目的，格式是其次的。
文档的目的我觉得主要是两点：
1. 写文档的过程中帮助你梳理清楚逻辑
2. 写出来的文档是要用来沟通的，让其他人通过文档明白你的思路
所以建议不用太在意格式，重点放在内容上就好了。2019-03-01 4- 纯洁的憎恶老师的留言区真是异彩纷呈啊😁
作者回复: 感觉大家项目经历都很丰富，一些内容触动了大家留言的想法💡
很喜欢看大家的留言，可以了解大家想要什么有什么问题，也可以了解到很多有意思的项目，根据留言还可以调整后面的内容呢。
谢谢2019-02-28 4 - Felix实际工作中我举一个例子，倒逼项目往往就自然而然地使用了瀑布模型，而中间一些领导的"创意"或竞品的对齐导致需求变更，最惨的是瀑布的下游——开发和测试 的疯狂加班，请问宝玉老师对于倒逼项目有没有自己的处理方式和建议
作者回复: 通常两种方案：
1. 砍需求，以保证可以按时完成
2. 快速迭代，可以及时响应变更2019-02-28 4 
javaadu我们是包在敏捷开发下的瀑布模型，实际实施的时候还有点边写边改模型的成分。
瀑布模型之于软件开发，就像流水线作业之于小作坊，有了这套理论指导下的软件小作坊终于有机会稍微正规一点。
瀑布模型最大的问题就是难易快速响应需求的变化。
我最近对需求不明确有点感想：软件开发中的需求不明确加上变动多，对于技术人员来讲真的非常懊恼，因为意味着工作的反复和不可控，但是从需求方的角度来看如果一件事情已经想得很清楚，那说明有其他人做过了类似的事情，那我们在做的时候已经晚人一步了。
我觉得需求变更并不是说完全不可接受，但是要有个度，而且要考虑成本，加（改）需求带来的工作量增加不能一直让技术团队加班来承担，否则团队的挫败感会积累。
特别想听老师专门讲讲如何应对这些情况，如何有效得做可行性分析和需求管理。
祝近安。
阿杜作者回复: 04就会讲迭代模型，是最容易从瀑布模型演进过去的，可以很有效的应对需求不清楚的情况。其实你这种情况最好是05敏捷开发，但是实施难度要大一些，不够了解的话还不如迭代模型。
具体到实施上来说呢，就是你考虑把大瀑布拆成小瀑布，固定迭代的周期（例如2-4周），每个迭代都发布一个可以运行的版本（非常重要），本质上还是瀑布，但是这种模式，可以让你先选择优先级高的需求，当前迭代如果没搞清楚需求也没关系，下个迭代改进完善。
可行性分析和需求分析在后面章节会涉及。2019-02-28 4- Tomcat瀑布模型原来才是最经典的软件开发模型！这一点大大出乎我的意料。也就是说，后续那些敏捷开发等模型都是在解决瀑布模型的缺点而努力的！
作者回复: 👍
是的，瀑布模型虽然问题比较多一点，但是意义重大。后续的模型都是为了解决瀑布模型而努力的。2019-02-28 4 
Charles我们现在用的也基本是瀑布模型+小版本瀑布迭代，碰到需求变更也尽量放到下个版本拥抱，你文章的案例和留言中的案例看完，感触颇深似曾相识，精彩😄
几个点请教下老师：
1. 文中案例时间预估是老板给的，还有一种是老板或客户给个简单的需求和案例让预估时间，那么在瀑布模型下是否先要经历完需求分析以及架构设计阶段才能预估出时间了？能否给个预估时间好的实践？谢谢🙏
2. 瀑布模型非常考验人的能力，会造成互相扯皮推卸责任，上线以后有什么问题，还会互相推锅背，这种情况下管理者有啥好的方式去解决？老师有什么经验分享吗？谢谢🙏作者回复: 《10 | 项目计划：代码未动，计划先行》会讲时间估算。
通常时间估算并不需要特别精确，初步的需求分析就可以大致估算出每个阶段需要的时间。大致时间确定后，就可以设置里程碑。里程碑定了后再确定细的计划。
虽然我觉得甩锅不是什么好事，但是如果你真要甩锅，最简单有效就是设置流程去划分责任：）
上线后有问题其实很正常的，重要的是要有合理的机制：
1. 及时发现问题，监控报警、用户投诉反馈等
2. 马上解决问题，对线上版本有专门的代码分支，可以随时打补丁修复，测试上线
3. 避免后续再犯同样的错误。要分析原因，看什么导致问题，然后改进流程。
希望以上回答能解答你的问题，如果还有不清楚的欢迎继续留言。2019-03-02 3
草裡菌几年前用瀑布模型开发过一些手机APP项目，可能是APP比较量轻，除了第一版耗时4个月左右，之后就进入快速迭代（迭代周期在一个月内）。产品部会在当前版本的开发和测试的环节进入新版本迭代进程，等到测试完毕，差不多设计也快递交结果给开发了，工种间的空闲间隔并不长，工作量还是蛮饱和的。不过进入大功能迭代还是会“卡壳”，而且无论何时，开发和测试总在加班，哈哈哈。期待后续的专栏。作者回复: 大功能确实会超过一个迭代周期，这种情况下，还是应该坚持按时发布更新，先把完成的小功能和bug修复发布，没完成的放在后面的迭代中继续完成。不然就又回去大瀑布了。
2019-03-01 3
陈云强有了软件工程，软件开发才更像一个产业作者回复: 《构建之法》中说：软件=程序+软件工程，不无道理
2019-03-19 2
中年男子花了一个小时把这一篇的正文及评论看完，真是精彩，受益匪浅，评论区的案例和宝玉老师的回复看一遍都不过瘾。
我现在公司最大的问题就是使用瀑布模型，需求还频繁改动，程序员苦不堪言。老板驱动极大权利极小责任简直是说到心坎里了…作者回复: 是的，其实我这也算是抛砖引玉，提出一个观点，然后引发更多讨论，有时候甚至讨论的观点更精彩！👍
那你可以尝试快速迭代试试，如果周期能短一点，也许对于需求的响应能迅速一点，能改善一点。2019-03-06 2
beyondzhao能不能问一下老师，现在行业使用较多的原型工具有哪些？是Axure吗？作者回复: 具体还是看什么应用，App还是Web还是其他，Web的话Axure应该是不错的选择。
如果是App我最近看到一个高保真的原型设计工具 framer 非常厉害：
https://www.framer.com/2019-03-06 2- beyondzhao非科班出身的我现在在学校有项目都是拿来就写代码，觉得需求分析是形式主义，结果往往写到一半感觉思路混乱。看来系统学习软件工程的知识还是很有必要的，尤其是关键的需求分析阶段，是帮助你理清思路的必要步骤。
作者回复: 认同的，做之前先要想清楚。我昨天正好写了一个微博：
> 我在带新人的时候，一般都会要求他们在实现一个稍微大一点的项目的时候，先做一个简单的设计，想清楚分哪些模块，模块之间关系是什么，要提供哪些对外的接口等。对设计文档格式没有要求，但写完要给我Review，我会提一些建议，其实就是帮他们想清楚。
> 这么做主要目的让他们在写文档的过程中，把问题考虑清楚，不要上手就写代码，结果写一半才发现当初有很多问题没考虑到的，要大概甚至重写。
https://www.weibo.com/1727858283/HjAaacaMl?from=page_1005051727858283_profile&wvr=6&mod=weibotime&type=comment2019-03-06 2 
卡皮定了很多课程，宝玉老师是每条留言都回复的，赞一个！作者回复: 谢谢夸奖。
其实这就像上课，课后的答疑。毕竟一篇文章不可能面面俱到，难免有没讲到和没讲清楚的地方，通过留言和回复，可以把这些问题补充说明清楚。2019-03-05 2- alva_xu另外，老师提到瀑布里夹敏捷，我觉得这是大型项目常用的方法。比如对于大型系统的架构设计和落地，我觉得采用瀑布方法比较好，架构就如地基，如果需求不明，设计上经常要修改，自然会影响项目质量和进度。我觉得还是以造房子为例，越是地基和框架，越要少改，尽量一次成型。
作者回复: 还是看项目类型吧，因为架构一定是构建在需求之上的，如果需求不明确，很难设计出来合适的架构，所以难免会改，反倒不如先设计合适的架构，后面慢慢修改，一定阶段后重构。
2019-03-02 2 - alva_xu在我们企业，由于软件开发以外包为主，由于合同的原因，往往在项目外包前就已经基于需求做出了工作量的预算，以便有明确的合同价格，所以，难以推行敏捷或者迭代的工作方法，往往采用瀑布模式进行开发。但同时，又存在“老板驱动的流程” 也就是 领导“有极大权力， 极小责任”，需求变更随时随地，用户验收又不好好进行，导致项目质量和工期都难以把握。我觉得比较好的解决方法，有两个，1，是建立自开发团队，2是和外包团队签长期合作合同。这样就可以用敏捷迭代的方法来面对需求变更了。当然，这里也会带来工作量核算等等问题。
作者回复: 你说的第二个方案应该还是可行的，因为甲方关心的是产品质量和价钱，如果你的方案价钱差不多，质量可以更好，他们应该会支持的。
当然这个很多时候不是一个人就能解决的了的。及时是瀑布模型，也可以借鉴一些其他模型好的实践来优化，例如在开发阶段采用迭代模型或者敏捷开发，采用持续集成提升效率。2019-03-02 2 
Linuxer老师您好，小公司有很多项目就是一两个人，没有那么多角色，怎么做到按这种流程去开发项目呢?比如常常在代码编写过程中发现很多问题都没考虑全面又感觉在交流需求的时候根本就没想到，要怎么在之后的项目中不再犯这种问题呢？作者回复: 即使只有一个人，建议也要做简单的需求分析和设计，做完后，形成简单的文档，找人评审一下，提一些意见。
因为你写文档的过程，给别人讲的过程，其实是在帮助你思考，帮助你梳理清楚逻辑，避免在实现的时候发现好多问题没想清楚。
还有一个思路就是快一点迭代，每一个迭代解决优先级最高的问题，然后下一个迭代中改进上一个迭代的问题。
项目中犯错误其实很正常的，重要的时候要总结，看看通过什么方式能改进，避免犯类似的错误。2019-03-01 2
beiler我觉得可以把需求细分，版本进行快速的迭代，比如列清1.1版本的需求，1.2版本的需求，每个月发布一个版本，这种快速迭代。但是这样就又有问题了，如果1.1版本我发现有bug，1.3版本都开发完了，那我bug怎么merge进去呢？可能每个版本的代码都出现了改动，这样合并会出现冲突。第二个问题，架构师如何把数据库设计的更合理能满足后续不断变更的需求呢？请老师指点下，有没有什么好的文章或书也可以推荐下作者回复: 如果你在1.1发现bug，需要甄别一下紧急程度，紧急的话，就1.1分支修复，然后hotfix，不紧急的，就1.2修复好了。
分支合并有两种策略：1. 不合并，如果有bug fix，各个分支同步修改；2. 分支合并回主分支，例如1.1上线时创建分支，1.2开始在主分支开发，开发时发现1.1的bug，只更新1.1分支，再定期把1.1的分支合并回主分支。
敏捷开发中，通常建议只做刚刚好的设计，不必要考虑太多后续的需求变更，定期再重构（例如你可以重新设计表，然后把旧数据导入）。
极客时间有个《从0开始学架构》的专栏（也出书了）不错，你可以看看。2019-03-01 2