Главная » Хабрахабр » Тёмная сторона agile

Тёмная сторона agile

Внимательный читатель листает ленту и задает вопрос: «Что, опять текст про agile?». Ага.

Эта статья — о процессах, технических аспектах и немного о том, как agile живет и внедряется в Яндекс.Деньгах. Если вы прошли хотя бы половину пути до настоящего agile, какие-то вещи могут показаться вам очевидными, и это нормально.

Под катом про тестовые стенды, запирание людей в переговорках и про то, как управлять отделом, когда все разбрелись по командам и наслаждаются жизнью.

Тут что, про Дарта Вейдера?» Увы, нет, речь пойдет о темной стороне Луны, которая была неизвестна человечеству, пока туда не прилетел аппарат, чтобы сфотографировать и показать ее всем.

Когда внедряете agile, вы составляете проект освоения Луны, не зная,
что на другой стороне
А еще внимательный читатель спросит: «Почему „Темная сторона"?

Все начинается с попытки внедрить новые процессы разработки.
Скрам, канбан, скрамбан или какой-то еще местный велосипед — не так важно.

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

Javaналево, JavaScriptнаправо

Появляются продуктовые команды, потому что для PO нет ничего более ценного, чем выделенный ресурс и собственная команда. Эта игра продолжается до какой-то критической точки, после которой в компании принимают мысль о том, что вот сейчас-то точно нужен agile. Продакт оунеры довольны, потому что с живой командой проще отвечать за функциональность и нести бремя ответственности за 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 дорогие административно и ресурсно, а еще требуют дорогих и сложных компетенций, которых на рынке нет.

В какой-то момент они придумали семейную подписку, но не смогли ее реализовать из-за сложности в синхронизации и планировании между командами, у которых есть свой roadmap и планы. История из жизни: Spotify — одна из образцовых agile-компаний. А через год семейную подписку выкатили Google и Apple.

Синхронизация и конфликты планирования

Основная проблема с «зонтичными» проектами — синхронизация всех участвующих команд. Она связана с тем, что люди не любят договариваться.

В agile приходится синхронизироваться и согласовывать всё происходящее с несколькими командами. Это проявляется во многих вещах, начиная со скрама, когда люди не могут договориться в рамках одного ресурсного отдела. Это ведет к провалу.
И если в какой-то момент перестать требовать от всех совместной работы, то каждая команда возвращается в свой любимый темный угол и работает самостоятельно.

Это грубо, но работает. Лайфхак
Если осталось два месяца до очередного закона, или до рекламной кампании, или босс требует — возьмите людей из 4 команд, заприте в одну комнату, дайте еды и воды и контролируете. Потому что если пытаться заниматься синхронизацией в ограниченные сроки, вы провалите проект.

Она усложняет жизнь в проектах с понятным дедлайном и высокой критичностью — сроки плывут от 10% до 50%, а такое часто недопустимо. В целом, синхронизация нужна и без нее нельзя двигаться дальше.

Как этим руководить?

Классический руководитель в распределенном отделе не понимает, в чем его роль, потому что его учили парадигме «Я всем раздал задачи», а работать приходится с «У меня вообще нет людей, зачем я в компании?».

Когда людей раздают в команды, они задают вопрос: «Зачем я здесь?». Хуже всего приходится контрол-фрикам, которые не пропускают ни одну задачу, решаемую отделом, устраивают двойные публичные код-ревью и контролируют буквально всё. Ответ такой — затем, чтобы разработчики во всех командах менялись информацией, росли синхронно в одном направлении и система не расползалась.

Вообще, когда звучит такой вопрос, руководителя нужно или менять, или учить.

Мы считаем, что это важно, и однажды пришли к HR и попросили большой двухгодичный курс для руководителей — от основ до performance и нефинансовой мотивации. Учить потому, что многие руководители (у нас в том числе) вырастают из инженеров, и им никто никогда не преподавал soft skills.

Культура в IT

В agile есть ещё один тонкий момент, который касается организации команд. Когда разработчики договариваются о чем-то внутри команды, они могут начать отстаивать интересы команды, забывая об интересах компании.

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

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

У этого пути есть важные характеристики.
Долго. Например, DevOps на рынке появился лет пять назад, а его внедрение сейчас обойдется в 1-2 года, в зависимости от размеров компании. Если начинать им заниматься, когда у вас очереди на тестовых стендах, то вам гарантированы полгода ада, потому что админы будут разрываться между всем.

Внедрять agile и двигаться по этому пути можно только в случае, когда есть крепкий бизнес и крепкая компания, а вы понимаете, что в будущем все равно придется расти. Дорого.

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

Три вывода

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

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

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

Для тех, кто запоминает ушами

Этот текст — пересказ доклада техдира Яндекс.Денег Дмитрия Круглова на Agile Days. Если вам лучше послушать — вот видео.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Сетевой дайджест: 20 экспертных материалов о протоколах, стандартах и информационной безопасности

В эту подборку мы включили свежие посты, подготовленные специалистами компании VAS Experts. Главные темы подборки — сетевые протоколы, 5G и информационная безопасность. Под катом вы также найдете ряд рекомендаций по построению сетей операторов связи. / Pxhere / PD Про ИБ ...

[Перевод] Забудьте о мегаструктурах инопланетян: новые наблюдения объясняют поведение звезды Табби одной только пылью

Художественное изображение KIC 8462852, яркость которой за последние несколько лет менялась необычным образом Когда планета проходит перед её родительской звездой, если смотреть с нашей точки зрения, часть света звезды на некоторое время исчезает. Научная охота за планетами в XXI веке ...