ITMF 2018: DevOps как форма существования цифрового предприятия

Марк Смолли: «Цифровая платформа — это сочетание унаследованных и современных технологий с тесно переплетенными интерфейсами между различными компонентами. Устойчивость такого сочетания нельзя гарантировать, все находится в движении, что требует постоянных экспериментов и изучения»


10:41 09.06.2018  (обновлено: 09:25 10.06.2018)   |   5446 |  Дмитрий Волков |  «Открытые системы»

Рубрика Предприятие



DevOps — романтический культ, религия или профессиональное движение? В этом вопросе разбирались участники одной из сессий международного форума профессионалов в управлении ИТ.

В Москве прошел пятнадцатый форум IT Management Forum, организованный издательством «Открытые системы» и собравший более 400 представителей отечественных и зарубежных компаний из разных отраслей зарождающейся цифровой экономики. Слоган форума – «Стратегия и практика управления ИТ. В ответе за цифровое предприятие» — весьма точно характеризует современное состояние процесса цифровой трансформации, которая не сводится к последовательной и уже привычной автоматизации. Сама по себе автоматизация не улучшает текущие бизнес-модели – за счет одного лишь применения новых технологий цифрового общества не построить, поэтому требуется, как считают участники сессии «Корпоративный Agile/DevOps и другие инновации в управлении», изменение культуры, профессиональное движение, нацеленное на изменение производственных отношений.

В форумах ITMF регулярно принимают участие ведущие зарубежные и отечественные эксперты. В этом году на форуме выступил Марк Смолли, всемирный посол фонда ASL BiSL и ассоциации DevOps Agile Skills, который на пленарном заседании задал вектор обсуждения вопроса о роли DevOps, сравнив, в частности, разговоры вокруг этой методологии с религиозными спорами, а именно, с дзэн-буддизмом.

Итак, что такое DevOps – культ романтиков, где на любого, пришедшего на обсуждение без принятых артефактов, смотрят с подозрением, либо это лишь рядовой метод разработки программного обеспечения, а может быть, это развивающееся профессиональное движение, нацеленное на укрепление производственных отношений между разработчиками и специалистами подразделения эксплуатации и ускорение выполнения запланированных работ?

В своем докладе «Первые шаги к DevOps и контроль качества ПО» Ольга Тимашева, руководитель центра компетенций по тестированию и обеспечению качества ПО «ЮниКредит Банка», рассказала о движении банка в сторону DevOps. В конце 2017 года была образована инициативная группа с привлечением команд разработчиков приложений, команды развития инфраструктуры и команды тестирования для реализации проекта объединения всех инициатив по автоматизации. В качестве основы на первых порах были выбраны некритичные для бизнеса приложения. Сразу выяснилось, что текущий способ управления изменениями не готов к процессам непрерывной доставки и развертывания, причем невозможно автоматизировать «человеческий фактор» в деле согласования изменений. Однако при развертывании тестовых сред вполне возможно минимизировать субъективизм, а для коллектива из молодых специалистов, стремящихся к освоению новых подходов, нет проблем при движении к DevOps.

Евгений Карасик, менеджер по продукту израильского центра разработок компании Micro Focus, отметил в своем докладе «Как мы внедряли DevOps. Рецепты успеха на основе личного опыта» важность ответственности всей команды за общее дело. Подход DevOps был выбран как способ реализации требований бизнеса за счет регулярной и ранней поставки ПО благодаря организации взаимодействия подразделений разработки, тестирования и эксплуатации. При этом продукты разрабатываются не только на основе принятых методологий, но и с учетом личного опыта разработчиков, а главный принцип звучал как «все,что может быть использовано более, чем один раз, должно быть автоматизировано». Следование DevOps позволяет выявлять и преодолевать организационные, технологические и психологические барьеры для создания управляемого и контролируемого прозрачного процессa с быстрой обратной связью. Однако нельзя делать DevOps наполовину, а эффект будет выше, если всем членам команды интересно работать «по душе, а не по карьерному росту», отметил Карасик. Если до перехода на DevOps новая версия продукта выходила раз в год, то после – по запросу бизнеса, технологический стек стал меняться теперь не раз в несколько лет, а по мере необходимости. Обычно объем кода увеличивался на 30% для каждой версии, а теперь максимум на 3-5%, причем автоматизация тестирования составила 80%, а не 20%, как раньше. Все это позволило резко повысить качество продукта.

Однако, несмотря на такие высокие показатели, не все докладчики сессии рекомендовали слушателям всегда следовать дорогой DevOps. Ирина Марчева, руководитель продуктового офиса компании «М.Видео», в своем выступлении «Нужен ли вам Agile?» обратила внимание на то, что внедрение DevOps не следует считать панацеей. Гибкие методологии итеративной разработки, например Scrum, эффективны в случаях, когда неясен результат и требуется быстро проверить различные гипотезы, а для классических, размеренных проектов с четкими сроками и целями достаточен инкрементальный, эволюционный подход. Проблема может возникнуть в крупных организациях, когда одна часть компании живет в парадигме Agile, а другая – в старой «водопадной», и здесь может помочь SAFe. Проект создания интернет-магазина «М.Видео» с его неясными целями и масштабами изначально относился к Agile, и, по словам Марчевой, его успеху способствовали поддержка со стороны руководства, привлечение консультантов и, главное, – предоставление команде права на ошибку.

Бизнесу нужны конкретные конкурентные преимущества, и ему в конечном счете нет дела до Agile как культуры, отметил в своем докладе «Покажи мне свои практики. Когда Agile краснеет» Олег Егоркин из «Ростелекома». Однако эффективность любой практики, а значит, и результаты бизнеса сильно зависят не только от возможностей команды, но и от способности самих бизнес-руководителей принять культурные преобразования. Свое выступление Егоркин построил вокруг общей многоуровневой модели развития организационной культуры – поведение всех сотрудников компании определяется ее принадлежностью к конкретному уровню: импульсивная (банда), конформистская (церковь), конкурентная (корпорация), плюралистическая (семья) и эволюционная (живой организм). В наибольшей степени практики DevOps начинают работать лишь на четвертом уровне, на втором Dev и Ops существуют раздельно, а на третьем появляется ITIL. Предложенная модель позволяет понять, готова ли команда к DevOps и имеет ли смысл перенимать практики у команд с более развитым культурным кодом.


Теги: DevOps Agile Цифровая трансформация ITMF 2018
На ту же тему: