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

从我的最初印象开始,我会假设不这样做,主要是因为我们的经理提议的是将时间表违反所有内容,并向业务说“ SLA的高优先级任务必须在x小时内完成”等...我们将受到开发人员的惩罚。如果我们不遇到这些SLA。

如果有的话,我希望有一个谈判策略,即时间表是基于敏捷速度方法和故事指向来协商预期时间范围的最终用户的。

我们拥有敏捷的开发实践,测试驱动的开发,持续整合,有改进的领域,但我们正在努力。

其他ITIL和敏捷方法的经历是什么?

有帮助吗?

解决方案

在我的公司中,ITIL框架用于服务交付(生产和事件支持)。因为这种SLA是合适的,好像您说的是每小时损失客户/金钱,那么预计业务应该有一些迹象表明何时会解决问题。它与开发方法没有直接关系。只有当您决定需要紧急修补程序并批准紧急修补程序时,才能进行一些开发。但是,热修正通常很小,并且针对固定缺陷,并且不应引起敏捷方法的任何问题。新要求永远不会作为Hotfix更改,并在正常的DEV/测试/发布过程中进行。

其他提示

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

如果ITIL真正呼吁,我会怀疑,特别是因为“必须在X小时内完成高优先级任务”不适合敏捷,它不适合软件开发,即所有任务都不是出生的。

更新:

那么,您是否会说正常的开发过程可以免于ITIL方法论,并且纯粹专注于基础设施/事件支持领域?

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

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

也许更合适的问题是:ITIL的管理方面/实践适用于软件开发管理? 我不知道,但怀疑是在ITIL中特别解决的。至少我知道ITIL 3引入了与企业体系结构实践相关的更改,这些更改肯定与敏捷兼容(实际上是推动者) - 但至少与固定估计 /任务跟踪 / DEV响应时间有关。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top