2.2 从瀑布到敏捷

DevOps思想可以被认为是敏捷开发思想的延伸和扩展，因此我们再回顾一下敏捷开发思想的发展历程，以便更好地理解DevOps和软件工厂的理念。

谈敏捷开发思想就不得不谈瀑布模型，如图2-1所示。

瀑布模型的基本谬误在于：它假设项目只经历一个过程，而且架构是优于使用且易于使用的，对于实现的设计是合理且可靠的，编码实现在测试进行中是可修复的。

换句话说，瀑布模型假设错误全发生在编码实现阶段，因此它们的修复可以很顺畅地穿插在单元测试和系统测试中。

特别是从项目管理的角度来看，瀑布模型将各种工作角色隔绝起来，他们无法看到各角色之间的关联，更侧重将工作扔到“瀑布后面的”下游团队。因此，各团队更像“我们与他们”式的独立团队，由此带来的后果就是，“现在的”工作是“我们的”，“以后的”工作是“他们的”。

2.2.1 传统项目管理问题

传统项目管理的核心领域主要为范围管理、时间管理、成本管理、质量管理和风险管理，如图2-2所示。

另外，在传统项目管理的思想下，每个领域会存在以下隐藏的假设。

1.范围管理

❑ 范围可以完整定义。

❑ 范围定义可以在项目开始前完成。

2.时间管理

❑ 软件开发由截然不同的活动组成。

❑ 可以对软件开发活动进行排序。

❑ 总会有一种方式产生有意义的估计。

❑ 项目团队的规模不会影响开发过程。

3.成本管理

❑ 可以单独将活动分配给团队成员。

❑ 一位开发人员的成本与另一位开发人员相同。

❑ 能够获得可接受的准确估计。

4.质量管理

指标足以用于评估软件的质量。

5.风险管理

风险可以接受、转移、避免、缓解。

2.2.2 向互联网企业学习的敏捷

国内传统企业（如银行、运营商等）企图通过导入敏捷项目管理模式来改变软件生产模式，但是目前看来效果不是非常理想。因为国内最先推行敏捷开发思想的互联网企业居多，而国内传统企业是向互联网企业学习的，但是国内传统企业与互联网企业存在比较大的差异。差异体现在很多方面，例如：互联网企业可以使用清一色的X86机器，而国内传统企业背负了很多历史包袱，使用的有X86机器，有小机也有大机等；互联网企业可以快速地推出产品，找终端用户试错，而国内传统企业依赖第三方开发商的合同式开发，流程长、周期长、政策规范、监管严、试错成本高；互联网企业是小规模团队协同，而国内传统企业的部门众多……

这就导致国内传统企业向互联网企业的学习不起作用。

我们认为国内传统企业不能为了敏捷而敏捷，应该从敏捷的本质出发，去学习和掌握敏捷。

2.2.3 敏捷的起源

大部分人认识的敏捷，是2001年17位方法学家在Utah-Snowbird会晤，并进行大量的讨论后形成的“敏捷宣言”发展出来的软件工程方法，如图2-3所示。

而我认为敏捷的缘起要追溯到20世纪20年代。

20世纪20年代，Frederick Taylor的“科学管理理论”提出，由管理者为每个工人发送指令卡，工人按照指令卡执行，管理者比工人更了解工作状态（这和敏捷没关系，但为后续的“知识工人”做了铺垫）。

20世纪50年代，美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式增量方法（IID）。

20世纪60年代，随着科技发展，制造业岗位消减，“知识工人”产生，旧模式不再奏效，生产工具在人的头脑里，旧方法被提倡信息共享和劝导的新方法代替。同时，Thomas Gilb提出演化项目管理的概念（EVO方法）。

1970年，Winston Royce发表文章Managing the development of large systems，阐述瀑布方法的概念，并注解说明“是危险的并且可能导致失败”的原因，因为它将测试放在了最后。

1986年，Tankeuchi和Nonaka发表白皮书The New New Product Development Game，讨论了Scrum方法。

由此可见，很多国内传统企业向互联网企业学习敏捷是错误的，正统的敏捷早在互联网企业盛起之前就存在，我们不应该学习互联网式的敏捷，而应该回归正统敏捷。

真正有效的敏捷应该是自企业文化开始的敏捷，只有企业敏捷、组织敏捷，才能项目敏捷。互联网企业能轻易实施敏捷项目管理的根本原因是其自身的敏捷，互联网加速了人与人、企业与企业之间的沟通。为了快速应对市场变化，抢夺市场制高点，需要快速推出产品，抢占先机。在资本的推力下，甚至一个产品原型就可以被推向市场，形成焦点效应。而互联网普遍面向C端的特点导致迭代式开发、边用边改成为可能。

2.2.4 瀑布模型

