软件行业的表现

衡量原则以及如何优化业务

最近，我读了马丁·福勒（Martin Fowler）在他的博客”加速：精益软件和DevOps的科学”上推荐的这本书，该书由Nicole Forsgren博士，Jez Humble和Gene Kim撰写。 本书中的任何内容对我来说都不是真正的启示，但是它把我已经在想的东西都写成了文字。

通过四年的开创性研究，Nicole Forsgren博士，Jez Humble和Gene Kim着手使用严格的统计方法来找出驱动软件交付性能的因素以及如何对其进行衡量。 简而言之，这本书试图解释什么使软件公司有效地运作，以及如何衡量该业绩。 正如我们大多数业内人士都知道的那样，软件行业的性能一直是争论和矛盾的源头。 令人耳目一新的是，最终找到了一种评估绩效的方法，这种方法有意义且具有积极影响，并使用实际数据和度量来验证我们的假设或反驳某些先入为主的想法。

现在，Accelerate所说的是，软件开发可以更加系统化，而且相关人员不必（字面意义上）退缩只是为了获得所谓的”良好”性能。

软件正在统治世界

作为一家支持技术的公司，如果您的软件效率低下，那么您就死定了（或至少落后了）。 通常，在这种情况下，任何公司都无法继续照常营业。 毕竟，企业必须不断改进IT的各个方面，因为所有竞争对手都在这样做。 这是我从书中获得的第一点收获。 实际上，在研究进行期间接受调查的所有公司都改善了他们的IT计划。

但是话又说回来，高管人员和从业人员对IT成熟度和进步的估计之间常常是脱节的。 高管们往往高估了他们公司的技术成熟度，而实际上，在机房里，从业人员迫切需要改进。 因此，至关重要的是以一种精确且可衡量的方式在层次结构阶梯上传达情况的真实性。

另一个与行业背道而驰的事情是，它受到误解的困扰。 谬论之一就是”我们错过了截止日期，因为我们太慢了。” 事实是，实际上有很多变量可以影响该方程式。 其中最重要的事实是，人类在预测几乎所有事物方面都非常糟糕。 因此，假设我们”速度慢”可能首先意味着估算不准确。

另一种常见的误解是这样的想法：”使团队中的人员增加一倍，将确保工作进度快一倍。” 这是不正确的。 经验告诉我们，在已经落后的项目中增加更多开发人员甚至可能适得其反，并导致工作延误。

由于估算主要用于在开发应采取的路径上做出决策和选择，因此很长一段时间以来，我们一直在寻找一种有效的方法来衡量项目开发过程中哪些方面进展良好，哪些方面存在问题。 下面我们讨论这些测量。

衡量表现

度量常常被误解并且难以实现，因为在软件世界中，没有固定的任务或商品清单。 任务或开发计划的初始清单可能会由于经常无法预测的原因（例如市场变化等）而快速更改和发展。

一致地，到目前为止，衡量软件行业性能的尝试均以失败告终，因为人们专注于输出（例如，与估算值匹配的工作时间，代码行数等）而不是结果（即，工作软件） ，而是针对个人而不是团队（例如，每个团队成员的缺陷或不足）。

在专制（以权力为导向）和官僚（以规则为导向）的公司中，衡量常常会导致不利的结果，因此，人们需要谨慎对待它们-也许在开始计算业绩之前考虑一下公司文化的变化。

而且，开发人员很容易产生错误的性能印象。 在有恐惧的地方，您一定会找到错误的指标。 要解决该问题，请关注良好的指标。 错误的指标可能会被篡改，即使结果没有改善，也可能会产生良好的结果。 好的度量标准即使被篡改以表明有所改善，也仍然可以带来积极的结果。

为了更好地理解这一点，我们首先考虑书中所述的4个软件开发性能指标，建议将其推荐给业界使用：

1.部署频率（按周期部署数）

定义一个周期/周期（例如，按sprint进行），并计算您在此期间实现的部署数量-部署越多越好。 这有三个方面。

首先，按周期增加部署数量将迫使团队迅速交付持续运行的软件。 为此，在一定程度上，团队将必须使用自动化来确保高质量，并在开发生命周期的早期发现错误。

第二个方面是，通过创建小的增量改进，我们可以固定反馈回路。 最终用户和客户可以在平台上看到持续的改进并提供反馈，并可以保证产品在不断发展。

第三，通过减小发布的大小，我们还最小化了所做更改的影响。 将所有内容保持较小是在人类可理解和可管理的环境中停留的好方法。

对于用户而言，最糟糕的事情是，您正在使用的软件中的错误将在未来几个月内无法得到解决。 另一方面，对于开发人员来说，不知道花在开发时间上的六个月是否真正可行或有意义。 这也破坏了客户或最终用户对公司提供适当功能以及解决其自身问题的能力的信任。

因此，倾向于繁重的行政和文件编制流程的老式整体方法绝对不再是行业标准。 我们希望始终向前并迅速前进。

2.交付时间（交付所需功能的时间）

按照上述说明，我们希望快速发布新功能，以便我们可以快速收集客户的反馈。 要计算该指标，可以使用功能票证的创建日期和标记为已发布的日期。 有时，最好使用票证移至活动冲刺或选择进行开发的日期。

3.平均恢复时间（修复故障的时间）

遵循以上两个指标，我们希望在问题出现时迅速解决。 通过这些指标，您可以很好地了解修复故障和发布修复的速度。 要进行计算，可以使用错误凭单的创建日期以及标记为正式发布的日期。

4.更改失败百分比（通过更改失败的次数）

