你如何在不牺牲质量的前提下提升交付速度？

Question

Accepted Answer

在任何长于一个 sprint 的时间跨度上，速度和质量**并不对立** —— 让你变快的那些东西（小批量、自动化、快速反馈）正是让你保持安全的同样东西。真正的敌人不是“质量”，而是**大批量、手工苦活和漫长的反馈环**。攻击它们。

## 速度真正来自哪里

- **更小的批量。** 更小的 PR 和更小的发布，review 更快、测得更好、rollback 更干净。大多数慢来自排队，而非打字。
- **减少在制品。** 把事情做完胜过开新坑。高 WIP 制造上下文切换和卡住的 review；限制它，吞吐量就上升。
- **自动化门禁。** CI、测试、lint 和一键部署，去掉那些悄悄吃掉数小时、又招致人为错误的手工步骤。
- **缩短反馈环。** 基于主干的开发、feature flag 和快速流水线，让你在几分钟而非几周内发现缺陷。

## 我使用的一个框架

1. **先度量**，用 DORA 指标 —— 部署频率、前置时间、变更失败率、MTTR。它们显示你是既更快*又*更安全，还是只是更快。
2. **找到瓶颈**，通常是 review 队列、一个不稳定的手工 QA 步骤，或一个慢环境。优化那一个约束，而非所有东西。
3. **用自动化而非人工审批门禁来保护质量。** 测试和 flag 让你安全地快；签字委员会只是增加延迟。

## 取舍与陷阱

- 砍掉测试买来几天，却在 **incident 和返工**上付出数月 —— 假节省。
- 没有 **observability** 就求快，意味着你在盲飞；把速度与监控和便捷 rollback 配对。
- 别让“快速行动”成为在**不可逆决策**（schema、公开 API）上跳过设计的借口。可逆的事快行；单向门要小心。
- 警惕局部优化 —— 如果瓶颈是两天的 review 等待，一个更快的 IDE 没用。

## 为什么这很重要

大多数团队相信他们必须用质量换速度，于是放慢以求心安，结果两者都没得到。一位能证明**工程纪律才是让团队变快之物**的 Tech Lead，能解锁可持续的 velocity —— 那种会复利增长、而不是崩塌成一堆 incident 和 tech debt 的速度。