项目流程如何标准化？

前些天有个读者小周私信说在公司推流程遇到了一些阻力，研发团队对自己推行的流程很不满意，但他又认为这些流程都是必须的，于是双方僵持不下，工作没法继续开展。小周碰到的问题我想一定不是个例，作者曾经也遇见过类似的情况，今天就来聊聊流程这个话题。

我们都有这么一种感觉，测试很喜欢流程，研发又很讨厌流程。什么原因？双方的利益诉求点不同。在某种固有的习惯上，我们喜欢用线上问题数去考核测试，用发布需求数去考核研发，站在团队整体的角度上看，目标其实是不一致的。

在这样的背景下，测试只好把流程当成自己的救命稻草，作为一条执法大棒去挥舞，追求过程的绝对正确性。对于测试来说，流程越重、越严，安全感也就越足；对于研发来说，流程越繁、越长，麻烦也就越多。

这是一种责任上的失衡，人为制造角色的对立，造成无谓的团队内耗。这也是很多团队流程难以推进的首要原因。产品也好、研发也好、测试也好，需求的进度和质量是团队一起努力的成果，不是单个角色的责任。

对于测试而言，我们也不应该把流程当做是套给产品、研发的枷锁，而要把流程作为团队的一道保障，给大家一种安全感。因此我们要理解的第一点是：团队协作的意义在于一致性，流程一定是多方共同认定的结果，是为了达成共同的目标。

有些测试小伙伴在进入一个新环境之后，喜欢直接照搬之前团队的流程，或参考他人分享的经验，套用到现有的团队中，不去考虑这些流程的意义和目的，这是一些流程无法被接受的另一个重要原因。

举个例子，有个常见的流程是研发自测，由测试提供自测用例，研发按照清单自测过后才能提测。但这个问题并不是所有团队都存在，如果研发的自测习惯本身就已经很好了，我们设定这个流程只会增加多余的负担。

流程的应用，必然有其背景。比如多数团队有个环节是集成回归。设定这个环节的理由是什么？因为代码合并之后，有可能会引入新的缺陷。所以我们要理解的第二点是：流程的存在一定是为了解决特定的问题，它不能凭空产生。

好的流程，是能够以最“恰好”的方式，去解决团队的问题的。如果我们总是在犯同样的错误，说明流程存在缺失；如果我们去掉其中一个环节而不影响结果，说明流程存在冗余。流程没有万能的，只有最合适的。

我们在制定流程之前，需要先想清楚几个问题：团队的构成是什么？大家的协作习惯是什么？当前存在哪些问题？主要的薄弱点在哪里？针对这些问题，再去考虑我们的流程应该是什么样。

常见的流程制定的维度有两种：一种是基于角色来确定，比如产品、研发、测试、运维；另一种是基于环境来确定，比如开发环境、预发环境、灰度环境、正式环境。每个单元（某维度下的单个项）有各自的准入标准和准出标准（最后随文附上实例）。

当然，流程既然被制定出来，就需要认真去执行（因此还是那句话，先取得认知的一致很要紧）。正因为每个人都有犯错的可能，所以我们才需要靠流程去保证大家能够把事情做对，而不是在每一次过程中碰运气。

1986 年 1 月，美国挑战者号航天飞天发生重大事故，飞机起飞 73 秒后解体，7 名宇航员全部遇难。事故原因是用于密封右侧固体助推器的 O 形环失效，然而早在之前工程师就预警过该问题，但是管理人员却对此置若罔闻，没有向上汇报。

从以往的经验来看，90% 的错误其实都是可以避免的。历史上多数很严重的事故，往往源于一些微不足道的原因。不是我们没有能力去发现这些问题，而是我们对流程缺乏足够的敬畏。心存侥幸必遭不幸，事出偶然实则必然。

那么流程确定了之后，就万事大吉了吗？肯定不是，流程是会变化的，需要持续精进。我们所处的环境、依赖的因素、团队的要求，无时无刻不在发生变化。因而我们需要定期去审视我们的流程在当下的适合性。

有这么一个“不拉马的士兵”的故事，英国一位军官上任伊始，看到一个情况：每门火炮总有一名士兵自始至终站在火炮的炮管下面纹丝不动。后经了解这是炮兵操练条例规定的。该军官回去后查阅军事文献，发现是马车牵引时代制定的规则。

在那个时代，火炮由马车运载到前线，站在炮管下的士兵的任务是负责拉住马的缰绳，以便在发射后调整由于后坐力产生的距离偏差。而现在火炮的自动化程度已经很高，不再需要这样一个角色，可操练条例却没有及时修订，结果就出现了“不拉马的士兵”。

由此可见，流程既是静态的，又是动态的。说它是静态的，因为流程确立之后，就需要共同遵守，不能随意打破；说它是动态的，因为流程不能一成不变，需要审时度势，调整适应。

最后还是要提醒一句，流程终归只是团队意志的文字呈现，更重要的还是自己的判断和决策。我们千万不能让流程代替思考，而要让流程服务于我们的目的，否则便失去了制定流程的最初意义了。

---

流程的一个实例，再次提醒不要硬套，根据自己的情况灵活运用：

开发环境准入

• CodeReview 通过

• 开发环境部署确认

• 代码扫描通过

• 研发自测通过

• 自动化测试通过

开发环境准出

• 产品验收通过

• 设计验收通过

• 测试验收通过

• 中高优先级缺陷全部解决

预发环境准入

• 配置提交管理系统

• 预发环境部署确认

• 自动化测试通过

预发环境准出

• 测试验收通过

• 发布清单准备就绪

• 数据脚本准备就绪

• 非体验类缺陷全部解决

灰度环境准入

• 发布清单已执行

• 数据脚本已执行

• 灰度环境部署确认

• 自动化测试通过

灰度环境准出

• 测试验收通过

• 各级监控无异常

• 灰度比率超过 X%，时长已满 N 小时

• 非体验类缺陷全部解决

正式环境准入

• 发布清单已执行

• 正式环境部署确认

• 自动化测试通过

正式环境准出

• 测试验收通过

• 各级监控无异常

• 客情监测无异常

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!