众所周知，敏捷是针对传统研发过程采用的瀑布模型提出的，那么我们来看一看瀑布模型的起源。

在软件工程领域，Winston Royce对于因采用“先写了再说”的方法而造成的大型软件项目失败深感震惊，于是独立地引介了一种由七个步骤组成的瀑布模型，以使流程更规范。事实上，Winston Royce是将他的瀑布模型当作一个假想的批判对象提出来的，但是很多人引用并追随这个假想的批判对象，他提出的更复杂、精妙的模型反而被大家忽略了。

1.什么是瀑布模型

1970年，Winston Royce提出了著名的“瀑布模型”，直到20世纪80年代早期，它一直是唯一被广泛采用的软件开发模型。

2.瀑布模型的核心思想

瀑布模型的核心思想是按照工序将问题简化，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为制订计划、需求分析、软件设计、程序编写、软件测试和运行维护六种基本活动，并且规定它们相互衔接的固定次序，如同瀑布流水，逐级下落。

2.2.5 传统企业不可能全盘敏捷化

传统企业的IT形态有以下两类。

1.传统IT（Predictable IT）

特点：

❑ 需求明确。

❑ 相比追求速度，更倾向稳定性、安全性和标准化。

❑ 瀑布开发模式。

❑ 记录型系统（SOR，System Of Record）。

2.数字化IT（Nonlinear IT）

特点：

❑ 追求和探索新业务设计、流程和模式。

❑ 相比追求可靠性，更倾向速度。

❑ 敏捷开发模式。

❑ 参与型系统（SOE，System Of Engagement）。

因此传统企业往往存在双模IT。什么是双模IT？这是Gartner在2014年提出的概念。

一方面，传统企业为了保障业务持续增长，安全生产运行依然是IT部门的首要工作。另一方面，云计算、移动化、社交化的技术浪潮极大地丰富了应用场景，依托于互联网架构的新应用不断出现，应用开发迭代周期从数月缩短为数天，秒杀、红包等突发性高并发应用需要更加弹性的技术架构。

如何同时运维、管理这两种不同的架构，成为传统企业IT部门的一个巨大挑战。

2.2.6 从版本上线过程管理看敏捷与瀑布

从版本上线过程来看，瀑布开发模式的上线周期更长，因为它强调一次上线成功，为了最终上线成功，前面分为若干个阶段严格把控质量，如需求阶段、设计阶段、开发阶段、测试阶段。

而敏捷开发模式的上线周期更短，因为它强调多次、高频率上线，每个上线周期内都或多或少地包含需求分析、设计、开发、测试的内容，如图2-4所示。

传统企业（如银行）的应用系统，基本都采用传统开发模式。随着银行从产品销售向客户服务转型，并鉴于传统开发模式对推出产品及服务的局限和相关内部管理问题，可以预见，在不久的将来，某些应用系统（特别是服务型系统）将引入敏捷开发模式，而且这种趋势将逐渐加快。因为随着金融行业管制和市场参与主体的开放，尤其是借助电子平台及新技术的非金融企业（如互联网金融）的崛起，行业的格局将发生重大变化，竞争将加剧，各种金融创新将成为市场竞争的有效手段。这一变化反映在科技部门，将是产生大量、迅速变化的新需求、新产品，甚至会出现对部分产品线的反复重构。

2.2.7 敏捷的前提是“不敏捷”

在传统企业中，我们既会碰到RUP（Rational Unified Process，统一软件开发过程）强调的“每个管理过程和工艺过程都需要详尽的书面表达”，也会碰到敏捷强调的“当面沟通”，我们需要一套新的管理方法帮助客户找到平衡。

我们尝试从银行的情况进行分析：敏捷开发模式适用于银行应用的某些系统，由于银行是特殊的风险经营类机构，应用系统有其特殊性，因此需要因地制宜，即并非所有的银行应用系统都适合敏捷开发模式。一般而言，敏捷开发模式的优势需要建立在以下条件之上。

❑ 需求持续变更。

❑ 版本交付迅速。

❑ 系统适当松耦合，适于拆分，以供一群小规模的团队相对独立地协同完成。

在银行内部的应用系统中，如果能够满足上述条件，则是一些打算进入高度竞争市场的新产品，或者是原有产品线中变更和改造比较活跃的成分，再或者就是正在使用传统开发模式但有必要被敏捷的项目。

双模IT模式造成了IT研发管理模式的分裂，导致某些号称采用敏捷方法的研发品质降低、管理结构混乱。因此我们需要在面向敏捷的架构下，采用“冻土层”模型，保持核心架构稳定，如图2-5所示。

除此之外，也需要统一采用“工艺化+工作室”的方法，如图2-6所示，帮助客户找到平衡点，实现企业组织级敏捷。