04 | 瀑布模型之外，还有哪些开发模型？
快速开发快速改
请订阅文章所属专栏。
精选留言(33)
纯洁的憎恶稳定、可靠、一步到位的瀑布模型，不太适用于违约风险大、需求不明确、快速见效的场景。
快速原型模型：不见兔子不撒鹰。期初不考虑质量、架构，用最快的速度见效，并向用户确认需求。经过几轮直观、快速的反馈，把需求确定下来。接下来，既可以抛弃原型用瀑布精密重构，也可以在模型基础上完善。优点是快速有效的确认需求。不足难以有效应对后续的需求变更。
增量模型：分而治之。将大系统横向拆分成相对独立的若干小模块，每个模块采用瀑布模式分批次交付。优点是较快见到成果，且能够及时了解项目进展。不足是存在需求明确、系统可拆分、交付可分批等适用条件。
迭代模型：罗马不是一天建成。把软件项目纵向划分成若干阶段，从核心功能入手，逐渐深化、细化，直到满足用户的全部需求。每个阶段都是一个瀑布，都要在前一阶段成果基础上加工、打磨。优点是快速满足基本需要，并体会软件演进的快感。不足是需求演化具有不确定性，会导致代码冗余、系统重构风险、项目周期不可控。
我做甲方管过不少外包项目，大V模型再熟悉不过了。整个过程冗长繁琐，走流程比建软件更累心。而且等项目结束的时候，需求早就变得面目全非了。乙方只能硬着头皮做，不然连业绩都没有，真是血本无归。在增量或迭代模型的每次交付后都做一次风险评估，演进为螺旋模型，可以及时止损。
项目做成这样，更深远的原因是业务都是在摸着石头过河，需求不变更才怪呢。但每年几个亿的信息化预算还是非常诱人的，投标单位络绎不绝。RUB看起来不错，但需求快速演化会依然带来无法回避的系统重构压力，终归还要具体问题具体分析。作者回复: 总结的非常详细👍
你的这些分享相信对其他看这篇专栏的同学都非常有价值👍2019-03-06 1 36- Felix在没听宝玉老师这篇文章之前，一直以为迭代模型就是敏捷(T﹏T)，期待下周二的文章
作者回复: 以前我也分不清楚：）
下周的敏捷开发文章会有针对两者的对比，希望能帮助你解惑2019-03-02 8 
tangkangkai快速原型模型和迭代模型感觉很像 都是先交付一个茅草屋 再根据反馈迭代 一步步迭代进化作者回复: 还是有些不一样，原型开发呢，基本上没什么设计，代码质量也不要求，甚至就是工具生成，就是为了怎么快确认需求怎么来。
而迭代模型则是控制需求范围，通过减少需求保证时间段速度快，不牺牲质量2019-03-02 8
AICC感觉迭代模型开发举的例子不是很贴切，显然从茅草屋到木屋到大别墅更像是快速模型中的抛弃模型，迭代模型我自己觉得更像是从一个毛坯房到室内装修再室外装修再加家具布置的精装过程哈哈哈哈作者回复: 确实，想通过类比的方式讲清楚确实有点难度。精装修的问题是，不是从头开发的，不涉及功能模块的开发，都是在修修补补：）
我们也不必过于纠结这些，毕竟例子只是辅助理解的，还有很多文字介绍，应该结合起来可以比较容易理解一点。从你的留言看明显是懂了的👍2019-03-02 7
小先生快速原型模型：使用原型图即可，用于确认需求。
增量模型：按模块划分，进行开发。
迭代模型：所有功能都做，但是做得比较简陋，下一个版本再进行迭代升级。作者回复: 👍都总结在点上。
我再补充一点文章中可能没交代清楚的：
迭代模型在迭代时，不是简单什么功能都做，而是在每个迭代选择当前优先级最高的功能，最核心的功能。2019-03-03 4- alva_xu修改一下。对于第二点，系统架构要尽量避免或减少修改次数，但在需求不是很清晰的情况下，系统架构肯定会随着需求的迭代而迭代。为了减少系统架构修改而带来的大范围的系统变更，应该尽量采用稳定的可伸缩的可插拔的分层的充分解耦的系统架构。老师你看这样表述是不是更合适些？
作者回复: 表述没问题的。
我觉得关于架构设计可以看看这篇文章：《从0开始学架构-08 | 架构设计三原则》合适原则、简单原则、演化原则https://time.geekbang.org/column/article/7071
跟你总结的比较类似，非常有道理。2019-03-02 4 
一路向北目前我们自己的项目基本上以迭代模型开发为主，几乎每周都会有一个升级的版本，主要是增加一些新的功能和修复前面版本的BUG。
对于一个需求不明确的项目，比较合适的步骤是：
第一，先做原型，和客户确认基本需求，来回几次之后基本上也就清楚客户6-7十的需求了。
第二，项目开发采用迭代模型，先给客户一个比较基础的版本，实现部分核心功能，给客户先用，客户在此基础上提出需求。
第三，迭代版本到一定的程度，如果软件的架构或者采用的技术不太合适，可以做一个重构，这时可以采用一个瀑布模式去做。
这里的关键是每个迭代周期需要设定实现的目标，实际过程中很难控制这个过程，因为即使做了一个短周期的迭代目标，客户的需求也会改变，这里是否有更好的方法？作者回复: 👍你的答案整理的很好。
如果没有直接客户，产品直接面向最终用户，这种可以跳过原型步骤。
有些大的重构和迭代可以并行做，重构的完了再把现有数据迁移过去
在一个迭代里面，正常情况下，是不会轻易接受需求变更的，会放到下一个迭代。如果必须要变，那就需要重新调整迭代目标了，但这样的情况不能出现太多，不然就失去迭代的意义了。2019-03-02 4
林云文中提出可以借鉴软件开发模型中的特点，这一点并不是普通软件开发成员可以使用的。任何一个软件开发模式都有对应的主要问题。就像你把飞机的引擎放在拖拉机上一样。需要对模型进行总体考虑。而且不同的软件开发模式都有对交付团队有能力的要求。举个不恰当的例子，组合软件开发模式的特点就像让一个摩托车驾驶员开着安装了飞机引擎的拖拉机。这并不是软件工程想达到的结果。希望作者对组合研发模式的前提和应用过程进行描述以减少软件工程方法使用的随意性。作者回复: 🤝谢谢指正，结合最近波音747Max的案例，确实不能乱用，不能说飞机的软件也用敏捷这种快速上线快速迭代的模式。
我觉得组合研发模式的前提还是质量，软件工程的目标就是要构建和维护高质量的软件，无论怎么组合开发模式，都不能牺牲质量。
这里我也列一些我觉得好的实践：
1. 瀑布模型可以参考敏捷开发，引入持续集成、自动化测试，提升效率
2. 敏捷开发可以参考瀑布模型，开发前多设计，开发后多测试，尤其是要辅助人工测试2019-03-13 3
老张需求不明确是经常发生的，要根据项目情况分析迭代还是增量模型。
一般来说，功能相对独立的项目更适合增量，比如管理信息系统，而单目标的系统更适合迭代，比如游戏、功能性软件(专家系统)。
其实这两种模式是经常混用的，因为项目中常常在分别有这两种情况出现。
另外，前后端分离式的开发模式其实也应该算一种开发模式，也就是前端工程师设计了全部交互，后端大部分代码自动化生成，核心架构才由后端工程师负责。作者回复: 👍是的，要根据实际情况选择。
至于前后端分离，算一种开发模式也说的过去。我个人觉得也算增量的一种，按模块划分，类似的还有按服务划分。2019-03-08 3
javaadu如果已经有客户了，但是客户需求不明确，那么这种情况比较适合使用快速原型模型确定客户的需求，然后再根据抛弃策略或附加策略进入下一阶段的开发，由于后期需求可能会变化很大，在后续开发中适合使用迭代模型（企业内部的业务管理系统属于这种情况，例如滴滴打车系统、美团外卖系统等等）。
如果暂时没有客户，但是我对要解决的客户问题很熟悉（很多toB的公司属于这种情况），只是具体方案没想好（后期需求会变），可以直接上迭代模型，同时需要在每个迭代间做风险评估。作者回复: 💯
迭代模型的时候，一定要注意先上优先级高的需求、核心的需求。2019-03-02 3
西西弗与卡夫卡当前不够明确、后期可能有较大变化的需求，准确说首先要考虑的不是用哪种开发方法，而是最好避免一开始就投入开发资源。开发的代价非常高，推倒重新开发的代价更高。最好是先想别的办法，验证需求是否真实存在之后再动手写代码作者回复: 👍是的，需求不明确导致的返工会造成很大浪费。
建议还可以思考下：如何验证？是全都验证还是先验证一部分？2019-03-02 3
fei宝玉老师，我想了想我最近做的一个系统，是对数据进行分析处理，计算每个任务阶段消耗的时间，整个业务流程共6大块，每块又分为5-15的小阶段，每个小阶段可能又有0-20个更小的粒度，
第一期先完成先对数据清洗处理后，计算6大块任务阶段每部分的耗时，将数据给经理展示看看能不能定位出每个任务主要耗时的任务阶段，如果效果能达到预期，进行第二期
第二期就是第二层粒度的数据，将任务耗时更加精细化
第三阶段考虑汇总所有数据、看看能不能找到一些规律，用一些折线图，饼状图等展示出来，提高指导产品的用户体验
我想了想，我每期提供一个可运行的版本、并且版本没有扔，每个版本有设计，文档，编码，测试流程，所以是典型的迭代融合瀑布模型吧。作者回复: 👍是的，应该就是迭代模型，整个项目变成了若干小的周期，每个项目周期就是一个瀑布模型。
另外不用纠结于是哪种模型，更多的是去看看这些模型哪些是有你可以借鉴的地方，看有什么是可以帮助你改进优化项目流程的。
比如说迭代模型，它的发布周期通常是固定的，一个周期到了，小瀑布要走完要发布小版本，这样可以避免延期，倒逼着你优先选取核心的功能。2019-09-09 2
库洛洛我是一个自由职业的freelancer，在我的开发历程中，最多的两个类型的客户，一种是山寨的直接拿了一个案例过来给你照着做，这种我会直接划分模块采用增量方法进行开发；还有一种是大致有一个想法，但没有明确需求，这种我会先出一个方案，将功能和客户的需求写下来，收取订金1，然后原型->修改->原型->修改的方法直至客户对他的想法有一个确认，对整个系统有一定了解，需求确认了我会再收取订金2，之后正式开发，选取框架，编码，测试，这样做有两个好处，一个是你的劳动可以分阶段收钱，一个是客户可以看到你的工作的付出，降低了客户和你的风险，双赢吧，如果到了某一阶段客户需要终止，也能即时止损了。作者回复: 赞，这样的做法确实不错，对客户来说可以不担心花了钱做不出来东西，对于你来说不担心做了收不到钱👍
2019-08-04 2
dave老师讲的非常好，请问老师的图是用什么工具画的？谢谢作者回复: Keynote画的，另外还有OmniGraffle
2019-04-25 1 2- 庄小P瀑布模型让我想起了我导师，经常和我们这样说，你想一下你十年后要成为什么人，然后倒退回来你现在研究生应该研究什么，再倒推回来需要补什么基础知识。
作者回复: 你们导师说的很有道理👍
2019-04-12 2 
Joey老师，您好！
认认真真看了之前每一篇文章以及所有留言讨论，
发现每个公司\团队的情况不尽相同，所以对于这些开发模型，没有哪个是最好的，只有选择最适合自己的就是最好的。
另外，我们公司是比较大的国企（多个业务部门对一个开发部门），对质量要求较高，现在业务条线也比较多，业务部门基本都嫌我们开发部门效率低，
对于我们研发部门，组织架构还是按照瀑布模型设计的，开发模型基本是迭代+增量，
如果想推行敏捷，肯定需要调整组织架构，一旦调整，就会触发一些利益关系，
请教老师，在在这种背景下，有没有什么好的招数，既可以提高研发效率，又可以保证质量？谢谢老师解答作者回复: 如果你想推行敏捷，可以先找个小项目，组个小团队试点，成了可以作为一个参考，领导可以去邀功，以后可以更大规模尝试；失败了也损失不大，领导也不用担责任。
不管用不用敏捷开发，你都可以学习其中好的实践，例如持续集成用起来，帮助你高效的集成部署；自动化测试代码写起来，帮助你提高项目质量；迭代快起来，以前3个月变成1个月，以前1个月的变2周。有些事情即使只是程序员都是可控范围内的，做着做着其实你就“敏捷”起来了。2019-03-03 2- alva_xu对于增量或迭代开发，大型企业需要考虑这些不适应点：
(1)大型官僚机构的办事程序和敏捷过程不匹配
比如开发想敏捷，但财务采购等都不敏捷。代码敏捷了，基础环境不敏捷等
(2)伴随增量的添加，系统结构会逐渐退化。
特别是对于大型系统，其系统结构的建设，就需要提前制定计划，而不是增量开发
(3)与开发方的合同问题，需要新形式的合同
旧形式的合同是固定合同，做多少事拿多少钱都在合同时谈好了，不适应工作量的变更。作者回复: 👍是的，要敏捷起来，组织架构、流程制度也必须要跟着调整，光喊口号做样子是没用的。
2019-03-02 2 
一步那么最小可行性产品MVP应该就是迭代开发了？作者回复: MVP更多的是需求定义上的概念，和开发模型并没有关系。
但是你使用迭代开发或者敏捷开发，必然要优先选择最核心最重要的功能需求先开发。
所以通常MVP的方式选择核心需求，用迭代模型或敏捷开发开发需求。2019-03-02 2
一年按照这个道理，开发一款测试市场反应的产品，也应该使用快速原型模型是不是好点呢老师作者回复: 恐怕不行，因为快速原型模型是牺牲质量的。质量差的软件，去测试市场，你不知道是因为质量问题不行还是需求没抓住不行：）
这种情况，可以考虑用迭代模型，先开发核心需求，然后再逐步迭代。2019-03-02 2
小伟我们组正在做系统的重构，属于平台系统，功能需求相对很明确，架构师从业务模型上给拆分成三个子系统，规定好系统间的协议后，同时对三个子系统重构设计开发，我理解这个属于增量开发模型吧？作者回复: 👍对，增量模型就是需求很明确，可以划分成几个模块，然后按照模块分别应用瀑布模型开发，而且多个模块可以并行开发。
2019-03-02 2