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 тем, кто не готов его принять — неблагодарное дело.

    0
    0
  2. Александр

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    0
    0
  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 традиционно так пересказывают; отчасти – потому что мало кто сам читал, что там написано. Надо с этим все что-то делать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Кстати.

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

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

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

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

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

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

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

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

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

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

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

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

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

           

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

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

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

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

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

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

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

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

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

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

    0
    0
  12. Nargiza Suleymanova

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

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

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

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

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

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

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

      0
      0
      1. Nargiza Suleymanova

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    0
    0

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

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

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)