中国ESG新故事：主动、常态、变革
06-18
编者按：本文探讨了软件发布“速率”和“加速”与无服务器计算之间的关系。
众所周知，Serverless可以简化数字业务运维、降低成本，但这不是本文的重点。
重点分析如何在“敏捷”协作中实现更快的软件“发布速度”和“发布加速”。
上一篇文章：“软件发布率”和无服务器计算 在上周 JeffConf 的小组讨论中，一位小组成员（我忘了是谁）表示，“公司对通过云节省托管成本不感兴趣，因为它的成本已经相对较低。
企业有兴趣提高发布软件功能的速度。
”这种见解对我影响很大。
我对无服务器价值的看法一直是它带来的较低的“总拥有成本/TCO”。
减少维护，更少的错误修复和问题似乎适用于无服务器，但我没有太多考虑功能速度（FV）（软件发布速度），所以我一直在思考什么是软件发布率？它是向产品添加新软件功能的速度，这是衡量技术团队是否提供附加功能的一种方法，而且很容易理解……但衡量起来并不容易，有时很难定义这一点。
仅仅因为软件功能没有固定的大小/时间范围，因此需要不同的开发持续时间来开发不同的功能，您可以将每个功能分解为称为“工作单元”的已知交付单元（许多人这样做）。
），但在开始开发功能之前，这只是猜测（对于经验丰富的团队，这是经过专业评估的猜测）。
这也不是特别容易做到，因为存在偏见。
如果一个团队想成为一个高发布速度团队，那么他们可以在开始时轻松添加额外的（高估的）“工作单元”并快速交付它们，瞧：我们是一个高发布速度团队。
工作单元可以是常见的工作日或故事点，许多敏捷方法使用这些作为确定团队是否足够快地交付工作的基础。
对于团队了解自己是领先还是落后来说，这是一个广泛且相对有用的概念。
对于技术团队之外的人员来说，这也是一个有用的概念，可以衡量团队是否执行（或未执行！）其工作任务。
我在使用发布率作为技术团队绩效衡量标准时遇到的最大问题是，它只是一个高度连续的软件开发过程的“快照工具”。
在管理良好的团队中的任何给定时间点，您可以通过查看发布率来判断团队是领先还是落后（通常落后......但这是评估软件工作的另一个主题）。
如果你考虑一件事，这绝对没问题：当你刚刚开发新功能时，发布率非常高。
问题是，除非您是一家相当大的企业，否则您绝对不仅仅是开发新功能。
在一个小型技术团队中，你可能有多个关注领域，包括维护基础设施、修复错误、“架构债务”、“技术债务”等。
而且你还会有 DevOps 同事围绕它工作，并使用 CI/CD 来解决这些问题。
管理开发和软件代码库等。
换句话说，技术团队的工作不仅仅是开发新功能。
随着时间的推移，团队会执行许多其他任务，这些任务可能会影响您的工作，从而影响您的发布率。
那么这与无服务器有什么关系呢？这真的很简单。
发布速度（Feature Velocity）需要在一段时间内完成，而不是作为“快照”。
换句话说，它需要在整体而不是孤立的背景下完成。
当您随着时间的推移采用发布率指标时，高层领导会提出一组不同的问题。
如果您构建了一个软件并发布了它，并且产生了很多错误，那么您就会减慢未来的发布速度。
如果你在特定技术堆栈之上构建软件，然后发现需要更换该技术堆栈，那么你将再次降低未来的发布率。
如果您以较慢的速度构建软件，您可能会发现您的发布率会增加。
当然，所有这些都是假设的，但是当您将无服务器解决方案添加到您的技术平台时会发生什么？因此，我经常谈论的主要内容之一是无服务器的总拥有成本。
事实是，如果您构建了正确的解决方案，那么在管理和维护整个解决方案所花费的时间方面，您最终应该会减少 DevOps（开发 + 运营）负担。
无服务器的优点之一是您可以更轻松地“就地”替换解决方案的元素。
将 Lambda 函数替换为其他函数通常对整体解决方案的影响很小。
这意味着技术债务和错误修复实际上可以提高发布速度。
更不用说，如果您倾向于使用更少的代码行（和更少的库），就像我所提倡的那样，您最终将需要维护更少的代码，这意味着您（在某种程度上）减少了出错的能力发生这种情况可以减少错误修复的数量和积累的技术债务。
除此之外，您还依赖云提供商提供基础设施，同时还可以最大程度地减少架构债务。
在计算资源自动缩放管理场景中，您不必考虑配置新的 RDBMS 服务器或添加数据库实例，而且它还限制了您可以使用哪些技术的选择（这通常是一件非常好的事情）。
发布率不一定是最重要的指标 当您使用无服务器开发软件时，我对这个问题的关注越多，我就越发现发布率在整个软件项目持续时间内显着增加。
我确实认为“发布速度”值得用作“我们现在所处位置”的快照，但我确实认为有很多指标，并且它们被过度使用，从项目管理来确定我们是否正在“快速移动项目”足够的”。
弄清楚技术团队的表现如何以及他们是否高效工作是一件很难衡量的事情。
通常，高级团队领导者会寻找简单的指标，为他们提供有关团队是否正常工作的线索。
我认为我们需要对此进行更长远的考虑，并且我认为无服务器在提高团队中长期效率方面可以发挥重要作用。
因此，如果有人说你的行动不够快，请考虑他们是否正在查看快照，或者他们是否正在更大的时间窗口内观察团队的项目工作环境和场景。
我的观点是，无服务器为您提供了提高软件功能发布速度的机会，但必须在合理的时间窗口内评估该速度。
下一篇：“软件发布加速”和无服务器计算 我刚刚写完上一篇文章，意识到：我还没有谈到“软件发布加速”，这有点疯狂，因为我的学位主要是物理，而且我学习讲速度随时间变化，称为“加速度”。
我还发现了一篇关于敏捷和衡量软件生产力的博客文章，用 .这让我感觉自己正在重新发现一些被遗忘的东西。
这篇 IBM 文章讨论了我在上一篇文章中讨论的一些内容，并用数字更详细地进行了分解。
我认为提及这篇旧博客文章会很有帮助，以便为本文的前一部分和本文（第二部分）提供更多背景信息。
但 IBM 的那篇文章遗漏了一些东西。
如果您只是衡量团队/个人的生产力，那么加速很好地解释了如何衡量团队中的每个人是否都在做好自己的工作。
软件开发“加速”是对个人或团队生产力的衡量。
那么加速度就不是效率的衡量标准。
加速和效率 当您开始一个全新项目时，一切都是有趣、美丽和令人愉快的。
每个人都可以构建自己的解决方案，没有人会受到重大问题的影响，也不会因新功能请求或软件错误而让用户感到沮丧。
您还没有什么限制或问题需要解决。
当您完成一个项目时，您会发现代码中的错误和问题，或者您从未考虑过的边缘情况（不可能定义所有边缘情况，这就是“系统弹性”很重要的原因），这是一个大问题。
在多软件迭代场景中通常会发生的情况是，您最终会从没有缺陷、没有技术债务、没有架构债务的情况下开始，并且一切似乎都运行良好。
然后，在后续的迭代中，“非原始需求和特性”元素不断被添加，并成为当前和未来版本迭代的一部分。
因此，我们在看“发布速率”和“发布加速”时，仍然存在一个问题，因为我们必须问以下问题：什么是“软件功能”？通常，当以“敏捷”方式管理软件工程任务时，软件发布速度使用冲刺（工作周期）中的“单元工作”和“故事数量”作为衡量标准。
但这不是“软件发布速度”而是“故事速度”。
这是衡量团队和个人生产力的重要指标。
如果你想要“发布速度”，你必须分解哪些故事是“软件功能”，哪些是“故事”。
因此，让我们看一组数字，看看我们是否最终会遇到这种情况（假设团队规模始终保持不变）：（围绕功能/缺陷/技术债务/架构债务完成的单元工作）迭代 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（函数即服务/无服务器架构）来实现解耦（当然这也取决于你如何构建软件，但我们就是这样做的），这意味着修复一个函数中的bug对系统的其余部分没有影响 有些相对无害。
基本上，我对无服务器环境中发生的情况的经验是：您最终会获得更稳定的软件功能“发布率”。
这将增加软件的“发布加速”。
团队制作的软件最终将包含更少的“缺陷加速”和“技术债务加速”。
我承认架构债务加速是一个不同的问题，但你更依赖于你的供应商，所以应该能够很好地缓解这个问题，但我们还没有最好的工具来解决这个问题。
鉴于上述所有情况，我建议无服务器云计算往往会显着提高“发布率”并提高整体“团队效率”（工作产出）。
效率胜于速度 最后，重申一下上一篇文章中提出的观点：因此，如果有人说您的软件团队进展不够快，只需询问他们是否正在查看“工作快照”，或者他们是否正在查看更广泛的软件工程项目管理背景。
对于高级管理层来说，让您的团队高效并能够随着时间的推移提供恒定或接近恒定的“发布率”比能够在迭代中提供大量故事更有价值。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-18
06-17
06-17
06-17
06-18
06-18
06-18
最新文章
Android旗舰之王的过去与未来
智能手表不被开发、AR眼镜被推迟，Meta的产品经历了一波三折
为什么Cybertruck是特斯拉史上最难造的车？
更新鸿蒙3后，文杰允许你在车里做PPT了
新起亚K3试驾体验：追求“性价比”，韩系汽车仍不想放弃
阿维塔15登场！汽车配备了增程动力，理想情况下会迎来新的对手吗？
马斯克宣布创建 ChatGPT 竞争对手！ OpenAI的CEO给他泼了冷水， GPT-5可能会发生巨大变化
骁龙无处不在，是平台也是生态