ACM

ACM通信

首页 / 杂志存档 / 2019年9月(第62卷第9期) / 软件工程的速度 /全文

实践

软件工程的速度

汤姆·基拉利亚著
美国ACM通信，2019年9月，第62卷第9期，44-47页
10.1145 / 3345626
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 数码版分享: 通过电子邮件发送在reddit上分享在StumbleUpon上分享在黑客新闻上分享在推特上分享在Facebook上分享

软件工程在所有现代公司中都是必要的，但软件工程师是昂贵的，而且供应非常有限。因此，从现有的软件工程投资中提高速度自然会引起很大的兴趣。在大多数情况下，软件工程是一项团队活动，突破通常是通过协作网络通过许多小步骤实现的。好的想法往往是丰富的，尽管在高速的执行是难以捉摸的。好消息是，速度是可控的;公司可以有系统地投资来增加它。

速度的化合物。它也会形成习惯;高速度的团队习惯于更高的标准。当速度停滞时，高贡献者会创造性地寻找重新建立高速的方法，但如果外部力量延长了停滞，他们很快就会想要加入另一个具有高速潜力的团队。高速会让人上瘾，也会提高门槛。

方向．速度是方向和速度的函数;你不能只关注其中一个。在这两者中，方向更容易被忽视。然而，项目失败最常见的原因是团队构建了错误的东西。正如托马斯·默顿(Thomas Merton)说得更有说服力:“人们可能花了一生的时间在成功的阶梯上攀爬，但当他们到达顶峰时，却发现梯子靠在了错误的墙上。”

亚马逊的逆向工作产品开发过程试图弥补确定方向的困难(也就是说，预测产品/市场适合度)。“向后工作”流程新闻稿和常见问题解答的明确工件已经被广泛讨论，⁸在这个过程中，固有的是清楚地识别客户是谁，然后从他们的需求往回追溯，找到能够切实满足这些需求的产品定义。通常情况下，这是关于关注客户的声音，或者，正如Intuit联合创始人斯科特·库克所说，“成功不是交付一个功能;成功就是学会如何解决客户的问题。”团队经常抱怨他们的客户只使用了他们发货的20%。理想情况下，我们愿意倾听客户的意见，满足他们的需求，同时只发货他们最感兴趣的20%。

即使是最好的听众和最有远见的创新者，也很难预测客户的需求。因为在选择方向时需要一些猜测，所以灵活性和路线修正就变得至关重要。灵活性可能表现为开放、最大限度地提高实验速度、快速学习、减少对任何给定计划的承诺、快速开发产品以及在决策中区分单向(不可逆)和双向(可逆)门。亚马逊首席执行官杰夫·贝索斯说:“如果你擅长纠正方向，犯错的代价可能比你想象的要低，而慢则肯定会付出高昂的代价。”

速度。2003年，在亚马逊的历史上有一段时间，我们对软件工程的速度感到特别沮丧，我们求助于马特·勒德(Matt Round)，他是一位非常有趣的工程主管，他的团队似乎比其他任何团队都要完成更多的工作，但他仍然非常没有耐心，大声抱怨任何事情都很难完成。他写了一篇长达六页的文章，第一段有一个很好的吸引人的地方:“对我们很多人来说，亚马逊感觉更像是一块构造板块，而不是F-16战斗机。”没有人对这一声明进行辩护，这反映了亚马逊当时的文化。相反，他的回答是一种认同:“他把我们钉住了。这是我们!一个构造板块!”

Matt的论文提出了许多建议，这些建议到目前为止已经被广泛采用，包括通过在高度解耦组件之间采用rest风格的接口来最大化团队的自主权以及由这些团队操作的服务的自主权，平台标准化，移除路障或看门人(高摩擦的官僚主义)，以及持续部署孤立的组件。他还呼吁扩展“完成”的定义，包括低持续维护成本的成就，以及基于软件工程师花在构建而不是做其他任务上的时间百分比的持久性能指标。建筑商想要建造，马特及时的建议影响了亚马逊技术品牌的塑造，成为“建筑商可以建造的最佳场所”。

