В качестве примера Томайко приводит другой внутренний запрос GitHub касательно миграции баз данных. Он был длиной в несколько страниц, содержал обширный анализ возможных рисков и завершался следующей фразой автора запроса: «Я сейчас отправляю эту правку в исходный код. Сборки этой ветки сейчас падают, потому что на CI-серверах (серверах непрерывной интеграции) не хватает одного столбца» (ссылка на лог падения MySQL).
Автор правки потом извинился за сбой и рассказал, какие условия и ошибочные предположения привели к неполадке, а также предложил список мер для предотвращения этой проблемы в будущем. Все это сопровождалось страницами разбора и анализа. Читая этот запрос, Томайко улыбнулся: «Вот это отличный запрос!»
Как описано выше, мы можем оценить эффективность процессов рецензирования, проанализировав выборочные запросы как из всей совокупности запросов на внесение изменений, так и только из имевших отношение к сбоям.
Бесстрашно избавляйтесь от бюрократических процессов
Пока что мы обсуждали рецензирование кода и парное программирование, позволяющие увеличить качество результатов и избавиться от необходимости получать разрешения от внешних структур. Однако у многих компаний до сих пор есть процессы одобрения изменений. На них требуются месяцы. Эти процессы могут значительно увеличивать время создания продукта, что не только не дает быстро выполнять заказы клиентов, но также потенциально препятствует достижению целей организации. Если такое все же происходит, нужно изменить процессы внутри компании, чтобы цели достигались быстрее и безопаснее.
Как отмечает Адриан Коккрофт, «вывешивать на широкое обозрение стоит отличный показатель — сколько встреч и тикетов нужно, чтобы сделать один релиз. Цель — неуклонно сокращать усилия инженеров на создание продукта и поставку его заказчикам».
Точно так же Тапабрата Пал, сотрудник компании Capital One, описал одну программу под названием Got Goo?[141]. Специальная команда устраняет всевозможные препятствия, включая инструменты, процессы и одобрение, мешающие завершению процесса. Джейсон Кокс, старший директор по проектированию систем компании Disney, в презентации на конференции DevOps Enterprise Summit 2015 г. описал программу Join the Rebellion[142]. Ее цель — избавить от тяжелого труда и всевозможных препятствий.
В 2012 г. в компании Target комбинация процесса принятия новых технологий (TEAP) и ведущей комиссии контроля по архитектуре (LARB) привела к тому, что на одобрение использования новой технологии требовалось очень много времени. Чтобы предложить новую технологию, например иную базу данных или систему мониторинга, нужно было заполнить форму TEAP. Эти предложения затем оценивались, и стоящие заносились в список вопросов ежемесячных встреч LARB.