无服务器计算、发布速率和发布加速度

编者按：本文探索软件发布「速率」和「加速度」与无服务器计算的关系。众所周知，无服务器能简化数字化业务运维和降低成本，但这还不是本文重点，重点是解析如何在「敏捷」协作中实现更快的软件「发布速率」和「发布加速度」。

上篇：「软件发布速率」与无服务器计算

上周在 JeffConf 的一个小组讨论中，一位小组成员（我忘了是谁）说，「公司对通过云节省托管成本并不感兴趣，因为它的成本已经相对较低。企业感兴趣的是提高他们的软件功能发布速率」。

这一洞察对我冲击很大。我对无服务器价值的认知一直是随之而来的降低「总拥有成本 / TCO」，减少维护、减少错误修复和问题似乎与 Serverless 配合得很好，但我并没有过多考虑 Feature Velocity（FV）（软件发布速率）。

所以我一直在思考这个事。

什么是软件发布速率？

很简单，就是将软件新功能添加到产品中的速度。

这是一种衡量技术团队是否提供附加功能的方法，而且很容易理解……

…… 但如何衡量就没那么容易。

有时很难在技术团队的环境中定义它，仅仅是因为软件功能不是固定大小/时间范围，因此开发不同的功能需要不同的开发工期。

您可以把每个功能分解为一个称为「单元工作」的已知交付单元（许多人都这样做），但在开始开发一个功能之前，这只是猜测（对于有经验的团队来说，这是经过专业评估的猜测）。这也不是特别容易做到，因为那里有偏见。如果一个团队希望成为具有高发布速率团队，那么他们可以轻松地在开始时添加额外的（超额预估的）「单元工作」并快速交付，瞧：我们是高发布速率团队。

单元工作可以是常见的工作天数或故事点，许多敏捷方法使用这些作为确定团队是否足够快地交付工作的基础。

对于团队来说，了解他们是领先还是落后是一个广泛且相对有用的概念。对于技术团队以外的人来说，这也是一个有用的概念，可以用来衡量团队是否在执行（或不执行！）工作任务。

将发布速率作为衡量技术团队绩效的标准，我遇到的最大问题是：它只是针对连续性很强的软件开发过程的一个「快照工具」。在管理良好的团队中的任何给定时间点，您都可以通过查看发布速率来了解团队是领先还是落后（通常是落后的……但这是关于评估软件工作的另一个话题）。

如果您考虑一件事，这绝对没问题：

当您只是开发新功能时，发布速率非常高。

问题是，除非您是一家相当大的企业，否则您绝对不仅仅是在开发新功能。

在一个小型技术团队中，您可能有多个关注领域，包括维护基础设施、修复错误、「架构债」、「技术债」等。

而且您还将让 DevOps 同事们围绕它工作，并使用 CI/CD 管理开发和软件代码库等。

换句话说，技术团队的工作绝不仅仅是开发新功能。随着时间的推移，团队会执行许多其它任务，这些任务可能会影响您的工作，从而影响您的发布速率。

那么这与无服务器有什么关系呢？

这真的很简单。 发布速率（Feature Velocity）需要在一段时间内进行，而不是作为「快照」。换句话说，它需要在整体而不是孤立的背景下进行。

当您在一段时间内采用发布速率指标时，高层领导会提出一系列不同的问题。

如果您构建了一个软件并发布它，并产生了许多错误，那么您就降低了您未来的发布速率。

如果您在特定技术栈之上构建软件，然后发现需要替换技术栈，那么您将再次降低未来的发布速率。

如果您以较慢的速度构建软件，您可能会发现您的发布速率提高了。

当然，所有这些都是假设，但是当您将无服务器解决方案添加到技术平台中时，会发生什么变化？

因此，我经常谈论的主要内容之一是无服务器的总体拥有成本。事实是，如果您构建了正确的解决方案，就管理和维护整个解决方案所花费的时间而言，您最终应该会承担更小的 DevOps（开发+运维）负担。

无服务器的优点之一是您可以更轻松地「就地」替换解决方案的元素。将 Lambda 函数替换为另一个函数通常对整个解决方案的影响很小。这意味着技术债和缺陷修复实际上可以提高发布速率。

