在寻求公司以提高 IT 交付服务的敏捷性时，出现了一种名为 DevOps 的 IT 行业趋势。在这里，我们将探讨在 IT 业务中应用树方法框架方法。

什么是 DevOps？

如前所述，DevOps 是 IT 行业旨在提高 IT 交付服务敏捷性的新趋势。此举强调透明通信、协作以及开发人员软件和 IT 运营之间的集成。 DevOps 认识到开发人员和 IT 操作员是不相关的组，可以相互交互，但无法真正 协同工作。

DevOps 可帮助组织快速创建 IT 服务和软件，从而减少迭代。 DevOps 团队使用两个关键组件（称为"通信"和"实时可见性"） 取得成功。

树法弗雷梅工作方法

树方法框架基于增量方法，侧重于将 DevOps 采用的风险和成本降到最低，同时构建必要的技能和动力，以实现在整个企业中成功部署。

《DevOps 手册》的三种方法原则

Gene Kim 的 “三种方法原则” 基本上设定了增量采用 DevOps 的不同方法：

• **第一种方法：**系统思维。
• **第二种方式：**反馈。
• **第三种方式：**增量采用。

1. 系统思维

最重要的是，DevOps 组织总是从系统的角度考虑。

系统是指为共同目标设定的集成流程集。

对于 DevOps 组织，系统是指整个业务，而不是其特定部门或团队，在软件开发中组织受信任的活动涉及不同的程序和流程。

这个过程可能涉及许多人和程序。系统思维意味着每个团队必须了解在开发生产线上工作的所有其他团队的行为，并最终交付给客户。

**DevOps 定义了操作如何不仅影响团队，而且影响整个系统。**这意味着开发人员团队可以在整个生命周期中具有更大的可见性。

这也意味着

• 开发人员团队必须了解代码的可能后果。
• 系统管理员必须充分了解性能对应用程序的影响，一旦他们被释放给客户。系统思维是思考内疚的极好方法。
• **企业需要消除个人犯罪的倾向。**这是关于不责怪一个人谁不幸地按下按钮，并导致系统崩溃，但我们可以责怪系统，允许这种情况发生。系统思维将处理像系统中任何故障这样的事件。

2. 反馈

在没有任何反馈的情况下，学习效率低下，因此 DevOps 实现总是鼓励不同类型的反馈。

反馈以客户反馈的形式发生在同一团队的对等方之间和企业之间。

DevOps 保持沟通渠道畅通，以方便反馈，并允许客户在开发和运营层面进行渗透。

DevOps 鼓励快速开发，其反馈循环也不例外。

为了在最短的时间内将功能交付给客户，尽快获得反馈至关重要。 DevOps 方法扭转了传统方法，客户通过开放反馈渠道控制开发。

客户端能够提供即时反馈，这些反馈经过筛选和优先级处理，并转换为新代码，这些代码将成为通过反馈循环再次向客户端发送的基础结构。

对于提供应用程序的人（如业务分析师、网络工程师、开发人员、测试人员等）的参与和交互，这一点同样重要。

通过多阶段概念验证和克服抗变化的阻力，可降低生产风险。

尽管增量流程方法需要数年时间，但结果总是具有变革性的，但底线是 DevOps 是动态的。

3. 增量采用

积极采用 DevOps 的替代方法是增量采用;虽然这可能需要更长的时间，但它将显著降低风险，并确保成功实施。

该方法从设置小目标开始，例如将 DevOps 部署到由小型开发人员团队维护的单个应用程序中。一旦成功完成，所吸取的经验教训可以应用于越来越大的目标，直到最终在流程改进和流程执行之间实现健康平衡。

关键的挑战仍然是在组织复杂的 IT 环境、部署速度和风险之间找到平衡点，这些环境必须协同工作。

因此，DevOps 应计划持续改进，而不是同时实现事件。

增量战略最好必须采用周期性的分层方法，将采用 DevOps 以构建必要的内部技能组合的风险和成本降至最低，并推动实施更大、更快的周期。

每个步骤都将建立在上一步之上，在整个全球周期的投资和准备方面。对于大多数公司来说，开发时间是现实的，并且会根据组织的文化和政策而大相径庭。

小组会议可能会占用大部分时间，其估计基于有 1 到 3 人的小型实施团队，他们不断与来自应用程序 2-4 人的关键员工进行交互。