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

导航

需要帮助？

如果您需要有关XWiki的帮助，可以联系：

深圳市艾拓先锋企业管理咨询有限公司