从瀑布到敏捷一漫画解读软件开发模式变迁史（逐层刨析）

照片总览

内容概述

自上世纪由福特之父-亨利福特在汽车生产上创建第一天流水线式生产线，使得汽车制造行业迎来新的革命。汽车生产工业从此迈入大规模生产时期。并在随后，由丰田公司提出的丰田生产系统（Toyota Production System）又为汽车工业带来了很多先进的生产和管理理念。
实现好的经济效益 = 适合的生产模式 + 先进的管理系统。软件工业随起步较晚，但是发展的速度和规模却十分迅猛，也得益于优秀的生产模式和管理理念的发展。其中就有很多是在汽车生产中学习而来的。上面的图片，以汽车的生产过程为模型来了解软件开发模式的变迁史。（资料部分源自网上）

图片构造

自上而下依次为五个体系：
一.瀑布模型（WaterFall）

瀑布模式顾名思义，向水从高处往低处流一样，有个从上到下的逻辑关系。即线性开发模式，类似流水线生产，各自负责自己手头的工作，对上层交付的进行加工，然后交付给下层进行下一步操作。总体分为需求 → 设计 → 制造 → 测试，四个阶段。

从图可知，在该体系中，客户是被排除在生产过程之外的（围墙是不透明的是封闭的），只能从需求的接口处提出对产品的需求（Client places order）。也因此，客户是无法了解生产过程的费用及所需要的时间周期，因此会出下以下笑话------用户的期望和预算成本不匹配（跑车的需求，自行车的预算）

当需求被采纳后，便到了设计阶段。

设计完毕后交付下层开始执行生产环节。

在线性的生产系统中，需求和设计是不可以进行修改的。工人被安排在制造系统中一个个工位上，每个人仅负责一个部件的生产和装配，每人各司其职，负责好自己的任务便可。

（ I know HTML ）即对于HTML开发者来说，只需要完成对HTML的开发环节，对其他程序开发环节，不需要也不应该去关心。
当生产完毕就需要对产品进行测试(Teseing)

在图中这位老兄处于无事做的状态，不过并不是他在摸鱼，而是因为上边的生产环节还未完成。在瀑布模式（线性生产模式）中，下层的工作的展开是需要上一层的工作的完成并交付才能开始。有一个逻辑上的依赖关系。所等待的时间，对于追求效率的开发无疑是一种浪费。

生产测试完之后便可以下线交付了

在此模式中，客户的需求一旦确定，直到产品交付的整个过程中都不能进行任何改变（Plans never change）

二.敏捷开发(Agile)—对老旧模式的升级

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。(源自百度)

即在软件开发中，用户的需求总不可能从一开始便能完美的提出并被采纳，不可能所有问题都能考虑到。用户的需求在整个开发过程中不改变是不可能的。一开始所提出的需求会受到各种现实因素的影响最终会和初始期望不符合。因此在敏捷开发中客户参与了开发过程（Client is involved in the process）

在敏捷开发中，开发过程不在封闭，用户不再只能通过需求接口来提出需求，而是切切实实参与到开发过程。透明是关键（TRANSPARENCY IS KEY ）

但是，万事都有两重性，用户参与生产过程可以完善生产出来的产品，但是当过多的用户参与进来，越来越多不相关的需求被提出使得实现最终的产品变得困难。

敏捷开发中，相比与WaterFall，生产不再是线性，在开发的同时也会进行测试，使得开发的效率大幅度提高。

（Tesing）

敏捷开发的另一个重要概念就是迭代，就是不断对产品进行细微的、渐进式的改进（Small incremental changes），以至于最终生产出来的产品更能让客户满意。

利用敏捷模式开发出的产品，相较于传统的软件交付方式，一个显著的特点是能够及时响应客户需求的变更，不断适应新的趋势。能做到及时的满足客服新提出来的需求。

也因此敏捷模式的最终完成品会与最初的设计会有出入。

在垃圾桶里或许能找到您的第一份方案稿。：D

三.看板（KANBAN）


神奇的东方老者–丰田看板大师（KANBAN SENSEI）所说：确保所有团队能按照看板所列出的事项来有序进行工作。
也因此可以得知，相比与敏捷模式，看板模式更加的灵活并且有序。

看板管理，常作“Kanban管理",是指为了达到JIT准时生产方式而控制现场生产流程的工具，主流商管教育均对“看板”——这一源自丰田生产方式的管理工具有所介绍

看板要求把待完成的事项都列在表上以to-do的形式展出

在制造业中，看板也是非常重要的管理方法。也有将其称为目视化管理的。
对照着“板”的事项，每个人都可以直到自己所负责的任务，别人所负责的任务

四.Scrum（模式）

Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums.

Scrum主管 Scrum Master:

SCURM Master 对整个SCRUM 过程负责，不惜一切代价（AT ANY COST），保证团队的工作时间和计划
产品负责人 Product Owner:
产品负责人负责维护订单
开发团队 Team:

进行软件的开发测试维护环节
在 SCRUM 过程中，开发团队通常会进行冲刺 （Sprint）即完成任务的时间指标。

至于以下图片:

是对看板（KANBAN）和SCRUM之间关系的一个比较（或是结合）。（暂时未能参透）

五.精益软件模式

麻省理工《国际汽车计划》研究团队主要成员、《改变世界的机器》作者沃麦克，在他与琼斯合著的《精益思想》中说；《改变世界的机器》提供了丰富的标杆数据，介绍了由日本丰田公司首先推出的，在生产组织、管理方面的一种好方式。我们称这种方式为精益生产方式（简称精益生产），因为用这种方式能以越来越少的投入获取越来越多的产出

精益软件开发不再像传统的软件开发一样，耗时几年才向客户交付完整的软件。取而代之的是，优先建立一个最简可用的原型产品投放市场或交付到客户手中。让客户先享受到产品带来的收益是最重要的

Eric Ries曾在《精益创业实战》中提出MVP（minimum viable product）概念，意即“最简可行产品”——用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节。（网络资料）

尽管MPV 的概念听上去是如此的简单，可是实施起来却没有那么容易

所有不必的东西（ALL NON-ESSENTIALS ARE THROWN OUT）都不能应用到当前的最小可用产品。
此外，尽早交付产品给客户或部署到生产环境，也促进了 DevOps，持续集成（CI），生产环境测试（testing in production）等实践的发展。尽早交付产品，尽早从用户获取反馈，不论是好的还是坏的，促使问题尽早暴露，尽早修复，持续集成，持续改进。

In the end

该图片自上而下的顺序，是软件生产模式发展的迭代更新，相互之间都有关联。不同的开发项目需要的模式是不一样的，选择合适的模式能够在生产开发中能有更高的效率。了解各种不一样的开发模式对于今后的实践工作有很大的帮助。