为什么害怕失败是 DevOps 的沉默病毒

您是否认出以下情景？我认得，因为一位经理曾经扼杀了我的热情和创新，以至于我焦虑地做出决定、承担风险并专注于重要的事情：“通过实践和帮助他人实践来发现开发软件的更好方法”（敏捷宣言，2001）。

开发者：“用户体验假设失败了。用户对新的导航体验反应不佳，导致 80% 的用户切换回经典导航。”

经理：“这太糟糕了！这怎么可能？我们需要解决这个问题，因为我不确定我们的利益相关者想听到你的失败。”

这是一个不同且更强大的回应。

领导者：“我们的假设失败的可能原因是什么？我们如何改善用户体验？让我们分析一下，并与我们的利益相关者分享我们的补救计划。”

这一切都与以建设性和无责备心态为中心的语气有关。

有各种类型的恐惧会麻痹人们，然后他们会感染他们的团队。他们害怕永远不够，逼迫自己做更多的事情，将反馈视为不利的，并且经常把自己累垮。他们努力工作，而不是聪明地工作——交付数量，而不是价值。

其他人害怕被评判，将自己与他人比较，并逃避责任。他们很少分享他们的知识、热情或工作；他们没有充满活力的协作，而是发现自己在一个充满骷髅和腐臭鱼的幽灵船上游荡。

“我们唯一需要恐惧的就是恐惧本身。”——富兰克林·D·罗斯福

害怕失败在许多组织中都很普遍，尤其是在那些已经踏上数字化转型之旅的组织中。它是由失败的不受欢迎、对后果的了解以及对已验证学习的缺乏兴趣造成的。

这是一种奇怪的现象，因为当我们查看《敏捷软件开发宣言》时，我们注意到提到了“客户协作”和“响应变化”。精益思想提倡诸如“优化整体”、“消除浪费”、“创造知识”、“内置质量”和“尊重人”等原则。此外，看板原则中的两项提到了“可视化工作”和“持续改进”。

我有一个假设

“我相信，如果我们向所有利益相关者阐述失败在软件工程背景下的好处，组织将拥抱失败。”

让我们看一下传统的软件开发生命周期，它力求质量，基于严格的流程，并且对失败敏感。我们按顺序设计、开发和测试所有功能。当质量保证和安全部门给我们“批准”时，解决方案将发布给客户，然后是快乐的用户（成功）或不快乐的用户（失败）。

在传统模型中，我们只有一次失败或成功的机会。如果我们正在构建火箭或飞机等价值数百万美元的敏感产品，这可能是一个有效的模型。背景很重要！

现在，让我们看一下更现代的软件开发生命周期，它力求质量并拥抱失败。我们设计、构建和测试，并将有限的版本发布给我们的用户进行预览。我们获得反馈。如果用户满意（成功），我们将继续进行下一个功能。如果用户不满意（失败），我们将根据已验证的反馈来改进或废弃该功能。

请注意，我们每个功能至少有一次失败的机会，这让我们在发布相同产品之前，至少有 10 次机会根据已验证的用户反馈来改进我们的产品。本质上，这种现代方法是传统方法的重复，但它被分解为更小的发布周期。我们无法减少设计、开发和测试我们的功能所需的工作量，但我们可以学习和改进流程。您可以将此软件工程流程更进一步。

• 持续交付 (CD) 旨在以短周期交付软件，并通过业务或用户单击按钮来可靠地一次发布一个功能。
• 测试驱动开发 (TDD) 是一种软件工程方法，在业务、开发和质量保证部门的利益相关者之间引起了很多争论。它依赖于简短而重复的开发周期，每个周期都根据需求制作测试用例，使其失败，然后开发软件以通过测试用例。
• 假设驱动开发 (HDD) 基于一系列实验，以验证或反驳我们在复杂的未知领域中的假设。当假设失败时，我们进行调整。当假设通过时，我们专注于下一个实验。与 TDD 一样，它基于非常短的重复来探索并对已验证的学习做出反应。

是的，我确信失败不是坏事。事实上，它是创新和持续学习的推动者。重要的是要强调，我们需要以快速失败的形式拥抱失败，这意味着我们将我们的产品切分成可以快速可靠地开发和交付价值的小工作单元。当我们失败时，必须最大限度地减少浪费和影响，并最大限度地提高已验证的学习。

为了避免工程师害怕失败，组织中的所有利益相关者都需要信任工程流程并拥抱失败。最好的解药是支持和鼓舞人心的领导者，以及拥有集体无责备的心态来计划、确定优先级、构建、发布和支持。我们不应鲁莽或无视失败的影响，尤其是在失败影响到投资者或生计时。

我们在开发软件时不能害怕失败。否则，我们将扼杀创新和发展，进而扼杀人员、流程和持续交付价值的结合，这是 Donovan Brown 定义的 DevOps 的关键要素。

“DevOps 是人员、流程和产品的结合，旨在实现向最终用户的持续价值交付。”

特别感谢 Anton Teterine 和 Alex Bunardzic 分享他们对恐惧的看法。