更不用说如果你倾向于使用更少的代码行（和更少的库），就像我所提倡的那样，你最终需要维护的代码也会更少，这意味着你（在一定程度上）降低了错误发生的能力，减少了您累积的错误修复和技术债的数量。

再加上这一切，你依赖于你的云提供商来提供基础设施，你也在最大限度地减少你的架构债。在计算资源自动伸缩管理场景下，您不必考虑配置新的 RDBMS 服务器或增加数据库实例，还会限制了您可以使用哪些技术的选择（这通常是一件非常好的事情）。

发布速率不一定代表全部指标

当您使用无服务器开发软件时，我对这个问题的关注越多，我就越发现发布速率在整个软件项目工期范围内有显著增加。

我确实认为「发布速率」值得作为「我们现在所处的位置」的快照，但我确实认为有很多指标，并且从项目管理中被过度使用，以确定我们是否正在「足够快」地推动项目。

弄清楚一个技术团队的表现如何，以及他们是否高效地工作，是一件很难衡量的事情。通常，高级团队领导会寻找一些简单的指标来为他们提供有关团队是否在工作的线索。我认为我们需要更长远地考虑这一点，我认为无服务器在提高团队中长期效率方面发挥着重要作用。

因此，如果有人说您的动作不够快，请考虑他们是否正在查看快照，或者他们是否正在一个更大的时间窗内观察团队的项目工作环境和场景。

我的看法是，无服务器为您提供机会增加软件功能发布速率，但必须放在合理时间窗去评估这个发布速率。

下篇：「软件发布加速度」与无服务器计算

刚写完上篇才意识到：我没有在「软件发布加速度」方面展开谈过，这有点疯狂，因为我的学位主要是物理学，而我正在谈论随时间变化的速度，即「加速度」。

我还发现了一篇写于 2008 年关于敏捷和衡量软件生产力的博文。这让我觉得我正在重新发现一些被遗忘的东西。这篇 IBM 帖子谈到了我上篇里谈到的一些事情，并用数字更详细解析过。我认为提及这篇旧博文有助于为本文的上篇和本文（下篇）提供更多背景信息。

但是那个 IBM 帖子还缺少一些东西。

如果您只是衡量团队/个人的生产力，那么「加速度」很好解释了如何衡量团队中的每个人是否都在做他们的工作。

软件开发「加速度」是衡量一个人或团队的生产力。

那么加速度就不是效率的衡量标准。

加速度和效率

当你开始一个新建项目时，一切都是有趣、美好和愉快的。每个人都可以构建自己的解决方案，没有人会受到重大问题的影响，或者用户因新功能需求或软件缺陷而鸡飞狗跳地让他们闹心。您（暂时）几乎没有要解决的限制条件或问题。

当您完成一个项目时，您会发现代码中的缺陷和问题，或者您从未考虑过的边缘案例（不可能定义所有边缘案例，这就是为什么「系统弹性」很重要），这是很大的问题。

在多软件迭代场景中通常发生的情况是，您最终会从没有缺陷、没有技术债、没有架构债开始，并且似乎得到的是完美的所有功能。

然后，在后续迭代中，「非原始需求和功能」元素继续增加并成为当前和未来版本迭代的一部分。

因此，我们在观察「发布速率」和「发布加速度」还存在一个问题，因为我们必须提出以下问题：

什么是「软件功能」？

通常，在按「敏捷」管理软件工程任务时，软件发布速率利用了一个 sprint（工作周期）中的「单元工作」和「故事数量」作为衡量标准。

但这并不是「软件发布速率」而是「故事速率」。

这是衡量团队和个人生产力的重要指标。

如果你想要「发布速率」，你必须分解哪些故事是「软件功能」，哪些是「故事」。

因此，我们通过观察一组数字看看是否最终会遇到这种情况（假设团队规模始终保持不变）：

（围绕功能/缺陷/技术债/架构债完成的单元工作）

迭代 1：15/0/0/0 = 15 个故事

迭代 2：12/3/1/0 = 16 个故事

