学习资料： 艾拓先锋论坛专家讲堂直播 300期视频回放

敏捷与服务管理能够共存吗？

我们身处数字化时代，可以随时随地快速访问数据。互联网和智能手机是这个时代的两大支柱，而客户是主要的受惠者。事实上，世界经济论坛创始人兼首席执行官 Klaus Schwab 早在 2016 年就曾说过：

未来的移动设备将具备前所未有的处理能力、存储容量和知识访问能力，未来全球几十亿人将通过这种移动设备实现互联是有无限可能的。

对于今天的服务提供商来说，需要能够利用此强大功能来交付服务，对不断变化的客户需求做出快速响应，并且在遭遇服务中断时展现出强大适应性，这一点至关重要。而在过去 20 年里，用于软件开发的敏捷方法论已逐渐成为高级服务管理的基础，因为它背后的思维能捕捉对变化的适应性和响应性。

但是，敏捷和服务管理有时是相互冲突的，有些人将它们视为是对立的。敏捷与服务管理能够共存吗？能！让我们来一探究竟。
敏捷和 ITSM 的起源IT 服务管理 (ITSM) 具体是何时兴起目前尚不可考，但是其起源与早期大型主机环境有着内在关联。此处，运营和支持活动涉及的是我们现在所说的 ITSM 流程和实践：

综合归纳服务管理的知识始于 20 世纪 80 年代，当时英国政府创建了 ITIL®，之后它在全球范围内作为相关主题的事实最佳实践框架得到广泛采用。

Microsoft 使用 ITIL 作为创建其专有 Microsoft Operations Framework (MOF) 的基础。之后，其他框架和标准继续扩大在此领域的知识范围，包括：

❖    ISO/IEC 20000

❖    USM

❖    VeriSM

立即下载：《ITIL 4 Foundation》中文精译版，关注微信公众号：ITILXF，并回复“ITIL 4”即可。

敏捷方法则是 17 位软件开发人员 2001 年在美国犹他州 Snowbird 的一次会议上的集体智慧结晶。这群独立的思考者称自己为“敏捷联盟”，想要为文档驱动的重量级软件开发流程寻找一种替代解决方案。

他们这次会议的成果是达成了一份宣言，其中概括了轻量级软件开发方法需要的思想和价值观，它本身包含一系列不同的方法和实践，涉及迭代、重视反馈和客户驱动的多个方面。这些方法主要包括：

❖    Scrum

❖    Kanban

❖    XP

敏捷对比 ITSM随着数字化时代推动软件开发飞速发展，有些人认为 ITSM 不再有用武之地。他们认为，服务管理方法从本质上与敏捷的思想是对立的，特别是考虑到大量实践和流程都源于主机思维，难以实现客户需要的灵活性和响应性。
此外，一些人将敏捷归类为一种开发理念，而将 ITSM 纳入运营范畴。这无一例外地导致了一种两者无法共存的认知。敏捷倡导的是具有适应性且以人为本的方法，而不是强调预测性和以流程为导向，因此就有人认为这一点与 ITSM 是对立的，因为 ITSM 采用的是更加以流程为中心的方法。
但事实是，敏捷与 ITSM 可以产生许多协同增效作用。两者之合力可以大大提升带给企业的价值。

敏捷与 ITSM 结合使用由于 ITSM 源于一个更加结构化的流程方法，没有任何一点表示其实践不能借鉴敏捷思维并通过服务管理中的速度、实验和迭代来提升面向客户的价值交付能力。
采用数字化技术进行开发，意味着旧的流程方法需要加以调整才能适应数字化时代的需求。ITIL 4 和 VeriSM 等较新版本的 ITSM 方法已根据该思维模式进行调整。让我们来了解一下敏捷宣言，看看可以如何将该思维运用到服务管理。
我们重视个体和交互胜过流程和工具比如说，在 ITSM 中，我们收到客户报告的一个事件，并已记录到 ITSM 请求提交工具中。但是事件原因不清楚。那么此时就存在一种风险，即您会看到在一个僵固的工作流中，这个问题在各个孤立的团队间被踢皮球，得不到解决，这就会：
❖    导致问题迟迟无法解决
❖    影响客户满意度
另一种做法是采取诸如 swar** 一类的技术，让不同的团队达成共识，一同找出解决方案，突破工具工作流的桎梏。这意味着各个团队可以：
❖    不必通过一层层的组织渠道沟通。
❖    使用共同的系统，让信息无障碍流通。
同样的思维也可以运用到不同团队间需要公开共享信息的 IT 项目中，拥有不同技能组合的人可以借助提供的论坛共享知识并展开协作，并且有流式组织结构提供支持，不会妨碍合作。这可以创造共享工作区间，让 ITSM 从业者坐到一起工作，无论每个人有何专长。

