如有ITIL认证、ITIL培训或ITIL考试需求，可点击了解详情

申明：

本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：ITILXF，并回复“软件开发和管理”即可。

1 关于本文档

本文档提供软件开发与管理实践实用指南，分为五个主要部分，涵盖：

● 本实践的一般信息

● 本实践相关的流程和活动及其在服务价值链中的作用

● 参与本实践的组织和人员

● 支持本实践的信息和技术

● 对本实践的合作伙伴和供应商的考虑

1.1 ITIL 4资格认证计划

本文档中的部分内容可作为以下教学大纲的一部分以供检查：

● ITIL专家创建、交付和支持

● ITIL专家交付利益干系人价值

详情请参考各部分教学大纲。

2 一般信息

2.1 目的和描述

• 关键信息

软件开发和管理实践的目的是确保应用程序在功能、可靠性、可维护性、合规性和可审核性方面满足内部和外部利益相关者的需求。

软件开发和管理实践侧重于应用软件的开发和管理。但是，许多原则也适用于作为开发和管理应用程序基础架构的软件。软件工程对于基础架构和平台管理越来越重要，例如基础架构即代码的应用这一概念使用机器可读的定义文件管理和配置IT基础架构和平台，而不用物理地配置硬件组件。

软件开发和管理涵盖应用程序的整个生命周期。这个生命周期可能从几个月到几十年不等，平均为10-15年。从经济角度看，历史上应用程序平均总体拥有成本的20％用于开发而不是管理，而软件管理成本的20％与纠正性维护有关。

现在应用程序总体拥有成本中的较大部分转移到了开发。由于不断的变更成为应用程序生命周期的组成部分，因此所有的维护活动都可以成为开发的一部分，而且通常不会称为维护。

2.2 术语和概念

软件

告诉计算机的物理组件（硬件）如何工作的一组指令。软件不仅存在于针对最终用户的应用程序中，而且存在于开发和操作应用程序所需的基础架构中。软件和基础架构与其他服务组件或资源组合在一起形成产品和服务的服务组件。

软件是业务的关键部分：它可以通过技术使能业务服务为客户提供价值。大多数现代服务不再是软件辅助的，而是软件使能的，软件开发变得至关重要。

软件开发

根据功能和非功能需求对应用程序进行设计和构建，并根据不断变化的功能和非功能需求对运行的应用程序进行修正和改进。

近年来，外包软件开发服务的趋势发生了逆转，许多组织将关键和战略开发重新纳入内部。这些组织包括银行、保险和零售公司。

维护

无论是更正还是改进，应用程序的修改是开发的一部分：

● 修正：修正应用程序中引发事件的缺陷

● 预防：在应用程序中的缺陷显现出来之前进行修补

● 适配：使应用程序适应变化的基础架构

● 完善：改进应用程序的功能、可用性和性能（有时称为“附加维护”，“改进”或“开发”）。

随着现代服务发展速度的加快，服务日新月异。现代通常在整个生命周期中应用程序都会修改。这意味着现在用于构成维护的所有活动都成为开发流程的一部分。

软件管理是一个泛指的术语，指代应用程序策略及规划、运营、应用程序相关制品的安全保障，以及应用系统下线。

该实践的目的是应用程序应该在功能、可靠性、可维护性、合规性和可审核性方面满足内部和外部利益相关者的需要。提及的所有术语均描述了软件质量。

软件质量：软件作为产品并体现其使用价值的条件

常见分类（ISO / IEC 25010：2011）为：

● 产品质量：功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性和可移植性

● 使用质量：有效性、效率、满意度、无风险和上下文覆盖

快速修复通常比适当但耗时的更改更受欢迎。软件的大量变更可能会导致在某个时间点必须完成大量累积返工，这称为技术债务。

技术债：选择替代变通方法而不是系统解决方案需要花费更长的时间，从而导致了返工积压。在软件开发和管理中，修复不合格（变更）软件所需的全部返工。

对于许多从事软件开发和管理的从业人员而言，主要的分水岭在于所选软件开发生命周期（SDLC）模型的“敏捷”程度。

