为什么企业要做大规模敏捷？

背景

软件工程里一个重要的指标就是“可用的软件”，敏捷宣言里也同样告诉我们“工作的软件高于详尽的文档”，那“可用的软件”、“工作的软件”意味着什么呢？在我的理解里，可以经历用户 “千锤百炼”的软件就是一个“可用的软件”。曾经听到过这样的说法：“一个有Bug的软件怎么能叫软件呢？”虽然这话在我们业内人士听起来有些可笑，但是这就是使用软件用户最真实的需求。所以如何在提高代码质量，最大程度地减少软件中的Bug同时，平衡软件迭代速度与交付效率是我今天想跟大家讨论的问题。

我有幸在两种完全不同风格的项目上进行过交付，让我们且称之为项目A和项目B。

项目A是一个客户为主导的巨大项目组，管理为明确纵向层级管理，横向开发团队来自于不同的供应商，并且采用瀑布式开发，由另一个事业部进行测试反馈，部门墙极其严重。

项目B则是一个由业务主导，每个敏捷团队有对应相关的业务领域，客户则是和供应商共同组成一个个敏捷团队，共同达成业务目标。

好了，完成了简单的背景介绍，我就要来说说下面的故事了。

故事

总览

首先，假设我们所需要达到的目标是由一个个大大小小功能（颜色模组）组成一个完整的软件，为了达到我们的交付目标，我们需要将每个功能进行开发，测试，将功能模块进行累加，最终获得一个完整而达标的软件。

同时两个项目都使用了大致相同的开发流程，为了保证质量，项目中都有基础的代码审计，CI/CD，应用测试，用户测试，等基本质量保证，软件开发的基础流程如下图。

在这种基础流程都相近的情况下，每个环节在不同架构下执行的的方式却有巨大的差异。

在讨论项目A的流程前，让我们先看看我们熟知的敏捷开发是怎么保证质量的：

项目B的情况

项目b的每一个小敏捷团队将业务需求从路径图（Roadmap）拆解下来，落到各大的业务功能的