返回本章节索引       阅读下一部分

一听到“敏捷”，大部分 IT 从业人员，都会马上联想到“软件开发”，并回想起 2001 年发布的《敏捷宣言》。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发过程中，软件项目的构建被切分成多个子项目——有点类似 PMBOK 中的“工作包”，各子项目成果均通过测试，具备集成和可运行的特性。简而言之，就是把一个大项目分为多个关联但可独立运行的小项目，并分别完成， 在此过程中软件一直处于可用状态。目前敏捷软件开发方法已被许多公司和软件团队采用，并且在许多情况下已被证明是有效的。

图4-9 敏捷开发路线图

与敏捷开发相关的概念非常多，包括测试驱动开发、持续集成、重构、结对编程、每日站会、小版本发布、自动化测试。敏捷软件开发通常包括：

• 通过反馈分析和直接观察收集不断变化的需求；

• 将开发工作分成小的增量和迭代；

• 建立基于产品的跨职能团队；

• 直观地呈现（看板）并定期讨论（每日站会）工作进度；

• 在每次迭代结束时向利益相关者展示一份（至少是最低可行性）软件——一般称为“MVP”， 最小化可行产品。

而在 ITIL 4 的教材中通篇可见“敏捷”，从侧面反映出了 ITIL 4 的态度：应采用整体的服务价值链方法，以确保服务提供商在整个服务生命周期内都是敏捷的。敏捷性应成为所有服务管理维度和所有服务价值链活动的质量衡量标准之一。在 ITIL 4 的指导原则中“基于反馈的迭代推进”、“协作和提升可视化程度”、“保持简单实用”、“优化和自动化”都包含了“敏捷”的元素。

敏捷开发与 ITIL 4 在组织内有相辅相成的共生之道。一方面，对于敏捷开发而言，成功的敏捷开发可以快速响应服务消费者不断变化的需求。但是，在许多组织中，敏捷开发的优势并未能得到良好的发挥。这通常是由于只在服务交付等少数阶段运用了“敏捷”，而在服务生命周期的其他阶段“脱敏”。这种孤立的敏捷性对组织的帮助不大，因为根据“木桶理论”——价值链的整体表现是由创造价值的最慢部分决定的。通过价值链的整体考虑方式，ITIL 为软件开发组织提供更广泛的视角和语言， 增强软件开发团队与别的服务团队的合作，也有助于提升敏捷开发在组织内的更好落地。

另一方面，对于 ITIL 的前版本而言，ITIL 在服务转换阶段，在软件开发方面相对较弱，在端到端服务的过程中也相对较弱，必须要借助敏捷的思维，保持对客户和用户价值的关注，摆脱流程变得笨拙、沉重且高度集中的可能性。两者间的协同工作方式如：

• 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；

• 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；

• 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。

   

综上所述，只有敏捷开发和服务管理一起以类似的节奏发展，说“同一种语言”，才可以确保组织继续与所有利益相关者共同创造价值。

返回本章节索引       阅读下一部分