Темная сторона Agile

Доклад на конференции AgileDays 22 марта 2018 года. Слайды доклада

Дмитрий Круглов, ИТ директор, Яндекс.Деньги

Очень интересно, что у нас подряд два доклада на похожую тему: «Почему, может быть, вам не стоит внедрять Agile?» [имеется в виду доклад Антона Зотина]. Но я сделаю акцент на том, в чём больше я считаю себя специалистом. Я не психолог, про людей у меня будет, но не много. Я сделаю акцент на процессах, на технических аспектах, и иногда даже и про деньги поговорим.

Скажите, пожалуйста, «тёмная сторона Agile» у кого ассоциируется с Дартом Вейдером? На деле — речь не про это. Речь пойдет о темной стороне Луны, которая, как известно, была для человечества неизвестна, до тех пор, пока туда не прилетел первый космический аппарат, который сфотографировал. Так вот, суть моего доклада и его идея в том, что, когда вы начинаете внедрять Agile, вы составляете проект освоения Луны, не зная, что на другой стороне. И лучше бы эти вещи представлять заранее.

Мой рассказ — в достаточной степени капитанский для тех, кто прошёл хотя бы половину пути. Если вы в завершающей части того, что сейчас прогрессивное человечество знает и умеет про Agile, то для вас вообще всё это будет просто повторением того, что вы уже пережили. Лично для меня это опыт в трёх разных компаниях, плюс достаточно много референсных историй от моих друзей, которые в общем вылились в то, что я рассказывал эту историю за последние полгода раз десять. И понял, что она стоит того, чтобы её рассказать на более широкую аудиторию.

Всё начинается с разработки

Всё начинается с попытки внедрить новый процесс разработки, будь то Scrum или Kanban, или гибрид Scrumban, или какой-нибудь велосипед, который изобретёте у себя. Но классические отделы разработки — это отделы с ресурсными менеджерами во главе, и у них есть общая потребность. Ну вы представляете себе, один человек говорит: «Не надо ходить, пожалуйста, к моим разработчикам, приходите ко мне». Дальше он распределяет эти задачи. Бывают хорошие ресурсные менеджеры, бывают плохие. Но даже хорошие, когда они прекрасно справляются с распределением задач, рано или поздно, начинают делить свою работу на выделенные потоки для выделенных клиентов. Потому что нормально, когда в бизнесе есть много различных внутренних заказчиков или даже внешних заказчиков, неизбежно начинаются конфликты, начинается борьба за ресурсы. И так или иначе, ресурсный менеджер пытается это решить, выделяя, например, потоки.

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

Бизнес очень доволен. Бизнес — это продакт оунеры — люди, которые помимо того что отвечают за функциональность, также несут бремя ответственности за P&L, за трафик, за прочие KPI, которые сверху им даны, такие как цена ресурса, который они получили. Так вот, бизнес доволен, потому что вот теперь мы видим живых разработчиков, мы с ними общаемся, есть прямой контакт, можно транслировать идею, можно их вовлекать. И это все работает, и все вроде хорошо.

Начинается изменение кодовой базы

Так вот, не все хорошо. Дело в том, что в большинстве отделов классической формации, экономически целесообразно иметь монолит. И это не голословно. Я знаю, у меня есть знакомый, который в крупном ритейле построил автоматизацию на монолите от вендора и вполне мотивированно объяснял мне, почему для него это лучшее из возможных решений. То есть, когда в каком-то отделе по инициативе самого отдела начинают внедряться, например, микросервисы – это скорее всего та же мотивация, как “попробовать новые технологии”. То есть, хочется что-то новенького. В большинстве же случаев, работа в монолите внутри отдела экономически оправдана, со всеми понятными последствиями — такими, как релизный цикл 2-3-4 недели, долгие сборки, долгое тестирование. Команды так жить не могут, Product Owner не будет ждать 2-3-4 недели, когда очередной крупный релиз проходит, поэтому команды начинают писать свой код.

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

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

Начинается реформирование тестирования

Я встречал в своей практике историю, когда в календаре заводили расписание использования тестового стенда, когда тестировщики дробили рабочее время на получасовые слоты, чтобы пользоваться тестовым стендом. Просто потому, что иначе начинался хаос. И можете себе представить, сколько усилий уходит на поддержание тестового стенда, которым пользуются несколько десятков команд одновременно в нормальном адекватном рабочем состоянии. Потому что одна команда сломала, а остальные 19 не могут пользоваться. Множить тестовые стенды, это тоже такая история сложная и оттуда, естественным образом, возникает потребность в виртуализации и контейнеризации, но мы это скажем чуть позже. Вот то, что эксплуатация становиться просто банально золотой, — это факт. Потому что хозяйство, помимо продакшена, ещё умножается на количество тестовых стендов, если вы смогли себе позволить их увеличить по количеству команд. И мы переходим к тому, что классические очереди сисопсов, обычных системных администраторов просто захлёбываются по количеству задач, которые к ним сваливаются из 20-ти команд.

