Является ли ITIL в гибком мире?

Question

Наш ИТ-менеджер настаивает на ITIL, я только слабо знаком с ним и хотел узнать, подходит ли ITIL в гибкий рабочий цикл?

Из моего первоначального впечатления я бы предпочел нет, главным образом потому, что наш менеджер предлагает поставить временные рамки против всего, заявив SLA о том, что «задачи с высоким приоритетом должны быть завершены за x часов» и т. Д. ... которые мы получить наказание в качестве разработчиков, если мы не встретим этих SLA.

В любом случае я бы предпочел стратегию переговоров, в которой временные рамки основаны на гибких методах скорости и сюжетных точек для согласования ожидаемых сроков конечных пользователей.

У нас есть гибкие методы разработки на месте, разработка, основанная на тестах, непрерывная интеграция, есть области для улучшения, но мы над этим работаем.

Что представляют собой другие эксперименты с методами ITIL и Agile, работающими вместе?

Answer 1

В моей компании рама ITIL используется для предоставления услуг (поддержка производства и инцидентов). Для этих SLA подходят, как будто вы говорите, что теряете клиентов/деньги в час, тогда ожидается, что бизнес должен иметь некоторые указания на то, когда все будет исправлено. Он напрямую не связан с методологией развития. Только если вы решите, что исправление по чрезвычайным ситуациям требуется и одобрено, может быть выполнена некоторая разработка. Но исправления, как правило, очень малы и нацелены на исправление недостатка и не должны вызывать проблем с гибкой методологией. Новые требования никогда не выполняются как исправление и не выполняются в обычном процессе dev/test/release.

Answer 2

Это не выглядит хорошо, если это так, это действительно не подходит для проворства.

Я подозреваю, что если ITIL действительно требует этого, особенно потому, что «задачи с высоким приоритетом должны быть завершены за x часов» выходит за рамки не подходящего проворства, он не подходит для разработки программного обеспечения, то есть все задачи не рождаются равными.

обновление:

Так бы вы сказать, что нормальные процессы развития могут быть освобождены от методологии ITIL и имеют чисто ITIL сосредоточиться на тех областях инфраструктуры поддержки/инцидентов?

Я не думаю, что это взаимно исключает. Хотя это может быть так, что ITIL не применим в том, как вы управляете командой, это не означает, что недействительные области, которые влияют на то, что вы разрабатываете.

Разработка должна включать соображения в конструкцию/продукт, которые требуются при инфраструктуре/поддержке, и это может относиться к практике, предложенной в ITIL.

Возможно, более подходящий вопрос: являются ли аспекты управления ITIL применимыми к управлению разработкой программного обеспечения?, которого я не знаю, но подозреваемый адресован специально в ITIL. По крайней мере, я знаю, что в ITIL 3 были внесены изменения, относящиеся к практикам Enterprise Architecture, которые определенно совместимы с гибкими (на самом деле являются адаптерами) --- но, по крайней мере, это далеко не все, что связано с фиксированными оценками/отслеживанием задач/временем отклика dev ,