Тема DevOps, "гибкой" разработки на слуху уже долгое время, многим она наверняка приелась, а практикам уж точно навязла в зубах. Работы, которые мы выполняем в рамках наших проектов, в подавляющем большинстве планируются и исполняются по классической водопадной схеме. Да, мы всегда пытаемся ускорить получение заказчиками результатов, где это возможно, но параллелизация потоков работ и введение локальной итеративности разработки продуктов или документов являются лишь незначительными элементами на общей картине проекта.

Мое личное мнение о новом тренде было очень скептичным, особенно, в последнее время. Ситуация, когда этот подход практически объявлятся "серебряной пулей", единственным правильным способом добиться настоящего успеха и результата, меня попросту раздражала.

Выдавшаяся возможность поиграть в деловую игру по DevOps вместе с моими с коллегами стала для меня замечательным экспериментом.

Что было на входе: 

• Группа коллег с нулевым реальным практическим опытом в организации DevOps-команд.
• Стойкое убеждение, что никакой положительный результат в этой области не сможет быть выстроен исключительно на теоретических знаниях. Идея о том, что самоорганизующаяся команда – это исключительно "emergent practice". Она не может быть выстроена по приказу сверху или сбоку. Осознание создаваемой в результате работы ценности, движение её потока должно быть прочувствовано, пропущено через жизнь, деятельность и коммуникации её участников.
• Уверенность в том, что эта пуля совсем не серебряная, умноженная на внутреннее сопротивление нагнетаемому хайпу, информационному шуму по этой теме. 

Как это было:

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

Раунд 1.

Первый раунд стал для группы определенной разминкой, и не надо было быть пророком, чтобы предположить, как мы сработали. Число задач требующих решения можно было посчитать на пальцах одной руки. Мы в ходе непродолжительного совместного мозговорго штурма определили наши "производственные" возможности, согласовали с "бизнесом" приоритеты задач и обработали все плановые и вненеплановые события раунда. Тезис про "emergent practice" сработал в полную силу. Таких слов как поток работ, жизненный цикл, поток ценности, способ и порядок передачи задач между ответственными, определение завершенной работы попросту не звучало, по причине полной их не нужности. Да. 🙂

Раунд 2.

Объем входящей информации, пул задач требующих решения во втором раунде серьезно расширились. Стало понятно, что предыдущий способ работы будет неэффективен. Команда встала перед потребностью выстроить внутреннее взаимодействие, определить жизненный цикл задачи, последовательность обработки и входящие в неё триггеры, определиться со способом контроля ресурсов, со способом маркировки и визуализации работы команды. Кроме этого, возникла потребность в защите собственных интересов группы, направленная на устранение узких мест производственной цепочки. Дерзко, весело и молодежно, особенно, при отсутствии маркеров и доски. Конечно, мы успели не всё, и раунд был вполне себе провален. Мы организовали некоторую последовательность обработки, но из-за неразберихи и непроработанных коммуникаций, возникали разногласия и ошибки в учете, мы устранили узкие места и начали плановые работы, но не смогли завершить их; отсутствие ресурсов на неплановые события дополнило картину. Поток не получился. Но наш эксперимент продолжался.

Раунд 3.

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

Раунд 4.

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

Обзор итогов

Анализ игры и разговор после неё подтвердил многие из моих ожиданий и предположений.

1. DevOps'ом нужно заниматься практически, а лучше жить в нем. Без практического опыта ценность профильных курсов и сертификатов не очень велика. Вероятно, что коллеги меня в этом не поддержат, но ощущения именно такие.

1.1. Следствие:  Путь по этой дороге у каждой организации будет своим. Культура, взаимодействие, оргструктура, мотивация у всех будут отличаться. Каждому участнику процесса нужно будет лично пережить это изменение парадигмы и найти свое место в ней.

2. Бизнес должен быть не менее гибким. В противном случае появляются точки, где результаты предыдущих этапов "перебрасываются через стену", что резко снижает полезность затеи в целом. Бизнес должен доверять команде, согласиться с тем, что бэклог не является обязательством (неприятная неожиданность для многих).

3. Гибкие подходы могут быть эффективнее, но, скорее всего, не будут дешевле. Лучший для результата вариант финансирования работ – авансирование.

• Всегда есть потребность в рефакторинге, улучшениях, проведении внутренних инвестиций и преобразований для уменьшения технического и организационного долга. В противном случае будут возникать сложности с мотивированием действительно интенсивно работающей команды, проблемы с качеством продукта.
• Идеальный вариант обеспечения ресурсами – выделенные на продукт, составляющие ядро команды, люди (7+-2 человека), работающие совместно значительный период времени. Разделяемые ресурсы – это путь боли и страданий.

4. Если в организации есть действующие ITSM-процессы, то их место, охват и практическая реализация могут существенным образом трансформироваться.

5. Колоссальная важность инструментария для отслеживания потока ценности, для доставки продукта от разработчика до пользователей. Ручной труд, направленный на релиз, тестирование практически недопустим. Все, что может быть автоматизировано – должно быть автоматизировано. Это обязательные регулярные затраты.

Если все же вернуться к игре, то её итоги лично для меня, как для человека знакомого с DevOps только теоретически, можно прорезюмировать следующим списком:

• Прекрасно показывает уровень коммуникаций и взаимодействия.
• Подталкивает в экспериментам и конструированию.
• Мотивирует использовать различные практики и способы организации работ, их визуализации. 
• Показывает на потребность в анализе и планировании.
• Способствует погружению в предметную область, местами иллюстрируя её же ограничения.
• Игру можно отиграть и без применения "этих ваших новомодных штук", но и пользы от неё тогда тоже будет не много.

Оцениваю полученный опыт полезным и желаю того же вам!

ИНТЕНСИВ С ТРЕНЕРОМ

Трансформация ИТ в традиционных компаниях

Учебный курс о кратном ускорении за счёт новой организации работы