Комментарии 5
Наверное стоило бы в первую очередь расписать как существующий подход работает для тех, кто обращается в поддержку - каким образом происходит формирование заявки в поддержку, как быстро происходит обработка запросов, от чего это зависит, какие варианты развития, как регламентируется критичность ситуации итд... и какая при этом происходит реакция... Эджайл есть у очень многих... но у одних задачи решаются за ожидаемое время, а у других "не совсем"... - как здесь помогает Эджайл?
Мне нравится ваша идея внедрения гибких подходов в ITSM, прежде всего потому, что нужно сокращать/автоматизировать бюрократические операции.
Как вы ранжируете и обозначаете приоритеты задач в канбан-доске (особенно, если это инциденты)?
И ещё мнение - я бы в этом подходе выделял отдельно run-команду и change-команду, если позволяет бюджет. Если нет, то можно брать в спринты run/change задачи в определенном фиксированном соотношении.
Делать разработку по скраму эффективно можно только если нет зависимостей от внешних команд. Как только сроки вашей реализации зависят от чего-то внешнего (вендор, другая команда), то скрам превращается в профанацию и постоянные переносы, так как вы не можете обеспечить выход запланированного бизнесом в спринт, а команда и все планы бизнеса были сфокусированы на конкретной цели в спринте, и тогда существенно эффективнее канбан, где каждый ресурс команды постоянно нагружается потоком работы вне зависимости от планов на спринт и бизнес фичи сразу выпускаются по мере готовности. TTM проектов/фич для бизнеса в целом по году получается значительно лучше. Да, больше переключений контекста и релизов не всем по душе, да и следить одновременно нужно за большим количеством фич. Но с точки зрения именно бизнес результата ИТ тогда выглядит как неостанавливающаяся фабрика постоянно дающая результат. По крайней мере мой опыт именно такой.
Статья о том, что когда у вас команда из шести человек, без заказчика, с которым по манифесту сотрудничество важнее требований (SLA же - "бюрократия"), да еще и без разработчиков (devops без dev - отличный подход) - вам ничего не остается, как только "митапить" друг-дружку канбан-доской. Один управляет релизами, другой координирует релизы, а того, кто их, собственно, создает и того, для кого он это создает - никто не спрашивает. Хороший "Agile подход". Главное, чтобы в спринте первая линия поддержки участвовала (ваш "Support Engineer"), да?
Переход от традиционного ITSM к Agile. Как построить гибкое управление ИТ-услугами?