devops失败的原因_为什么害怕失败是一种无声的DevOps病毒

devops失败的原因

您认识以下情况吗？ 我这样做是因为一位经理曾经扼杀了我的激情和创新，以至于我急于做出决定，冒险并专注于重要的事情：“ 发现通过开发软件并帮助他人开发软件的更好方法 ”（《 敏捷宣言》 ，2001 ）。

开发人员： “ UX假设失败。用户对新的导航体验React不佳，导致80％的用户切换回经典导航。 ”

经理： “ 这真的很糟糕！这怎么可能？我们需要解决此问题，因为我不确定我们的涉众是否希望听到您的失败。 ”

这是一个不同的，更有力的回应。

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

一切都围绕着建设性和无责的心态。

有各种类型的恐惧会使人们瘫痪，然后感染他们的团队。 害怕没有什么是永远足够的，迫使自己去做越来越多的事情，认为反馈是不利的，并且常常使自己筋疲力尽。 他们努力工作，而不是聪明，而是交付数量而不是价值。

其他人则害怕被审判，与他人进行比较，并逃避问责制。 他们很少分享自己的知识，激情或工作。 他们发现自己没有走上充满活力的协作，而是漫步在装满骷髅和肮脏鱼的幽灵船上。

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

在许多组织中，尤其是那些已经开始进行数字化转型的组织， 对失败的恐惧根深蒂固。 这是由于不希望有的失败，对后果的了解以及对经验证的学习缺乏兴趣所致。

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

我有一个假设：

“ 我相信，如果我们向所有利益相关者阐述软件工程中的失败收益，那么组织将接受失败。 ”

让我们看一下传统的软件开发生命周期，该生命周期追求质量，基于严格的流程并且对故障敏感。 我们按顺序设计，开发和测试所有功能。 当质量保证和安全性给我们“竖起大拇指”，然后是一个满意的用户（成功）或不满意的用户（失败）时，该解决方案就会发布给客户。

在传统模式下，我们只有一次失败或成功的机会。 如果我们要制造敏感产品，例如价值数百万美元的火箭或飞机，这可能是一种有效的模型。 上下文很重要！

现在，让我们看一个更现代的软件开发生命周期，该生命周期追求质量并接受失败 。 我们设计，构建，测试并发布了有限的版本供用户预览。 我们得到反馈。 如果用户满意（成功），我们将移至下一个功能。 如果用户不满意（失败），我们将根据经过验证的反馈来改进或取消该功能。

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

• 连续交付 （CD）旨在在短周期内交付软件，并在企业或用户单击按钮时一次可靠地发布功能。
• 测试驱动开发 （TDD）是一种软件工程方法，在业务，开发和质量保证的利益相关者之间引发了许多争论。 它依赖于短而重复的开发周期，每个周期都基于需求来编写测试用例，失败并开发软件以通过测试用例。
• 假设驱动的开发 （HDD）基于一系列实验，以验证或反证我们未知的复杂问题域中的假设。 当假设失败时，我们将进行枢纽行动。 当它通过时，我们将专注于下一个实验。 与TDD一样，它基于非常短的重复来探索和响应经过验证的学习。

快速失败 ，这意味着我们将我们的产品切成小块的工作单元，这些工作单元可以快速可靠地作为价值进行开发和交付。 当我们失败时，必须将浪费和影响降到最低，并将经过验证的学习最大化。

为了避免工程师担心失败，组织中的所有利益相关者都必须信任工程过程并接受失败。 最好的解药是那些支持和鼓舞人心的领导者，同时要有集体无的心态来计划，确定优先顺序，建立，发布和支持。 我们不应该鲁or或忽视失败的影响，尤其是当它影响投资者或生计时。

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

“ DevOps是人员，流程和产品的结合，可以为我们的最终用户持续交付价值。”

---

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

翻译自: https://opensource.com/article/19/8/why-fear-failure-silent-devops-virus

devops失败的原因