全方位解析业务敏捷

业务敏捷的根基是敏捷的理念和工作方式。因此，要理解业务敏捷，必须先理解敏捷的理念。

敏捷起源于软件开发领域。早在 1970 年，温斯顿 · 罗伊斯( WinstonRoyce)提出了著名的“瀑布模型”a ，如图 1所示，该模型成为软件开发领域的主要流程。

瀑布模型的核心思想是将软件生命周期划分为系统需求、软件需求、分析、软件设计、编码、测试和运行 7 个阶段，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布一样逐级下落。

图1-瀑布模型

进入 20 世纪 90 年代后，随着互联网技术的普及，市场变化更加迅速， 科技企业越来越认识到采用瀑布模型交付产品的方式无法满足快速响应市场 的需求。

2001 年， 17 位轻量级软件工程方法的代表人物齐聚美国犹他州的雪鸟滑雪胜地，经过 了两天的研讨会议之后，他们共同签署了对软件行业产生巨大影响的“敏捷 宣言”(如图 2所示)。敏捷宣言陈述了他们认同的软件开发方法的价值观。 同时，他们用“敏捷”这个词来总领这些理念。

图2-敏捷宣言

为了进一步阐述以上价值观，敏捷宣言给出了遵循的 12 条敏捷原则(如 图3 所示)。

图3-敏捷原则

敏捷的本质

PDCA 循环的含义是将质量管理分为 4 个阶段。

( 1 ) P (Plan)：计划。包括确定方针和目标，以及制定活动规划。

( 2 ) D ( Do )：执行。根据已知的信息，设计具体的方法、方案和布局； 再根据设计进行具体运作，实现计划中的内容。

( 4 ) A (Act)：处理。对检查的结果进行处理，对成功的经验加以肯定， 并予以标准化；对于失败的教训也进行反思，引起重视。对于没有解决的问 题，提交给下一个 PDCA 循环去解决。

以上 4 个阶段不是运行一次就结束，而是周而复始地进行，一个循环结 束后，解决一些问题，未解决的问题进入下一个循环，从而一个接一个循环 呈现阶梯式上升，如图 4 所示。戴明环具有普遍适用性，适用于任何项目 管理、企业管理、质量管理、团队管理，甚至是个人的提高、改进等活动。

图4-戴明环

敏捷将长周期的、串行的瀑布开发过程拆分为多个短小的时间箱，每个短小的时间箱都采用了 PDCA 循环的步骤，持续发布产品，同时通过持续地进行 PDCA 循环，在为客户持续交付价值后及时获得客户的反馈，通过市场和客户的反馈快速验证产品的价值，并将客户的反馈纳入产品的后续迭代中进行持续优化，如图5 所示。

图5-敏捷工作法

业务敏捷的定义：

理解了B 公司的业务敏捷如何开展之后，让我们看看业务敏捷如何定义， 应该遵循哪些原则，以及业务敏捷的框架。

鉴于敏捷不限于 IT 行业，适合于任何提供产品或服务的企业，越来越 多的企业像 B 公司一样，开始在 IT 以外的组织和产品范围应用敏捷的理念， 并切实提升了组织对市场和客户的响应。鉴于此发展背景，本书对业务敏捷 定义如下：业务敏捷是描述一个组织应用敏捷的思维，通过创新的解决方案 快速响应市场变化和新出现的机遇，从而在数智时代参与竞争并蓬勃发展的能力。在这个广义的定义下，业务敏捷适用于任何类型的行业、任何类型的 企业、企业里任何类型的组织，包括但不限于 IT 、产品、研发、销售、人 事、财务、生产等职能组织。

本书采用的业务敏捷的概念属于广义概念。敏捷在 IT 行业的发展历史悠 久，因此到目前为止，敏捷在 IT 行业应用仍旧是最为广泛和深入的。 图 5 是一个典型的软件产品全价值链示意图，团队在深入洞察用户和研 究市场后诞生产品的创意，之后经过了产品定义→需求分析→设计→开发→测 试→部署→上线的环节。在产品上线后，用户使用产品，提出反馈意见。用户 的反馈可能是关于产品新功能的创意，也可能是对已经上线的功能的优化意 见。团队将用户的反馈意见转换为需求后，继续进入产品的价值链流动。

在大部分IT 组织里，敏捷转型只是覆盖了整个价值链的研发环节(图 5中从开发到上线之间的环节)，而作为需求的提出方和用户反馈的收集方的业务团队没有覆盖。因此，很多 IT 行业从业者对业务敏捷的理解是突破 IT范围的敏捷应用，将业务部门与 IT 部门协同敏捷。