我们重视可工作的软件胜过详尽的文档计划变革时，ITSM 从业者特别注重大量文档的使用，以试图降低可能的服务中断或降级导致的风险。有时候，即使是简单的改变都要经过严格的更改评估和长时间的 CAB 会议讨论。但是对于满足客户需求，敏捷思维更倾向于快速执行可以产生价值的变更。
为了取得平衡，ITSM 从业者需要逐渐发展一种高效处理各种变更类型的思维，例如：
❖    参考Sprint待办事项获取信息，而不是索取变更请求关联的文档
❖    在变更审查和执行时分别采用同事审查的做法和 CI/CD 技术
这些做法可以加快新的和改进的服务功能的交付速速，这比大量支持文档更受欢迎。同一思维方式也适用于在 ITSM 环境中处理事件和问题。就落实选择的补救措施而言，不用坚持使用详尽的文档，您可以采取更具实验性的改进方法，包括：
❖    采用可提供即时审查和反馈的迭代操作。
❖    然后在解决问题后再形成支持文档。

我们重视客户合作胜过合同谈判客户就是上帝，并且在 ITSM 中，无论是内部用户还是外部客户，工作的重点都必须转换到可以为他们创造的价值。不采用刻板的服务水平协议 (SLA)，此时服务提供商竭尽所能来满足该协议，甚至以牺牲客户利益为代价，现在采用是的是一种协作式方法，即服务提供商在服务管理的各个方面都与用户和合作伙伴通力合作。

以下是重视合作胜过谈判的例子：您可以定期咨询业务用户，明确其优先级和偏好并做出相应调整，而不是维护不考虑环境变化的静态协议和计划。
ITSM 从业者可以基于现有业务关系管理 (BRM) 实践构建其服务交付模型（包括服务和流程），以确保开发出的该模型考虑到利益相关方意见，而不是完全与他们无关。

我们重视响应变化胜过遵循计划如前所述，如果客户反馈要求改变，或者当团队意识到有更好的机会来创造更多的价值时，某种敏捷方法可以做出相应的改变。ITSM 从业者可以借鉴这种思维方式，尝试采取更加灵活的服务管理做法。例如，通过与企业合作，您可以：
❖    早于计划发布新功能
❖    审查并重新确定已计划改进的优先级，以应对业务变化
采用灵活的服务基础架构（特别是通过云环境）还可以促进这种工作模式，因为提高了响应性，消除了僵固性。变革计划也不应设定得太死板，因为万一有关利益相关方担任不同的职位，则必须采取相应部署措施。

服务管理可以敏捷显然，我们务必不能再将敏捷归类为一种只有部分 IT 职能可以使用的单纯开发理念。随着敏捷方法继续在整个企业内得到更广泛的采用，而不仅限于 IT 部门内，服务管理必定可以利用敏捷思维来提升服务交付能力并改进客户服务。（转自[url=]BMC中国）[/url]

学习资料： 艾拓先锋论坛专家讲堂直播 300期视频回放

敏捷与服务管理能够共存吗？

我们身处数字化时代，可以随时随地快速访问数据。互联网和智能手机是这个时代的两大支柱，而客户是主要的受惠者。事实上，世界经济论坛创始人兼首席执行官 Klaus Schwab 早在 2016 年就曾说过：

未来的移动设备将具备前所未有的处理能力、存储容量和知识访问能力，未来全球几十亿人将通过这种移动设备实现互联是有无限可能的。

对于今天的服务提供商来说，需要能够利用此强大功能来交付服务，对不断变化的客户需求做出快速响应，并且在遭遇服务中断时展现出强大适应性，这一点至关重要。而在过去 20 年里，用于软件开发的敏捷方法论已逐渐成为高级服务管理的基础，因为它背后的思维能捕捉对变化的适应性和响应性。

但是，敏捷和服务管理有时是相互冲突的，有些人将它们视为是对立的。敏捷与服务管理能够共存吗？能！让我们来一探究竟。
敏捷和 ITSM 的起源IT 服务管理 (ITSM) 具体是何时兴起目前尚不可考，但是其起源与早期大型主机环境有着内在关联。此处，运营和支持活动涉及的是我们现在所说的 ITSM 流程和实践：

综合归纳服务管理的知识始于 20 世纪 80 年代，当时英国政府创建了 ITIL®，之后它在全球范围内作为相关主题的事实最佳实践框架得到广泛采用。

Microsoft 使用 ITIL 作为创建其专有 Microsoft Operations Framework (MOF) 的基础。之后，其他框架和标准继续扩大在此领域的知识范围，包括：

❖    ISO/IEC 20000

❖    USM

❖    VeriSM

立即下载：《ITIL 4 Foundation》中文精译版，关注微信公众号：ITILXF，并回复“ITIL 4”即可。

敏捷方法则是 17 位软件开发人员 2001 年在美国犹他州 Snowbird 的一次会议上的集体智慧结晶。这群独立的思考者称自己为“敏捷联盟”，想要为文档驱动的重量级软件开发流程寻找一种替代解决方案。

他们这次会议的成果是达成了一份宣言，其中概括了轻量级软件开发方法需要的思想和价值观，它本身包含一系列不同的方法和实践，涉及迭代、重视反馈和客户驱动的多个方面。这些方法主要包括：

❖    Scrum

❖    Kanban

❖    XP

