Agile vs ITIL

Нет, конечно, ITIL никак не противоречит Agile. Но согласитесь, для того, чтобы обеспечить высокую agility организации, эксплуатация тоже должна быть в игре. Ведь agile – это прежде всего про изменение культуры взаимодействий, про иной уровень вовлеченности, про существенное сокращение роли классического менеджмента в пользу горизонтальных связей, командообразования и новых форм лидерства. А тут на тебе: три линии поддержки и планирование изменений с частотой раз в две недели. Continuous delivery? Нет, не слышали.

Но это, скажем так, «оргмоменты». Процессы можно адаптировать, взаимодействие усилить, сроки сократить. Но есть между agile и ITIL противоречие и посерьезнее. Корневое противоречие. Философское (пишу и самому страшно). Называется оно – SLM.

Вот давайте посмотрим повнимательнее:

  • SLM строится на концепции сервисных отношений. Эта концепция предполагает построение эффективного диалога двух сторон – поставщика и потребителя услуг. В корпоративном сценарии это бизнес-подразделение и департамент ИТ. Мы и они, обязательства (как правило, с акцентом на эксплуатацию), контроль, регулярная отчетность. А в agile – мы часть одной команды, развиваем общий продукт, коммуникации у нас постоянные и отчетность общая – как мы вместе этот продукт развиваем. Способствует ли SLA укреплению командных отношений, как того требует Agile?
  • SLM исходит из идеи более-менее долгосрочной фиксации договоренностей в части предоставления услуг (редко на срок меньше года). Любые изменения в услугах должны быть подвергнуты анализу на предмет влияния на эти договоренности. Если выявлен риск такого влияния, надо либо принимать решения об изменении SLA, либо искать альтернативы в реализации. А это время, в крупных компаниях – приличное время. Можно ли назвать SLM «скорострельным» организационным механизмом и, как следствие, поддерживает ли он способность компании быть agile?
  • Agile постулирует, что рабочий продукт важнее документации. Что поэтому поводу думает SLM (а точнее книжка Service Design со своим замечательным Service Design Package) – мне кажется всем ясно. Тем, кто на практике пробовал строить каталог услуг, описывать инфраструктуру предоставления услуг, заключать соглашения с заказчиками услуг, предельно ясно. Можно ли согласиться с тем, что SLM пребывает в согласии с тезисом о вторичности документации?

Я вполне допускаю, что бесконечно заблуждаюсь – поставленных вопросов на самом деле нет, Agile и SLM могут гармонично сосуществовать. Но может ли кто-нибудь объяснить – как? Ведь это действительно вопросы не столько о процедурах, сколько о принципах, базовых подходах. Может быть, кто-то уже искал ответы на эти вопросы на практике, а не в теории?

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Service Offerings and Agreements

