04 | 瀑布模型之外，还有哪些开发模型？

Mar 2, 2019

04 | 瀑布模型之外，还有哪些开发模型？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

04 | 瀑布模型之外，还有哪些开发模型？

2019-03-02 宝玉来自北京

《软件工程之美》

课程介绍



讲述：宝玉

时长16:48大小15.40M



你好，我是宝玉，我今天分享的主题是：瀑布模型的衍生模型都有哪些，你该如何选择？
在上一篇文章中，我重点介绍了瀑布模型。你现在知道了，瀑布模型简单易行，对于软件质量是有比较高保障的。但是瀑布模型对于前期需求不明确的项目，很难开展需求分析，后续如果有需求变更，瀑布模型便很难响应。
而且，每个软件项目的情况各不相同，都有自己的特点。比如说：
有的项目风险很高，客户可能随时不给你钱了，得要做好准备，随时止损；
有的项目客户自己没想清楚要想的是什么，做出来后再提各种修改意见，必须得想办法降低变更成本；
有的项目客户希望能很快就能上线。
如果选用瀑布模型做这些项目，就会导致成本过高或者周期过长等问题出现。所以，并不是所有的项目都适合使用瀑布开发模型，你需要针对不同的情况做一些调整。
实际上，为了应对瀑布模型的不足，已经衍生出了很多其他的开发模型。今天，我将为你分享一些有代表性的瀑布模型的衍生模型，你可以了解到这些衍生模型的本质，在接手不同类型的项目时，可以灵活地进行选择。
快速开发快速改快速原型模型
我刚毕业时参加了一个项目的开发，项目经理跟我说，这个项目怎么快就怎么写，不要在意代码质量、架构、性能这些，当时我表示很不能理解，哪有这样做项目的？
我还偷摸着花了很多时间想把代码写好，结果发现，这个快速做好的简单版本，主要目的就是为了给客户演示，跟客户确认需求，然后把客户的反馈记录下来，再去优化。这样几个小版本下来，基本上就把需求确定了，而我当时写的好多代码根本就用不上。
后来我才知道，这就是快速原型模型。
快速原型模型，就是为了要解决客户的需求不明确和需求多变的问题。
先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫原型模型。
这就好比客户想要盖房子，但是他没想好要盖成什么样子，于是施工方就先搭了一栋彩钢房（就像工地里面搭的临时房子），让客户先用起来，然后再给反馈调整。
因为彩钢房搭建简单快速，改起来也相对容易。等到客户确定好需求，再在已经搭好的彩钢房的基础上完善，或者直接重新按照确定好的需求造房子。
不过，这样做也有一个问题，用彩钢房这种方式盖房子虽然快，但是房子质量不会太好，住的不算舒服，想有点个性化的风格也难。
同样的道理，也适用于软件项目。彩钢房就像是软件原型，重点是反映软件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但开发速度可以很快。
原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求。
但这种快速原型开发往往是以牺牲质量为代价的。
在原型开发过程中，没有经过严谨的系统设计和规划，可靠性和性能都难以保障。所以在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略。
抛弃策略是将原型只应用于需求分析阶段，在确认完需求后，原型会被抛弃，实际开发时，将重新开发所有功能。类似于用彩钢房盖房子，确认完客户需求后，拆掉重新建。
附加策略则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求，最终将原型变成交付客户的软件。类似于用彩钢房盖房子，最后还要做一番精装修，交付客户。
采用哪种策略来应用原型模型，还是要看项目特点，包括所采用原型开发工具和技术的成熟度。举例来说，如果客户对可靠性、性能要求高，那么就最好是抛弃策略，如果客户对质量要求不高，有简单功能就够了，那么可以试试附加策略。
快速原型模型即使到现在还一直有在用，用于低成本快速的确认需求。如果你将来遇到这种项目，就没必要花太长时间在代码质量上，赶紧做出来才是王道。
另外，原型制作并不一定要像传统代码一样进行设计编码，有很多原型工具，像 Axure、墨刀等，简单的拖拽就可以实现简单的界面和交互，同样可以达到确认需求的目的。现在原型设计已经成为产品经理确认需求的一个非常重要手段。
大瀑布拆小瀑布瀑布模型的很多问题，根源都是周期太长。周期长所以中间难以响应变更，周期长所以客户很久才能看到结果，周期太长所以风险不好控制。如果能将周期变短，那么很多问题就迎刃而解了。
基于这种思路，产生了很多开发模型，比较典型的主要是：增量模型 和 迭代模型。
增量模型——按模块分批次交付
增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试。相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是分批次交付。
如果拿盖房子来比喻的话，就是先盖卫生间，然后盖厨房，再是卧室。
盖卫生间的时候，也要先分析需求，然后设计，再实施，最后验收。有时候也可以多模块并行，例如同时盖卫生间和厨房，前提是模块之间不能有依赖关系，比如，你不可能先盖二楼再盖一楼。
你会发现，增量模型将整个系统进行模块化处理，所以你可以分批次交付软件产品，使用户及时了解软件项目进展。如果一个模块有问题，或者需要做需求变更，对整体影响也有限。在开发的时候，也可以灵活地按照模块来分工，多个模块并行开发提升效率。
因为增量模型的根基是模块化，所以，如果系统不能模块化，那么将很难采用增量模型的模式来开发。另外，对模块的划分很抽象，这本身对于系统架构的水平是要求很高的。
基于这样的特点，增量模型主要适用于：需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。
迭代模型——每次迭代都有一个可用的版本
迭代模型每次只设计和实现产品的一部分，然后逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。
我们还是继续拿盖房子来举例：如果用迭代模型的方式盖房子，第一个迭代要先盖一个茅草屋，快速满足客户对房子的核心需求；第二个迭代再盖一个小木屋，比茅草房更大更舒适；第三个迭代再盖成一个豪华别墅，满足客户所有需求。
你要注意，无论是造小木屋还是大别墅，整个过程都会像一个完整的项目一样，包括需求分析、设计、实现与测试验收。
在迭代模型中，整个项目被拆分成一系列小的迭代。通常一个迭代的时间都是固定的，不会太长，例如 2～4 周。每次迭代只实现一部分功能，做能在这个周期内完成的功能。
在一个迭代中都会包括需求分析、设计、实现和测试，类似于一个小瀑布模型。迭代结束时要完成一个可以运行的交付版本。
迭代模型和增量模型很容易混淆，因为都是把大瀑布拆成小瀑布。这两种模型的主要差别在于如何拆分项目功能上。
增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能。
还是用盖房子来理解，增量模型则是先盖厨房，再是卧室，这样一个个模块来完成。而迭代模型则是先盖一个简单的茅草房，有简易的土灶和土床，然后再升级成小木屋，有更好的灶和更好的卧室，这样一步步迭代成最终的房子。
我原来参与过的瀑布模型开发的项目，因为要很长时间才能看到最终结果，而且结果通常跟最初描述的结果相差较多，客户看到后多少会有些心理落差。
而后来改用迭代模型后，因为每次迭代完成后都有可以运行的版本，这样客户可以直观感受软件的进展，及时调整心理预期。尤其是当客户见证了一个软件从简陋到完善的过程，往往满意度是比较高的。
迭代模型最难的部分，在于规划每次迭代的内容和要达到的目标。多了可能完不成，少了可能造成每次迭代工作量不饱和，这需要在实践中去摸索，一个迭代一个迭代的去调整。
迭代模型由于在初始迭代时，只清楚当前迭代的需求，而不知道后续需求，设计可能会考虑不周全。这样的话，迭代一多，系统会有不少冗余，一段时间后就需要对系统进行重构。
另外每次迭代，用户可能会增加新的需求和对现有需求进行更改，因此开发时间上可能会比预期要长。如果你做的是小项目的话，并不建议使用迭代模型来开发。
我该选择什么过程模型？除了上面提到的这几种模型，还有很多其他开发模型，要记住所有的开发模型很难。你搞透了瀑布模型，搞清楚了其阶段划分，结合一些应用场景，你就可以举一反三，了解绝大部分衍生模型。
我在这里给你列举几个常见的项目场景，我们可以一起来分析下，看看用什么模型适合。
场景一：外包项目，需要阶段验收
假如你现在是一家外包公司，你可以采用瀑布模型开发，但是甲方需要对你项目的每个阶段进行验收测试，以确认你是不是达到要求。
针对从需求定义一直到编码阶段，每个阶段都有对应的测试验收。如果画成图，就是下面这个样子的。
这个模型就是 V 模型，本质上它还是瀑布模型，只不过它是更重视对每个阶段验收测试的过程模型。
场景二：项目风险高，随时可能会中断
如果你现在要做一个风险很高的项目，客户可能随时不给你钱了。这种情况下，如果采用传统瀑布模型，无疑风险很高，可能做完的时候才发现客户给不了钱，损失就很大了！
这种情况，基于增量模型或者迭代模型进行开发，就可以有效降低风险。你需要注意的是，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损。
图片来源：WikiPedia
这种强调风险，以风险驱动的方式完善项目的开发模型就是螺旋模型。
场景三：山寨一款软件产品，希望能快速上线发布
其实软件行业山寨的案例不少，山寨项目的特点是，项目需求是明确的，不会有什么变化，这时候就可以选择增量模型，划分好模块，先实现核心模块，发布可运行版本，再增量发布其他模块。多模块可以同步开发。
场景四：客户都没想清楚想要什么，但是个大单子
很多项目，客户一开始都没想清楚想要的是什么，需要花很长时间去分析定义需求，但是单子很大，值得认真去做好。
那么这样的项目，你可以考虑拆分成四个阶段：
1. 初始阶段
主要是确定需求边界和主要风险，几乎没有什么开发工作。
2. 细化阶段
这个阶段主要是确定需求，可以采用快速原型模型开发，和客户对需求反复确认，需要辅助一定量的开发和测试工作。对代码质量可以要求比较低，重点是确认需求。可能需要一个或多个版本迭代。
3. 构造阶段
在需求确认清楚后，现在可以使用迭代模型来开发，逐步交付产品。这个阶段的重点是开发和测试。如果迭代中，有新的需求加入或者需求变更，也可以在新的迭代中加入。
4. 交付阶段
在开发和测试完成后，产品可以交付客户，根据线上运行情况还需要修复一些 Bug。这个阶段重点是测试和部署。也会有多个迭代。
整个过程看起来就像下图这样。
图片来源：《构建之法》
上面这种开发方式来源自统一软件开发过程（Rational Unified Process，RUP），适用于复杂和需求不明确的软件系统。
场景五：我的产品已经上线，但是需要持续更新维护
很多产品在上线后，还在保持不停的更新维护，修复 Bug、增加新功能，每个月甚至每周更新。
在这种情况下，迭代模型是比较合适的。固定时间周期，在固定的周期内选择适合的需求开发任务和 Bug 修复任务去完成，按时发布。
另外还可以尝试敏捷开发，也是基于迭代的开发模型，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度。在敏捷开发中，系统交付的周期称之为冲刺（Sprint）。
严格来说，敏捷开发并不算是一种开发模型，更像是框架或指南。有各种开发模型来实现敏捷开发，比如说极限编程（Extreme programming），看板（Kanban）和 Scrum。有关敏捷开发，我将在下一篇中向你详细讲解。
总结现在的软件项目，各种类型都有，根据项目特点，选择好合适的开发模型，可以让你事半功倍，降低项目风险，提高项目开发效率，控制项目成本。比如说：
一个以确认需求为主要目的的项目，就可以不用花太多时间在代码质量上面，低成本、高效做出来才是最重要的；
一个高风险的项目，则可以采用螺旋模型，出现问题及时止损；
一个很长时间加班加点，却一直没法上线，导致士气低落的项目，可以改成增量模型，先上线一个小模块，让大家看到成绩提升士气，然后再迭代，逐步上线其他模块。
同时，你也不必拘泥于这几种开发模型，还可以借鉴其他模型做的好的地方，甚至创造自己的开发模型，比如说你觉得敏捷的“站立会议”适合你的项目，那也可以借鉴过来。
课后思考如果一个项目，需求不明确，后期可能会有比较大的变化，你觉得应该采用哪种开发模式或者哪几种开发模式组合比较好？你现在所参与的项目开发中，是采用的什么开发模式？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 18

提建议

03 | 瀑布模型：像工厂流水线一样把软件开发分层化

05 | 敏捷开发到底是想解决什么问题？

 写留言

精选留言(46)

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

