近几月学习了决胜B端这本书，收获很大（特别推荐），也是在这本书的引导下，花了一段时间在B站学习了清华大学的软件工程课程，以下是自己结合实际工作的一些总结和感悟
01瀑布模型从哪里来？
早期的软件开发管理处于探索阶段，会学习其他领域的一些做法，例如经典的瀑布模型产生于硬件领域，它是从制造业的角度去看软件开发的，当时的软件开发是处于萌芽阶段，而制造业经过这么多年的发展，具备了比较成熟的方法论，所以从制造业学习经验对当时来说是无可厚非，并且在当时的时代背景下，也取得了一定的成就。制造业重流程，重工序，软件开发行业结合其特性，产生了瀑布模型。
瀑布模型也是面向过程的，它的开发阶段是严格按线性方式进行，每一个阶段具有相关的里程碑和交付产品，且需要确认和验证。站在制作业的角度，为了追求效率，通常会采用流程化和规模化的生产方式，不可否认这种思想和制造业的结合是非常适合的，在软件开发的发展初期，线性方式的开发也对整个软件开发行业起到了促进作用。
正确的使用瀑布模型能节约大量的时间和金钱，在那个需求变化不多的年代，瀑布模型拥有其价值。
02
瀑布模型之核心思想
应运而生的瀑布模型短时间内被大部分软件开发公司所推崇，合理的使用瀑布模型让原本杂乱的软件开发变得有序。我们能看到，瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
如此的强调过程，必定会将混乱变得有序，但同时，也不再接受变化。瀑布模型具有几个典型特征
1.强调文档
瀑布模型中前一个阶段的输出就是下一个阶段的输入，文档作为是阶段之间衔接的唯一信息，是必不可少的。
瀑布模型是典型的预见性开发方法，加上开发过程中严格遵循步骤顺序进行，能够为项目提供按阶段划分的检查点，为了控制过程，软件开发过程中产生了大量的文档，一定程度上防止了混乱的产品，可以看出，瀑布模型是以过程控制为核心，以文档为驱动的开发过程。
严格的过程控制避免了混乱，但也带来了瀑布模型一个致命的缺陷，无法适应变化，对于经常变化的项目而言，瀑布模型无法体现他的思想和价值。瀑布模型中产生的大量文档，维护起来相当困难，极大的增加了开发的工作量。
2.拒绝变化
瀑布模型一个典型的特征是拒绝变化，瀑布模型强调过程，当变化不断发生的时候，会严重破坏瀑布模型本身的特性。拒绝变化也导致整个开发过程中不可逆。
3.排除客户
整个开发过程中，客户永远被排除在软件开发流程之外，只能通过需求接口人反馈需求。软件开发中，软件开发时间本身不可控，导致大多数项目都会存在延期，但和客户缺少沟通导致客户无法理解为什么交付总是延期。
瀑布模型的冗长周期加上不可逆，客户只有在最后一刻才能感受到软件的面貌，假如这时候客户发现软件不符合自己的期望，其中浪费的人力和物力是巨大的。
03
为何传统瀑布模型不再适合互联网产品
目前的大部分理念都认为，软件开发是一个创造的过程，而不是一个制造的过程，在传统制造业中，可能不同批次的人，能根据要求生成同一批次相差不大的物品，但在软件开发中，一个项目具体的成效如何，跟“人”这个因素有很大的关系，所以从制造业的角度去看软件开发是不合适的。
软件开发具有迭代性，需要不断的反复尝试，通过比较和选择不同的设计，最终确认令人满意的问题和解决方案。
谈到为何传统瀑布模型不再适合互联网产品时，我们应该先谈谈软件的本质特性，软件具有复杂性、演化性、不可见性三种本质特性。复杂性容易理解，一个能解决具体问题的系统，其本身的系统构造与逻辑处理必然有一定的复杂性。
演化性是指系统在和具体环境的交互中，会不断修改去适应环境，解决问题，不断的修改所带来的副作用会导致软件的退化，但与之矛盾的就是，我们应该清楚的认识到，一个不断修改的软件才证明始终有用户在使用它。
不可见性代表着我们无法对软件人员的工作质量，工作时间进行控制，也正是这点，与制造业背道而驰，制造业恰恰追求其可控性。
随着整个软件行业的发展以及互联网的浪潮的推动，软件开发者逐渐意识到，软件开发不是一开始就能看到结果的，它是一个逐步认知和明晰的活动，软件开发中的变化是实际存在和必然的。既然我们终究要面对变化，那意味着我们要在整体上抛弃传统的瀑布模型。
外部环境的变化促使着软件开发思想的转变。当互联网蒙眼狂奔的时候，速度，创新，快速响应用户需求等新要求不断冲击着传统的软件开发思想。
互联网的产品具有新的特点，它强调速度，快鱼吃慢鱼，市场第一独大，它强调创新，谁先找到用户的痛点，谁就能打下一片江山，它强调快速响应用户的变化，