任何一个组织都希望能够又快又好的交付产品，但真的能做到吗？原文: 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)
捷径是危险的，测试和质量之间的捷径已经让组织中出现了很多欺骗行为。
这又回到了最基本的问题:
- 测试是一种验证行为
- 质量是关于满足定义的属性
考虑到公司需要以最少的测试获得最高的质量:
- 由于复杂性、资源可用性或可行性等限制，质量属性不可能全部得到验证
- 更多的测试意味着更多的验证，但并不代表更高的质量，尤其是在软件生命周期的早期阶段。
"你无法检查产品的质量。" — Harold F. Dodge
我们的责任是培育生态系统，在这个生态系统中，质量属性被定义并且作为软件生产的一部分，必须成为一等公民。接下来的问题是，如何利用某种极简方法，尽可能快的验证哪里的质量属性得到了最充分的满足。
这需要转变思维模式。
5. 做得更好，做得更快(Build Better, Build Faster)
质量工程代表了许多软件团队所面临的"质量 vs 速度"这一历史矛盾的思维方式的改变。
这一悖论似乎没有正确答案:
- 质量本身会减缓组织保持竞争力的速度
- 速度本身会积累技术债务，而在这过程中会造成失败
范式的转变是"质量决定速度(Quality enables Speed)"。
通过在整个软件系统上部署最小实践集，用高质量支持更快的迭代周期，以最小复杂性和更易于更改的软件让事情流动起来。
以此开始，通过渐进式的、系统性的和可伸缩的实践按照成熟度模型来实现，应用"做得更好，做得更快"的原则来交付高质量软件。
准备好进行质量工程了吗?
你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！
