从瀑布式到DevOps，开发流程经历了什么？

　　上个世纪四五十年代，程序设计刚刚诞生之际，是没有“软件”的概念的。硬件是开发的主体，规模小、工具简单，而且主要是用于科学计算。

　　随着软件概念兴起，一些针对软件开发的“小作坊”也随之涌现。作坊做法往往随意，以个别编程员的意愿为主，没有形成明确标准，效率不高。此外，“作坊”式开发特别倚重个人能力，大多都杂乱无章，软件质量也无从保障。

　　20 世纪 70 年代开始，“工程化”思维开始进入软件开发流程。主要原因是，信息技术发展迅速，人们对软件的需求变大，软件生产必须提高产能，走向规模化。

　　然而，从工业借鉴而来的开发流程是否真的适合软件开发呢?随着社会不断发展，数字技术打破了各行各业的生产范式，软件开发自身也并没有停止进化。这些年，软件开发流程都经历了些什么呢?

　　师从工业的瀑布式开发

　　1913年，福特开发出了世界上第一条流水线，打破了汽车制造业的手工作坊式生产方式，这一模式的出现改变了世界。标准化和规模生产将汽车带入了寻常百姓家。

　　在软件开发陷入生产效能无法满足日渐扩大的需求的困境中时，福特的“流水线”概念或许多多少少启发到了当时的软件开发者们。

　　瀑布式开发(Waterfall)由此出现。大多数观点认为，传统瀑布式开发有不少于30年的历史。

　　其根源可以追溯到 1970 年，那一年温斯顿·罗伊斯(Winston Royce)在论文《管理大型软件系统开发》(Managing the Development of Larger Software Systems)中提出，将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

　　但是，这样套用传统工业生产的方法，多少会有不适应计算机软件开发的弊病。因为过程是线性的，没有充分照顾到客户需求，难免会闹出一些笑话：比如客户希望你造一辆汽车，却经费不够，但瀑布式开发要在汽车完成生产和测试之后，一次性交付到客户手中，需求沟通不足导致最后交付的却是一辆自行车。

　　瀑布式开发模式较好的例子是微软。微软 Office 、 Windows 等主打产品的更新周期一般 3 年左右，软件延期发布也是家常便饭，因此其软件产品遭受大家诟病也是无可厚非。随后，微软不得不放弃传统的瀑布式开发模式，改变产品研发策略。

　　有观点认为，瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。

　　因此，在需求不明并且在项目进行过程中可能发生变化的情况下，瀑布式基本是不可行的。

　　向客户倾斜的敏捷开发

　　时间到了上个世纪90年代，一批轻量的软件工程方法和框架相继诞生，它们共同的特点是，相对传统软件工程，都遵循演进和迭代的模型，过程更加轻量灵活。

　　既是对传统的反叛，也是对野蛮生长的规范，敏捷运动应运而生。

　　2001 年 2 月，17 位轻量级软件工程方法的代表人物，齐聚美国犹他州的雪鸟滑雪胜地，其中也包括 Scrum 和极限编程的几位发明人。在两天的会议之后，敏捷宣言发布。

　　敏捷概念的出现，可以说适逢其时，立即在当时发展成为了一场运动，被迅速地推广和应用。在早期，敏捷专注研发交付，目标是帮助产品和研发团队提升敏捷响应能力。

　　但是，之后敏捷开发开始向客户靠拢，成为以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，客户会参与到软件开发的整个流程中。整个开发过程不再是一堵不透风的墙，透明是关键(TRANSPARENCY IS KEY)，但是，随着越来越多的用户参与进来，越来越多的问题也暴露出来了，越来越多不着调的需求也会被提出。

　　因此，在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，可独立运行的小项目，在此过程中软件一直处于可使用状态。

　　在微软云计算 Azure 的理解中，敏捷的基础是创建工作原型或在需求和要求不断变化的现实中构建。弥合开发团队和最终用户之间的差距，适应性是敏捷的核心属性，优先考虑用户和利益干系人的需求，而不是严格的计划。

　　DevOps带来的改变是巨大的

　　显然，敏捷并没有将“运维”作为关注的重点。实际上，光有系统开发是不够的，开发完的系统必须即时顺利部署，并连续稳定运行才能够实现价值。而传统上，这部分是由运维负责的。

　　《阿里巴巴 DevOps 实践》认为，从价值的角度，开发加运维才构成相对完整的 IT 价值链。而DevOps 的诞生，正是为了解决IT 价值链的最突出问题——开发和运维之间的问题。

　　在传统的 IT 组织下，开发团队 (Dev) 和运维团队 (Ops) 之间有一道无形的部门墙。开发团队(尤其是敏捷团队) 追求变化，运维团队追求稳定，二者存在利益冲突。

　　2009 年，比利时独立 IT 咨询师 Patrick Debois 组织了第一届 DevOpsDays， DevOps 正式登上舞台。此后，DevOps 发展迅速，已经为企业数字化的核心能力之一，是对 IT 交付和运行的基本要求。其中，以容器化和自动编排调度为代表的云原生技术的出现极大加速了这一进程。

　　根据微软云计算 Azure，DevOps 的独特之处在于开发、IT 运营、质量工程和安全团队协同工作，在发布新产品、版本或更新所涉及的所有任务中创造效率。其中，DevOps 的主要表现形式包括持续集成、持续交付和连续部署。

　　在 《凤凰项目》和《DevOps 实践指南》两本书中，Gene Kim 等人总结了 DevOps 实施的三步工作法：

• 流动原则:聚焦 IT 系统的整体价值流，全局优化，保证价值从左(上游)到右(下游)的快速流动。
• 反馈原则:创建从左到右的反馈循环，并缩短反馈周期和放大反馈效果。这样，就可以更快的响应和理解内外部客户，并即时获取改进所需要的知识。
• 持续的实验和学习原则:创建承担风险、持续实验并从错误中学习的文化，在不断的尝试中精进能力，并提高系统的韧性。

　　在现实操作中，DevOps 也不乏实现工具。比如我国国产的飞算 SoFlu 全自动软件工程平台，其出发点是想让 DevOps 真正的落地，而实现“落地”，首先重点要解决的就是开发的问题， 包括开发的品质、安全和效率等，再逐步解决测试和运维问题。

　　除了飞算 SoFlu 全自动软件工程平台，帮助 DevOps 实现组织落地的工具不在少数，其中还包括开源的 CI/CD 服务器 Jenkins、容器平台 Docker等等。

　　此外，值得关注的，在主流观点中DevOps 成功与否的重点，或许不在现实层面，而在于文化。Puppet field CTO Nigel Kersten 就曾表示，“仍然存在组织对变革的抵制，这是一个真正的问题。而且人们真的没有看到他们实际上试图通过 DevOps 实现的实际价值。”

　　从瀑布式开发、到敏捷，再到目前最流行的DevOps，不难发现，软件开发流程正在向自动化、便捷化和智能化的方向发展，而这样的发展会大大加快开发效率、降低开发门槛，让未来的开发流程呈现出全然不同的样貌。