Внимательный читатель листает ленту и задает вопрос: «Что, опять текст про 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 нужны новые компетенции, которых у людей пока не так много. Получается замкнутый круг — нет людей -> все делается не очень хорошо -> нет денег -> неоткуда взять людей.

Три вывода

1. Не надо трогать «классические» отделы разработки без необходимости. В Яндекс.Деньгах работает гибридная система — есть продуктовая команда, но есть отделы, которые эффективно справляются с работой без agile.
   
2. Если у вас нет задачи перестраивать всю компанию, но есть желание или потребность сделать новый продукт по новым подходам быстрее, то иногда проще нанять аутсорсеров, которые работают по agile, и дать продакт оунеру внешний ресурс.
   
3. Если IT-трансформация неизбежна, то обо всем лучше договариваться «на берегу». Стоит заключить некое «джентльменское соглашение» с руководством — что будет бюджет на железо, людей (на новые позиции сисадминов, тестировщиков и разрабов). В случае чего, возможно периодически возвращаться к этому соглашению и обсуждать, что и как было сделано.
   

У всего вышесказанного есть одна беда. Пройти этот путь целиком != прийти к успеху. Не пройти его = гарантированно прийти к провалу.

Но если вы уже в пути — удачи вам!