SDLC模型：执行软件开发生命周期各个阶段的顺序。

主要阶段包括：

● 确定需求

● 设计

● 编码

● 测试

● 运行/使用应用程序。

● 瀑布模型：开发生命周期的每个阶段都按顺序执行，从而一次性交付供使用的整个应用程序。

● 增量模型：在确定了整个应用程序的需求和优先级之后，将应用程序分为几个部分开发（构建）。每次构建都会依次执行开发生命周期的每一个剩余阶段。构建可以（部分）并行开发，并且应用程序按可用的部分交付。

● 迭代或演化模型：在部分确定整个应用程序的需求和优先级之后，在单独的构建（例如增量模型）中开发应用程序。但是由于无法在一开始就完全建立需求，因此设计、编码、测试或构建的使用可能会导致需求的优化，从而导致另一构建版本应用程序的部分优化。

敏捷和Scrum方法是增量和迭代的结合，重点是与应用程序所有者紧密合作，获取快速反馈并实现小增量的快速开发，所有者可以从中获得价值。

Scrum定义：

一种迭代的、有时间限制的产品交付方法，描述为“一个人们可以在解决复杂的适应性问题，并以富有成果和创造力的方式交付具有最高价值的产品的框架”（Ken Schwaber和Jeff Sutherland撰写的《 Scrum指南》，2017年11月更新） ）。

DevOps方法使用持续集成/持续交付之类的技术（部分地）通过自动化部署管道加速从编码到运行/使用的转换，从而进一步提高了吞吐量。

许多敏捷方法都使用“完成的定义”作为工具，在产品或产品增量/待办事项列表认为完成之前约定要满足的一组标准。

• 完成的定义：提议产品或服务的商定标准，反映了功能和非功能要求。

2.3 范围

软件开发和管理的范围包括一组活动，以及影响这些活动的资源。

软件开发和管理实践支持的活动包括：

● 应用开发

● 软件和软件制品管理

● 应用程序运维（与基础架构和平台管理紧密协作）。

软件开发和管理实践范围内的资源是所使用的各种环境中的具体应用程序。主要的应用制品是说明书、设计、源代码、目标代码和文档。

软件开发和管理的职责定位于：

• 确定开发和/或管理要求的应用程序所有者
• 基础架构管理，即（a）提供用于软件开发和管理的环境，以及（b）管理生产环境，软件管理在该生产环境中运维应用程序
• 应用程序使用方面需要支持的用户
• 软件管理组织认为：

● 负责管理应用程序的前期，并涉及应用程序的启用，

● 负责管理应用程序的后续，并涉及应用程序的停用。

软件开发和管理实践没有包括许多密切相关的活动和职责范围。这些活动和职责范围在表2.1中列出，并引用了相关实践。重要的是记住，ITIL实践通过价值流将价值链活动结合并交付价值。

表2.1其他实践指南中描述的相关活动

2.4 实践成功因素

实践成功因素（Practice Success Factor, PSF）

实践为实现其目的所需的复杂功能组件。

实践成功因素不仅仅是一项任务或活动，它包括服务管理所有四个维度的组成部分。在一项实践中，PSFs活动和资源的性质可能有所不同，但这些活动和资源共同确保实践有效。

软件开发和管理实践包括以下PSFs：

● 同意并改进组织开发和管理软件的方法

● 确保软件在整个生命周期中持续满足组织的要求和质量标准

第一个PFS是选择合适的方法，第二个是如何应用合适的方法。

2.4.1 同意并改进组织的软件开发和管理方法

如SLDC模型（2.2）所述，有多种开发和管理软件的方式，如瀑布式、增量式和迭代式（或渐进式）。敏捷和Scrum方法是增量和迭代的结合。

软件开发和管理的前提是有多种方法可供使用，反映了预期发生的各种情况。该战略决策还涉及其他实践，例如架构管理、业务分析、变更实施、发布管理、部署管理、信息安全管理、组合管理、风险管理、服务验证和测试以及战略管理。因此，决策是在应用这些实践的（服务）价值流的上下文中做出的。

