从该领域汲取的DevOps经验教训：人员，流程和技术

从现场获取这些DevOps经验教训，开始迈向更高的团队士气，更好的沟通和更全面的了解。Tiffany Jachja分享了她的内幕技巧，建议和关键观察，以改善DevOps。

两年前，我坐在OpenShift容器平台新手训练营中，以更好地了解容器技术。在我们休息期间，讲师问我们是否看过黄皮书，我想知道房间周围的洗牌是什么意思。有人走到房间的最前面，将书从他们的书包中取出。“是的，我现在正在阅读。”

“好，你们都应该读这本书，”讲师宣布。他称其为DevOps的圣经。有人表示赞同。我敢肯定我几乎要跳出座位了。圣经？在不知不觉中，培训结束了，我手里拿着《 DevOps手册》（由Gene Kim，Jez Humble，Patrick Debois和John Willis撰写）。

在很短的时间内，我开始学习DevOps以及围绕核心概念的实践，通过共同努力，开发人员和运营团队可以通过软件推动业务价值的交付。我开始了解DevOps是人员，流程和技术的结合。

诚然，我花了很多时间来学习这三个领域的相互影响。挑战之一是诊断一支胜出的团队与一支失败的团队之间的关系。它通常归结为团队的领导，并影响了团队在人员，流程和技术方面的实践和文化。

通过我必须促进和与不同团队合作的机会，我能够注意到关于改进DevOps实践的重要观察和建议。本着这种精神，这里是领导者在DevOps历程中从实地汲取的三个教训。

定义目标结果

我已经意识到，在结果没有明确定义和确定优先顺序的任何努力中，事情都会出错。伪影很重要；我们在设计思考会议，功能构建和发现会议中进行制作。他们通常需要领导者跟踪KPI的输出。它们以文档，图表和/或代码的形式存在。但是，当团队误解其目标时，这些人工制品会迅速贬值。

这里的关键点是不要将结果与输出混淆。您不应该运行设计冲刺来为您的开发人员开发积压的积压；这是一个专注于输出的示例。结果的一个例子是让您的关键利益相关者（包括您的开发人员）了解问题空间以开始开发解决方案。如果您正在运行会话或事件，并且要生成工件和复选框，那就太好了。这样可以确保角色和责任得到处理。这些职责应该是由该角色处理的单独议程。

具有相同结果的团队将获得更好的价值和结果。Accelerate是一本非常出色的书，在采用DevOps的公司中谈论这方面。有针对性的结果可确保涉及技术和人员的流程符合您的业务需求。

创建安全的环境

安全的环境对于维持公司的健康至关重要。员工在感到有能力时会尽力而为。这里的主要收获是维护一个安全的环境，让每个人都可以做出贡献。

如果您保持一支健康，优秀的团队，则可能会达到目标成果，定期在整个公司或团队中推动价值并汲取教训。大量的反馈通常会导致人们希望进一步改进或尝试当前的流程。

如果您在努力创造价值和实现目标成果方面苦苦挣扎，那么很少有实践可以帮助您从团队中学习，例如回顾。敢于领导是我个人的最爱，因为它在公司内的冲突和复杂性中之以鼻。

无论如何，我们无法预测混乱，因此在执行周期内，通常有必要进行调整。改变公司中当前的结果和流程可能很困难，尤其是在团队士气和团队动力方面。如果这些变化导致无法交付的产品，也会导致不满和责备。

降低团队士气的一些迹象包括，人们对事情不畅感到沮丧，退缩以及问题增多。如果您正在经历对团队造成伤害的冲刺或执行中枢，以下是一些枢纽提示：

1. 确保更改符合定义的目标结果。

2. 按时间限制更改/确保班次有时间限制。在执行过程中进行更改时，这一点尤其重要。

3. 在第1点和第2点的背景下向您的团队解释。

维持安全的环境将有助于发展一种文化，使个人获得自主权，从而扩大价值。

建筑师技术

公司认为有必要进行适应和创新，以保持竞争力和在市场中保持领先地位。随着技术的采用和出现，公司中的团队成员必须了解您公司的技术前景。

确保有关您的应用程序体系结构的文档是最新的并且可用。

如果您没有任何体系结构图，请花时间与您的团队合作，至少制作一张跨您的环境的大图。将此呈现给您的公司，并确保每个人都了解您环境中的每个工具和框架如何交互。

使用参考图，您的开发人员可以理解软件应用程序，并指出与当前正在进行的工作有关的所有遗漏细节。全面了解还可以使您更好地确定哪些领域最受益于技术的采用。

了解您的工具和技术如何使您的软件开发生命周期受益，可以加快软件交付速度。