我们的 IT 经理正在推动 ITIL，我只是对它不太熟悉，想知道 ITIL 是否适合敏捷工作周期？
从我最初的印象来看，我认为不会，主要是因为我们的经理提议的是对所有事情设定时间表，向业务说明 SLA “必须在 x 小时内完成高优先级任务”等......我们作为开发人员会受到惩罚如果我们不满足这些 SLA。
如果有的话，我更喜欢一种谈判策略，其中时间表基于敏捷的速度和故事点方法，以便与最终用户协商预期的时间范围。
我们有我们的敏捷开发实践、测试驱动开发、持续集成，还有需要改进的地方，但我们正在努力。
ITIL 和敏捷方法协同工作的其他经验是什么？
在我的公司，ITIL 框架用于服务交付（生产和事件支持）。对于这个 SLA 是合适的，就好像你说每小时失去客户/金钱，那么预计业务应该有一些迹象表明什么时候会解决问题。它与开发方法没有直接关系。只有当您决定需要并批准紧急修补程序时，才能进行一些开发。但是修补程序通常非常小，旨在修复缺陷，并且不会导致敏捷方法出现任何问题。新需求永远不会随着修补程序的更改而完成，而是在正常的开发/测试/发布过程中被采用。
这看起来一点都不好，如果是这样的话，它真的根本不适合敏捷。
我怀疑 ITIL 是否真的需要这样做，特别是因为“必须在 x 小时内完成高优先级任务”超出了不适合敏捷的范围，它不适合软件开发，即并非所有任务生来都是平等的。
更新：
那么，您是否会说正常的开发流程可以免除 ITIL 方法，让 ITIL 完全专注于基础设施/事件支持领域？
我不认为这是相互排斥的。虽然 ITIL 可能不适用于您管理团队的方式，但这并不意味着它的有效领域不影响您的开发。
开发需要在设计/产品中考虑基础设施/支持所需的考虑，这可能与 ITIL 中建议的实践有关。
也许更合适的问题是：ITIL 的管理方面/实践是否适用于软件开发的管理？我不知道，但怀疑是在 ITIL 中专门解决的。至少我知道 ITIL 3 引入了与企业架构实践相关的更改，这些更改绝对与敏捷兼容（实际上是促成因素）——但至少这些与固定估计/任务跟踪/开发响应时间相关的东西相去甚远.