软件开发和管理的实践成功因素与战术决策本身有关，即根据组织对产品的需求，从这个预定义的方法集合中选择最适合每个软件产品的方法。

这种战术选择取决于完成工作有多少信息可用以及执行工作所需的资源如何。可以将要完成的工作细分为需求和必须满足的优先级。根据有关需求、优先级和所需资源信息的可用量，选择适当的方法。

示例：

● 当知道需求和优先级、如何开发软件以及需要哪些资源时，瀑布式方法可能是一种有效的选择。

● 在知道需求优先级，但是还不知道如何开发软件以及需要哪些资源时，首先制定最重要工作项的时间盒方法可能是更好的选择。

● 如果对需求和优先级有较高的了解，但是难以最终确定，则线性迭代方法将使产品所有者可以在多次迭代中体验和完善产品。

● 并行实验可以为产品所有者提供原型，帮助他们在需求模棱两可甚至不明确的情况下制定需求。

不同的方法需要不同的资源组合。这些资源涵盖了服务管理的所有四个方面，并在本文档的第3-6部分介绍。

常见的资源组合：

● 小型的、相对独立的、多功能的、基于产品的开发/维护团队，由产品经理管理要完成的工作的优先级

● 基于平台的团队，为开发/维护团队（自行）提供开发/维护和生产所需的基础设施

● 跟踪所有生产制品的版本控制工具（例如代码和文档）

● 用于持续集成和交付/部署软件的自动化流程。

实现此PSF涉及多种实践。来自软件开发和管理的方法要求以组织绩效信息和改进机会的形式呈现。这些转变即改进措施和计划（持续改进）。执行该组织变更管理计划，可以根据要完成的工作（软件开发和管理）的特征应用各种方法和资源。

2.4.2 确保软件在整个生命周期中持续满足组织的要求和质量标准

软件质量用于将软件描述为一种产品及其使用方式，通常使用以下术语：

● 产品质量：功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性和可移植性

● 使用质量：有效性、效率、满意度、无风险和上下文覆盖。

在ISO / IEC 25010：2011标准中，这些特征中的每一个都包含最多六个子特征，帮助指定所需的软件属性。

这些特征也可以视为功能需求（例如，功能适用性和可用性）和功效需求（例如，性能效率和可维护性）。

与软件开发和管理相关的活动影响或受这些特征影响。例如，可维护性在很大程度上取决于源代码的结构和文档编制方式（在自身的维护文档和源代码中均如此）。软件初始开发过程就需要决定要投资多少时间在可维护性方面。这取决于预期的维护量以及投资是否值得。在软件的初始开发过程中，满足了这些要求。因此，最初的开发会影响软件的可维护性。

初步开发后，维护受到软件实现的可维护性的影响。了解软件通常代表一半的维护工作量，因此可维护性会影响维护的速度和成本。

维护不仅受可维护性的影响，而且也会影响可维护性。要么付出努力维护，要么软件的质量会趋于下降（“软件熵”）。这项投资限制了技术债务（修复不合标准的软件变更所需的返工）。

这些软件质量特性的许多要求是软件开发和管理的输入，由软件所有者确定。但是，某些特性不是软件开发和管理的主要关注点。例如，有效性取决于用户对软件的理解以及用户如何使用软件以及软件所支持的信息或设备。

该实践成功因素最重要的组成部分是：

● 了解源代码、各个模块之间的相互关系以及应用程序架构

● 了解使用该应用程序的要求和上下文

● 确保完成的定义中包含非功能性（功效）需求

● 编码前创建测试

● 所有应用程序制品的有效版本控制

● 充分认识到编码的巨大困难并尊重人脑固有的局限性，从而完成编码任务

● 遵守编码约定

● 同行评审

● 来自测试的快速反馈，例如使用自动化测试，并快速采取补救措施。

软件开发和管理不是唯一的实践。要实现此PSF，还需要为软件建立正确的需求（业务分析）、测试软件是否符合这些需求（服务验证和测试）、在生产基础架构上运行软件（基础架构和平台管理）、制定问题报告（问题管理）等。因此，必须在更广泛的范围内注意这些指标。

