Agile ITIL是否适合敏捷世界？

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

从我最初的印象来看，我认为不会，主要是因为我们的经理建议将时间线与所有事情放在一起，向业务部门说明SLA“高优先级任务必须在x小时内完成”等。。。如果我们不满足这些SLA，我们将作为开发人员受到惩罚

如果有什么不同的话，我更喜欢谈判策略，其中时间线基于敏捷的速度和故事点方法，以便与最终用户协商预期的时间框架

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

---

ITIL和敏捷方法协同工作的其他经验是什么？

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

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

更新：

---

那么，您是否认为正常的开发过程可以不受ITIL方法的限制，而让ITIL只专注于基础设施/事件支持领域

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

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

---

也许更合适的问题是：ITIL的管理方面/实践是否适用于软件开发的管理？我不知道，但ITIL中特别提到了这个问题。至少我知道ITIL 3引入了与企业架构实践相关的变更，这些变更肯定与敏捷兼容（事实上是促成因素）——但至少这些变更与固定估计/任务跟踪/开发响应时间无关。

在我的公司，ITIL框架用于服务交付（生产和事故支持）。对于此SLA是合适的，就像您说每小时损失客户/金钱一样，那么预计业务部门应该有一些指示，说明何时会解决问题。这与开发方法没有直接关系。只有当您决定需要并批准紧急修补程序时，才可以进行某些开发。但修补程序是有效的通常非常小，针对的是修复缺陷，不应导致敏捷方法的任何问题。新的需求永远不会作为热修复更改来完成，而是在正常的开发/测试/发布过程中进行。

我倾向于同意，我们的经理是基础架构/支持团队的一部分，并且正在尝试对软件任务和支持应用相同的规则请求。试图解释这一点似乎不太好。@Brett我建议你找到超越敏捷的参考资料。试图将基础结构/支持的本质应用到开发中是一个完全不同的野兽，它是双向的-技能不一样/双方的人往往会错过对方的很多关键部分。所以您认为正常的开发过程可以不受ITIL方法的限制，而让ITIL完全专注于基础设施/事件支持领域吗？事件也可以与软件相关。例如，在复杂的企业环境中，可能是某些应用程序由于数据不好而无法工作。或者是一个批处理作业应该自动启动ly失败是因为上一个作业中止等。支持所有这些可能需要数据修复或配置文件或时间表更改等。您可能很少会发现真正的缺陷，需要立即作为紧急代码更改和发布进行修复。ITIL应该解决这一问题。是的，正常的项目开发不在ITIL之下，可以遵循敏捷过程SSE。项目没有SLA，因为项目通常比修复事件需要更长的时间，并且项目有包括发布计划在内的计划。感谢更新，并对延迟表示抱歉。这正是应用程序团队的感受，但是IT经理仍然试图通过在全球应用相同的SLA规则来让SLA围绕我们。例如e、 一个SLA是，我们必须在报告后的半天内解决中等优先级的问题，但是bug和新功能请求被同等对待，因此，当我半天内没有提交新功能请求时，我将受到处罚。我认为是时候换一份新工作了：）你的问题在