有许多尝试直接观察软件团队的速度，但是众所周知，测量这样的速度非常困难。为了弥补这一点，公司可以使用敬业度调查来询问与开发速度相关的问题。这样的调查已经很普遍了，但它们往往仅限于衡量员工敬业度和与公司目标的一致性的高层指标。一些公司利用他们的调查作为机会，以确定他们是否适合建造者高速建造，向软件工程师询问他们实际花了多少时间设计和编写软件，他们的工具的充分性，他们的过程的有效性，以及技术债务的影响。

软件工程师可能会愤世嫉俗。在开始带有这些问题的调查之前，公司应该承诺根据结果采取行动，这样这些行动就会对当前的速度和未来对此类调查的反应产生积极影响。

自主权。的发布以来，软件工程项目的扩展挑战(增加工程师会带来更大的吞吐量)已经被广泛讨论神话中的人月^3.弗雷德·布鲁克斯1975年的作品。Brooks研究了软件工程项目中由于工程师增加而缺乏提高吞吐量的现象，并将其与收割小麦或采摘棉花等活动进行了对比。他把责任归咎于协调和沟通的成本。

可伸缩性可以通过组织成自治的团队来提高，这些团队围绕特定且边界良好的上下文或职责领域具有高度的内部内聚性。团队和他们负责的服务彼此公开应用程序编程接口(api);在理想的情况下，不会发生跨团队的通信，因为api是与业务逻辑交互所需的全部，而业务逻辑是远程服务背后的团队的责任。⁵

服务的实现细节通常不共享，而且不存在对远程服务所依赖的数据存储的后门访问。协调变得没有必要;即使服务需要以向后不兼容的方式更改，api的新版本和旧版本通常会在重叠的时间段内可用，因此客户端可以在旧版本被弃用之前迁移。Round甚至主张测量团队之间的相声，以便客观地解读他们的独立性水平。

服务所有者可以按照他们的团队自己的节奏发展和发布更改，这些更改独立于他们周围可能发生的其他更改，并在时间上与它们分离。未经许可的创新，“他人在我们所创造的通信结构之上创造新事物的能力”，IETF主席贾里·阿科这样定义，¹可以蓬勃发展。然而，识别职责区域之间的裂缝的工作是具有挑战性的，而且不可避免地，这些裂缝将随着时间的推移而演变。完美的自主权永远是虚幻的。

即使在需求快速发展的世界中，只要使用最新的版本进行sprint计划，团队有序的待办事项安排不断变化也是可以的。

一组软件服务不断发展，就像一个有生命的有机体。发布了新的接口，整个服务可能被拆分或合并，个别服务可能经过重大的重新设计或弃用。理想情况下，公司内部的团队拥有高度的自主权，并且“高度一致，松散耦合”，引用Netflix文化文档中的话说。⁶

通过康威定律的延伸，这些团队运营的服务应该是独立的。一个崇高的目标是，任何给定的团队都可以实现他们backlog中80%的项目，而不需要对他们所依赖的服务进行任何更改。在剩下的20%中，对远程服务所有者的一个简单请求可能会导致一个响应，该响应指示所请求的附加或更改的接口是有意义的，并且在请求者计划开始使用它时它将是可用的。

在其余的情况下，服务所有者可能同意所请求的更改是有意义的，并且符合服务的路线图，但是它在路线图上的位置与请求者放在它上面的优先级相比是低的。在这种情况下，请求者可能会提供一个“外出团队”来实现所请求的更改。一个离开的团队可能由来自请求者团队的一对开发人员组成，他们临时加入了拥有服务的团队。away团队设计、测试、实现和发布所请求的更改，所有这些都要得到服务所有者的阶段性批准，而服务所有者将是更改的长期所有者;当他们完成任务后，就会回到他们的“主队”。这种客场团队方法的一个副作用是最佳实践的交叉传播，在一个团队之间很少交流的世界里，这可能特别富有成效。

敏捷性。在产品开发的敏捷方法中，可以在路线修正和优化速度之间建立一个健康的平衡。

