软件工程中的速度
近期读到一篇前亚马逊工程师 Tom Killalea（作者曾在亚马逊工作 16 年，现主要为技术公司提供咨询，也是 Akamai、MongoDB 等技术公司的董事成员）的文章，颇有启发。
在所有现代公司中，软件工程都是必要的，但软件工程师很贵，而且供应有限。所以自然的，针对现有软件工程的投资中，提高其速度会引发很多利益相关的兴趣。在大部数情况下，软件工程是一项团队活动，通常由协作者网络通过许多小步骤来取得突破进展。尽管高速执行是有点难以捉摸，但好的想法还是很多的，公司可系统的投资来提升它。
速度是一种化合物。它也是习惯的养成，高效团队形成了更高标准的习惯。但速度受阻时，高贡献者会创造性的寻找方法来重建高速，但如果是外力延长了这种停滞，很快他们就会想加入另一个具有高速潜力的团队。高速是让人上瘾的，并且抬高了标准。
方向
速度是方向和速率的函数，你不能只关注其中的一个。两者之中，方向更容易被忽视。然而，项目失败最常见的原因是团队在建设错误的东西。正如托马斯·莫顿（Thomas Merton）更雄辩的宣称：“人可能一辈子都在攀登他们唯一找到的成功阶梯，但是等他们到达顶端时，却发现梯子靠在了错误的墙上。”
亚马逊的 “逆向工作” 产品开发流程旨在弥补确定方向的困难（如：预测产品/市场匹配度）。“逆向工作” 流程的明确交付件——新闻稿和FAQ（常见问题）——这已被广泛讨论过了，这个过程内在的目标是清晰得定义出客户是谁，然后从他们的需求逆向推导出可能满足这些需求的产品定义。通常，它是关于注意倾听客户的声音，或者，正如 Intuit 联合创始人斯科特·库克（Scott Cook）所说：“成功不是交付一组功能，成功是学习如何解决客户的问题。” 团队常概叹他们的客户只使用他们交付的 20% 的功能。理想情况下，我们期望倾听客户的需要，并通过交付他们最感兴趣的 20% 来满足他们的需求。
即使是最好的倾听者和最有愿景的创新者，预测客户的需要也是很困难的。因为在选择方向上会有一些猜测，保持灵活和路线修正变得极其关键。灵活意味着保持开放，最大化实验比率，快速学习，减少对任何计划的固执承诺，快速演化产品，决策时能明晰单向（不可逆）和双向（可逆）“选择之门” 的区别。关于路线修正，亚马逊 CEO 杰夫·贝佐斯（Jeff Bezos）说：“假如你擅于路线修正，犯错就比你想的要便宜，然而缓慢则无疑代价高昂。”
速度
2003 年，是亚马逊历史上这样一个时刻，我们为软件工程的速度感到特别的沮丧。我们求助于马特·朗德（Matt Round），他是一名最有趣的工程主管，说话就像嘎吱作响的车轮，但他的团队似乎相比其他任何团队总是能完成更多工作。是的，他还是那么不耐烦，大声抱怨，且清楚的知道搞定任何一件工作有多么困难。他写了一篇六页的文章，其中第一段很勾人眼球：“对我们很多人来说，工作在亚马逊感觉更像在制造零部件，而非驾驶 F-16 战机。” 没人对此声明做出防御性的反应，这很好的反映了当时亚马逊的文化。相反，对此的回应是一种认可：“它把我们钉在这里，这就是我们！一块构造板！”
马特的文章提出了许多建议，如今这些建议已经被行业广泛采用，这包括：团队及其运营的服务的自治最大化；在高度解耦的组件之间采用 REST 风格接口；平台标准化；清除路障或看门人（高摩擦官僚机构标配）；持续部署独立的组件。他还号召扩展延伸 “完成（complete）” 的定义，这包括，达成后续的低维护成本，和一个持续的绩效指标——基于软件工程师花费在建造而非其他任务上的时间百分比。建造者（builders）只想要建造（build），马特及时的建议影响了之后亚马逊技术品牌的打造：“建造者进行建造的最佳场所。”
已有过许多尝试来直接观察软件团队的速度，但测量这样的速度，众所周知很困难。作为补偿，公司可以使用专注度调查来询问与速度有关的问题。这种调查已被广泛使用，但往往仅限于高级别的员工敬业度和公司目标契合度。一些公司利用调查的机会来确定，对于建造者期望的高速建造，公司是否是理想的场所。并向软件工程师询问，他们实际花多少时间来设计和编写软件，其工具的适当性，过程的有效性，以及技术债务的影响。
软件工程师可是愤世嫉俗的。在进行诸如此类的问题调查之前，公司应该承诺对调查结果采取行动，因为这些行动会对当前的速度和未来对此类调查的反馈产生积极影响。
自治
自 1975 年弗雷德·布鲁克斯（Fred Brooks）的《人月神话》出版以来，软件工程项目规模化的挑战——通过增加工程师带来更大吞吐量——就一直被人们大量讨论。布鲁克斯研究了这个问题，随着更多工程师的加入，软件工程项目的吞吐量并没有增加，并将其与收割小麦和采摘棉花等活动进行了对比。他发现协调和沟通的成本是罪魁祸首。
可伸缩性可以通过组织自治的团队来提高，自治团队拥有高度内部凝聚力，围绕着明确且清晰定义的职责领域（上下文 contex）。团队及其负责的服务，相互之间以公开的 API（应用编程接口）交互。在理想的世界里，没有跨团队的沟通，因为 APIs 就是所需的全部，代表了远程服务背后团队所负责的业务逻辑交互的一切。
服务的实现细节通常是不共享的，也没有后门能直接访问远程服务背后依赖的数据存储。协调变得不再必要，尽管服务可能需要以一种不向后兼容的方式变化，但新旧版本的 APIs 通常也会同时并行一段时期，所以客户能在旧版 API 过期前迁移。朗德更进一步，甚至主张衡量团队之间的相互串扰，以便客观的了解他们的独立性水平。
服务负责人可以按照团队自己的节奏来演进和发布变化，在时间上独立且和发生在周围的其他变化解耦。由 IETF 主席贾里·阿科科（Jari Arkko）定义的 “自主创新”——他人在我们创建的通信结构之上创造新事物的能力——将会蓬勃发展。然而，界定职责区域之间缝隙的工作颇有挑战，而且这些接缝不可避免的会随着时间而演化，完美的自治永远是虚幻的。
一组软件服务在不断演进，与活的有机体没什么不同。新接口被发布，整个服务可能拆分或合并，独立的服务也许经历重大的重新设计或过期淘汰。理想情况下，公司内部团队具有高度的自治权，引用《奈飞文化手册》的话来说：“高度对齐，松散耦合”。
通过康威定律的延伸，这些团队运营的服务应该是独立的。一个崇高的目标是，任何团队都能实现他们积压列表中 80% 的需求，而不需要他们依赖的服务做出任何改变。而剩余的 20%，可以向远程服务所有者发出一个简单请求并可能会有响应，表明请求增加或修改的接口是有意义的，而且还能匹配上请求者计划开始使用它的时间。
而在剩余的其他情况下，服务所有者可能同意这样合理的修改请求，并且符合服务本身的发展路线图（roadmap），但与请求者预期的优先级相比，其在路线图上的优先级位置较低。在这样的情况下，请求者可以提供 “客场团队” 来实现请求的变更。一个客场团队可能由来自请求者团队的一对开发人员组成，这些开发人员临时进入服务拥有者团队。客场团队设计、实现、测试并发布请求的变更，所有这些变更都需要一步步获得服务拥有者（他们才是这些变更的长期维护者）的同意。当变更实现完成，客场团队就回归他们的主场。这种团队协作方法有一种副作用，可以对最佳实践进行 “交叉授粉”，在这样一个团队之间极少交流的世界，这种做法会特别富有成效。
敏捷
在软件开发的敏捷方法中，是有可能建立路线修正和速度优化两者的健康平衡的。
即使是在一个需求快速演化的世界里，只要是基于最新版本的冲刺（sprint）计划，团队已排序好的需求列表的持续变化也是 ok 的。团队从需求列表中挑出一组任务，并做出一个明确的承诺，由此获得一段受保护且不被干扰的时间窗口，在这个时间窗口中用最大可能的速度冲刺。随着这段幸福且无干扰的时光结束后，冲刺的结果展示了团队达成的承诺。
下一轮的冲刺计划会使用经过路线修正的积压需求列表，在下轮冲刺周期继续之前，团队会进行回顾。这是一次内部反思会议，团队会评估上次冲刺达到的速度，并确定在后续冲刺中提升速度的方法。一次诚实的内省反思，基于信任和自我意识，可以用来搞清楚在下一次冲刺前如何 “利其器”。
专注
要达到高速，专注是必须的。
当朗德梦想着有一天他的团队能够独立在不到一分钟内将他们的软件部署到亚马逊的网站，而无需获得批准甚或通知其他任何人，此时安迪·贾西（Andy Jassy）正在为一项新业务规划愿景，这项业务将服务于开发者的需要。随着时间推移，贾西的 AWS（Amazon Web Services）愿景将围绕帮助开发者避免 “无差别举重（undifferentiated heavy lifting）” 的需求。
团队想要专注于解决客户的问题，并以高速实现业务逻辑，这才是他们独一无二的职责。采购、供应和运维数据中心，服务器和网络之类的繁重工作是他们不愿承受的负担。他们还希望尽可能避免被任何不受他们控制的（处于他们团队之外的）人或流程所阻碍。正如贝佐斯所说：“即使最善意的看门人也会减缓创新”。云计算是自主创新的赋能者，并且推动了软件架构去 “看门人” 化。在这样的架构中，门控功能，如访问控制，权限断言，是通过编程的方式强制实行的。
文化
一个高效团队会注意培养一种文化，以鼓励团队人才蓬勃发展并交付成果。这是一种自我强化：拥有高速文化的团队往往会高比例的吸引顶尖人才。重要的是，假设人都是有才华的，使命一致的，并且想要高效工作。对速度产生积极影响的文化包括如下一些方面：多样性，包容性，谦逊，信任，学习的开放性、愿意 “紧迫且专注” 的行动，所有权、自主权和集体承诺交付成果的意愿。
使能
为了达到高速，很有必要投资建设系统来帮助工程师高效工作，并且最大化他们花费在其独一无二职责领域的时间比例。这显而易见的起点是他们用来构建、集成和部署代码的工具与流程，以及在代码发布后用于运维以确保其满足可用性、可靠性、性能和安全要求的工具和流程。
没那么明显的是对可观察性的需求。当服务化架构带来了自治和速度的好处时，跨服务边界的失败错误会更难诊断。如果测量、收集、传播、监控、告警和问题跟踪成为一种公共服务将会很有帮助。可观察性能力应该能够进行分布式跟踪，便于精确的诊断关键信号和指标，以及对问题搜索空间的逐步收敛，最终定位到根本原因。
实验
在提高创新速度的竞赛中，许多公司积极的寻找降低实验的成本，以便可以做更多的实验。更高的实验率能够促进更频繁的路线修正。这值得注意，更高的实验率可被视作更大量的抛弃想法、死亡代码和错误。
成功的团队拥抱失败，他们知道他们的模型可能不完整，并且他们做出的大多数错误选择能容易地逆转。皮克斯的联合创始人埃德·卡特穆尔（Ed Catmull）说：“如果处置适当，失败可能成为增长的机会。但是，大多数人解释这一主张的方式是，错误是必要的魔鬼。错误并不是必要的魔鬼，它们完全不是魔鬼。它们是创新时的一种必然结果，因此，应该被认为是有价值的，没有错误，我们就不会拥有原创性。”
总结
软件工程在所有行业公司中扮演着越来越关键的角色，但太多软件计划都以脱靶和超出预算而告终。有效交付包括一个完美的愿景，关于什么是需要的，再加上通往愿景的坚定不移与艰难跋涉，一路上对所有的干扰或新信息视而不见，这终究是一个神话。一条更可靠的路径是，优化速度，对实验和学习保持开放，敏捷，并遵行定期的路线修正。
参考
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.acm.org/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.
作者：Tom Killalea
翻译：mindwind
日期：2019-07-29
原文：[Velocity in Software Engineering](见文末 阅读原文)
近期文章
此刻瞬间
根据康威定律，组织的软件工程架构最终总是演变为匹配组织的通信（沟通）结构。而通信结构就是组织架构，变化更快更容易，而软件架构的变化就没那么快而容易，感觉会总是在跟随着变化的路上。
写点文字，画点画儿，分享成长的
瞬息之间