Джин Ким - Руководство по DevOps

Пример блиц-обучения — программа ежемесячного испытания в додзё [158]DevOps компании Target. Благодаря Россу Клэнтону, директору по эксплуатации Target, переход на систему DevOps прошел быстро. Одним из основных механизмов этого был центр технологических инноваций, более известный как додзё DevOps.

Додзё DevOps занимает площадь примерно в 1700 квадратных метров офисного пространства, где тренеры DevOps помогают командам улучшать свои навыки. Самый интенсивный формат называется «тридцатидневными испытаниями». За это время команды разработки работают в додзё с профильными коучами и инженерами. Команда формулирует проблему, с которой долгое время пыталась бороться, цель испытания — за 30 дней совершить прорыв в решении.

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

Клэнтон пишет: «На данный момент тридцатидневные испытания могут проводить не более восьми команд одновременно, поэтому мы фокусируемся на самых стратегически важных проектах компании. Через додзё уже прошли самые важные подразделения, включая группы, занимающиеся POS-терминалами, товарно-материальными запасами, ценообразованием и рекламными кампаниями».

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

Рави Пандей, менеджер по разработке Target, прошедший через эту программу, поясняет: «В прежние времена, чтобы получить тестовую среду, нам приходилось ждать шесть недель. Теперь же мы получаем ее за минуты и работаем рука об руку с инженерами эксплуатации. Они помогают нам действовать более продуктивно и создают нужные нам инструменты, чтобы нам было проще достигать поставленных целей. — Клэнтон продолжает: — Не так уж редко команды за несколько дней решают проблемы, которые раньше заняли бы у них от трех до шести месяцев. На данный момент через додзё уже прошло примерно 200 сотрудников. В общем они завершили 14 тридцатидневных испытаний».

В додзё также есть менее интенсивные модели работы, например Flash Build, где команды собираются на один-три дня, чтобы разработать минимально жизнеспособный продукт (minimal viable product, MVP) или минимально жизнеспособную функциональность (minimal viable capability, MVC). Кроме того, в компании каждые две недели проводят дни открытых дверей: все желающие могут прийти в додзё, чтобы поговорить с тренерами, посмотреть на результаты работы команд или пройти тренинг.

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

В этой части мы опишем ритуалы, помогающие разработчикам и инженерам эксплуатации выделять время на улучшение текущей работы, например на автоматизацию, введение нефункциональных требований и так далее. Один из самых простых способов — запланировать и регулярно выполнять блиц-обучение длиной в один день или одну неделю, когда вся команда (или вся организация) занимается наиболее волнующими проблемами и никакая работа над компонентами функциональности не разрешается. Это может быть проблемный участок кода, среда, архитектура, инструмент и так далее. Для блиц-обучения команды могут собираться из представителей всей производственной цепочки, например из разработки, IT-эксплуатации и службы информационной безопасности. Тех, кто обычно не работает вместе, объединяют навыки и усилия, чтобы улучшить работу в выбранной области и затем продемонстрировать результаты всей компании.

Помимо таких терминов бережливого производства, как kaizen-blitz и блиц-обучение, методика ритуалов по улучшению работы также называется весенней или осенней генеральной уборкой (spring или fall cleaning) или неделями инверсии очереди задач (ticket queue inversion weeks). Иногда используются и другие термины, например хакатон (hack day, hackaton) или 20 % времени на инновации (20 % innovation time). К сожалению, конкретные ритуалы часто предназначены для совершенствования готовых продуктов и создания прототипов новых продуктов, а не для улучшения повседневной работы и, что еще хуже, методики используют только разработчики, что очень далеко от целей блиц-обучения [159].

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

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

Сила блиц-обучений в том, что они вдохновляют непрерывно выявлять и решать проблемы без посторонних стимулов. Представьте, что наша сложная система — это паутина, переплетающиеся в ней нити постоянно ослабевают и рвутся. Если порвется определенная комбинация отдельных нитей, то всей паутине придет конец. Нет управления сверху, чтобы указывать рабочим, какие нити и в каком порядке нужно чинить. Вместо этого нужно создать организационную культуру и нормы, побуждающие сотрудников самим находить и исправлять слабые места системы в процессе ежедневной работы. Как отмечает Спир, «неудивительно, что пауки заделывают разрывы в паутине, как только они появляются, а не ждут, когда их станет слишком много».

Хороший пример успешного воплощения блиц-обучений описан Марком Цукербергом, генеральным директором Facebook. В интервью Джессике Стиллман, размещенном на сайте Inc.com, он рассказывает: «Каждые несколько месяцев мы проводим хакатон, где все желающие создают прототипы для новых идей. В конце мероприятия вся команда собирается вместе и смотрит, что получилось. Многие из наших самых успешных продуктов появились именно во время хакатонов, в том числе Timeline, чат, видео, среда разработки для мобильных приложений и некоторые компоненты инфраструктуры, например компилятор HipHop».