即使在需求快速发展的世界中，只要使用最新的版本进行sprint计划，团队有序的待办事项安排不断变化也是可以的。团队从待办事项中明确承诺完成一组任务，作为回报，团队获得了一个不间断的受保护时间窗口冲刺以尽可能快的速度工作。在这个愉快的不间断和无搅动的阶段结束后，sprint演示展示了团队所达到的承诺。

在使用经过过程修正的产品待办事项安排进行下一个sprint计划会议之前，团队会举行一次回顾会议。这是一个内省环节，团队在其中评估所达到的速度，并确定在后续sprint中提高速度的方法。一个诚实的回顾，建立在信任和自我意识的基础上，可以用来弄清楚在进入下一个冲刺阶段之前如何“削尖锯子”。

的焦点。专注是实现高速的必要条件。

当Round梦想着有一天，他的团队可以在不到一分钟的时间内，独立地将他们的软件部署到亚马逊网站上，而不需要获得任何人的批准，甚至不需要通知任何人时，Andy Jassy正在为一项新业务制定一份愿景文件，以满足开发人员的需求。随着时间的推移，Jassy的AWS (Amazon Web Services)愿景将围绕帮助开发人员避免“无差别的繁重工作”的需求而结合起来。

团队希望专注于解决客户的问题，并以高速度实现业务逻辑，这是他们特有的责任。采购、供应和操作数据中心、服务器和网络的繁重工作是他们不愿承担的负担。他们还希望尽可能避免被他们无法控制的人员或流程(也就是说，位于他们自己团队之外)所阻碍。正如贝佐斯所说:“即使是善意的守门人也会减缓创新。”²云计算是无许可创新的推动者，也是向明显缺乏看门人的软件架构发展的推动者，在这种软件架构中，看门人控制(例如访问控制和遵从性断言)是通过编程实现的。

文化。一个高速度的团队注重培养一种文化，鼓励团队的人才蓬勃发展并取得成果。这是一种自我强化:拥有高速度文化的团队往往会不成比例地吸引顶尖人才。重要的是要从这样一个假设开始:人们都是有才华的，与任务一致的，并且希望以高速度工作。对速度有积极影响的一些文化方面包括多样性和包容性、谦逊、信任、开放学习、愿意“紧急和专注”地行动，⁷所有权、自主权和集体致力于交付结果的意愿。

实现。为了实现高速度，有必要投资系统，使工程师能够快速工作，并最大限度地将他们的时间花在他们独特的责任领域。最明显的起点是他们用来构建、集成和部署代码的工具和过程，以及在发布代码后用于操作代码的工具和过程，以确保代码满足可用性、可靠性、性能和安全性方面的需求。

不太明显的是，需要启用可观察性;虽然基于服务的体系结构可能带来自治和速度方面的好处，但跨服务边界的故障可能要困难得多。如果度量收集和传播、监视、警报和问题跟踪在服务之间是通用的，那么这是很有帮助的。可观察性能力应能够实现分布式跟踪，促进关键信号和指标的精确检测，并逐步细化搜索空间，最终查明根本原因。

实验。在提高创新速度的竞争中，许多公司积极寻求降低进行实验的成本，这样他们就可以做更多的实验。较高的实验率可以促进更频繁的航向修正。值得注意的是，高频率的实验可以被视为大量被丢弃的想法、死代码和失败。

成功的团队接受失败，他们知道他们的模型可能是不完整的，他们所做的大多数不正确的选择是很容易逆转的。皮克斯的联合创始人Ed Catmull说:“失败，如果处理得当，可能是成长的机会。但大多数人对这一论断的解释是，错误是一种不可避免的罪恶。错误并不是一种必要的罪恶。他们一点也不邪恶。它们是尝试新事物的必然结果，因此应该被视为有价值的;没有他们，我们就没有创意。”⁴

结论。软件工程在所有部门的公司中占据着越来越重要的角色，但是太多的软件计划最终都没有达到目标，而且超出了预算。一个持续存在的神话是，有效的交付包括一个完美的需要的愿景，并朝着这个愿景缓慢而坚定的前进，对所有干扰或新信息视而不见。更可靠的路径优化了速度，开放实验和学习，灵活，并受定期更正的影响。