PDF软件工程中的速度
从构造板块到F-16
汤姆·基拉利亚
软件工程在所有现代公司中都是必要的，但软件工程师成本高昂且供应非常有限。因此，人们自然对现有软件工程投资的速度提升非常感兴趣。在大多数情况下，软件工程是一项团队活动，突破通常是通过许多协作者的网络进行的许多小步骤实现的。好的想法往往很丰富，但高速执行却难以捉摸。好消息是速度是可控的；公司可以系统地投资以提高速度。
速度是累积的。它也容易形成习惯；高速团队会习惯更高的标准。当速度停滞时，高贡献者会创造性地寻求重新建立高速的方法，但如果外部力量延长停滞期，他们很快就会想加入另一个具有高速潜力的团队。高速是令人上瘾且能提高标准的。
方向
速度是方向和速度的函数；你不能只关注其中一个。在这两者中，方向更容易被忽视。然而，项目失败最常见的原因是团队构建了错误的东西。正如托马斯·默顿更雄辩地指出：“人们可能会花费一生攀登成功的阶梯，但一旦他们到达顶峰，却发现梯子靠在错误的墙上。”
亚马逊的“从后向前推导”产品开发流程旨在弥补确定方向（即预测产品/市场匹配度）的难度。“从后向前推导”流程的明确产物——新闻稿和常见问题解答——已被广泛讨论，8并且该流程固有的特点是明确识别谁是客户，然后从他们的需求倒推到一个能够切实满足这些需求的产品定义。通常，这关乎倾听客户的声音，或者，正如 Intuit 联合创始人斯科特·库克所说，“成功不是交付一个功能；成功是学习如何解决客户的问题。” 团队经常抱怨他们的客户只使用了他们交付的 20% 的功能。理想情况下，我们希望在仅交付他们最感兴趣的 20% 的功能的同时，倾听客户的意见并满足他们的需求。
即使对于最好的倾听者和最有远见的创新者来说，也很难预测客户需要什么。由于选择方向涉及一些猜测，因此灵活性和纠正方向变得至关重要。灵活性可能表现为开放性、最大化实验速率、快速学习、减少对任何给定计划的承诺、快速演进产品，以及区分决策中的单向（不可逆）和双向（可逆）门。至于纠正方向，亚马逊首席执行官杰夫·贝佐斯说：“如果你擅长纠正方向，那么犯错的代价可能比你想象的要小，而缓慢肯定会付出高昂的代价。”
速度
2003 年，在亚马逊历史上，我们对软件工程的速度感到特别沮丧的时候，我们求助于工程领导者马特·朗德，他是一个最有趣的“吱吱作响的车轮”，因为他的团队似乎比任何其他团队完成的工作都多，但他仍然非常不耐烦，并且大声而清晰地抱怨完成任何事情有多么困难。他写了一份六页纸的文件，第一段有一个很棒的引子：“对我们许多人来说，亚马逊感觉更像是一个构造板块，而不是一架 F-16。” 没有人对这句话做出防御性回应，这很好地反映了当时亚马逊的文化。相反，回应是认同：“他一语中的。那就是我们！一个构造板块！”
马特的文件提出了许多建议，这些建议现在已被行业广泛采用，包括最大限度地提高团队和这些团队运营的服务的自主性，方法是在高度解耦的组件之间采用 REST 风格的接口、平台标准化、消除障碍或守门人（高摩擦官僚主义）以及持续部署隔离组件。他还呼吁扩展“完成”的定义，使其包括实现低持续维护成本，并呼吁建立一个持久的绩效指标，该指标基于软件工程师花费在构建而不是执行其他任务上的时间百分比。构建者想要构建，马特的及时建议影响了亚马逊技术品牌塑造为“构建者可以构建的最佳场所”。
已经有很多尝试直接观察软件团队的速度，但衡量这种速度是出了名的困难。为了弥补这一点，公司可以使用敬业度调查来询问与速度相关的问题。此类调查已变得普遍，但通常仅限于对员工敬业度和与公司目标的一致性的高层衡量。一些公司利用他们的调查作为机会，以确定他们是否是构建者以高速构建的绝佳场所，询问软件工程师他们实际花费多少时间来设计和编写软件、他们工具的充分性、他们流程的有效性以及技术债务的影响。
软件工程师可能很愤世嫉俗。在开始进行此类问题的调查之前，公司应承诺根据结果采取行动，以便这些行动对当前速度和未来对此类调查的响应产生积极影响。
自主性
自 1975 年弗雷德·布鲁克斯出版《人月神话》3以来，如何扩展软件工程项目，使工程师的增加能够带来更高的吞吐量，一直备受讨论。布鲁克斯考察了在软件工程项目中增加更多工程师后吞吐量没有增加的情况，并将其与收割小麦或采摘棉花等活动进行了对比。他认为责任在于协调和沟通的成本。
通过组织成自主团队，这些团队围绕特定且界限明确的上下文或责任领域具有高度的内部凝聚力，可以提高可扩展性。团队以及他们负责的服务相互公开 API（应用程序编程接口）；在理想的世界中，不会发生跨团队沟通，因为 API 是与远程服务背后团队负责的业务逻辑进行交互所需的全部。5
服务的实现细节通常不共享，并且无法后门访问远程服务所依赖的数据存储。协调变得不必要；即使服务需要以向后不兼容的方式进行更改，新旧版本的 API 通常会在重叠的时间段内提供，以便客户端可以在旧版本被弃用之前进行迁移。朗德甚至主张衡量团队之间的串扰，以便客观地了解他们的独立程度。
服务所有者可以按照自己团队的节奏演进和发布更改，独立于并且在时间上与其他可能正在发生的更改解耦。正如 IETF 主席贾里·阿尔科1所定义的，无需许可的创新，“其他人在我们创建的通信结构之上创建新事物的能力”，可以蓬勃发展。然而，识别责任领域之间的接缝是一项具有挑战性的工作，而且不可避免地，这些接缝会随着时间的推移而演变。完美的自主性将永远是虚幻的。
一组软件服务不断演进，就像一个活的有机体。新的接口被发布，整个服务可能会分裂或合并，并且单个服务可能会经历重大的重新设计或弃用。理想情况下，公司内部的团队具有高度的自主性，并且“高度一致，松散耦合”，引用 Netflix 文化文档。6
通过 Conway 定律的延伸，这些团队运营的服务应该是独立的。一个崇高的目标是，任何给定的团队都可以在不需要他们所依赖的服务进行任何更改的情况下，实现他们积压工作中 80% 的项目。在剩余的 20% 中，向远程服务的所有者发出一个简单的请求可能会得到一个响应，表明请求的附加或更改的接口是有意义的，并且在请求者计划开始使用它时，它将可用。
在其余情况下，服务所有者可能会同意请求的更改是有意义的并且符合服务的路线图，但其在该路线图中的位置相对于请求者对其的优先级而言较低。在这种情况下，请求者可能会提供一个“外派团队”来实施请求的更改。外派团队可能由来自请求者团队的一对开发人员组成，他们暂时加入拥有该服务的团队。外派团队设计、测试、实施和发布请求的更改，所有这些都经过服务所有者的阶段性批准，他们将是更改的长期所有者；当他们完成时，他们返回他们的“主队”。这种外派团队方法的一个副作用是最佳实践的交叉传播，这在一个团队之间几乎没有沟通的世界中尤其富有成效。
敏捷性
在产品开发的敏捷方法中，可以在纠正方向和优化速度之间建立健康的平衡。
即使在需求快速变化的世界中，团队井然有序的积压工作不断变化也是可以的，只要最新版本用于 sprint 计划即可。团队对积压工作中的一组任务做出明确的承诺，并以此换取不受干扰的受保护时间窗口，即sprint，在此期间尽可能快地工作。在完成这个幸福的、不受干扰且无变动的时期后，sprint 演示展示了团队完成的承诺。
在周期使用经过方向纠正的产品积压工作继续进行下一次 sprint 计划会议之前，团队会举行回顾会议。这是一个内省会议，团队在其中评估其达到的速度，并确定在后续 sprint 中提高速度的方法。一个基于信任和自我意识的诚实回顾会议可以用来弄清楚如何在继续下一个 sprint 之前“磨砺锯子”。
专注
专注对于实现高速是必要的。
当朗德梦想着他的团队可能能够在不到一分钟的时间内独立地将其软件部署到亚马逊网站，而无需获得任何人的批准甚至通知任何人时，安迪·贾西正在为一个新的业务撰写愿景文件，该业务将满足开发人员的需求。随着时间的推移，贾西的 AWS（亚马逊网络服务）愿景将围绕帮助开发人员避免“无差别的繁重工作”的需求而凝聚。
团队希望专注于解决客户的问题，并以高速实施独特地属于他们的责任的业务逻辑。采购、配置和运营数据中心、服务器和网络的繁重工作是他们宁愿不承担的负担。他们还希望尽可能避免被他们无法控制的（即位于他们自己团队之外的）任何人或流程所阻碍。正如贝佐斯所说，“即使是善意的守门人也会减慢创新速度。”2云计算是无需许可的创新以及朝着软件架构发展的推动力，这种架构显着缺乏守门人，并且在其中以编程方式执行诸如访问控制和合规性断言之类的守门控制。
文化
高速团队会注意培养一种文化，这种文化鼓励团队的人才蓬勃发展并交付成果。这是自我强化的：具有能够实现高速的团队文化往往会不成比例地吸引顶尖人才。重要的是首先假设人们是有才华的，与使命保持一致，并且希望高速工作。对速度产生积极影响的文化的一些方面包括多样性和包容性、谦逊、信任、对学习的开放性、愿意“以紧迫感和专注力”7行动、所有权、自主性以及愿意集体承诺交付成果。
赋能
为了实现高速，有必要投资于使工程师能够快速工作的系统，并最大程度地提高他们花费在独特责任领域的时间百分比。显而易见的起点是他们用来构建、集成和部署代码的工具和流程，以及那些用于在代码发布后操作代码以确保其满足可用性、可靠性、性能和安全性的要求的工具和流程。
不太明显的是启用可观察性的需求；虽然基于服务的架构可能带来自主性和速度的好处，但跨服务边界的故障可能更难以排除故障。如果指标收集和传播、监控、警报和问题跟踪在服务之间是通用的，则会很有帮助。可观察性功能应启用分布式跟踪，从而有助于精确检测关键信号和指标，以及逐步改进搜索空间，从而精确定位根本原因。
实验
在竞相提高创新速度的过程中，许多公司都在积极寻求降低运行实验的成本，以便他们可以进行更多实验。更高的实验速率可以促进更频繁的方向纠正。值得注意的是，高实验速率可以被视为大量废弃的想法、死代码和失败。
成功的团队拥抱失败，他们知道他们的模型可能是不完整的，并且他们所做的大部分不正确的选择都是容易逆转的。皮克斯联合创始人埃德·卡特穆尔说，“如果以正确的方式对待失败，它可能是一个成长的机会。但大多数人对这种断言的理解是，错误是必要的罪恶。错误不是必要的罪恶。它们根本不是罪恶。它们是做新事物的必然结果，因此，应该被视为有价值的；没有它们，我们就不会有独创性。”4
结论
软件工程在各个行业的公司中都扮演着越来越重要的角色，但太多的软件计划最终都偏离目标且超出预算。一个持久的神话是，有效交付需要对所需内容有一个完美的愿景，并结合朝着该愿景缓慢而坚定地前进，对所有干扰或新信息视而不见。更可靠的路径是针对速度进行优化，对实验和学习持开放态度，敏捷，并定期进行方向纠正。
参考文献
1. Arkko, J. 2013. Permissionless innovation. IETF; https://www.ietf.org/blog/2013/05/permissionless-innovation/.
2. Bezos, J. 2012. Annual letter to Amazon shareholders.
3. Brooks Jr., F. 1975, 1995. The Mythical Man-Month. Addison-Wesley.
4. Catmull, Ed. 2014. Creativity Inc. Random House.
5. Killalea, T. 2016. The hidden dividends of microservices, acmqueue 14(3); https://queue.org.cn/detail.cfm?id=2956643.
6. Netflix Culture. Netflix Jobs; https://jobs.netflix.com/culture.
7. A quick guide to Stripe's culture. Stripe; https://stripe.com/us/jobs/candidate-info?a=1#culture.
8. Vogels, W. 2006. Working backwards. All Things Distributed (Nov. 1); https://www.allthingsdistributed.com/2006/11/working_backwards.html.
相关文章
与沃纳·沃格尔斯的对话
从亚马逊技术平台学习
吉姆·格雷
https://queue.org.cn/detail.cfm?id=1142065
与技术领导者的对话：埃里克·梅杰
优秀的工程师能够最大限度地发挥他们的脑力。
凯特·松平
https://queue.org.cn/detail.cfm?id=3092954
认识一下 Virts
虚拟化技术并不新鲜，但在过去 30 年里已经成熟了很多。
汤姆·基拉利亚
https://queue.org.cn/detail.cfm?id=1348589
汤姆·基拉利亚曾在亚马逊工作了 16 年，现在为技术驱动型公司提供咨询，并在 Akamai、Capital One、Carbon Black 和 MongoDB 的董事会任职。
版权 © 2019 由所有者/作者持有。出版权已授权给 。
最初发表于 Queue 第 17 卷，第 3 期—
在 数字图书馆中评论本文
更多相关文章
凯瑟琳·海耶斯，大卫·马龙 - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全要求，存在许多针对加密哈希的标准，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布非常有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。
妮可·福斯格伦，埃里尼·卡利亚姆瓦库，阿比·野田，米凯拉·格雷勒，布莱恩·霍克，玛格丽特-安妮·斯托里 - DevEx 在行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。技术领导者凭直觉接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
若昂·瓦拉豪，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。
伊瓦尔·雅各布森，阿利斯泰尔·科克本 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中不断开发新的工具、技术和技巧来为商业和社会服务，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚的反复无常的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入，并在后来普及，是这些成熟的解决方案之一。
© 保留所有权利。