Тёмная сторона agile
Внимательный читатель листает ленту и задает вопрос: «Что, опять текст про agile?». Ага.
Эта статья — о процессах, технических аспектах и немного о том, как agile живет и внедряется в Яндекс.Деньгах. Если вы прошли хотя бы половину пути до настоящего agile, какие-то вещи могут показаться вам очевидными, и это нормально.
Под катом про тестовые стенды, запирание людей в переговорках и про то, как управлять отделом, когда все разбрелись по командам и наслаждаются жизнью.
А еще внимательный читатель спросит: «Почему «Темная сторона»? Тут что, про Дарта Вейдера?» Увы, нет, речь пойдет о темной стороне Луны, которая была неизвестна человечеству, пока туда не прилетел аппарат, чтобы сфотографировать и показать ее всем.
Когда внедряете agile, вы составляете проект освоения Луны, не зная,
что на другой стороне
Все начинается с попытки внедрить новые процессы разработки.
Скрам, канбан, скрамбан или какой-то еще местный велосипед — не так важно.
Во главе классических отделов разработки обычно сидит ресурсный менеджер. Он говорит окружающему миру: «Не ходите к разработчикам, ходите ко мне, я сейчас тут все распределю». Однажды такой менеджер впервые выделяет поток, потому что появился какой-то особенный заказчик. Потом таких заказчиков внутри и вне компании становится больше, начинаются конфликты, борьба за ресурсы, а менеджеру приходится все это разруливать. Тоже выделением потоков.
Java — налево, JavaScript — направо
Эта игра продолжается до какой-то критической точки, после которой в компании принимают мысль о том, что вот сейчас-то точно нужен agile. Появляются продуктовые команды, потому что для PO нет ничего более ценного, чем выделенный ресурс и собственная команда. Продакт оунеры довольны, потому что с живой командой проще отвечать за функциональность и нести бремя ответственности за PNL, трафик и прочие KPI.
Звучит корректно, но в реальной жизни все немного не так.
В большинстве классических отделов разработки выгоднее работать с монолитом. При этом все атрибуты прилагаются — релизный цикл в 3–4 недели, долгое тестирование и сборка.
Иногда монолит — норм
А вот выделенные команды так не работают. Вообще, мир пришел к микросервисам из-за того, что все начали переходить на небольшие команды и работать в них. Да, это приводит к тому, что код «расползается» и всё становится сложнее контролировать.
С другой стороны, мы ускоряем выпуск продукта, чаще выкатываем релизы, но упираемся в проблемы с тестированием. И их тоже нужно как-то решать.
Реформирование тестирования
Если у вас одна команда и один тестовый стенд — все в порядке, можете не переживать (или переживать, но по другому поводу). Часто в таких случаях он даже не считается чем-то критичным — так, дополнительный инструмент вроде почты или корпоративного чатика. Все внимательно следят за продакшеном, и им тоже нормально.
Если вы уже полетели на эджайловую Луну, то тестовый стенд это штука, которая будет тормозить весь процесс, и вот почему.
История из жизни: в одной компании энтропия вокруг agile начала расти слишком быстро. В этот момент тестировщики завели в календаре расписание единственного тестового стенда — они разбивали время на получасовые слоты и пытались как-то контролировать хаос.
Стендом, вообще-то, должны пользоваться 20 команд, но не могут,
потому что одна из них все сломала
Про тестовые стенды
Когда-то давно у нас было несколько монолитов, на каждый — по тестовому стенду, и все были довольны. Однажды мы сделали сложный проект по разделению стендов, выделили команды, и тогда стендов стало 20.
Сейчас их 70, но мы целимся в 200 — чтобы всем, даром, и никто не ушел обиженный.
Из диалога с админом:
— Скажите, а где же автоматизация деплоя?
— Выкладка раз в две недели занимает час, что мне здесь автоматизировать?
На деле так: (200 стендов + production) * (50+ компонентов) = Куча усилий на деплой.
Сейчас у нас более 50 компонентов, которые выкатывает робот. Если бы не он, то всем было бы плохо.
На этом этапе в компании, которая идет в сторону agile, появятся автоматизированные системы сборки и доставки на production, постепенно наладится работа в командах и показатели тоже вырастут — до 60–80 релизов в неделю, а каждый компонент будет релизиться 2–3 раза в день.
В этот момент все понимают, что система стала слишком большой, чтобы один человек мог охватить ее взглядом
В любой команде, которая поддерживает монолит, обязательно найдется пара старожилов. Они были здесь с самого начала и помнят все баги за всё время, помнят странные логические решения, которые продавил бизнес.
История из жизни:
«Вообще, нормально попробовать постучаться в клиента 3 раза, но этот клиент особый, и мы будем 100 раз стучаться, там поправочный коэффициент стоит, и не надо его, пожалуйста, трогать, он там не просто так».
На поддержание работы стендов уходит столько ресурсов, что эксплуатация становится «золотой» — умножьте все хозяйство на количество тестовых стендов, добавьте production, расстройтесь и позовите уже наконец админов.
Другой мониторинг
Админы придут и скажут: «У нас все покрыто мониторингом». Это прекрасно, но с одним уточнением — мониторингу хорошо бы быть кастомным.
«Железячные» метрики, объем потребляемой джавой памяти, температуры всех ядер всех процессоров — все это полезно, но не всегда помогает при инцидентах у клиентов. Бизнес-метрики тоже будут бестолковыми, если вы не сделали их кастомными. Мир сложен — редко бывает, что ваш идеальный API все идеальные клиенты используют идеально. Всё делают люди, и всем приходится подстраиваться — иногда клиентам под вас, иногда вам под клиентов.
Как на атомной электростанции
История из жизни: мы долго искали и починили баг у себя на проде. После этого у одного из клиентов сломалось несколько процессов, в которых этот баг учитывался.
В такие моменты приходится добавлять кастомный мониторинг, потому что без вычленения исключительных ситуаций и агрегации это просто не будет работать. Поэтому, кстати, так часто говорят и пишут про машинное обучение и сложные системы, которые определяют проблемы вместо человека.
Раз в полгода приходится проводить ревью мониторинга, потому что ожидания бизнеса со временем увеличиваются. Бывает так — в компании все построено и контролируется, а бизнес приводит нового клиента, которому нужен SLA на порядок выше. И вся история заново.
Если это побороть, то система будет работать достаточно хорошо во всех случаях, кроме «зонтичных» проектов.
«Зонтичные» проекты
Это, например, внедрение 54-ФЗ, когда государство говорит: «А перестройте-ка все кассовые процессы в стране». Или когда маркетинг оплатил проект, над продуктом еще работать и работать, а дедлайн настоящий, и за него потом расстреляют. Или когда просто приходит кто-то из топ-менеджмента, не важно по какой причине, и у него тоже есть проект с дедлайном.
Спойлер — мало кто на рынке понимает, как их делать. Можно покупать разные надстройки над скрамом и канбаном, можно читать истории успеха, но практика показывает, что делать такие проекты по теории себе дороже. К тому же все эти SAFE и LEAN дорогие административно и ресурсно, а еще требуют дорогих и сложных компетенций, которых на рынке нет.
История из жизни: Spotify — одна из образцовых agile-компаний. В какой-то момент они придумали семейную подписку, но не смогли ее реализовать из-за сложности в синхронизации и планировании между командами, у которых есть свой roadmap и планы. А через год семейную подписку выкатили Google и Apple.
Синхронизация и конфликты планирования
Основная проблема с «зонтичными» проектами — синхронизация всех участвующих команд. Она связана с тем, что люди не любят договариваться.
Это проявляется во многих вещах, начиная со скрама, когда люди не могут договориться в рамках одного ресурсного отдела. В agile приходится синхронизироваться и согласовывать всё происходящее с несколькими командами. И если в какой-то момент перестать требовать от всех совместной работы, то каждая команда возвращается в свой любимый темный угол и работает самостоятельно. Это ведет к провалу.
Лайфхак
Если осталось два месяца до очередного закона, или до рекламной кампании, или босс требует — возьмите людей из 4 команд, заприте в одну комнату, дайте еды и воды и контролируете. Это грубо, но работает. Потому что если пытаться заниматься синхронизацией в ограниченные сроки, вы провалите проект.
В целом, синхронизация нужна и без нее нельзя двигаться дальше. Она усложняет жизнь в проектах с понятным дедлайном и высокой критичностью — сроки плывут от 10% до 50%, а такое часто недопустимо.
Как этим руководить?
Классический руководитель в распределенном отделе не понимает, в чем его роль, потому что его учили парадигме «Я всем раздал задачи», а работать приходится с «У меня вообще нет людей, зачем я в компании?».
Хуже всего приходится контрол-фрикам, которые не пропускают ни одну задачу, решаемую отделом, устраивают двойные публичные код-ревью и контролируют буквально всё. Когда людей раздают в команды, они задают вопрос: «Зачем я здесь?». Ответ такой — затем, чтобы разработчики во всех командах менялись информацией, росли синхронно в одном направлении и система не расползалась.
Вообще, когда звучит такой вопрос, руководителя нужно или менять, или учить.
Учить потому, что многие руководители (у нас в том числе) вырастают из инженеров, и им никто никогда не преподавал soft skills. Мы считаем, что это важно, и однажды пришли к HR и попросили большой двухгодичный курс для руководителей — от основ до performance и нефинансовой мотивации.
Культура в IT
В agile есть ещё один тонкий момент, который касается организации команд. Когда разработчики договариваются о чем-то внутри команды, они могут начать отстаивать интересы команды, забывая об интересах компании.
Идеально, когда люди понимают, что вокруг их эджайловой Луны есть кто-то ещё — служба безопасности со своими требованиями; архитектура, которую не просто так придумали; другие команды, интересы которых нужно учитывать. Мы стараемся выявлять, взращивать и поощрять такое поведение.
Agile — верхушка айсберга
У этого пути есть важные характеристики.
Долго. Например, DevOps на рынке появился лет пять назад, а его внедрение сейчас обойдется в 1–2 года, в зависимости от размеров компании. Если начинать им заниматься, когда у вас очереди на тестовых стендах, то вам гарантированы полгода ада, потому что админы будут разрываться между всем.
Дорого. Внедрять agile и двигаться по этому пути можно только в случае, когда есть крепкий бизнес и крепкая компания, а вы понимаете, что в будущем все равно придется расти.
Нет людей. Для agile нужны новые компетенции, которых у людей пока не так много. Получается замкнутый круг — нет людей → все делается не очень хорошо → нет денег → неоткуда взять людей.
Три вывода
- Не надо трогать «классические» отделы разработки без необходимости. В Яндекс.Деньгах работает гибридная система — есть продуктовая команда, но есть отделы, которые эффективно справляются с работой без agile.
- Если у вас нет задачи перестраивать всю компанию, но есть желание или потребность сделать новый продукт по новым подходам быстрее, то иногда проще нанять аутсорсеров, которые работают по agile, и дать продакт оунеру внешний ресурс.
- Если IT-трансформация неизбежна, то обо всем лучше договариваться «на берегу». Стоит заключить некое «джентльменское соглашение» с руководством — что будет бюджет на железо, людей (на новые позиции сисадминов, тестировщиков и разрабов). В случае чего, возможно периодически возвращаться к этому соглашению и обсуждать, что и как было сделано.
У всего вышесказанного есть одна беда. Пройти этот путь целиком != прийти к успеху. Не пройти его = гарантированно прийти к провалу.
Но если вы уже в пути — удачи вам!
