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

你是否遇到过以下情况？ 我经历过，因为一位经理压制了我的热情和创新，以至于我不敢做决定、承担风险，并且无法专注于重要的事情：“*通过实践并帮助他人实践来发现开发软件的更好方法*” (敏捷宣言，2001)。

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

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

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

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

一切都取决于以建设性和不责备的心态为中心的语气。

有各种各样的恐惧会麻痹人们，然后他们会感染他们的团队。 害怕永远不够，推动自己做越来越多，将反馈视为不利，并且经常筋疲力尽。 他们努力工作，而不是聪明地工作——交付数量，而不是价值。

其他人则害怕被评判，将自己与他人比较，并回避责任。 他们很少分享他们的知识、热情或工作； 他们发现自己在鬼船中游荡，到处都是骷髅和发臭的鱼，而不是充满活力的协作。

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

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

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

我有一个假设

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

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

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

现在让我们看看更现代的软件开发生命周期，它力求质量并*接受失败*。 我们设计、构建、测试并向用户发布有限的版本以供预览。 我们得到反馈。 如果用户满意（成功），我们就会进入下一个功能。 如果用户不满意（失败），我们会根据有效的反馈来改进或放弃该功能。

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

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

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

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

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

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

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