快速高质量交付的 5 大原则

任何一个组织都希望能够又快又好的交付产品，但真的能做到吗？原文: 5 Principles for Quality at Speed

原则塑造了我们。

当我们面临压力时，生存机制会让我们依赖基于原则的潜在结果。

这种行为本身没什么问题，但当有问题的原则让我们做出错误决定时，尤其在时间很紧迫的时候，问题就出现了。

在当今快节奏环境中，软件的交付越快越好，因此快速决策的压力无处不在。

从平衡速度和质量的角度出发，必须限制正在进行的工作，而不是试图做太多事情，必须掌控两者的矛盾。

本文讨论了软件工程的五个原则，以克服"质量 vs 速度"的困境，从而更快构建更好的软件。

1. 少即是多(Less is More)

活跃而忙碌的文化总是围绕这种观念: 努力工作总比少工作好，会有更好的结果。

不得不承认，我(或者说曾经)非常坚定的相信这一点。

但如果你观察成功的个人和组织，他们会反复说:

• 把注意力集中在影响最小的事情上

• 坚决选择不做某些事情

• 对于做或者不做某些事情依赖某些强烈的原则

"少即是多"是个强大的原则，迫使我们专注于能提供大部分价值的东西，避免做其他低价值的事情。

实际案例从初创公司到服务数百万用户的公司都可以看到，通常他们都专注于解决某个特定问题，或者在更大的公司里会看到他们在每个阶段都集中精力于一件事情。例如，苹果先是推出 iPod，然后是 iPhone、iPad，然后专注于配件来打造品牌生活方式。

在软件工程中可以通过以下方式来应用这些原则:

• 通过帕累托分析来确定哪部分 20%的努力产生了 80%的结果

• 通过技术组合和技术雷达以简化技术堆栈

• 减少正在进行的工作(WIP, work-in-progress)从而获得更好的预期回报

• 分析功能使用情况并删除使用率低于最小阈值的功能

• 编写更好、更少、需要更少注释的代码。

在更广泛层面上，少即是多就是更偏向于用最小实践来开发业务，而不是更时尚、更受追捧的实践——正如质量工程成熟度模型MAMOS所捍卫的那样。

2. 旧即是新(The Old is New)

目前的创新速度，尤其是在技术领域，让我们觉得好像每天都有颠覆性解决方案出现。

但大多数创新都是在经过验证的模型上逐步建立的。

"创新就是把现有的两种东西以一种新的方式组合在一起。" — Tom Freston

以软件行业的流行词汇为例:

• 云是一种部署基础设施，可以实现自助服务和可扩展性

• 软件定义网络建立在历史悠久的 7 层网络之上

• 许多质量实践都是基于戴明或丰田的实践

• 这个列表还在继续(包括 ChatGPT)

重点并不是说没有变化(渐进式和破坏性创新正在发生，改变着行业现状)。

关键是要了解营销手段背后的原因:

• 利用了哪些成熟技术?

• 要达到承诺的效果需要哪些条件?

• 该项创新能够持续或被取代的可能性有多大?

我们的价值在于正确评估潜在机会，做好功课，确保掌握了所提出解决方案的基础。

接下来的问题是，要足够强大的运用之前的"少即是多"原则，只保留最有价值的选项。

3. 慢即是快(Slow is Fast)

让·德·拉封丹(Jean De La Fontaine)的一则寓言讲述了龟兔赛跑的故事，令人惊讶的是，乌龟赢了。

同样不可思议的事情也发生在软件行业。

从长远来看，跑得太快通常意味着会失去动力，原因如下:

• 缺乏关键利益相关者的参与和支持

• 缺少预算、资源和团队来交付早期成果

• 只是让系统回到初始状态的表面变化

• 实践组织无法支持的复杂实践

• 未能使组织持续变革。

速度是在适当地方做出正确选择的结果，尽量减少对组织成熟实践造成太大影响。

"生活中没有什么事情像你想的那么重要。" ― Daniel Kahneman,思考快与慢

在越来越追求短期的文化中，拥有长期视角和持续努力的延迟反馈将变得更加稀有，而涉及到软件构建时，也会更加与众不同。

4. 质量无法测试(You Can’t Test Quality)

捷径是危险的，测试和质量之间的捷径已经让组织中出现了很多欺骗行为。

这又回到了最基本的问题:

• 测试是一种验证行为

• 质量是关于满足定义的属性

考虑到公司需要以最少的测试获得最高的质量:

1. 由于复杂性、资源可用性或可行性等限制，质量属性不可能全部得到验证

2. 更多的测试意味着更多的验证，但并不代表更高的质量，尤其是在软件生命周期的早期阶段。

"你无法检查产品的质量。" — Harold F. Dodge

我们的责任是培育生态系统，在这个生态系统中，质量属性被定义并且作为软件生产的一部分，必须成为一等公民。接下来的问题是，如何利用某种极简方法，尽可能快的验证哪里的质量属性得到了最充分的满足。

这需要转变思维模式。

5. 做得更好，做得更快(Build Better, Build Faster)

质量工程代表了许多软件团队所面临的"质量 vs 速度"这一历史矛盾的思维方式的改变。

这一悖论似乎没有正确答案:

• 质量本身会减缓组织保持竞争力的速度

• 速度本身会积累技术债务，而在这过程中会造成失败

范式的转变是"质量决定速度(Quality enables Speed)"。

通过在整个软件系统上部署最小实践集，用高质量支持更快的迭代周期，以最小复杂性和更易于更改的软件让事情流动起来。

以此开始，通过渐进式的、系统性的和可伸缩的实践按照成熟度模型来实现，应用"做得更好，做得更快"的原则来交付高质量软件。

准备好进行质量工程了吗?

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！