返回ITIL 4 Foundation中文翻译目录，[ ttp://www.itilxf.com/thread-139244-1-1.html]点击[/url]

4.3 ITIL 指导原则

指导原则是指导组织在任何情况下的建议，无论其目标，战略，工作类型或管理结构如何变化。 指导原则具有普遍性和持久性。

专注于价值

组织所做的一切都需要直接或间接地为利益相关者创造价值。关注价值原则包含许多观点，包括客户和用户的经验。

从你的位置开始

不要从头开始构建新的东西，而不考虑已经可以利用的东西。目前的服务，流程可能会有很多可用于创建所需结果的程序，项目和人员应当直接调查和观察当前状态，以确保完全理解。

反复进行反馈

不要试图一次完成所有事情。即使是巨大的举措也必须反复完成。通过将工作组织成可以及时执行和完成的较小的，可管理的部分，更容易保持对每项工作的更加关注。

在每次迭代之前，之后和之后使用反馈将确保即使情况发生变化，操作也是集中且适当的。

协作并提升可视化

跨越边界合作产生的结果具有更大的支持度，与目标更相关，并且增加了长期成功的可能性。实现目标需要信息，理解和信任。应该明确工作和后果，避免隐藏的议程，并尽可能地分享信息。

全面思考和工作

没有服务或用于提供服务的元素是独立的。服务提供商和服务消费者所取得的成果将受到影响，除非该组织作为一个整体服务于该服务，而不仅仅是其部分通过有效和高效的管理以及信息，技术，组织，人员，实践，合作伙伴和协议的动态整合，将结果传递给内部和外部客户，这些都应该协调以提供定义的价值。

保持简单实用

如果流程，服务，行动或指标未能提供价值或产生有用的结果，则将其消除。在流程或程序中，使用完成目标所需的最少步骤数。始终使用基于结果的思维来产生可提供结果的实用解决方案。

优化和自动化

应该使用所有类型的资源，特别是人力资源，以达到最佳效果。消除任何真正浪费的东西，并使用技术来实现其能力。人的干预应该只发生在真正有价值的地方。

这里定义的指导原则体现了 ITIL 和服务管理的核心信息，支持各种类型和各个层面的成功行动和良好决策。它们可用于指导组织在采用服务管理方法时的工作，并根据自己的特定需求和情况调整 ITIL 指南。指导原则鼓励和支持各级各组织不断改进。

这些原则也反映在许多其他框架，方法，标准，哲学和/或知识体系中，例如精益，敏捷，DevOps 和 COBIT。这使组织能够有效地将多种方法的使用整合到服务管理的整体方法中。

指导原则几乎适用于任何倡议以及与利益相关方团体的所有关系。例如，第一个原则，即关注价值，可以（而且应该）不仅适用于服务消费者，而且适用于所有相关利益相关者及其各自的价值定义。

表 4.1 提供了指导原则的高级介绍。本章稍后将介绍每种原则的其他详细信息。

敏捷方法应用于软件开发时，专注于为软件产品提供增量变更，同时响应用户不断变化的（或不断变化的）需求。他们培养了一种不断学习，灵活和愿意尝试新方法并适应快速变化的需求的文化。敏捷的工作方式包括时间框工作，自组织和跨职能团队等技术，以及与客户和用户的持续协作和沟通。

敏捷软件开发团队通常专注于快速交付产品增量，但要考虑更全面的视图，这些视图考虑了这些产品在实时环境中的可操作性，可靠性和可维护性。同样，持续学习和改进计划可以专注于改善用户需求的清晰度和优先级，或简化开发，测试和部署工作软件的过程。虽然这些举措可以提供有价值的结果，但它们也存在与服务级别的其他举措不同步的风险。

正如敏捷技术为服务组织提供产品和软件增量流一样，ITIL 也可以为软件开发组织提供更广泛的视角和语言，以便与其他服务团队合作。在没有 ITIL 的情况下采用敏捷可能会导致更高的成本，例如采用不同技术和架构的成本，以及发布，操作和维护软件增量的成本。同样，在没有敏捷技术的情况下实施 ITIL 可能会失去对客户和用户价值的关注，从而形成缓慢移动且高度集中的官僚机构。

当 Agile 和 ITIL 一起采用时，软件开发和服务管理可以以类似的节奏发展，共享一个共同的术语，并确保组织继续与所有利益相关者共同创造价值。 ITIL 和 Agile 可以协同工作的一些方式包括：

●简化诸如变更控制之类的做法，建立程序，以便对计划外中断的管理进行整合和优先排序

●（事件），并调查失败的原因

●如果需要，在管理来自软件开发团队使用的“参与系统”（例如协作工具）的服务所需的“记录系统”（例如配置管理数据库）之间分离交互。

DevOps 方法基于敏捷软件开发和服务管理技术，强调软件开发和技术操作之间的紧密协作。

利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，DevOps 能够揭示可协助管理的软件产品的可操作性，可靠性和可维护性等方面服务。 DevOps 从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动，以便产品和服务团队与相同 的目标保持一致并使用相同的方法。

人们常说，DevOps 结合了软件开发技术（敏捷），良好治理和价值共创（ITIL）的整体方法，以及对学习和改进价值生成方式（精益）的痴迷。因此，采用 DevOps 方法为改进软件产品的开发和管理方式提供了更多机会，例如：

●创建从交付和支持到软件开发和技术操作的快速反馈循环

●简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值

●区分部署管理与发布管理，倡导“系统视图”，强调企业治理，服务团队，软件开发和技术操作之间的紧密协作。

唐龙翻译

返回ITIL 4 Foundation中文翻译目录，[ ttp://www.itilxf.com/thread-139244-1-1.html]点击[/url]

4.3 ITIL 指导原则

指导原则是指导组织在任何情况下的建议，无论其目标，战略，工作类型或管理结构如何变化。 指导原则具有普遍性和持久性。

专注于价值

组织所做的一切都需要直接或间接地为利益相关者创造价值。关注价值原则包含许多观点，包括客户和用户的经验。

从你的位置开始

不要从头开始构建新的东西，而不考虑已经可以利用的东西。目前的服务，流程可能会有很多可用于创建所需结果的程序，项目和人员应当直接调查和观察当前状态，以确保完全理解。

反复进行反馈

不要试图一次完成所有事情。即使是巨大的举措也必须反复完成。通过将工作组织成可以及时执行和完成的较小的，可管理的部分，更容易保持对每项工作的更加关注。

在每次迭代之前，之后和之后使用反馈将确保即使情况发生变化，操作也是集中且适当的。

协作并提升可视化

跨越边界合作产生的结果具有更大的支持度，与目标更相关，并且增加了长期成功的可能性。实现目标需要信息，理解和信任。应该明确工作和后果，避免隐藏的议程，并尽可能地分享信息。

全面思考和工作

没有服务或用于提供服务的元素是独立的。服务提供商和服务消费者所取得的成果将受到影响，除非该组织作为一个整体服务于该服务，而不仅仅是其部分通过有效和高效的管理以及信息，技术，组织，人员，实践，合作伙伴和协议的动态整合，将结果传递给内部和外部客户，这些都应该协调以提供定义的价值。

保持简单实用

如果流程，服务，行动或指标未能提供价值或产生有用的结果，则将其消除。在流程或程序中，使用完成目标所需的最少步骤数。始终使用基于结果的思维来产生可提供结果的实用解决方案。

优化和自动化

应该使用所有类型的资源，特别是人力资源，以达到最佳效果。消除任何真正浪费的东西，并使用技术来实现其能力。人的干预应该只发生在真正有价值的地方。

这里定义的指导原则体现了 ITIL 和服务管理的核心信息，支持各种类型和各个层面的成功行动和良好决策。它们可用于指导组织在采用服务管理方法时的工作，并根据自己的特定需求和情况调整 ITIL 指南。指导原则鼓励和支持各级各组织不断改进。

这些原则也反映在许多其他框架，方法，标准，哲学和/或知识体系中，例如精益，敏捷，DevOps 和 COBIT。这使组织能够有效地将多种方法的使用整合到服务管理的整体方法中。

指导原则几乎适用于任何倡议以及与利益相关方团体的所有关系。例如，第一个原则，即关注价值，可以（而且应该）不仅适用于服务消费者，而且适用于所有相关利益相关者及其各自的价值定义。

表 4.1 提供了指导原则的高级介绍。本章稍后将介绍每种原则的其他详细信息。

敏捷方法应用于软件开发时，专注于为软件产品提供增量变更，同时响应用户不断变化的（或不断变化的）需求。他们培养了一种不断学习，灵活和愿意尝试新方法并适应快速变化的需求的文化。敏捷的工作方式包括时间框工作，自组织和跨职能团队等技术，以及与客户和用户的持续协作和沟通。

敏捷软件开发团队通常专注于快速交付产品增量，但要考虑更全面的视图，这些视图考虑了这些产品在实时环境中的可操作性，可靠性和可维护性。同样，持续学习和改进计划可以专注于改善用户需求的清晰度和优先级，或简化开发，测试和部署工作软件的过程。虽然这些举措可以提供有价值的结果，但它们也存在与服务级别的其他举措不同步的风险。

正如敏捷技术为服务组织提供产品和软件增量流一样，ITIL 也可以为软件开发组织提供更广泛的视角和语言，以便与其他服务团队合作。在没有 ITIL 的情况下采用敏捷可能会导致更高的成本，例如采用不同技术和架构的成本，以及发布，操作和维护软件增量的成本。同样，在没有敏捷技术的情况下实施 ITIL 可能会失去对客户和用户价值的关注，从而形成缓慢移动且高度集中的官僚机构。

当 Agile 和 ITIL 一起采用时，软件开发和服务管理可以以类似的节奏发展，共享一个共同的术语，并确保组织继续与所有利益相关者共同创造价值。 ITIL 和 Agile 可以协同工作的一些方式包括：

●简化诸如变更控制之类的做法，建立程序，以便对计划外中断的管理进行整合和优先排序

●（事件），并调查失败的原因

●如果需要，在管理来自软件开发团队使用的“参与系统”（例如协作工具）的服务所需的“记录系统”（例如配置管理数据库）之间分离交互。

DevOps 方法基于敏捷软件开发和服务管理技术，强调软件开发和技术操作之间的紧密协作。

利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，DevOps 能够揭示可协助管理的软件产品的可操作性，可靠性和可维护性等方面服务。 DevOps 从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动，以便产品和服务团队与相同 的目标保持一致并使用相同的方法。

人们常说，DevOps 结合了软件开发技术（敏捷），良好治理和价值共创（ITIL）的整体方法，以及对学习和改进价值生成方式（精益）的痴迷。因此，采用 DevOps 方法为改进软件产品的开发和管理方式提供了更多机会，例如：

●创建从交付和支持到软件开发和技术操作的快速反馈循环

●简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值

●区分部署管理与发布管理，倡导“系统视图”，强调企业治理，服务团队，软件开发和技术操作之间的紧密协作。

唐龙翻译