敏捷对比 ITSM随着数字化时代推动软件开发飞速发展，有些人认为 ITSM 不再有用武之地。他们认为，服务管理方法从本质上与敏捷的思想是对立的，特别是考虑到大量实践和流程都源于主机思维，难以实现客户需要的灵活性和响应性。
此外，一些人将敏捷归类为一种开发理念，而将 ITSM 纳入运营范畴。这无一例外地导致了一种两者无法共存的认知。敏捷倡导的是具有适应性且以人为本的方法，而不是强调预测性和以流程为导向，因此就有人认为这一点与 ITSM 是对立的，因为 ITSM 采用的是更加以流程为中心的方法。
但事实是，敏捷与 ITSM 可以产生许多协同增效作用。两者之合力可以大大提升带给企业的价值。

敏捷与 ITSM 结合使用由于 ITSM 源于一个更加结构化的流程方法，没有任何一点表示其实践不能借鉴敏捷思维并通过服务管理中的速度、实验和迭代来提升面向客户的价值交付能力。
采用数字化技术进行开发，意味着旧的流程方法需要加以调整才能适应数字化时代的需求。ITIL 4 和 VeriSM 等较新版本的 ITSM 方法已根据该思维模式进行调整。让我们来了解一下敏捷宣言，看看可以如何将该思维运用到服务管理。
我们重视个体和交互胜过流程和工具比如说，在 ITSM 中，我们收到客户报告的一个事件，并已记录到 ITSM 请求提交工具中。但是事件原因不清楚。那么此时就存在一种风险，即您会看到在一个僵固的工作流中，这个问题在各个孤立的团队间被踢皮球，得不到解决，这就会：
❖    导致问题迟迟无法解决
❖    影响客户满意度
另一种做法是采取诸如 swar** 一类的技术，让不同的团队达成共识，一同找出解决方案，突破工具工作流的桎梏。这意味着各个团队可以：
❖    不必通过一层层的组织渠道沟通。
❖    使用共同的系统，让信息无障碍流通。
同样的思维也可以运用到不同团队间需要公开共享信息的 IT 项目中，拥有不同技能组合的人可以借助提供的论坛共享知识并展开协作，并且有流式组织结构提供支持，不会妨碍合作。这可以创造共享工作区间，让 ITSM 从业者坐到一起工作，无论每个人有何专长。

我们重视可工作的软件胜过详尽的文档计划变革时，ITSM 从业者特别注重大量文档的使用，以试图降低可能的服务中断或降级导致的风险。有时候，即使是简单的改变都要经过严格的更改评估和长时间的 CAB 会议讨论。但是对于满足客户需求，敏捷思维更倾向于快速执行可以产生价值的变更。
为了取得平衡，ITSM 从业者需要逐渐发展一种高效处理各种变更类型的思维，例如：
❖    参考Sprint待办事项获取信息，而不是索取变更请求关联的文档
❖    在变更审查和执行时分别采用同事审查的做法和 CI/CD 技术
这些做法可以加快新的和改进的服务功能的交付速速，这比大量支持文档更受欢迎。同一思维方式也适用于在 ITSM 环境中处理事件和问题。就落实选择的补救措施而言，不用坚持使用详尽的文档，您可以采取更具实验性的改进方法，包括：
❖    采用可提供即时审查和反馈的迭代操作。
❖    然后在解决问题后再形成支持文档。

我们重视客户合作胜过合同谈判客户就是上帝，并且在 ITSM 中，无论是内部用户还是外部客户，工作的重点都必须转换到可以为他们创造的价值。不采用刻板的服务水平协议 (SLA)，此时服务提供商竭尽所能来满足该协议，甚至以牺牲客户利益为代价，现在采用是的是一种协作式方法，即服务提供商在服务管理的各个方面都与用户和合作伙伴通力合作。

以下是重视合作胜过谈判的例子：您可以定期咨询业务用户，明确其优先级和偏好并做出相应调整，而不是维护不考虑环境变化的静态协议和计划。
ITSM 从业者可以基于现有业务关系管理 (BRM) 实践构建其服务交付模型（包括服务和流程），以确保开发出的该模型考虑到利益相关方意见，而不是完全与他们无关。

我们重视响应变化胜过遵循计划如前所述，如果客户反馈要求改变，或者当团队意识到有更好的机会来创造更多的价值时，某种敏捷方法可以做出相应的改变。ITSM 从业者可以借鉴这种思维方式，尝试采取更加灵活的服务管理做法。例如，通过与企业合作，您可以：
❖    早于计划发布新功能
❖    审查并重新确定已计划改进的优先级，以应对业务变化
采用灵活的服务基础架构（特别是通过云环境）还可以促进这种工作模式，因为提高了响应性，消除了僵固性。变革计划也不应设定得太死板，因为万一有关利益相关方担任不同的职位，则必须采取相应部署措施。

服务管理可以敏捷显然，我们务必不能再将敏捷归类为一种只有部分 IT 职能可以使用的单纯开发理念。随着敏捷方法继续在整个企业内得到更广泛的采用，而不仅限于 IT 部门内，服务管理必定可以利用敏捷思维来提升服务交付能力并改进客户服务。（转自[url=]BMC中国）[/url]