Учебный курс: проектирование и предоставление ИТ-услуг, SLA и SLM, экономика и финансы ИТ, управление поставщиками и подрядчиками — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Vladimir IvanovVladimir Ivanov

    Но при этом есть организации, которые движутся в сторону формализации и им это необходимо. ITIL им в помощь. А вот потом... рано или поздно начнётся обратное движение, и им надо будет помочь «to unlearn». А навязывать Agile тем, кто не готов его принять — неблагодарное дело.

  2. Александр

    По-моему, любая теория доведенная до абсолюта — абсолютно бесполезна. Но какой-то симбиоз, и в каждом конкретном случае видимо свой, вполне возможен. На мой взляд выглядит все так: Agile — это когда разработка. И цель тут получить новый продукт наиболее подходящий требованиям заказчика (который может их доконца не представлять). ITIL — это больше оперирование. И цель — снизить издержки на эту самую операционную деятельность. В процессе разработки выстроить процесс решение инцидентов к следующей итерации продукта помогает ITIL. В работающей среде выбрав и зафиксировав требуемое изменение реализовать его помогает agile. Вообщем такой вот Инь-Янь.

  3. Владимир Калёнов

    Перенесу из Facebook. Противоречия нет и, сам факт противопоставления приводит к раздору.

    1. Delivery и Discovery в Agile дополняют друг друга. Если рассматривать SLA как "Сотрудничество с заказчиком важнее согласования условий контракта" т.е. департамент ИТ выходит на это обсуждение с желанием рассказать о собственных возможностях и ограничениях, и пытается аргументированно показать заказчику границы своих возможностей, а заказчик говорит о своих потребностях, то это и есть "эффективный диалог двух сторон". Любая договоренность подразумевает, что "Люди и взаимодействие важнее процессов и инструментов", а значит заказчик должен быть проинформирован заранее. Не заказчик лезет в новый инструмент смотреть в мониторинг, а ему приходят отчеты, подготовленные поставщиком. От которых заказчик спокоен  Ответственность ИТ департамента — информировать заказчика о качестве предоставления сервиса, доступным для заказчика способом (а не удобным для поставщика). В такой ситуации не нужен контроль. Agile манифест просто признает, что в реальной жизни даже самый компетентный заказчик не может контролировать поставщика — слишком разная нужна компетенция 🙂

    2. SLM классная штука. В ITIL SLM говорит — "ИТ внемлите! Клиент всегда прав, почти всегда"  "Любые изменения в услугах должны быть подвергнуты анализу на предмет влияния на эти договоренности" За это мне нравится ITIL! В нем всё Agile. Agile манифест требует от вас работающего продукта, прямо сейчас, не работающую систему, а продукт. "Если выявлен риск такого влияния, надо либо принимать решения об изменении SLA, либо искать альтернативы в реализации" — прийдите и спросите заказчика, которы работает с вашим сервисом (я думаю вы знакомы  ) — это остановит бизнес или может его приостановить? Если да, меняйте SLA. Или ищите другие способы реализации.

    3. В третьем пункте просто укажу на неверную трактовку манифеста "Agile постулирует, что рабочий продукт важнее документации. " — "Работающий продукт важнее исчерпывающей документации. То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева". 

    То что Дмитрий написал ниже просто великолепно. Инструменты Agile они для случая, когда "предельно ясно" не про продукт, который вы выпускаете.

  4. Александр Тараторин

    Наш практический ответ проще всего объяснить все в тех же Agile принципах:

    Люди и взаимодействие важнее процессов и инструментов; Сотрудничество с заказчиком важнее согласования условий контракта

    Исходя из этого SLA как документ появляется только там, где на подписании формальной бумаги настаивает получатель сервиса или аудит. В остальных случаях должен наглядно показан понятный обеим сторонам уровень сервиса, для которого  определены критерии "что такое хорошо" и "что такое плохо". Критерии, которые обсуждаются и при необходимости корректируются каждый месяц на очном разборе результатов работы сервиса с заказчиком

    Работающий продукт важнее исчерпывающей документации; Готовность к изменениям важнее следования первоначальному плану

    Опять же, самое важное — это то, как отработал сервис. Если мы при формулировании показателей и таргетов где-то что-то упустили, и у нас произошла непредусмотренная соглашением нестандартная ситуация, носящая все признаки аварии — это будет важнее чем формальное выполнение SLA или KPI других процессов

    1. Дмитрий Исайченко Автор

      Я доглго думал перед тем, как ответить. Мне кажется, этот кейс интересен тем, что это практика,  а не просто осмысление теоретических основ. НО. Он не про отсутствие противоречия, а про то, что его удается уменьшить за счет крайне выборочного подписания SLA (SLA как документ появляется только там, где на подписании формальной бумаги настаивает получатель сервиса или аудит) и нестрогого следования действующим SLA (...это будет важнее чем формальное выполнение SLA).

      То есть он, пожалуй, только потверждает факт противоречия. В Вашем случае, судя по тексту, приоритет отдается Agile, и там, где проявляется конфликт, SLM отступает.

      P.S. Кстати, как вы смогли научить аудиторов согласиться с выборочными SLA? Раньше они, я помню, требовали более категорично: "SLA должны быть". Без всяких там границ и полутонов 🙂

      1. Александр Тараторин

        Да, наверное, противоречие есть. Если обе истории (и Agile, и ITSM) возводить в абсолют. Как минимум потому, что в их основе лежат разные цели — Agile (и DevOps) это в первую очередь для time-to-market, а ITSM — про для стабильности.

        А так как мы не пытаемся прийти к абсолюту, наш подход можно сформулировать в стиле тех же agile-принципов: "Ценности Agile для нас важнее ценностей классического ITSM". То есть мы ценим и то и другое, но первое все-таки больше.

        Что касается аудита — когда аудит ценит здравый смысл больше, чем следование букве "лучших практик", то такие вопросы решаются гораздо проще 🙂

  5. Олег Воронцов

    Позволю себе дерзнуть.

    Да, Agile и DevOps противоречат ITIL. И противоречие действительно корневое. Но скорее не философское, а генетическое. Просто ITIL — это про сервис, про то, что ИТ не бизнес, а оказывает бизнесу услугу. А agile и DevOps — это про in house, про родное, про реализацию мысли, про “правую руку” бизнеса, которая никогда не сервис.

    Адепты этих методологий — разные люди, по-разному видящие и роль ИТ и место сервисов в ней.

    Здесь написал подробнее.

  6. Роман Журавлёв

    Вот что я думаю по сути вопроса:

    Всякая Agile-организация неминуемо потребляет чьи-то услуги. Если условия предоставления этих услуг оказываются препятствием для agility, у организации есть разные варианты преодоления этого препятствия:

    Отказаться от услуг и делать то, что делал поставщик услуг, самостоятельно (Мы часть одной команды, развиваем общий продукт, коммуникации у нас постоянные и отчетность общая – как мы вместе этот продукт развиваем.) Тогда нет сервисных отношений и нет противоречия.

    Отказаться от услуг формата «поставщик делает за нас / для нас» и перейти на услуги формата «поставщик предоставляет ресурсы (руки/головы/технологии…)». Тогда SLA сохранится, и будет в основном про качество ресурсов, масштабируемость и фронт работ, к которым эти ресурсы могут применяться. Но управление применением ресурсов – на заказчике, и в рамках этого управления реализуются принципы agile.

    Отказаться от услуг формата «поставщик делает за нас / для нас строго то, о чем договорились» и перейти на услуги формата «поставщик услуг – партнер, с которым мы вместе решаем, что надо делать». Это как в предыдущем варианте, но менеджер, который управляет применением ресурсов, — не наш, а поставщика.

    Во втором и третьем вариантах сервисные отношения сохраняются, они могут быть описаны в SLA, но эти SLA становятся более гибкими, поддерживая такое же свойство организации-заказчика. А противоречия вроде бы нет. Для этого, конечно, нужно, чтобы поставщик услуг был достаточно гибким, зрелым и ориентированным на клиента, чем могло быть достаточно в традиционном формате сервисных отношений с четкими стабильными параметрами качества услуг.

    То есть это тоже «оргмоменты».

    Вот что я думаю по поводу дискуссии:

    Вопрос – не столько про agile vs ITIL, сколько про Agile vs сервисные отношения.

    ITIL – совсем не только про эксплуатацию.

    Agile в контексте заметки – совсем не только про проекты, и тем более не только про разработку

    ITSM – не только для стабильности; ITSM, как и ITIL – для управления услугами в соответствии с приоритетами: кому-то нужно больше стабильности, кому-то – больше гибкости.

    Все (почти) модные и немодные слова (DevOps, Agile, ITIL, ITSM…) одинаково страдают от непонимания бизнес-контекста и попыток их применения в границах ИТ, или ИТ-разработки, или ИТ-эксплуатациии… В то время как все они – в первую очередь про оптимизацию работы организации-заказчика (aka Бизнес). Чуть не написал – про digital transformation.

    ITIL воспринимается как источник рекомендаций про то, как строить строгие процессы эксплуатации. Отчасти потому что ITIL так написали, что в тексте можно найти примеры, подтверждающие эту точку зрения; отчасти – потому что ITIL традиционно так пересказывают; отчасти – потому что мало кто сам читал, что там написано. Надо с этим все что-то делать.

    Как-то так. Извините за много букв и категоричность. 

  7. Дмитрий Исайченко Автор

    Вопрос – не столько про agile vs ITIL, сколько про Agile vs сервисные отношения

    Это очень верно (вот и Олег выше про это писал, и я с ним соглашался). Но сервисные отношения ведь один из центральных моментов в ITIL. И мне кажется, что именно в них, а не в организации поддержки, скрыты наиболее корневые противоречия.

    И я не увидел в твоих примерах 2 и 3 отсутствие противоречия. Во втором мы подменяем суть услуги (как предельный пример переходим с аутсорсинга на аутстаффинг). Таким образом, услуга теперь про одно, а agile — про другое. То есть, мне кажется, есть небольшая подмена понятий. В третьем противоречие снимается за счет поставщика, который настролько зрел, что умеет его снять. Однако, вероятнее всего, это не отсутствие противоречия, а другой баланс — больше гибкости, меньше SLA, как в примере Александра Тараторина. Разве нет?

    1. Роман Журавлёв

      Просто есть ведь услуги и услуги. 

      Конечно, второй пример — компромисс между первым вариантом и третьим. Хотя, согласись, даже в предельном варианте аутстаффинга сервисные отношения все равно присутствуют, и ограничения в них остаются (фронт работ для ресурсов, сроки и предел масштабирования...). Но организация-заказчик меньше ограничена в своей гибкости и при этом пользу от услуг получает. 

      Третий вариант очень созвучен примеру Александра, но почему "меньше SLA"? По-моему, тут даже больше SLA, потому что границы услуг шире, гибче, тарификация сложнее, и так далее.

      Это гораздо легче представить для услуг, в которых много деятельности и мало технологий (разработка ПО, уборка помещений, транспорт...), но по мере развития комплексных облачных технологических решений такой широкий гибкий вариант SLA становится более реальным и для более привычных нам услуг по автоматизации бизнеса. 

      Давай, например, представим, гибкая организация-заказчик потребляет услуги по автоматизации бизнес-процессов на основе, скажем, ServiceNow. Или, скажем, CleverEngine. Или, скажем, HP OV Service Desk. 

      И в рамках этой своей гибкости заказчик хочет, чтобы ИТ-услуги оперативно меняли место предоставления, функциональность, производительность и красоту. 

      У поставщика услуг совсем нет возможностей выполнить требование к гибкости, если он оказывает услуги на основе HP OV SD; больше возможностей, если на основе CleverEngine; еще больше, если на основе ServiceNow. Поправь меня, если я ошибаюсь в этом примере, но идея понятна — современные технологии позволяют расширять границы обязательств в SLA. Возможно, даже до уровня, достаточного для гибкой организации. 

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

  8. Дмитрий Исайченко Автор

    Я вот, что еще думаю. Даже в самом ITIL есть противоречия, заложенные в разные процессы, и именно за счет этих противоречий достигается правильный баланс между разными целевыми установками. Это такие полезные рабочие конфликты, мы как-то с тобой это обсуждали. И, может быть, представленное здесь противоречие — тоже полезное, если научиться его использовать. Например, как средство поиска баланса "TTM vs MTBF".

    1. Роман Журавлёв

      Эта идея мне очень нравится. Беда только, что в ITIL эти противоречия спрятаны, а не описаны с рекомендациями, как их правильно готовить. И, как я уже писал выше, надо что-то с этим делать. 

      Кстати.

      Это же тот самый CCC — core chronic conflict, описанный в книжках про DevOps (и, например, тут). Просто у них за ТТМ отвечает Dev, а за MTBF — Ops. А у нас в этой дискуссии  Agile и SLM соответственно. В книжках про DevOps решение — сам DevOps, но, как описано и в статье по ссылке, и в самих этих книжках, ITSM и SLM при этом очень могут пригодиться. А значит, и ITIL. Но Adapt'a, конечно, нужно с каждым годом все больше, одним adopt'ом уже не обойтись...

  9. Вячеслав Алпатов

    Вот что интересно — те кто живут и работают в мире Agile/DevOps (а так же прочих Канбанов, Скрамов и т.д.) совершенно не переживают о месте ITIL/ITSM в их мире. Видимо потому что ему места там нет (В первую очередь из-за формализованности, разграничения зон отвественности и ориентации на разные SLA). А те кто живут в мире ITIL/ITSM/SLA страшно переживают как бы все эти новомодные Agile/DevOps в свой мир загнать. Желательно без разрушения привычной картины. С чего бы это? 🙂

    1. Роман Журавлёв

      Вот это — самое печальное. Ведь фактически здесь написано следующее: "Люди, занятые проектной деятельностью, считают, что Agile, Scrum, kanban и даже Devops — про проектную деятельность, а на эксплуатацию — как ИТ- , так и бизнес- , им наплевать. Про ITSM/ITIL они знают, что это формализованный бюрократизированный старый и косный подход — хорошо, что не к их работе." Вячеслав, я не очень переврал ваши тезисы? 

      А те, кто живут в мире ITSM не все пытаются загнать в него номодный Agile, хотя есть и такие. Просто некоторые из тех, кто живет в мире ITSM, понимают, что мир ITSM намного шир мира эксплуатации. И мир Agile намного шире мира проектов разработки ПО. А DevOps совсем не равно Dev + Ops, а гораздо шире, и, по-хорошему, включает в себя и бизнес, и разработку, и эксплуатацию, и ИБ... 

      Очень, мне кажется, важно отличать эту общую картину мира бизнеса-использующего-ИТ от попыток прикрутить agile проволокой к ITIL.​

      1. Вячеслав Алпатов

        Сильно переврали. Потому что ключевой момент в Agile/DevOps — объединение эксплуатации и разработки. А вы их все время противопоставляете по ITSMовский привычке. А потом удивляетесь что у вас "ну не получается".

        Ну и еще добавлю что в мире Agile/DevOps люди отлично понимают, что это не для всех ситуаций и не для любого объема бизнеса. Поэтому не надо натягивать сами знаете что на глобус. А "генерализация" особенно присуща аполагетам ITIL/ITSM (достаточно посомтреть на миллионы советов о преимуществах применения ITIL/ITSM в малом бизнесе)

        1. Чернов Антон

          Я последние 1,5 года применяю ITIL в малом и среднем бизнесе. Конечно выборочно и упрощенно. Простые регламенты, КПЭ, базовое обучение сотрудников ИТ и бизнес-руководителей. Это не мешает быстро внедрять процессы ИТ: управление ИНцидентами и ЗнО, SLM и каталог ИТ сервисов в простой реализации и даже Управление Доступностью. 

          Причем бизнесом эти вещи востребованы. В результате работа ИТ становится сильно понятней и прозрачней. ServiceDesk, 2-3 процесса управления ИТ, 3-4 КПЭ работы ИТ.  

           

  10. Алескандр Сырбу

    Почитал выше указанное и по опыту могу сказать следующее:

    У нас,в Банке,по основному бизнес направлению inhouse разработчики работают по Agile, новые продукты выкатывают каждую неделю, time-to-market :))). Но SLA c бизнесом нет что в свою очередь затрудняет работу поддержки. При глобальных проблемах все решается ASAP. На данный момент работаем над внедрением процессов ITIL учитывая текущий подход по разработке. Как это будет работать с ITIL, время и опыт покажет, но пока сопротивления в ИТ и в Бизнесе нет.

    1. Вячеслав Алпатов

      Что логично. Либо вся организация переходит на Agile/DevOps и разделяет его ценности, либо будет боль (как у вас). Собственно что и является косвенным подтверждением, что не скрещиваются ёж с ужом.

  11. Андрей другой

    Никогда такого не было и вот опять:)

    Опять нормальная идея становится жертвой жесткого маркетинга. Опять технологию (методологию), эффективную для определенного типа задач хотят объявить серебрянной пулей, уникальным и единственным решением, отменяющим весь ранее накопленный человеческий опыт. Agile хорошая штука, но не всегда. Если у вас уже есть солидная основа в виде фундаментальной информационной системы и вам  надо только лишь добавить модные фантики, то Agile вполне правильная вещь. Правда раньше это называлось "прототипирование" или "промышленный прототип". И для прототипов действительно никто не разрабатывал полную проектную документацию — только самое необходимое для выпуска прототипа.(Таким методом, к стати, на ЗИЛе членовозы создавали. Не понравился фонарь — хрясь и на опытном производстве быстро новый сделали по эскизу, сделанному на коленке) Но строить по таким принципам с нуля мост(это один из примеров при обсуждении Agile) или ракету. Ну не знаю — давайте быстренько слепим мост, если там что-то не понравится, то быстернько подправим :))) Опять таки, если мост уже стоит и вам надо фонари на нем поменять на более модные, то геологические изыскания видимо делать не стоит, но если моста нет, то уж извините, Agile тут не поможет.

    А ITIL — это про технологические процессы по серийному производству продукции и SLA — это фактически ГОСТ или ТУ на выпускаемую продукцию. Вы его можете и не подписывать с заказчиком, но руководствоваться все равно стоит.

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

  12. Nargiza Suleymanova

    Меня терзают смутные сомненья, что ожесточенные споры Agile/DevOps/... vs ITSM/Prince2/... имеют общую причину: мало кто пытается сначала глубоко вникнуть в суть и того, и другого. На самом деле, как мне кажется, противоречий нет, а одни сплошные взаимодополнения и красота подходов: и то, и другое было инициировано практиками для решения практических задач наиболее эффективными и рациональными способами. Причем, и с одной, и другой стороны настоятельно заостряют внимание на необходимости их адаптирования под ваши конкретные нужды.

    Вообще, все основополагающие принципы подходов к управлению имеют кучу пересечений и совпадений 🙂

    1. Дмитрий Исайченко Автор

      На самом деле ... противоречий нет, а одни сплошные взаимодополнения и красота подходов...

      Наргиза, если противоречий нет, то как Вы откомментируете сам текст поста? Вы действительно не видите противоречия? Если нет, расскажте, почему. Интересно.

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

      Это не исключает возможность противоречия, если это были разные задачи (например).

      1. Nargiza Suleymanova

        Дмитрий, я как раз сейчас на этапе формулировки своих мыслей об ITIL, Prince2, Agile, DevOps, TOC, поэтому обстоятельный ответ писать пока не хочу, боюсь ошибиться с формой 🙂

        В целом, не ощушаю в них каких-то принципиальных несостыковок. Они к месту каждый в своей области назначения, при этом могут быть скомбинированы для получения лучших результатов. Например, как это сделано в Prince2 Agile или в ITIL Practicioner c его кучей отсылок к DevOps. Для меня это не выглядит как дань моде, кстати 🙂 Правильной дорогой  идут товарищи.

  13. Дмитрий Ермаков

    Из моей практики:

    ITIL/ITSM/COBIT — общий процессный фреймворк для IT организации.

    Agile (в частности, SAFE) — вполне себе неплохо детализирует КАК именно эффективно организовать разработку и внедрение. В ITIL/COBIT на эту тему нет необходимой детализации и чётких рекомендаций. Причина этого, очевидно, в истории вопроса — корни этих практик идут в те времена, когда уровень технологий был таков, что, в первую очередь, надо было обеспечить эффективную поддержку. Сейчас зрелость технологий и зависимость от них выше и, закономерно, акцент сменился на эффективность разработки.

    DevOps. Я воспринимаю его как ответ на очередной вызов, связанный с развитием технологий. Требования к скорости реализации идей и их сложнсть опять выросли на порядок. Требования к качеству, как минимум, не уменьшились. Требуется новый уровень коллаборации и автоматизации IT процессов. При этом сами процессы (функции) остались те же. Просто выше требования к скорости, качеству, и, как следствие, степени автоматизации.

    Тут выше в переписке видел коллег, которые, по слухам (;)), имеют отношение к разработке ITIL v.4... Думаю, в него надо интегрировать SAFE (как детализацию ServiceDesign & Service Transition) и DevOps (как необходимость повышенной коллаборации и автоматизации). И, возможно, будет практично и удобно использовать формат CookBook...  

  14. Чернов Антон

    Противоречия нет. ITIL не только про эксплуатацию, а Agile\DevOps не только про проекты и разработку. Собственно DevOps появился, чтобы уравновесить Agile с позиций качества, надежности, доступности ИТ систем не теряя при этом в скорости и безопасности за счет Continual Integration. Просто надо брать все лучшее от каждой методологии. 

    Gartner например сделал финт ушами и объявил, что все дело в Бимодальных ИТ.

    Mode 1 ориентирован на стабильность, надежность, процессы и ITIL

    Mode 2 на инновации, поиск новых решений, time to marker и т.д. DevOps где-то между ними. Вернее даже является неким мостом между ними. 

    Когда выйдет новая версия ITIL v4 или 3.5 (я точно не знаю) она все расставит на свои места. Я надеюсь. А может появится куча новых вопросов.

    Вот в такое веселое время мы и живем. Это мы еще взаимопроникновение IT и Digital не начали обсуждать ))))

  15. Чернов Антон

    Еще раз перечитал философское противоречие SLM и Agile. 

    Мне кажется, что в современном мире SLM мутирует из внутрикорпоративной среды на уровень Customer Experience. Те нет как такового бизнес-заказчика для Core IT Products и IT Services -  есть клиенты и их потребности. И взаимная интеграция ИТ услуг и продуктов в Бизнес услуги и продукты. А бизнес-подразделения этих клиентов всячески удовлетворяют вместе с ИТ, которое так перемешалось с бизнесом, что уже не понятно.

    В таком контексте  клиенту нужен сервис определенного качества, вот тут SLM и выходит на сцену и через Service Design Package и V-Model выкатывает требования к Agile разработчикам как на фичи, так и на параметры производительности, безопасности, надежности и т.д. Они включаются в бек-лог, Ops-инженеры занимаются сокращением MTBF\MTTR и пошло поехало... 

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Empty