迭代 3：9/5/2/1 = 17 个故事

迭代 2：7/9/2/2 = 20 个故事

现在我知道这完全是人为的，但它说明了指标是如何误导我们的。

在这种情况下，团队正在整个迭代中提高其「故事速率」：15、16、17、20。故事共有 68 个单元工作。从简单事物观察方式来看，这非常好。

这个团队正在交付大量的「工作」。

但是，如果您查看「发布速率」，您会通过迭代得到一个不同的故事：15、12、9、7。总共有 43 个软件功能单元工作（量）。这不是很好，它实际上正在减速。

（以此类推，如何分析「缺陷速率」、「技术债速率」和「架构债速率」，我们就当作练习留给各位读者吧。）

但是随着时间的推移，团队肯定会交付更多的单元工作。这是一个积极的结果，对吧？

但是……如果你是管理人员，往往会发生的是团队觉得他们工作非常努力，但是当你看到冷酷的数字时，团队正在放慢它的软件功能发布速率。

这是一个问题。

随着时间的推移，团队变得越来越低效，虽然付出更多努力，却取得更少成就。

现在，让我们看一个稍微不同的场景（假设相同的团队规模和迭代长度）：

迭代 1：12/0/0/0 = 12 个故事

迭代 2：12/1/1/0 = 14 个故事

迭代 3：12/2/1/0 = 15 个故事

迭代 2：13/2/1/1 = 17 个故事

故事速度：12、14、15、17（总共 58 个工作单元）

特征速度：12、12、12、13（共 49 个工作单位）

（同样，我将把它作为练习留给读者：如何分析「缺陷速率」、「技术债速率」和「架构债速率」）

从外部看，这种情况看起来团队做的「工作」比其他团队少。确实，正在完成的工作单元越来越少，但令人着迷的是「软件发布速率」正在加速（虽然加速缓慢）。

现在，这可能有很多原因（当然这是人为的），但其中一个原因可能是更好的软件编码需要更长的时间，产生更少的缺陷/技术债或更好的技术决策，使技术的基础层更加稳定。

关键是在这种情况下，如果你只看软件团队开发完成任务的「故事速率」和「故事加速度」，两个团队看起来都不错。但团队一看起来比团队二更好，因为他们似乎完成更多「工作量」。

但是，如果您观察「发布速率」和「发布加速度」，您最终会得到不同的结果。团队二看起来比团队一好很多。团队二更有效率。

这与无服务器有什么关系？

（我在上一篇文章中指出了这一点，但我认为它需要数字）

基本上，我的经验是：你仍然有软件缺陷和技术债等等，但随着时间的推移，你的团队有一个非常不同的「发布速率」，因为你实际上消除了一些围绕技术运维的成本，以及缺陷修复和技术债相对更容易找时间修复。这部分是通过采用 FaaS（函数即服务/无服务器架构）实现解耦的（当然也取决于您如何构建软件，但我们就是这样做的），这意味着修复一个函数中的错误对系统的其余部分相对无害。

基本上，我对无服务器环境中发生的事情的经验是：

你最终会得到一个更加稳定的软件功能「发布速率」。

这会提升软件「发布加速度」。

团队产出的软件最终也会包含更少的「缺陷加速度」和「技术债加速度」。

我承认，架构债加速度是一个不同的问题，但是您更依赖您的供应商，因此应该能够很好地缓解这种情况，但我们目前还没有最好的工具来解决这个问题。

鉴于以上所有情况，我建议无服务器云计算倾向于提供显着改进的「发布速率」和整体「团队效率」的改进（工作产出）。

效率胜于速度

最后，我们简单重申上篇文章中的观点：

那么，如果有人说你的软件团队动作不够快，只需考察他们是否正在观察「工作快照」，还是正在观察更广泛的软件工程项目管理背景。

让您的团队高效，并能够随着时间的推移交付恒定或接近恒定的「发布速率」对于高级管理人员来说比能够在迭代中交付大量故事更有价值。

而且，我甚至还没开始谈论「平台规模发展」话题……

（作者：Paul Johnston，封面摄影：Pixabay）