管理承诺和 DevOps 的框架条件
Posted: Mon Jan 27, 2025 6:14 am
在我们在文章第一部分阐明了一般性内容之后，我们想在下面向您展示如何划分和构建项目阶段。此信息旨在帮助您为各自的 IT 组织制定项目方法。该模型被视为一个模块化系统，可以根据您的特定情况进行调整。
“创造框架条件”阶段
尤其重要的是对公司的 IT 战略进行必要的调整，以定义和建立个人的 DevOps 愿景。每个公司都必须自己定义 DevOps 的含义以及应在多大程度上实施 - 例如，对于远离或靠近生产的环境。此定义必须由管理层、部门和 IT（开发和运营）共同商定。
应该考虑的另一点是为项目提供“预算和行动权力”——除其他外，以创建和调整必要的蓝图。这个因素经常被忽视或至少被低估。但在实践中，这是成功的关键之一。经验表明，有许多蓝图会减慢或阻碍项目。因此，“Just do it”的策略在很多情况下并没有错，因为所有不必要的蓝图都会被放入抽屉中并创建新的蓝图。
如果您还没有这样做，您应该最晚在这个阶段检查引入 DevOps 或相应的技术堆栈是否会带来预期的好处。例如，如果 IT 运营人员使用现有软件开发流程的软件交付时间已经足以满足当前和未来的公司需求，则不需要 DevOps 技术堆栈。
成功的关键是 IT 安全和 IT 架构领域辅导职能的定义。这意味着那些通常会对其传统角色施加障碍甚至阻碍的部门必须与项目团队一起以建设性的方式制定新的蓝图。在实践中，项目和一线 IT 之间的合作方法可以带来最佳结果。
建立项目框架条件并定义项目基础设施
由于项目基础设施欠佳，项目通常会出现初期问题：
DevOps 团队有时在多个地点工作，协作资源很少 - 例如没有足够 牙科电子邮件列表 的团队空间或白板。在这种情况下，为整个团队提供一个大房间，也可以用于展示目的，以便利益相关者和感兴趣的各方也可以参加团队活动，这是一个很大的优势。
为开发人员提供足够的权限同样困难 - 例如其开发计算机上的本地管理权限。另一点是可以访问互联网上的工件存储库。许多公司没有为此做好准备，甚至在项目启动之前就浪费了时间。基础知识必须提前到位，例如网络区域或访问路径和权限，这些不会妨碍敏捷开发。
此外，还应提前提供足够的项目工具，以便团队可以开始其运营工作。其中包括像 Confluence 这样的项目 wiki 和像 JIRA 这样的规划工具。
“计划项目”阶段
框架条件创建完成后，该阶段开始实际的项目规划。
项目规划概述
初始 DevOps 技术堆栈的第一个定义对于规划至关重要。在这里，根据需求以及公司特定的规范和特殊功能启动了一组初始工具，并对其在 DevOps 环境中的使用进行了测试。重要的是，来自 IT 安全和 IT 架构领域的教练在做出此选择时从一开始就提供支持。在冲刺期间，经过“反复试验”后测试并选择合适的工具。
作为项目组织的一部分，事实证明，定义 DevOps 教练的角色也是有用的，让他或她履行中立权威和主持人的职能。 DevOps 教练在技术和软件开发方面拥有丰富的经验，可以为其他项目提供灵感并创造背景。这样，项目内部和外部就可以进行交流和联网。
“执行项目”阶段
然后在实施阶段构建实际的技术堆栈。为此，创建必要的蓝图，DevOps 团队开发和验证流程，以便能够成功使用该技术。绝对应该邀请管理层代表和感兴趣的各方，以便他们能够对敏捷方法有个人印象。如果工具未按照预先计划的要求或操作目标运行，则必须对其进行调整或用其他工具替换，直到满足所有既定标准。从第一天起，经验和发现就应该以易于理解的方式记录下来。例如，经验表明使用项目 wiki 有助于取得成功。
“完成项目”阶段
完成项目时只需考虑一些特殊功能。经典项目方法的现有程序和结构就足够了。
项目完成概况
重要的是适当的技术和专业测试的定义和顺序：
通过必要的测试（负载和性能、故障转移、恢复等）建立新的操作平台的测试和验收
测试并验收各个版本，稍后将在DevOps平台上运行
必须为这两种形式的测试定义技术和功能测试用例。无论如何，应该首先实现测试自动化，这样以后就不会出现瓶颈。
项目组织至关重要
引入 DevOps 技术堆栈的项目组织至关重要。除了技术项目中已知的结构和参与者之外，还有一个特点是核心项目本身通常是一个开发项目：
治理与合规性（IT 安全、数据保护等）的指导作用
IT 架构的辅导角色，如有必要，企业架构的辅导角色
IT 运营的积极整合（作为 DEV 和项目参与者的教练）
项目集成场景——DevOps 技术堆栈到底应该做什么？
仅 IT 流程模型不会为公司带来任何附加价值。最终，还必须有相应的目的或项目范围。这同样适用于这里：少即是多。在通过使用 DevOps 取得初步小成功的欣喜之中，公司经常发现自己陷入了复杂性陷阱。
“创造框架条件”阶段
尤其重要的是对公司的 IT 战略进行必要的调整，以定义和建立个人的 DevOps 愿景。每个公司都必须自己定义 DevOps 的含义以及应在多大程度上实施 - 例如，对于远离或靠近生产的环境。此定义必须由管理层、部门和 IT（开发和运营）共同商定。
应该考虑的另一点是为项目提供“预算和行动权力”——除其他外，以创建和调整必要的蓝图。这个因素经常被忽视或至少被低估。但在实践中，这是成功的关键之一。经验表明，有许多蓝图会减慢或阻碍项目。因此，“Just do it”的策略在很多情况下并没有错，因为所有不必要的蓝图都会被放入抽屉中并创建新的蓝图。
如果您还没有这样做，您应该最晚在这个阶段检查引入 DevOps 或相应的技术堆栈是否会带来预期的好处。例如，如果 IT 运营人员使用现有软件开发流程的软件交付时间已经足以满足当前和未来的公司需求，则不需要 DevOps 技术堆栈。
成功的关键是 IT 安全和 IT 架构领域辅导职能的定义。这意味着那些通常会对其传统角色施加障碍甚至阻碍的部门必须与项目团队一起以建设性的方式制定新的蓝图。在实践中，项目和一线 IT 之间的合作方法可以带来最佳结果。
建立项目框架条件并定义项目基础设施
由于项目基础设施欠佳，项目通常会出现初期问题：
DevOps 团队有时在多个地点工作，协作资源很少 - 例如没有足够 牙科电子邮件列表 的团队空间或白板。在这种情况下，为整个团队提供一个大房间，也可以用于展示目的，以便利益相关者和感兴趣的各方也可以参加团队活动，这是一个很大的优势。
为开发人员提供足够的权限同样困难 - 例如其开发计算机上的本地管理权限。另一点是可以访问互联网上的工件存储库。许多公司没有为此做好准备，甚至在项目启动之前就浪费了时间。基础知识必须提前到位，例如网络区域或访问路径和权限，这些不会妨碍敏捷开发。
此外，还应提前提供足够的项目工具，以便团队可以开始其运营工作。其中包括像 Confluence 这样的项目 wiki 和像 JIRA 这样的规划工具。
“计划项目”阶段
框架条件创建完成后，该阶段开始实际的项目规划。
项目规划概述
初始 DevOps 技术堆栈的第一个定义对于规划至关重要。在这里，根据需求以及公司特定的规范和特殊功能启动了一组初始工具，并对其在 DevOps 环境中的使用进行了测试。重要的是，来自 IT 安全和 IT 架构领域的教练在做出此选择时从一开始就提供支持。在冲刺期间，经过“反复试验”后测试并选择合适的工具。
作为项目组织的一部分，事实证明，定义 DevOps 教练的角色也是有用的，让他或她履行中立权威和主持人的职能。 DevOps 教练在技术和软件开发方面拥有丰富的经验，可以为其他项目提供灵感并创造背景。这样，项目内部和外部就可以进行交流和联网。
“执行项目”阶段
然后在实施阶段构建实际的技术堆栈。为此，创建必要的蓝图，DevOps 团队开发和验证流程，以便能够成功使用该技术。绝对应该邀请管理层代表和感兴趣的各方，以便他们能够对敏捷方法有个人印象。如果工具未按照预先计划的要求或操作目标运行，则必须对其进行调整或用其他工具替换，直到满足所有既定标准。从第一天起，经验和发现就应该以易于理解的方式记录下来。例如，经验表明使用项目 wiki 有助于取得成功。
“完成项目”阶段
完成项目时只需考虑一些特殊功能。经典项目方法的现有程序和结构就足够了。
项目完成概况
重要的是适当的技术和专业测试的定义和顺序：
通过必要的测试（负载和性能、故障转移、恢复等）建立新的操作平台的测试和验收
测试并验收各个版本，稍后将在DevOps平台上运行
必须为这两种形式的测试定义技术和功能测试用例。无论如何，应该首先实现测试自动化，这样以后就不会出现瓶颈。
项目组织至关重要
引入 DevOps 技术堆栈的项目组织至关重要。除了技术项目中已知的结构和参与者之外，还有一个特点是核心项目本身通常是一个开发项目：
治理与合规性（IT 安全、数据保护等）的指导作用
IT 架构的辅导角色，如有必要，企业架构的辅导角色
IT 运营的积极整合（作为 DEV 和项目参与者的教练）
项目集成场景——DevOps 技术堆栈到底应该做什么？
仅 IT 流程模型不会为公司带来任何附加价值。最终，还必须有相应的目的或项目范围。这同样适用于这里：少即是多。在通过使用 DevOps 取得初步小成功的欣喜之中，公司经常发现自己陷入了复杂性陷阱。