软件工程中的开发模型

本文阅读时间大约4分钟。

今天分享的是我在学习《软件工程之美》时候记录的最新的笔记，关于软件项目开发中的开发模型。宝玉老师用两节课的内容分享了以下内容：

瀑布模型的价值相当于工业界第一次提出流水线作业：让软件开发过程有序可控、让分工协作变得可能、让软件质量更有保障

瀑布模型最大的问题就是不能及时响应需求变更，越到后期变更代价越大。为了应对瀑布模型的问题，软件工程界衍生除了很多其他模型：快速原型模型、增量模型、迭代模型、风险模型等等。

开发模型，就是我们开发软件的步骤和方式。

在学校做一些项目的时候，完全没有开发模型的概念，并没有很好得将软件工程课程上上学到的理论知识应用到实践中，但是我们自己摸索出了一条路——边写边改模型。

工作以后，刚开始接触的都是一件成型的系统，我们接到的任务也是BUG FIX、新功能添加等等，运气好一点能赶上系统重构的任务，但是很少有机会能从0到1构建一个软件项目。

我经历的项目比较多，这些类型的项目我都经历过：处于迭代中的项目、处于维护期的项目、对老系统进行重构、从0到1构建一个项目。在这个过程中我遇到了很多痛点：

• 对于新入行的程序员，刚开始就进入一个迭代项目中，没有很好的全局观

• 老系统重构的时候，如何处理好新老系统的关系

• 如何平衡项目的周期和任务拆分

• 如何控制和管理需求的变更

• 如何把控项目的质量

• 我过去使用过的开发模型又哪些，是瀑布模型，还是迭代模型，敏捷开发又是什么模型

• 如何在将来的软件项目中选择合适的开发模型。

这次学习这门课的时候，我也在思考如何解决上述的疑惑。

现在很多团队都在强调自己是敏捷开发，但是敏捷开发其实不是一个开发模型，很多团队使用的其实是披在敏捷外衣下的瀑布模型，或者是迭代模型。

从需求方的角度来看，尤其是创业团队，如果一件事情已经想得很清楚，那么久说明已经有其他人做过了，那么他的价值也就不大了，因此在一个项目中，需求的变更是可以接受的，但是需要考虑时间成本、人力成本，不能将变更需求的成本一味得压到技术团队上，让技术团队用加班来应对需求的变更。

对于需求不明确或后期可能变化比较大的情况，宝玉老师给出的建议是：要看客户的情况，如果有客户，那么就可以先采取快速原型模 型，挖掘和明确客户的真实需求，然后再近些重新开发或迭代；如果没有客户，也就是需要有一定的质量，那么最好采用迭代模型，先验证核心逻辑的可行性，然后在后面的迭代中近些优化。

根据宝玉老师课程中给的案例，我总结了几条开发模型选择的标准：

• 有没有客户

• 客户的需求是否明确

• 项目当前的状态

• 系统是否支持模块化

• 客户对质量的要求

• 客户对软件交付时间的要求

实际工作中，常常需要根据时间情况，组合使用几种模型来解决问题，因为不同的阶段有不同的需求。

学习了《软件工程之美》的五六节课了，发现这门课还有一个很令人惊喜的地方：留言区非常活跃和精彩，其他读者的分享和老师的回复，令我更加深刻得理解了文章中的知识点，总之就是一个字：值。

你再主动一点点    我们就有故事了