全面解析瀑布式开发和敏捷式开发 - 项目管理

很多人毕业后，都在从事跟所学专业不同的工作，有的人一筹莫展，有的人习以为常。

我是一名编导生，毕业后去做抗战纪录片，工作中接触更多的是历史、影像与表达。但一个偶然的契机，让我转战向互联网产品行业，工作中对接的是产品经理、开发和测试，用户画像、CDN 、 UV 、 PV 等一大堆新概念也扑面而来。后来又从产品逐渐深入到软件行业，有朋友认为这是新世界的大门；也有朋友觉得这是当下社会的缩影，各行各业的发展牵动着人性的各种追求与欲望，毕竟人们总想要追求新事物。于我而言，每天推陈出新，不断收获，享受当下就好，然而，接纳新事物其实没那么简单。

最开始接触软件行业，最常听到的就是瀑布式开发、敏捷开发，于是心里就有了疑问，我翻阅了各大网站查找相关的资料，去B 站上观看图文结合的相关视频，结合自己的理解，以刚入行的视角现给大家整理了一份有关敏捷式开发与瀑布式开发的概念解析。

参考资料推荐：禅道官网、 CSDN博客、 B站视频

一、什么是瀑布式开发

瀑布式开发的基本流程是需求 → 设计 → 开发 → 测试，是一个更倾向于严格控制的管理模式。要求有明确的需求，大家按照需求一步步做好规划，每一阶段工作的完成是下一阶段工作开始的前提，每一阶段都要进行严格的评审，保证各阶段的工作做得足够好时才允许进入下一阶段。这种模式一般适用于需求比较明确、to B 端的项目。

不得不说瀑布项目失败率会比较高，因为它有一个很大的缺陷，就是受各种条件的制约。当产品研发完成后，到了产品测试阶段万一发现问题，或者发现其无法满足市场需求，那么就需要重新开发，甚至需要重新规划产品，这间接导致了产品延期发布的高发性与不确定性。

微软的瀑布式开发模式就是个很好的例子。随着用户对软件的需求越来越苛刻，微软的软件产品曾经遭受了大家的不满，原因并非是产品的使用问题，而是其更新周期太过漫长。比如微软Office 、 Windows 等主打产品的更新周期长达 3 年左右，软件延期发布实属家常便饭，此时微软的瀑布式开发模式已经难以满足新型软件的开发要求，不得不改变产品的研发策略。

随着网络的逐渐兴起，软件交付模式发生了巨大变化，也正是在那个时候，“敏捷开发”模式被国外的软件先行者们探索出来了。

二、什么是 敏捷式开发

简单的说，敏捷开发是一种以用户需求进化为核心、迭代、循序渐进的开发方法。首先把用户（客户）最关注的软件原型做出来，交付或上线，在实际场景中去快速修改弥补需求中的不足，再次发布版本。通过一些敏捷实践方式，细化story ，提供更小的迭代。如此循环，直到用户（客户）满意。适用于需求不明确、创新性或者需要抢占市场的项目。

还是拿微软来说，微软的Visual Studio 2010是公司内部首个因敏捷开发模式而受益的Visual Studio版本，该软件发布于2010年4月，耗费了两年的时间完成开发，但随后研发团队发现软件中的许多模板对于敏捷开发者来说太过笼统，几乎没有太大的实际意义，微软的软件研发策略也就从此开始发生了巨大变化。以往的产品更新周期为两到三年，目前的版本更新速度已经缩短至一个季度左右，这在瀑布式开发模式下是难以想象的。

敏捷式开发在国外大放异彩，当然在国内也不例外，国内很多研发者们结合当下软件市场环境，也有了新的研发策略。

国产开源的禅道项目管理软件，2009 年开始遵循Scrum （敏捷式开发中比较流行的一种方式）的管理思想，发布了第一个产品版本。自发布以来，禅道 连续四年荣膺国内外软件测试行业最常用测试管理工具第一名 ，也算是国产软件的骄傲了。

在产品开发过程中，禅道研发团队认为Scrum方法虽然注重实效，操作性强，非常适合软件研发项目的快速迭代开发，但它只规定了核心的管理框架，还有很多细节流程没有完善。于是禅道团队结合国内研发现状，整合了bug管理、测试用例管理、发布管理、文档管理等功能，完整的覆盖了软件研发项目的整个生命周期。在禅道软件中，明确将产品、项目、测试三者概念区分开，产品人员、开发团队、测试人员，三者分立，互相配合，又互相制约，通过需求、任务、bug来进行交相互动，终通过项目拿到合格的产品，是敏捷式开发的优秀案例。