ITIL 是否适合敏捷世界？ [关闭]答案

【问题标题】：Does ITIL fit into an Agile world? [closed]ITIL 是否适合敏捷世界？ [关闭]
【发布时间】：2010-09-17 08:11:00
【问题描述】：

我们的 IT 经理正在推动 ITIL，我只是对它不太熟悉，想知道 ITIL 是否适合敏捷工作周期？

从我最初的印象来看，我认为不会，主要是因为我们的经理提议的是对所有事情都设置时间表，向业务说明 SLA 是“必须在 x 小时内完成高优先级任务”等等......我们得到了如果我们不满足这些 SLA，我们将作为开发人员受到处罚。

如果有的话，我更喜欢一种谈判策略，其中时间表基于敏捷的速度方法和故事点，以便与最终用户协商预期的时间范围。

我们有我们的敏捷开发实践、测试驱动开发、持续集成，还有需要改进的地方，但我们正在努力。

其他人在 ITIL 和敏捷方法协同工作方面有哪些经验？

【问题讨论】：

你的问题是关于ITIL Stackexchange的话题

标签： agile agile-processes itil

【解决方案1】：

在我的公司中，ITIL 框架用于服务交付（生产和事件支持）。对于这个 SLA 是合适的，就像您说每小时失去客户/金钱一样，那么预计业务应该有一些迹象表明什么时候会解决问题。它与开发方法没有直接关系。只有当您决定需要并批准紧急修补程序时，才能进行一些开发。但修补程序通常非常小，旨在修复缺陷，不会导致敏捷方法出现任何问题。新需求永远不会随着修补程序的变化而完成，而是在正常的开发/测试/发布过程中进行。

【讨论】：

那么您是否会说正常的开发流程可以免除 ITIL 方法，让 ITIL 完全专注于基础设施/事件支持领域？
井事件也可能与软件有关。例如。在复杂的企业环境中，某些应用程序可能由于数据错误而无法工作。或者一个应该自动启动的批处理作业因为前一个作业中止等而失败。支持所有这些可能需要数据修复或配置文件或计划更改等。很少你会发现真正的缺陷并且需要立即修复紧急代码更改和发布。 ITIL 应该解决这个问题。
是的，正常的项目开发不在 ITIL 下，可以遵循敏捷流程。项目没有 SLA，因为项目通常比修复事件需要更长期的工作，并且项目有包括发布计划在内的计划。
感谢您的更新，抱歉耽搁了。这正是应用团队的感受，但是 IT 经理仍然试图通过在全球范围内应用相同的 SLA 规则来将 SLA 放在我们身边。例如，一个 SLA 是我们必须在报告后的半天内修复一个中等优先级的问题，但是错误和新功能请求会得到同等对待，所以当我在半天内没有交付新功能请求时，我会受到惩罚。我认为是时候换一份新工作了:)

【解决方案2】：

这看起来一点都不好，如果是这样的话，它真的根本不适合敏捷。

我怀疑 ITIL 是否真的需要这样做，特别是因为“必须在 x 小时内完成高优先级任务”超出了不适合敏捷的范围，它不适合软件开发，即并非所有任务生来都是平等的。

更新：

那么您是否会说正常的开发流程可以不受 ITIL 方法的约束，让 ITIL 完全专注于基础设施/事件支持领域？

我不认为这是相互排斥的。虽然 ITIL 可能不适用于您管理团队的方式，但这并不意味着它的有效领域不影响您的开发。

开发需要在设计/产品中包含基础设施/支持所需的考虑因素，这可能与 ITIL 中建议的实践有关。

也许更合适的问题是：ITIL 的管理方面/实践是否适用于软件开发的管理？ 我不知道，但怀疑在 ITIL 中得到了特别解决。至少我知道 ITIL 3 引入了与企业架构实践相关的更改，这些更改绝对与敏捷兼容（实际上是促成因素）——但至少这些与固定估计/任务跟踪/开发响应时间相关的东西相去甚远.

【讨论】：

我倾向于同意，我们的经理是基础架构/支持团队的一员，并且正在尝试对软件任务和支持请求应用相同的规则。试图解释这似乎并不顺利。
@Brett 我建议您找到超越敏捷的参考资料。尝试将基础设施/支持的性质应用于开发完全是另一头野兽，它是双向的 - 技能不会转移相同/双方的人往往会错过对方的很多关键部分。