2.5 关键指标

ITIL实践是用于管理产品和服务的手段或工具。像任何工具的性能一样，实践性能只能在该工具的应用上下文中评估。但是，工具的质量可能有所不同。这种差异定义了工具的潜力或能力。

表2.2实践成功因素的示例指标

3 价值流和流程

3.1 价值流贡献

编辑

像任何其他ITIL管理实践一样，软件开发和管理有助于实现多种价值流。请记住，没有任何价值流是由单一实践组成的。软件开发和管理与其他实践结合，可以为消费者提供高质量的服务。软件开发和管理所贡献的主要价值链活动是：

● 获取/构建

● 交付和支持

图3.1此图显示了软件开发和管理所参与的主要价值链活动。

图3.2编码、构建和运行与服务价值链相对应的获取/构建和交付（和支持）活动

3.2 流程

每种实践可能包括实现该实践目的所必需的一个或多个流程和活动。

流程

将输入转换为输出的一组相互关联或相互作用的活动。流程定义操作的顺序及其依赖关系。

有许多模型可以构建软件开发和管理实践的流程。这些模型跨越几十年，范围从瀑布（例如V模型或Winston W. Royce模型）到迭代和增量模型（例如敏捷方法和螺旋方法）。

服务提供商组织通常会综合各种不同的方法，实现最有效和可管理的可重复过程集。但是，本文可以确定大多数实践方法中通用的一组活动。

表3.1软件开发和管理实践的输入、活动和输出

表3.2建议在传统的瀑布项目环境中以及在以产品为中心的敏捷开发团队中两种不同的实现活动方案

表3.2软件开发和管理实践的活动

4 组织和人员

4.1 角色、能力和责任

实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住：角色并非职位头衔。一个人可以担任多个角色，一个角色也可以分配给多个人员。

在流程和活动的场景中描述角色。每个角色都有一个基于以下模型的能力类型：

4.1.1 参与软件开发和管理活动的角色

表4.1中列出了部署管理活动中可能涉及的角色示例，以及相关的能力类型和特定技能

表4.1部署管理活动中涉及的角色

4.1.2 软件开发人员/团队成员

软件开发和管理实践的关键角色是开发人员或工程师。这是IT领域中最常见的知识工作者类型。算法思维是软件开发人员技能的核心。软件开发人员的核心知识和技能集的其他方面有：

● 编程语言、环境和技术

● 面向对象的软件设计

● 当代系统架构，例如事件驱动架构（EDA）

● 软件测试方式和方法

● 解决问题的技术。

但是，现代软件开发人员需要具有广泛的技术和沟通能力：

● 与他们从事的技术栈相邻的技术知识

● 在控制范围内（无论是自身还是管理的团队）计划和活动优先排序、决策和缓解风险措施的技术

● 人际交往，双向沟通和演讲的技能，包括突出问题，传递思想和观念以及记录和提出解决方案的能力

● 持续学习的能力，可以跟上技术发展的步伐。

软件开发人员还必须维护和具备一些个人特质：

● 愿意在解决问题的过程中快速前进，探索新的可能性，试验并承担合理的风险（参见高速IT OODA循环方法）。

● 渴望回顾已完成的工作，例如错误修复，代码重构，旧版软件维护和技术债任务。

● 系统性地执行运维任务，并展望关于软件运维相关的自动化部署、维护、备份、监视和与其他日常琐事。

● 团队协作的敏捷性，即软件开发人员在团队、产品或项目之间迁移，这在商业和大型服务提供商组织中尤其重要。

4.1.3 软件团队领导

软件开发人员通常经历从初级开发人员（处理低风险的基本任务）到拥有更多特定产品和基础技术经验的高级开发人员的职业发展历程。高级开发人员可以成为其他开发团队成员寻求建议的关键知识投票人 。

高级开发人员的一条职业道路是成为团队领导，俗称“团队领导”角色。团队领导可以在某些组织环境中担任管理职务（尤其是在传统团队中），但首先是为他们的开发人员团队服务的仆人式领导（请阅读有关高速IT的仆人式领导以及创建，交付和支持的更多信息）。

团队领导的主要任务是在广泛的业务或服务提供商范围内与其软件开发团队保持有效联系。除了列出的软件开发人员的技能和行为外，团队领导还应注意以下几点：

● 了解软件正在解决的业务问题

● 了解他们的团队面临的障碍

● 了解开发团队服务提供者上下文和拥有的服务提供者价值流

● 了解将要使用该软件的业务环境

● 了解其他学科，例如管理，产品开发，市场营销等。

● 谈判技术

● 员工激励。

在软件开发和管理组织中，随着控制范围的逐渐扩大，团队领导还具有其他角色，例如技术领导、开发经理等。请参阅下面第4.2节组织结构。

4.1.4 Scrum Master/敏捷教练

Scrum Master是一个口语术语，源于Jeff Sutherland和Ken Schwaber的《 Scrum Guide》（请参阅https://www.scrumguides.org)。该角色通常作为敏捷环境中指导原则的代言人。Scrum Master 确保所有参与人员都遵循敏捷的工作方式。从仆人式领导的纯粹咨询、沟通任务、拆分子集，或管理任务子集，有多种方式实现此目标。在后一种情况下，团队领导自然要承担Scrum Master的责任。

教练的重要性源于以下事实：敏捷方法要求对围绕服务和产品交付方式的习惯和传统进行根本性的改变。教练可以帮助团队成员开发和维持新的行为和态度，并提高团队所有活动成果的可见度。例如，教练是建议进行丰田Kata持续改进实践的基础（请参见3.4.3高速IT）。

需要了解更多有关现代敏捷服务提供商环境、文化转变的信息可参考高速IT（3.高速IT文化）和创建，交付和支持（2.3开发团队文化）中的相关内容。

4.1.5 产品所有者

这是软件开发和管理团队的外部角色，但对成功至关重要。通常在某些敏捷框架中将产品所有者定义为最终对业务结果负责的人。在传统的组织设置中存在项目经理，甚至服务所有者等相似的角色。

可以通过多种方式在服务提供商组织中实现软件开发和管理实践，这些方式包括敏捷框架（例如Scrum）。因此，至关重要的是为开发团队定义一个单独的权限，以便调整工作的优先级或进行外部升级。因此，此角色是在开发团队与服务​​提供商和服务消费者组织这样的部门之间建立正确接口的关键点。

4.2 组织结构和团队

无论是有能力还是有生产力，一个单独的开发团队都无法满足所有对新服务或更新服务的需求。由于团队规模通常是直接根据管理的自然能力定义的，即每位经理管理5至7名员工，因此开发团队的数量是主要的组织变量，决定了软件开发和管理实践中的人力资源投资。

尽管所有的软件开发和管理团队都执行类似的活动，但是可以根据软件产品在服务产品中的相对重要性以及总体组织设计，将它们分为不同的组，例如：

● 软件的目的和功能

● 软件功能

● 运行软件的平台

● 使用的技术的类型或品牌。

产品团队就是一个例子：一个相对独立的、多学科、多任务的开发/管理团队，只要存在应用程序（“产品”）就会存在。这是临时项目团队的替代方案，项目团队为了执行一个项目而组建，然后随着项目结束而解散。与基于项目的方案相比，产品团队工作执行的一致性更高。

到20世纪末，内部和商业IT服务提供商中的应用程序开发和管理部门主要充当独立单元，有时甚至是不同实体的一部分。两者之间的脱节和传统的项目与运行孤岛并无不同。但是，最近这两个部门承受了来自企业更大的压力，要求它们合并在一起响应和合作。DevOps模型可满足此类集成需求，建议开发人员担负确保自动化、易于出错地软件部署和持续运维的责任。

5 信息和技术

5.1 信息交流

有效的信息交流对软件开发和管理实践的成功至关重要。重要的是要注意，每个开发团队很少通过独立行动提供完整的软件产品，而是为服务产品做出贡献。这样的团队取决于其他团队的输出（例如基础架构和平台管理），并产生其他开发团队可能使用的成果（例如可重用的代码库）以及价值流中的下一步步骤（例如质量保证或部署）。

需求、支持请求和事件是软件开发和管理的主要输入，对运行的应用程序的访问和信息是主要输出。

图5.1软件开发与管理输入输出

信息交流清晰可靠很重要，应该设计成既可以在（可能在地理上分布广泛的）团队成员之间，也可以在外部团队之间保持高效。

在软件开发和管理实践中，几乎所有活动的核心都是待办事项列表中一个项目的概念。

根据使用的特定的工具集或方法，这些项目可以使用不同的名称和分类法。分级滚动分组（例如“史诗”或“主题”）可用于同时进行成千上万项目的开发环境中。在某些情况下，性质不同的项目甚至可能具有不同的生命阶段和推进条件。并且，大型开发和以产品为中心的组织可以采用积压的待办列表分发和控制项目流。

但是，通常公认的是，积压项目应以统一的精益方式处理，这与价值流方法的建议非常相似。开发团队应计划工作、寻找瓶颈，并将其活动和信息交流集中在所交付的价值上。

必须提供约定数量的文档以支持：

1. 持续发展
2. 运行
3. 使用

该文档是临时设计文档的补充，临时文档描述了需要创建或修改的内容。

5.2 自动化和工具

与软件相关的活动可从支持它们的信息管理工具中受益。表5.1为每种活动提供了具体工具。

表5.1用于软件开发和管理活动的自动化解决方案

6 合作伙伴和供应商

很少有仅使用组织自己的资源交付的服务。许多组织通常依赖于第三方提供的服务（有关服务关系的模型，请参见ITIL® Foundation：ITIL 4 Edition 2.4节）。

开发团队代表着高度专业化的能力，大多数组织都没有合适的方法管理。当代内部服务提供商通常将软件开发和管理能力外包给第三方。当商业应用程序和其他软件的开发和管理中的一个或两者都是商业采购的时候，服务提供商的管理人员应考虑所有复杂性，同时定义该外部提供商的良好输出必须是什么样子。

在相应的软件采购合同中有几个重要的质量标准需要协商，以达成协议和定义：

• 服务的定义。显而易见，为开发和管理合同准确定义服务交付物绝对必要。此实践中的活动提供了开发团队可以确保软件质量的全部内容。该列表不仅限于简单的新编码和错误修复，还包括整个软件生命周期。各方应自觉地协商范围内的所需活动，并考虑双方的定价和伙伴关系收益，这对双方很重要。

• 人员和组织。各方必须就预期的组织结构、预期的知识转移机制、预期的转换速率、审查原则以及将组成开发团队的员工地理位置达成一致。

• 价值流和流程。各方必须就外部开发团队如何与其他人沟通达成共识。这一点尤其重要，因为在服务提供商内部保留一些开发和管理功能，而外部团队则需要遵守两组控制：供应商组织内部（即他们的雇主）和服务提供商内部的另一组（即客户组织）。可能发生冲突的例子很多：从双重记录保存和积压整理（边界浪费）的简单负担，到可用性计划的复杂性。服务所有者（或敏捷环境中的产品所有者）的工作对于分析外部开发团队对价值流的参与至关重要。

• 信息和技术。各方必须明确定义单一的记录合同目的的系统。如上所述，让开发团队花时间在其“本地”和外部系统中复制缺陷记录没有什么好处。该协议还明确涵盖信息安全方面的考虑和新员工的入职。

可以说，系统的成本效益分析得出的投资效益结果与外部专业开发团队总是比内部团队更“便宜”和“更有效”这样直观的预期完全不同。仅仅由于软件开发的速度和特性，短期内预期的额外收益并不能长期保证。实践中，架构符合用户期望的变化速度可能需要由外部供应商不愿意交付的功能支持。

7 重要提醒

实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：

●聚焦价值

●从你所处的地方开始

●基于反馈迭代推进

●协作和提升可视化程度

●通盘思考和工作

●保持简单实用

●优化和自动化

关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。

8 致谢

AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：

8.1 作者

Mark Smalley，Konstantin Naryzhny

8.2 审阅者

Oleg Skrynnik