Руководство по DevOps (Ким, Уиллис) - страница 235

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

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

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

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

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

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

Создайте ритуалы для погашения технического долга

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