Из личного опыта. Мы, когда начинали, у нас на каждый монолит было по одному тестовому стенду, и, в принципе, всё было хорошо. Потом, когда появились команды, и мы сделали очень сложный проект по разделению тестовых стендов, у нас их стало 20. Аппетит приходит во время еды, мы живём сейчас более чем 70-тью стендами и реально пониманием, что достаточно будет порядка двухсот. 200 тестовых стендов, плюс продакшен, умножить на более чем 50 компонентов в вашей системе… это же сколько приходится усилий тратить на деплоймент?! Когда мы только начинали этот путь, я спросил у одного из моих системных администраторов естественный вопрос: «Скажи, а где же автоматизация деплоя?». Он сказал: «У меня выкладка раз в две недели занимает час, что мне здесь автоматизировать?». Это эпоха монолита, а теперь мы имеем эти самые 50 плюс компонент, и, если бы их не катил робот, это было бы просто невозможно потянуть с точки зрения ФОТа.

Зарождается DevOps

И у вас неизбежно появляются автоматизированные процессы сборки, доставки на прод, у вас, более или менее, отлаживается работа в командах по процессу. И вы достигаете каких-то серьёзных показателей, например, 60-80 релизов в неделю: каждый компонент по паре, тройке раз релизится в день. Когда это всё заработает, вот тогда начинается состояние хаоса: никто не понимает, что вообще в системе в данный момент происходит. Она становится слишком большой, чтобы один человек её мог охватить взглядом. Вот чем хороши монолиты, — обязательно в отделе найдется пару старожилов, которые или создавали, или были с самого начала, и они вам просто на пальцах любую проблему объяснят и сразу у них чуйка на проблему, они знают, где и почему она возникла. Они помнят все эти баги, которые они закопали на 100 лет, они помнят все странные логические решения, которые бизнес продавил. Из разряда, надо нормально 3 раза попробовать в клиента постучаться, но вот этот клиент особый, мы будем 100 раз стучаться, там специально коэффициент поправочный стоит, и не надо его, пожалуйста, трогать, он там не просто так.

Требуется качественно другой мониторинг

В этот момент, катастрофически возникает потребность в мониторинге. И вы знаете, приходишь к админам, а они говорят: «Да, у нас есть мониторинг, у нас всё покрыто мониторингом, у нас, смотри, каждый процессор, его температура меряется». Кому это помогло в случае с инцидентом с клиентами? Железячные метрики не работают. Софтверные метрики разработчиков “Сколько Java сейчас памяти отожрала” — в большинстве случае вам тоже не помогут. И что самое обидное, вам не особо помогут бизнес-метрики, если вы их не сделали кастомными.

Почему? Дело в том, что мир сложен, он не чёрный и белый, и редко бывает, когда у вас идеальный API или идеальный продукт, и клиенты очень точно и правильно их используют. Чаще всего там есть эти самые пресловутые костыли. И клиенты, если они адекватные, это тоже принимают, они под костыли подстраиваются. И вот как вам поможет классический мониторинг, если вдруг там сломались платежи у клиента, потому что вы баг починили? А это обычная история, она случилась у нас 2 недели назад. Мы баг починили на продакшене, и сломалось несколько рабочих процессов у клиентов, у которых под нас была специальная подстройка — именно под этот конкретный баг. То есть, они его учитывали в своих процессах. А мы, естественно, баги, знаете ли, не мониторим.

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

Начинаются конфликты планирования

И зонтичные проекты, я считаю, — это история, которую никто пока рынке хорошо не решил. И как бы нам не продавали консультанты новые надстройки над ставшими уже классическими Скрамом и Канбаном, например, SAFe, — они не работают. Точнее, работают, но они дорогие. Они дорогие административно, они дорогие ресурсно. Они требуют еще более дорогих и сложных компетенций, которых на рынке пока нет. Поэтому история с зонтичными проектами ни у кого хорошо не решена. А зонтичные проекты – это, если кто-то в теме, например, ФЗ-52, когда государство так говорит: «Ребята, перестройте-ка, пожалуйста, все кассовые системы в стране». Или история, когда маркетинг уже проплатил вам рекламную компанию, а продукт-то еще не готов, и его еще пилить и пилить. А дедлайн, он настоящий, за него расстреляют. Или вот эта история: просто приходит кто-то из ТОПов, и не важно по какой причине, но у него есть дедлайн.

Я был впечатлен, когда, общаясь со Spotify, узнал, что они очень сильно фрустрировали из-за семейной подписки. Они придумали ее за год до того, как ее выпустили Apple и Google, но не смогли реализовать по одной простой причине. Spotify — на западном рынке сейчас одна из образцовых компаний, работающих по Agile. Команды по-настоящему независимы. Но проблема независимости, когда тебе нужно сделать проект на 10 команд, оборачивается очень долгими сроками, потому что всех нужно уговорить. Потому что, если команды скрамовские, самостоятельные и хорошо работают, у них свои roadmaps, и ваша семейная подписка – это вообще не их цель сейчас.

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

От руководителей требуется другое

