Вписывается ли ITIL в Agile мир?
Наш ИТ-менеджер настаивает на ITIL, я только слабо знаком с ним и хотел знать, хорошо ли вписывается ITIL в рабочий цикл Agile?
Исходя из моего первоначального впечатления, я бы предположил, что нет, главным образом потому, что наш менеджер предлагает ставить временные рамки против всего, заявляя SLA бизнесу, что "высокоприоритетные задачи должны быть выполнены за x часов" и т. Д., Которые мы наказываем как разработчики. если мы не встретим эти SLA.
Во всяком случае, я бы предпочел стратегию ведения переговоров, в которой временные рамки основаны на гибких методах скорости и основных моментах для согласования ожидаемых сроков с конечными пользователями.
У нас есть гибкие методы разработки, тестовая разработка, постоянная интеграция, есть области для улучшений, но мы работаем над этим.
Что другие испытывают при совместной работе ITIL и Agile?
2 ответа
В моей компании ITIL Framework используется для предоставления услуг (производство и сопровождение инцидентов). Для этого SLA уместны, как будто вы говорите, что теряете клиентов / деньги в час, тогда ожидается, что у бизнеса должно быть какое-то указание того, когда что-то будет исправлено. Это не имеет прямого отношения к методологии разработки. Только если вы решите, что экстренное исправление требуется и одобрено, тогда может быть проведена некоторая разработка Но исправления обычно очень малы и предназначены для исправления дефекта и не должны вызывать проблем с гибкой методологией. Новые требования никогда не выполняются как исправления и принимаются в обычном процессе разработки / тестирования / выпуска.
Это выглядит не очень хорошо, если это так, это действительно не подходит гибким вообще.
Я подозреваю, что ITIL действительно требует этого, тем более что "задачи с высоким приоритетом должны быть выполнены за x часов" выходит за рамки неподходящего гибкого подхода, он не подходит для разработки программного обеспечения, то есть все задачи не одинаковы.
Обновить:
Итак, могли бы вы сказать, что нормальные процессы разработки могут быть освобождены от методологий ITIL, а ITIL сосредоточится исключительно на областях поддержки инфраструктуры / инцидентов?
Я не думаю, что это взаимоисключающие. Хотя это может быть случай, когда ITIL не применяется в том, как вы управляете командой, это не означает, что нет действительных областей, которые влияют на то, что вы разрабатываете.
Разработка должна включать соображения в дизайне / продукте, которые требуются для инфраструктуры / поддержки, и они могут относиться к методам, предложенным в ITIL.
Возможно, более уместным будет вопрос: применимы ли аспекты / методы управления ITIL к управлению разработкой программного обеспечения? который я не знаю, но подозреваемый рассматривается специально в ITIL. По крайней мере, я знаю, что в ITIL 3 были внесены изменения, относящиеся к методам корпоративной архитектуры, которые определенно совместимы с гибкими (на самом деле являются активаторами) --- но, по крайней мере, они далеки от всего, что связано с фиксированными оценками / отслеживанием задач / временем отклика разработчиков,