背景
软件工程里一个重要的指标就是“可用的软件”,敏捷宣言里也同样告诉我们“工作的软件高于详尽的文档”,那“可用的软件”、“工作的软件”意味着什么呢?在我的理解里,可以经历用户 “千锤百炼”的软件就是一个“可用的软件”。曾经听到过这样的说法:“一个有Bug的软件怎么能叫软件呢?”虽然这话在我们业内人士听起来有些可笑,但是这就是使用软件用户最真实的需求。所以如何在提高代码质量,最大程度地减少软件中的Bug同时,平衡软件迭代速度与交付效率是我今天想跟大家讨论的问题。
我有幸在两种完全不同风格的项目上进行过交付,让我们且称之为项目A和项目B。
项目A是一个客户为主导的巨大项目组,管理为明确纵向层级管理,横向开发团队来自于不同的供应商,并且采用瀑布式开发,由另一个事业部进行测试反馈,部门墙极其严重。
项目B则是一个由业务主导,每个敏捷团队有对应相关的业务领域,客户则是和供应商共同组成一个个敏捷团队,共同达成业务目标。
好了,完成了简单的背景介绍,我就要来说说下面的故事了。
故事
总览
首先,假设我们所需要达到的目标是由一个个大大小小功能(颜色模组)组成一个完整的软件,为了达到我们的交付目标,我们需要将每个功能进行开发,测试,将功能模块进行累加,最终获得一个完整而达标的软件。
同时两个项目都使用了大致相同的开发流程,为了保证质量,项目中都有基础的代码审计,CI/CD,应用测试,用户测试,等基本质量保证,软件开发的基础流程如下图。
在这种基础流程都相近的情况下,每个环节在不同架构下执行的的方式却有巨大的差异。
在讨论项目A的流程前,让我们先看看我们熟知的敏捷开发是怎么保证质量的:
项目B的情况
项目b的每一个小敏捷团队将业务需求从路径图(Roadmap)拆解下来,落到各大的业务功能的