Отделы распределенные – это отделы, в которых руководителю очень некомфортно, потому что классический руководитель не понимает, в чем же его роль там в этом отделе. Это болезненный переход — от того, что я всем раздал задачи, до состояния, когда у меня вообще нет людей, и зачем тогда я в компании. Это процесс, когда нужно руководителей или учить и растить, или, упаси Боже, если так случается, менять. У меня был однажды руководитель в отделе — control freak на 100%: практиковал zero inbox сам и двойной публичный код ревью во всем отделе, и не дай Бог, если хоть одна задача без его внимания попадет на прод. И когда людей раздали в команды, у него не осталось людей, возникло страшное чувство дискомфорта: «Я вообще зачем здесь?». А затем, чтобы разработчики во всех командах обменивались информацией, росли более-менее синхронно в одном направлении, и чтобы система не расползалась и не превращалась в лоскутное одеяло, — вот зачем. А этому надо учить сначала самих руководителей, и это не просто, а на рынке их не достать.

Повышается требование осознанности

И последний момент: осознанность людей. Тут я даже не буду пытаться утверждать и говорить вам, что мы его перебороли или как-то освоили, или пережили. Увы, нет. Но изменения в культуре в IT становятся очевидными, если пройти все предыдущие этапы, и они касаются того, что мы ждём от отдельно взятого человека. Раньше чем разработчик был исполнительней, тем нам было комфортнее. То есть, поставил задачу, и он её очень чётко в срок быстро сделал. А теперь разработчики в командах, и состояние, когда они в команде внутри между собой самостоятельно договорились, — это тоже не очень хорошее состояние. Потому что они начинают отстаивать интересы команды, хотя это не единственные интересы в компании.

А правильное поведение — это когда люди дорастают до такого уровня зрелости, когда понимают, что есть служба безопасности, есть требования безопасности. Когда они понимают, что есть архитектура, она не просто так придумана и архитекторы не злодеи и не враги, и не сознательно им жизнь портят, а просто думают вперед на несколько лет. Когда они начинают учитывать интересы соседних команд. И вот такое поведение выявлять, взращивать, поощрять, — это становится очень серьёзной задачей.

Беда всей этой истории состоит в том, что, к сожалению, если пройти этот путь, никто не гарантирует вам, что у вас будет успех. Но я могу утверждать, что, если вы этот путь не пройдёте, у вас будет гарантированный не успех. Поэтому история такая: либо полный фейл, либо 50 на 50, повезёт или не повезёт. Делайте выводы сами, но имейте ввиду, чем будет сопровождаться этот путь. Имейте ввиду, что начиная изменения в процессе разработки, вы трогаете лишь верхушку айсберга.

Agile — верхушка айсберга

Таким образом, у этого пути есть несколько очень важных характеристик.

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

Второе: это процесс очень дорогой. Откровенно говоря, я считаю, что внедрять Agile и двигаться по всему этому пути нужно тогда, когда: а) у вас хороший, крепкий и достаточно устойчивый бизнес и крепкая компания и б) когда вы понимаете, что впереди будет больше, круче и вам нужно расти. Потому что, если у вас вопрос выживания, то извините меня, но вас это убьёт. И кажется, я где-то слышал статистику, что компании из top Fortune 500, которые начинали Scrum, оттуда и вылетали, потому, что это последняя вещь, которая добивает компанию. Там и так плохи дела, а ещё сверху Scrum, и вся это бодяга с инфраструктурой, админами и прочим.

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

Три вывода в заключение

В конце у меня есть для вас 3 вывода. Они очень простые.

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

Второй вывод. Если это локальная история, если у вас нет задачи всю компанию перестраивать, если у вас есть желание внутри или потребность, навязанная кем-либо, сделать новый продукт по новым подходам быстрее обычного, то иногда это проще отделить. И мы видели эти примеры на рынке. И Альфа Лаборатория тому хороший пример, и у Открытия есть свой «гараж», и можно даже банально нанять аутсорсера, который по Agile работает, дать продакт оунеру внешний ресурс. То есть, зачем завязываться на перестройку всего, если это локальная история…

А что если так получилось, что к вам прилетела эта замечательная задача пройти 2-х, 3-х летний путь всех этих мучений? Будет тяжело, и не раз вам прилетит от бизнеса на нижней фазе, когда всё разломано, а новое ещё не построено, плюс ещё и дорого: вам нужно это всё обосновывать. Так вот, о таких вещах, лучше договариваться на берегу. Это значит, что у вас должно быть джентльменское соглашение с руководством и гарантированно выделенный вам бюджет и на железо, и на людей. Потому, что вам понадобится и оверхед по людям, все эти новые дополнительные позиции: и у системных администраторов, и у тестировщиков, кто автоматизацией будет заниматься, и в разработке. Потому что у вас обязательно часть ресурса разработки уйдет на процесс на Agile, и часть ресурса уйдет на то, чтобы такой редкий, ценный, очень осознанный человек занимался синхронизацией. Вам нужен будет бюджет, поэтому об этом лучше договориться заранее. И периодически и регулярно возвращаться к этим договоренностям, напоминая, что это всё мы обсуждали с самого начала, и движемся, в целом, в рамках общего плана.

Ну, и если вы отважились и уже идёте по этому пути, то удачи вам!