此处的更改失败百分比旨在打破”快速失败”的格言。 我们希望增加部署频率，但与此同时，我们不想增加错误或失败的数量。 该指标将迫使开发团队针对质量保证标准（例如自动构建，测试，集成和部署）实施良好的自动化实践。

要计算此指标，您可以简单地计算发行后创建的错误的数量。 然后，您可以通过确定错误的原因来完善列表。

我认为这些指标合理的原因不是因为您不能伪造它们（要确保我们改进指标，比平常容易进行更多的部署），而是因为伪造它们时的结果将是积极的- 是，更多的部署可以提高反馈回路的速度。 另外，部署的质量也不能低劣。 否则，更改失败百分比指标将相应增加。 没有人想要。

“比分自理”

比尔·沃尔什（Bill Walsh）在他著名的著作《分数自理》中解释说，定义驱动结果的原则比尝试预测或衡量分数更为重要。 这是因为这些原则将不可避免地引导您走向成功。

为了使这个概念与我们的行业相关，您显然必须首先了解这些原则，然后才能应用它们。 这些知识仅来自经验和与其他专家的咨询。

我想强调这一点，因为我认为有些领导人经常在真正应该关注改进时就关注度量。 当您使用错误的指标进行衡量时尤其如此，如上所述，这可能会导致您朝错误的方向发展。 您还应注意短期改进，长期而言可能会适得其反。

综上所述，让我们现在来看一下可以由您的公司制定或利用的标准，或者可以要求您的软件提供商实施以确保性能将提高或保证开发成功的标准。 。

改善绩效的原则

如果将所有有关性能改进的问题总结为一句话，那就是：

“强大的DevOps推动成功的软件交付。”

那么，我们如何确定什么构成强大的DevOps？ 下面的原则（以及定义它们的特定实践）应作为有价值的指南，从以下内容开始：

持续交付

· 版本控制。 如果您还没有跳船，那就说您来晚了。 版本控制是不可避免的。 毕竟，Github最近有一个很好的理由被微软以$ 7.5B的价格收购。

· 基于主干的开发。

· 自动化的部署过程。 自动化部署过程，避免人为错误。

· 持续集成。 无论何时进行更改，该应用程序都会自动集成和测试。

· 测试自动化。 使您的测试自动化，并使其按照测试金字塔快速，可靠和隔离

· 测试数据管理。 拥有一组涵盖各种用例的最新测试数据。

· 从第1天开始的安全性包括从第1天开始的安全性关注，因为稍后它们的实施可能会变得更加困难和昂贵。

建筑

· 松耦合架构。 这意味着多层或微服务。

· 赋权的团队。 团队成员可以自己决定要使用哪种架构/基础架构。

产品和流程

· 客户的反馈意见。 确保您具有快速有效的反馈循环。

· 可见和可理解的业务流程。 这尤其是对开发人员而言，旨在促进透明度。 通常，商务人士试图将其想法转换为技术术语，这可能会导致极大的混乱，因为他们的技术理解不同于开发人员。

· 小批量。 目标是拥有可以快速测试的小型增量交付成果。

· 实验。 强烈建议您进行实验。

管理与监控

· 轻量级更改批准流程。 削减官僚主义。 删除阻碍因素，以获得更好的创新和自我责任感。 这也有助于保持积极性。

· 应用程序和基础架构监视。 清晰，可访问且透明的监视系统是一种让所有人都知道应用程序当前状态的好方法。

· 系统运行状况检查。

· 进行中的限制。 一次专注于一项或几项任务，并在完成其他任务之前先完成它。 避免中断和多任务处理。 消除”像螺丝刀一样的显影剂”的谬论。

· 进行中的＆质量可视化。

https://www.youtube.com/watch?v=h37csowx2Cg

文化

· 生成文化。 提倡一种生成文化，该文化注重及时完成公司的目标和任务。

· 学习经验。 这两个都应作为改进的基础。

· 合作。 在开发的各个阶段促进协作。

· 公寓赞赏。 有意义的工作值得赞赏。 让某人做某事然后扔掉他们刚刚做的事可能是向他们展示自己的工作的最好方法，这是毫无意义的。 这也是失去他们忠实员工的最佳途径。

· 变革型领导。 展现变革型领导能力。 好的领导者可以帮助人们改善和学习，并引导他们寻求更好的解决方案。

如您所见，DevOps和站点可靠性工程流程是交易的重要组成部分。 它们通过改善可见度并为实验留出更大的余地来固定反馈回路并提高质量。 他们还减少了对变更的恐惧（通过使用自动化测试和交付），增强了动力，并鼓励改进和学习新技术。

是时候看看你的表现了

随着软件开发彻底改变了技术和商业领域，IT公司正在大步前进以进行改进。 问题是：你也是吗？ 现在是时候长时间仔细地查看自己的组织，并查看可以进行哪些更改以使您的绩效再上一个台阶。 此外，了解产出和结果之间的差异。 当您停止对前者施加过多的压力而开始专注于后者时，您将获得更好的结果。 注意测量。 让他们积极向上，这样您就可以激发而不是灌输恐惧。 请记住，不断地重新访问和完善您的DevOps和公司文化。 它们是提高性能的金钥匙。

· https://martinfowler.com/articles/accelerate-foreword.html

· https://www.wsj.com/articles/SB10001424053111903480904576512250915629460

· https://martinfowler.com/articles/architect-elevator.html#TheArchitectElevator

· https://medium.com/specstimate/why-are-humans-so-bad-at-estimating-4b4290f83716

· https://www.arcanys.com/blog/the-7-most-common-software-dev-outsourcing-mistakes

· https://www.quality-assurance-solutions.com/Deming-Point-8.html

· https://www.amazon.com/Score-Takes-Care-Itself-Philosophy/dp/1591843472

· https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid