Version 10.1 by superadmin on 2021/02/07, 00:36
Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4 (((
5 (% class="wikigeneratedid" id="H5F0059CB96058BFB" %)
6 [[开始阅读>>doc:34 软件开发和管理.1 关于本文件.WebHome]]
7
8
9 需要下载 **ITIL 4软件开发和管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“软件开发和管理”即可。
10
11 [[image:微信截图_20210206234644.png]]
12
13
14 **申明：**
15
16 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
17
18
19 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
20
21
22 **翻译**：冀利斌        **审校**：曾庆东       **审核**：姚凯 
23 )))
24 )))
25
26
27 ----
28
29 = (% style="color:#2d2d2d; font-size:29px" %)**1 关于本文档**(%%) =
30
31 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=1]]
32
33 本文档提供软件开发与管理实践实用指南，分为五个主要部分，涵盖：
34
35 ● 本实践的一般信息
36
37 ● 本实践相关的流程和活动及其在服务价值链中的作用
38
39 ● 参与本实践的组织和人员
40
41 ● 支持本实践的信息和技术
42
43 ● 对本实践的合作伙伴和供应商的考虑
44
45
46 == 1.1 ITIL 4资格认证计划 ==
47
48 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
49
50 本文档中的部分内容可作为以下教学大纲的一部分以供检查：
51
52 ● ITIL专家创建、交付和支持
53
54 ● ITIL专家交付利益干系人价值
55
56 详情请参考各部分教学大纲。
57
58
59 ----
60
61 = **2 一般信息** =
62
63 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=1]]
64
65 == ==
66
67 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=2]]
68
69 == 2.1 目的和描述 ==
70
71 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=3]]
72
73 * **关键信息**
74
75 软件开发和管理实践的目的是确保应用程序在功能、可靠性、可维护性、合规性和可审核性方面满足内部和外部利益相关者的需求。
76
77 软件开发和管理实践侧重于应用软件的开发和管理。但是，许多原则也适用于作为开发和管理应用程序基础架构的软件。软件工程对于基础架构和平台管理越来越重要，例如基础架构即代码的应用这一概念使用机器可读的定义文件管理和配置IT基础架构和平台，而不用物理地配置硬件组件。
78
79 软件开发和管理涵盖应用程序的整个生命周期。这个生命周期可能从几个月到几十年不等，平均为10-15年。从经济角度看，历史上应用程序平均总体拥有成本的20％用于开发而不是管理，而软件管理成本的20％与纠正性维护有关。
80
81 现在应用程序总体拥有成本中的较大部分转移到了开发。由于不断的变更成为应用程序生命周期的组成部分，因此所有的维护活动都可以成为开发的一部分，而且通常不会称为维护。
82
83
84 == 2.2 术语和概念 ==
85
86 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
87
88 **软件**
89
90 告诉计算机的物理组件（硬件）如何工作的一组指令。软件不仅存在于针对最终用户的应用程序中，而且存在于开发和操作应用程序所需的基础架构中。软件和基础架构与其他服务组件或资源组合在一起形成产品和服务的服务组件。
91
92 软件是业务的关键部分：它可以通过技术使能业务服务为客户提供价值。大多数现代服务不再是软件辅助的，而是软件使能的，软件开发变得至关重要。
93
94 **软件开发**
95
96 根据功能和非功能需求对应用程序进行设计和构建，并根据不断变化的功能和非功能需求对运行的应用程序进行修正和改进。
97
98 近年来，外包软件开发服务的趋势发生了逆转，许多组织将关键和战略开发重新纳入内部。这些组织包括银行、保险和零售公司。
99
100 **维护**
101
102 无论是更正还是改进，应用程序的修改是开发的一部分：
103
104 ● 修正：修正应用程序中引发事件的缺陷
105
106 ● 预防：在应用程序中的缺陷显现出来之前进行修补
107
108 ● 适配：使应用程序适应变化的基础架构
109
110 ● 完善：改进应用程序的功能、可用性和性能（有时称为“附加维护”，“改进”或“开发”）。
111
112 随着现代服务发展速度的加快，服务日新月异。现代通常在整个生命周期中应用程序都会修改。这意味着现在用于构成维护的所有活动都成为开发流程的一部分。
113
114 软件管理是一个泛指的术语，指代应用程序策略及规划、运营、应用程序相关制品的安全保障，以及应用系统下线。
115
116 该实践的目的是应用程序应该在功能、可靠性、可维护性、合规性和可审核性方面满足内部和外部利益相关者的需要。提及的所有术语均描述了软件质量。
117
118 **软件质量：软件作为产品并体现其使用价值的条件**
119
120 常见分类（ISO / IEC 25010：2011）为：
121
122 ● 产品质量：功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性和可移植性
123
124 ● 使用质量：有效性、效率、满意度、无风险和上下文覆盖
125
126 快速修复通常比适当但耗时的更改更受欢迎。软件的大量变更可能会导致在某个时间点必须完成大量累积返工，这称为技术债务。
127
128 **技术债：选择替代变通方法而不是系统解决方案需要花费更长的时间，从而导致了返工积压。在软件开发和管理中，修复不合格（变更）软件所需的全部返工。**
129
130 对于许多从事软件开发和管理的从业人员而言，主要的分水岭在于所选软件开发生命周期（SDLC）模型的“敏捷”程度。
131
132 **SDLC模型：执行软件开发生命周期各个阶段的顺序。**
133
134 主要阶段包括：
135
136 ● 确定需求
137
138 ● 设计
139
140 ● 编码
141
142 ● 测试
143
144 ● 运行/使用应用程序。
145
146 ● 瀑布模型：开发生命周期的每个阶段都按顺序执行，从而一次性交付供使用的整个应用程序。
147
148 ● 增量模型：在确定了整个应用程序的需求和优先级之后，将应用程序分为几个部分开发（构建）。每次构建都会依次执行开发生命周期的每一个剩余阶段。构建可以（部分）并行开发，并且应用程序按可用的部分交付。
149
150 ● 迭代或演化模型：在部分确定整个应用程序的需求和优先级之后，在单独的构建（例如增量模型）中开发应用程序。但是由于无法在一开始就完全建立需求，因此设计、编码、测试或构建的使用可能会导致需求的优化，从而导致另一构建版本应用程序的部分优化。
151
152 敏捷和Scrum方法是增量和迭代的结合，重点是与应用程序所有者紧密合作，获取快速反馈并实现小增量的快速开发，所有者可以从中获得价值。
153
154 **Scrum定义：**
155
156 一种迭代的、有时间限制的产品交付方法，描述为“一个人们可以在解决复杂的适应性问题，并以富有成果和创造力的方式交付具有最高价值的产品的框架”（Ken Schwaber和Jeff Sutherland撰写的《 Scrum指南》，2017年11月更新） ）。
157
158 DevOps方法使用持续集成/持续交付之类的技术（部分地）通过自动化部署管道加速从编码到运行/使用的转换，从而进一步提高了吞吐量。
159
160 许多敏捷方法都使用“完成的定义”作为工具，在产品或产品增量/待办事项列表认为完成之前约定要满足的一组标准。
161
162 * **完成的定义：提议产品或服务的商定标准，反映了功能和非功能要求。**
163
164 == 2.3 范围 ==
165
166 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
167
168 软件开发和管理的范围包括一组活动，以及影响这些活动的资源。
169
170 软件开发和管理实践支持的活动包括：
171
172 ● 应用开发
173
174 ● 软件和软件制品管理
175
176 ● 应用程序运维（与基础架构和平台管理紧密协作）。
177
178 软件开发和管理实践范围内的资源是所使用的各种环境中的具体应用程序。主要的应用制品是说明书、设计、源代码、目标代码和文档。
179
180 软件开发和管理的职责定位于：
181
182 * 确定开发和/或管理要求的应用程序所有者
183 * 基础架构管理，即（a）提供用于软件开发和管理的环境，以及（b）管理生产环境，软件管理在该生产环境中运维应用程序
184 * 应用程序使用方面需要支持的用户
185 * 软件管理组织认为：
186
187 ● 负责管理应用程序的前期，并涉及应用程序的启用，
188
189 ● 负责管理应用程序的后续，并涉及应用程序的停用。
190
191 软件开发和管理实践没有包括许多密切相关的活动和职责范围。这些活动和职责范围在表2.1中列出，并引用了相关实践。重要的是记住，ITIL实践通过价值流将价值链活动结合并交付价值。
192
193 |**活动**|**实践指导**
194 |软件架构|架构管理
195 |功能和功效需求|业务分析
196 |应用程序制品从一个环境部署到另外的环境|部署管理
197 |提供用户反馈接口|服务台
198 |应用程序组合管理|组合管理
199 |使应用程序可用并可供用户使用|发布管理
200 |(((
201 验证应用程序是否符合要求
202
203 测试潜在的可发布应用
204 )))|服务验证和测试
205 |编排应用程序的整体设计|服务设计
206 |应用监控|监控和事态管理
207
208 表2.1其他实践指南中描述的相关活动
209
210
211 == 2.4 实践成功因素 ==
212
213 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
214
215 **实践成功因素（Practice Success Factor, PSF）**
216
217 实践为实现其目的所需的复杂功能组件。
218
219 实践成功因素不仅仅是一项任务或活动，它包括服务管理所有四个维度的组成部分。在一项实践中，PSFs活动和资源的性质可能有所不同，但这些活动和资源共同确保实践有效。
220
221 软件开发和管理实践包括以下PSFs：
222
223 ● 同意并改进组织开发和管理软件的方法
224
225 ● 确保软件在整个生命周期中持续满足组织的要求和质量标准
226
227 第一个PFS是选择合适的方法，第二个是如何应用合适的方法。
228
229
230 === 2.4.1 同意并改进组织的软件开发和管理方法 ===
231
232 如SLDC模型（2.2）所述，有多种开发和管理软件的方式，如瀑布式、增量式和迭代式（或渐进式）。敏捷和Scrum方法是增量和迭代的结合。
233
234 软件开发和管理的前提是有多种方法可供使用，反映了预期发生的各种情况。该战略决策还涉及其他实践，例如架构管理、业务分析、变更实施、发布管理、部署管理、信息安全管理、组合管理、风险管理、服务验证和测试以及战略管理。因此，决策是在应用这些实践的（服务）价值流的上下文中做出的。
235
236 软件开发和管理的实践成功因素与战术决策本身有关，即根据组织对产品的需求，从这个预定义的方法集合中选择最适合每个软件产品的方法。
237
238 这种战术选择取决于完成工作有多少信息可用以及执行工作所需的资源如何。可以将要完成的工作细分为需求和必须满足的优先级。根据有关需求、优先级和所需资源信息的可用量，选择适当的方法。
239
240 示例：
241
242 ● 当知道需求和优先级、如何开发软件以及需要哪些资源时，瀑布式方法可能是一种有效的选择。
243
244 ● 在知道需求优先级，但是还不知道如何开发软件以及需要哪些资源时，首先制定最重要工作项的时间盒方法可能是更好的选择。
245
246 ● 如果对需求和优先级有较高的了解，但是难以最终确定，则线性迭代方法将使产品所有者可以在多次迭代中体验和完善产品。
247
248 ● 并行实验可以为产品所有者提供原型，帮助他们在需求模棱两可甚至不明确的情况下制定需求。
249
250 不同的方法需要不同的资源组合。这些资源涵盖了服务管理的所有四个方面，并在本文档的第3-6部分介绍。
251
252 常见的资源组合：
253
254 ● 小型的、相对独立的、多功能的、基于产品的开发/维护团队，由产品经理管理要完成的工作的优先级
255
256 ● 基于平台的团队，为开发/维护团队（自行）提供开发/维护和生产所需的基础设施
257
258 ● 跟踪所有生产制品的版本控制工具（例如代码和文档）
259
260 ● 用于持续集成和交付/部署软件的自动化流程。
261
262 实现此PSF涉及多种实践。来自软件开发和管理的方法要求以组织绩效信息和改进机会的形式呈现。这些转变即改进措施和计划（持续改进）。执行该组织变更管理计划，可以根据要完成的工作（软件开发和管理）的特征应用各种方法和资源。
263
264
265 === 2.4.2 确保软件在整个生命周期中持续满足组织的要求和质量标准 ===
266
267 软件质量用于将软件描述为一种产品及其使用方式，通常使用以下术语：
268
269 ● 产品质量：功能适用性、性能效率、兼容性、可用性、可靠性、安全性、可维护性和可移植性
270
271 ● 使用质量：有效性、效率、满意度、无风险和上下文覆盖。
272
273 在ISO / IEC 25010：2011标准中，这些特征中的每一个都包含最多六个子特征，帮助指定所需的软件属性。
274
275 这些特征也可以视为功能需求（例如，功能适用性和可用性）和功效需求（例如，性能效率和可维护性）。
276
277 与软件开发和管理相关的活动影响或受这些特征影响。例如，可维护性在很大程度上取决于源代码的结构和文档编制方式（在自身的维护文档和源代码中均如此）。软件初始开发过程就需要决定要投资多少时间在可维护性方面。这取决于预期的维护量以及投资是否值得。在软件的初始开发过程中，满足了这些要求。因此，最初的开发会影响软件的可维护性。
278
279 初步开发后，维护受到软件实现的可维护性的影响。了解软件通常代表一半的维护工作量，因此可维护性会影响维护的速度和成本。
280
281 维护不仅受可维护性的影响，而且也会影响可维护性。要么付出努力维护，要么软件的质量会趋于下降（“软件熵”）。这项投资限制了技术债务（修复不合标准的软件变更所需的返工）。
282
283 这些软件质量特性的许多要求是软件开发和管理的输入，由软件所有者确定。但是，某些特性不是软件开发和管理的主要关注点。例如，有效性取决于用户对软件的理解以及用户如何使用软件以及软件所支持的信息或设备。
284
285 该实践成功因素最重要的组成部分是：
286
287 ● 了解源代码、各个模块之间的相互关系以及应用程序架构
288
289 ● 了解使用该应用程序的要求和上下文
290
291 ● 确保完成的定义中包含非功能性（功效）需求
292
293 ● 编码前创建测试
294
295 ● 所有应用程序制品的有效版本控制
296
297 ● 充分认识到编码的巨大困难并尊重人脑固有的局限性，从而完成编码任务
298
299 ● 遵守编码约定
300
301 ● 同行评审
302
303 ● 来自测试的快速反馈，例如使用自动化测试，并快速采取补救措施。
304
305 软件开发和管理不是唯一的实践。要实现此PSF，还需要为软件建立正确的需求（业务分析）、测试软件是否符合这些需求（服务验证和测试）、在生产基础架构上运行软件（基础架构和平台管理）、制定问题报告（问题管理）等。因此，必须在更广泛的范围内注意这些指标。
306
307
308 == 2.5 关键指标 ==
309
310 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
311
312 ITIL实践是用于管理产品和服务的手段或工具。像任何工具的性能一样，实践性能只能在该工具的应用上下文中评估。但是，工具的质量可能有所不同。这种差异定义了工具的潜力或能力。
313
314 |实践成功因素|示例指标
315 |同意并改进组织的软件开发和管理方法|(((
316 ● 对为软件开发和管理选择的方法利益相关者的满意度
317
318 ● 遵循所选方法的开发团队所占百分比
319
320 ● 对所选方法获准的变更效率利益相关者的满意度
321
322 ● 软件开发和管理实践的改进措施吞吐量
323
324 ● 内部和外部要求、政策和法规的遵循程序。
325 )))
326 |确保软件在整个生命周期中持续满足组织的要求和质量标准|(((
327 ● 对提供价值的应用程序利益相关者的满意度
328
329 ● 应用程序符合内部和外部要求和政策程度
330
331 ● 软件交付频率（用于新功能或更改功能）
332
333 ● 软件交付的速度（从收到规格说明书到提交代码到存储库并发布以进行部署）
334
335 ● 软件交付的可靠性（发布并部署后发现的缺陷）
336
337 ● 成本（每个功能点或其他大小单位；降低的成本）
338
339 ● 技术债务（修正不合格（变更）软件的返工估计成本）
340
341 ● 资源利用率（计算、网络、存储）
342
343 ● 软件的可用性（MTTR、MBTF）
344
345 ● 安全漏洞和与审核相关的成本等
346 )))
347
348 表2.2实践成功因素的示例指标
349
350
351
352 ----
353
354 = **3 价值流和流程** =
355
356 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=1]]
357
358 == ==
359
360 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=2]]
361
362 == 3.1 价值流贡献 ==
363
364 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=3]]
365
366 像任何其他ITIL管理实践一样，软件开发和管理有助于实现多种价值流。请记住，没有任何价值流是由单一实践组成的。软件开发和管理与其他实践结合，可以为消费者提供高质量的服务。软件开发和管理所贡献的主要价值链活动是：
367
368 ● 获取/构建
369
370 ● 交付和支持
371
372 (% style="text-align:center" %)
373 [[image:http://itil4hub.cn/bin/download/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/image-20200923163503-1.png?width=637&height=425&rev=1.1||alt="image-20200923163503-1.png" height="425" width="637"]]
374
375 图3.1此图显示了软件开发和管理所参与的主要价值链活动。
376
377
378 (% style="text-align:center" %)
379 [[image:http://itil4hub.cn/bin/download/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome/image-20200923163503-2.png?width=563&height=496&rev=1.1||alt="image-20200923163503-2.png" height="496" width="563"]]
380
381 图3.2编码、构建和运行与服务价值链相对应的获取/构建和交付（和支持）活动
382
383
384 == 3.2 流程 ==
385
386 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/3%20%E4%BB%B7%E5%80%BC%E6%B5%81%E5%92%8C%E6%B5%81%E7%A8%8B/WebHome?section=4]]
387
388 每种实践可能包括实现该实践目的所必需的一个或多个流程和活动。
389
390 **流程**
391
392 将输入转换为输出的一组相互关联或相互作用的活动。流程定义操作的顺序及其依赖关系。
393
394 有许多模型可以构建软件开发和管理实践的流程。这些模型跨越几十年，范围从瀑布（例如V模型或Winston W. Royce模型）到迭代和增量模型（例如敏捷方法和螺旋方法）。
395
396 服务提供商组织通常会综合各种不同的方法，实现最有效和可管理的可重复过程集。但是，本文可以确定大多数实践方法中通用的一组活动。
397
398 |输入|活动项目|输出
399 |(((
400 业务案例、业务逻辑需求、服务模型、架构文档、用户故事、任务、现有积压和项目计划中的缺陷
401
402 相关积压\项目项
403
404 现有环境配置
405
406 现有的开发工具集和版本跟踪方法
407
408 用户对应用程序的反馈
409
410 应用程序开发的技术标准。
411 )))|(((
412 产品计划和优先级
413
414 软件设计
415
416 新代码制作
417
418 代码评审
419
420 缺陷处理
421
422 技术债务管理
423
424 代码重构
425
426 研究与开发
427
428 定期会议和改进活动
429
430 软件运维自动化
431
432 管理开发环境
433
434 版本控制。
435 )))|(((
436 新的积压/项目任务、项目或变更交付计划
437
438 新软件或更改软件的技术要求。
439
440 应用程序代码、测试用例、自动化单元测试
441
442 更新的代码、新的待办事项
443
444 会议议程、会议记录、时间表、会议记录、决定和新规则、行动计划
445
446 软件管道、监控和维护自动化工具
447
448 更新的开发环境配置
449
450 准备部署的新版本、保留软件变更记录
451
452 对新的/提议的变更架构决策
453
454 有关软件价值的信息
455
456 有关正在开发的软件的发行说明：技术文档和用户文档（如何使用，安装，配置）、管理文档（如何管理）
457
458 新的/提议的变更的技术标准
459 )))
460
461 表3.1软件开发和管理实践的输入、活动和输出
462
463
464 表3.2建议在传统的瀑布项目环境中以及在以产品为中心的敏捷开发团队中两种不同的实现活动方案
465
466 |活动|项目管理实例|产品管理实例
467 |产品计划和优先级|请求者向相关项目经理或开发团队领导提交新的一批工作。|产品负责人收集新的外部需求，包括发现的积压缺陷，并可能与开发团队一起从积压中选择要在下一个迭代中交付的的任务。
468 |软件设计|开发人员或分析人员根据业务逻辑文档提供要在软件中实现的技术代码要求。|基于软件的详细信息和编码约定，可以直接在代码中构建技术规范和算法描述，无需单独提供的文件。
469 |新代码制作|软件开发人员将软件代码与单元测试一起提供，并确保单元测试通过完成。然后提交代码进行测试并验证和批准。|软件开发人员提供软件代码，并确保单元测试通过完成。然后提交用于自动化或手动测试的代码。
470 |缺陷处理|软件开发人员分析缺陷任务以验证缺陷。向项目管理人员提出项目问题，确保计划用于修复缺陷的资源，并修改相应的软件代码。|软件开发人员分析缺陷任务以验证缺陷。然后，修改软件代码以修复缺陷。
471 |减轻技术债务|(% colspan="2" %)软件开发人员分析技术债务任务并修改软件代码或架构。
472 |代码审查|(% colspan="2" %)软件开发人员通过查看或阅读代码检查代码。最好至少有一位不是代码作者的审阅人。
473 |代码重构|(% colspan="2" %)(((
474 重构是在不改变其外部行为的情况下重新构建源代码，旨在提高可维护性，效率等。
475
476 软件开发人员分析代码重构任务，然后相应地修改软件代码或架构。
477 )))
478 |研发|(% colspan="2" %)软件开发人员分析积压的研发任务，并提出新的任务，将任务添加到积压中。
479 |定期会议和改善活动|软件开发人员或开发团队领导参与项目沟通，并与其他项目团队交互，确保及时交换信息以及风险、问题管理。|开发团队执行定期迭代评估，例如：确保任务的有效进展，计划下一阶段的工作，并强调障碍。
480 |软件运维自动化|在实施项目期间，软件开发人员会提供一个工具集，以使软件的运行自动化，例如诊断收集、弹性增强、监视和警报系统、例行维护等。软件开发人员在软件运行的同事，维护并演进工具集。|软件开发人员通过开发和演进操作工具集的方式，优化操作软件​​所需的人力资源投入。
481 |管理开发环境|(% colspan="2" %)开发团队领导确保开发环境配置已提供给开发团队。
482 |版本控制|(% colspan="2" %)开发团队领导实施版本控制规则和工具集，确保团队成员之间一致的代码跟踪。
483
484 表3.2软件开发和管理实践的活动
485
486
487
488 ----
489
490 = **4 组织和人员** =
491
492 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=1]]
493
494 == ==
495
496 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=2]]
497
498 == 4.1 角色、能力和责任 ==
499
500 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=3]]
501
502 实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定于每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住：角色并非职位头衔。一个人可以担任多个角色，一个角色也可以分配给多个人员。
503
504 在流程和活动的场景中描述角色。每个角色都有一个基于以下模型的能力类型：
505
506 |能力代码|描述
507 |L|**领导Leader** 决策、授权、监督其他活动，提供激励和动力，并评估结果
508 |А|**管理员Administrator** 分配任务并确定优先级，保持记录，持续报告，并启动基本改进
509 |C|**协调者/沟通者Coordnator/Communicator** 协调多方，维护利益相关者之间的沟通，并开展宣传活动
510 |М|**方法和技巧专家Methods and techniques expert** 设计和实施工作技巧、记录步骤 、过程咨询、工作分析和持续改进
511 |Т|**技术专家Technical expert **提供技术（IT）专业知识并执行基于专家经验的作业
512
513 === ===
514
515 === 4.1.1 参与软件开发和管理活动的角色 ===
516
517
518 表4.1中列出了部署管理活动中可能涉及的角色示例，以及相关的能力类型和特定技能
519
520 |活动|(((
521 负责角色
522
523 （示例）
524 )))|能力概况|具体技能
525 |产品计划和优先级|(((
526 项目经理
527
528 产品所有者
529 )))|CMLT|(((
530 熟悉业务目标
531
532 熟练掌握项目管理实践和其他相关交付方法
533 )))
534 |软件设计|(((
535 业务分析师
536
537 或
538
539 软件开发人员
540 )))|TM|特定软件的技术开发和分析工具
541 |新代码制作|软件开发人员|TM|特定软件的技术开发和分析工具
542 |缺陷处理|软件开发人员|TM|特定软件的技术开发和分析工具
543 |减轻技术债务|软件开发人员|TM|特定软件的技术开发和分析工具
544 |代码审查|软件开发人员|TM|特定软件的技术开发和分析工具
545 |代码重构|软件开发人员|TM|特定软件的技术开发和分析工具
546 |研究与开发|软件开发人员|TMC|特定软件的技术开发和分析工具
547 |定期会议和改进活动|软件开发团队负责人、产品所有者、软件开发人员、业务分析师、测试工程师，Scrum大师|CLT|特定软件的技术开发和分析工具
548 |软件运维自动化|软件开发人员|MTC|(((
549 特定软件的技术开发和分析工具
550
551 对软件运行以及运维软件所需的手动活动的本质的理解
552 )))
553 |管理开发环境|软件开发团队领导，软件开发人员、基础架构工程师|MTC|熟悉受控环境配置
554 |版本控制|软件开发团队负责人、软件开发人员|MTC|熟悉软件版本跟踪方法
555
556 表4.1部署管理活动中涉及的角色
557
558
559 === 4.1.2 软件开发人员/团队成员 ===
560
561 软件开发和管理实践的关键角色是开发人员或工程师。这是IT领域中最常见的知识工作者类型。算法思维是软件开发人员技能的核心。软件开发人员的核心知识和技能集的其他方面有：
562
563 ● 编程语言、环境和技术
564
565 ● 面向对象的软件设计
566
567 ● 当代系统架构，例如事件驱动架构（EDA）
568
569 ● 软件测试方式和方法
570
571 ● 解决问题的技术。
572
573 但是，现代软件开发人员需要具有广泛的技术和沟通能力：
574
575 ● 与他们从事的技术栈相邻的技术知识
576
577 ● 在控制范围内（无论是自身还是管理的团队）计划和活动优先排序、决策和缓解风险措施的技术
578
579 ● 人际交往，双向沟通和演讲的技能，包括突出问题，传递思想和观念以及记录和提出解决方案的能力
580
581 ● 持续学习的能力，可以跟上技术发展的步伐。
582
583 软件开发人员还必须维护和具备一些个人特质：
584
585 ● 愿意在解决问题的过程中快速前进，探索新的可能性，试验并承担合理的风险（参见高速IT OODA循环方法）。
586
587 ● 渴望回顾已完成的工作，例如错误修复，代码重构，旧版软件维护和技术债任务。
588
589 ● 系统性地执行运维任务，并展望关于软件运维相关的自动化部署、维护、备份、监视和与其他日常琐事。
590
591 ● 团队协作的敏捷性，即软件开发人员在团队、产品或项目之间迁移，这在商业和大型服务提供商组织中尤其重要。
592
593
594 === 4.1.3 软件团队领导 ===
595
596 软件开发人员通常经历从初级开发人员（处理低风险的基本任务）到拥有更多特定产品和基础技术经验的高级开发人员的职业发展历程。高级开发人员可以成为其他开发团队成员寻求建议的关键知识投票人 。
597
598 高级开发人员的一条职业道路是成为团队领导，俗称“团队领导”角色。团队领导可以在某些组织环境中担任管理职务（尤其是在传统团队中），但首先是为他们的开发人员团队服务的仆人式领导（请阅读有关高速IT的仆人式领导以及创建，交付和支持的更多信息）。
599
600 团队领导的主要任务是在广泛的业务或服务提供商范围内与其软件开发团队保持有效联系。除了列出的软件开发人员的技能和行为外，团队领导还应注意以下几点：
601
602 ● 了解软件正在解决的业务问题
603
604 ● 了解他们的团队面临的障碍
605
606 ● 了解开发团队服务提供者上下文和拥有的服务提供者价值流
607
608 ● 了解将要使用该软件的业务环境
609
610 ● 了解其他学科，例如管理，产品开发，市场营销等。
611
612 ● 谈判技术
613
614 ● 员工激励。
615
616 在软件开发和管理组织中，随着控制范围的逐渐扩大，团队领导还具有其他角色，例如技术领导、开发经理等。请参阅下面第4.2节组织结构。
617
618
619 === 4.1.4 Scrum Master/敏捷教练 ===
620
621 Scrum Master是一个口语术语，源于Jeff Sutherland和Ken Schwaber的《 Scrum Guide》（请参阅[[https:~~/~~/www.scrumguides.org>>url:https://www.scrumguides.org/]])。该角色通常作为敏捷环境中指导原则的代言人。Scrum Master 确保所有参与人员都遵循敏捷的工作方式。从仆人式领导的纯粹咨询、沟通任务、拆分子集，或管理任务子集，有多种方式实现此目标。在后一种情况下，团队领导自然要承担Scrum Master的责任。
622
623 教练的重要性源于以下事实：敏捷方法要求对围绕服务和产品交付方式的习惯和传统进行根本性的改变。教练可以帮助团队成员开发和维持新的行为和态度，并提高团队所有活动成果的可见度。例如，教练是建议进行丰田Kata持续改进实践的基础（请参见3.4.3高速IT）。
624
625 需要了解更多有关现代敏捷服务提供商环境、文化转变的信息可参考高速IT（3.高速IT文化）和创建，交付和支持（2.3开发团队文化）中的相关内容。
626
627
628 === 4.1.5 产品所有者 ===
629
630 这是软件开发和管理团队的外部角色，但对成功至关重要。通常在某些敏捷框架中将产品所有者定义为最终对业务结果负责的人。在传统的组织设置中存在项目经理，甚至服务所有者等相似的角色。
631
632 可以通过多种方式在服务提供商组织中实现软件开发和管理实践，这些方式包括敏捷框架（例如Scrum）。因此，至关重要的是为开发团队定义一个单独的权限，以便调整工作的优先级或进行外部升级。因此，此角色是在开发团队与服务​​提供商和服务消费者组织这样的部门之间建立正确接口的关键点。
633
634
635 == 4.2 组织结构和团队 ==
636
637 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/4%20%E7%BB%84%E7%BB%87%E5%92%8C%E4%BA%BA%E5%91%98/WebHome?section=4]]
638
639 无论是有能力还是有生产力，一个单独的开发团队都无法满足所有对新服务或更新服务的需求。由于团队规模通常是直接根据管理的自然能力定义的，即每位经理管理5至7名员工，因此开发团队的数量是主要的组织变量，决定了软件开发和管理实践中的人力资源投资。
640
641 尽管所有的软件开发和管理团队都执行类似的活动，但是可以根据软件产品在服务产品中的相对重要性以及总体组织设计，将它们分为不同的组，例如：
642
643 ● 软件的目的和功能
644
645 ● 软件功能
646
647 ● 运行软件的平台
648
649 ● 使用的技术的类型或品牌。
650
651 产品团队就是一个例子：一个相对独立的、多学科、多任务的开发/管理团队，只要存在应用程序（“产品”）就会存在。这是临时项目团队的替代方案，项目团队为了执行一个项目而组建，然后随着项目结束而解散。与基于项目的方案相比，产品团队工作执行的一致性更高。
652
653 到20世纪末，内部和商业IT服务提供商中的应用程序开发和管理部门主要充当独立单元，有时甚至是不同实体的一部分。两者之间的脱节和传统的项目与运行孤岛并无不同。但是，最近这两个部门承受了来自企业更大的压力，要求它们合并在一起响应和合作。DevOps模型可满足此类集成需求，建议开发人员担负确保自动化、易于出错地软件部署和持续运维的责任。
654
655
656
657 ----
658
659 = **5 信息和技术** =
660
661 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=1]]
662
663 == ==
664
665 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=2]]
666
667 == 5.1 信息交流 ==
668
669 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=3]]
670
671 有效的信息交流对软件开发和管理实践的成功至关重要。重要的是要注意，每个开发团队很少通过独立行动提供完整的软件产品，而是为服务产品做出贡献。这样的团队取决于其他团队的输出（例如基础架构和平台管理），并产生其他开发团队可能使用的成果（例如可重用的代码库）以及价值流中的下一步步骤（例如质量保证或部署）。
672
673 需求、支持请求和事件是软件开发和管理的主要输入，对运行的应用程序的访问和信息是主要输出。
674
675 (% style="text-align:center" %)
676 [[image:http://itil4hub.cn/bin/download/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome/1600850663107-918.png?rev=1.1||alt="1600850663107-918.png"]]
677
678 图5.1软件开发与管理输入输出
679
680
681 信息交流清晰可靠很重要，应该设计成既可以在（可能在地理上分布广泛的）团队成员之间，也可以在外部团队之间保持高效。
682
683 在软件开发和管理实践中，几乎所有活动的核心都是待办事项列表中一个项目的概念。
684
685 根据使用的特定的工具集或方法，这些项目可以使用不同的名称和分类法。分级滚动分组（例如“史诗”或“主题”）可用于同时进行成千上万项目的开发环境中。在某些情况下，性质不同的项目甚至可能具有不同的生命阶段和推进条件。并且，大型开发和以产品为中心的组织可以采用积压的待办列表分发和控制项目流。
686
687 但是，通常公认的是，积压项目应以统一的精益方式处理，这与价值流方法的建议非常相似。开发团队应计划工作、寻找瓶颈，并将其活动和信息交流集中在所交付的价值上。
688
689 必须提供约定数量的文档以支持：
690
691 1. 持续发展
692 1. 运行
693 1. 使用
694
695 该文档是临时设计文档的补充，临时文档描述了需要创建或修改的内容。
696
697
698 == 5.2 自动化和工具 ==
699
700 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/5%20%E4%BF%A1%E6%81%AF%E5%92%8C%E6%8A%80%E6%9C%AF/WebHome?section=4]]
701
702 与软件相关的活动可从支持它们的信息管理工具中受益。表5.1为每种活动提供了具体工具。
703
704 |活动|自动化手段|关键功能|对实践的影响
705 |产品计划和优先级|(((
706 任务和工作流跟踪工具集
707
708 项目管理工具集
709 )))|工作安排和可视化|高
710 |软件设计|开发工具集，开发环境|协作和自动化设计|高
711 |新代码制作|开发工具集，开发环境|代码管理|高
712 |代码审查|开发工具集，开发环境|代码管理|高
713 |缺陷处理|开发工具集，开发环境|代码管理|高
714 |减轻技术债务|工作流和任务跟踪系统，已知错误数据库，开发工具集，开发环境|代码管理|高
715 |代码重构|开发工具集，开发环境|代码管理|高
716 |研发|开发工具集，开发环境|代码管理|高
717 |定期会议和改进活动|开发工具集，开发环境|协作和调度；保持记录|中
718 |软件运维自动化|远程管理工具，配置管理工具，自动化部署系统，开发工具集，开发环境|脚本化任务自动化和调度，基础架构编排|高
719 |管理开发环境|配置管理工具集，开发环境|基础架构编排|高
720 |版本控制|开发工具集，开发环境|代码仓库管理|高
721
722 表5.1用于软件开发和管理活动的自动化解决方案
723
724
725
726 ----
727
728 = **6 合作伙伴和供应商** =
729
730 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/6%20%E5%90%88%E4%BD%9C%E4%BC%99%E4%BC%B4%E5%92%8C%E4%BE%9B%E5%BA%94%E5%95%86/WebHome?section=1]]
731
732 很少有仅使用组织自己的资源交付的服务。许多组织通常依赖于第三方提供的服务（有关服务关系的模型，请参见ITIL® Foundation：ITIL 4 Edition 2.4节）。
733
734 开发团队代表着高度专业化的能力，大多数组织都没有合适的方法管理。当代内部服务提供商通常将软件开发和管理能力外包给第三方。当商业应用程序和其他软件的开发和管理中的一个或两者都是商业采购的时候，服务提供商的管理人员应考虑所有复杂性，同时定义该外部提供商的良好输出必须是什么样子。
735
736 在相应的软件采购合同中有几个重要的质量标准需要协商，以达成协议和定义：
737
738 * 服务的定义。显而易见，为开发和管理合同准确定义服务交付物绝对必要。此实践中的活动提供了开发团队可以确保软件质量的全部内容。该列表不仅限于简单的新编码和错误修复，还包括整个软件生命周期。各方应自觉地协商范围内的所需活动，并考虑双方的定价和伙伴关系收益，这对双方很重要。
739
740 * 人员和组织。各方必须就预期的组织结构、预期的知识转移机制、预期的转换速率、审查原则以及将组成开发团队的员工地理位置达成一致。
741
742 * 价值流和流程。各方必须就外部开发团队如何与其他人沟通达成共识。这一点尤其重要，因为在服务提供商内部保留一些开发和管理功能，而外部团队则需要遵守两组控制：供应商组织内部（即他们的雇主）和服务提供商内部的另一组（即客户组织）。可能发生冲突的例子很多：从双重记录保存和积压整理（边界浪费）的简单负担，到可用性计划的复杂性。服务所有者（或敏捷环境中的产品所有者）的工作对于分析外部开发团队对价值流的参与至关重要。
743
744 * 信息和技术。各方必须明确定义单一的记录合同目的的系统。如上所述，让开发团队花时间在其“本地”和外部系统中复制缺陷记录没有什么好处。该协议还明确涵盖信息安全方面的考虑和新员工的入职。
745
746 可以说，系统的成本效益分析得出的投资效益结果与外部专业开发团队总是比内部团队更“便宜”和“更有效”这样直观的预期完全不同。仅仅由于软件开发的速度和特性，短期内预期的额外收益并不能长期保证。实践中，架构符合用户期望的变化速度可能需要由外部供应商不愿意交付的功能支持。
747
748
749
750 ----
751
752 = **7 重要提醒** =
753
754 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/7%20%E9%87%8D%E8%A6%81%E6%8F%90%E9%86%92/WebHome?section=1]]
755
756 实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
757
758 ●聚焦价值
759
760 ●从你所处的地方开始
761
762 ●基于反馈迭代推进
763
764 ●协作和提升可视化程度
765
766 ●通盘思考和工作
767
768 ●保持简单实用
769
770 ●优化和自动化
771
772 关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
773
774
775
776 ----
777
778 = **8 致谢** =
779
780 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=1]]
781
782 AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
783
784
785 == 8.1 作者 ==
786
787 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=2]]
788
789 Mark Smalley，Konstantin Naryzhny
790
791
792 == 8.2 审阅者 ==
793
794 [[编辑>>url:http://itil4hub.cn/bin/edit/34%20%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E5%92%8C%E7%AE%A1%E7%90%86/8%20%E8%87%B4%E8%B0%A2/WebHome?section=3]]
795
796 Oleg Skrynnik
797
798
799 (% class="row" %)
800 (((
801 (% class="col-xs-12 col-sm-4" %)
802 (((
803
804 )))
805 )))
深圳市艾拓先锋企业管理咨询有限公司