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


    Три вывода


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

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

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

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


    Яндекс.Деньги 163,28
    Об электронных платежах и устройстве Я.Денег
    Поделиться публикацией
    Комментарии 10
      +1
      Хм, а дайте плиз совет.
      Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.
      Общие совещания — раз в полгода и дальше слов дело не идет.
      Внедрить GIT для всех разработчиков не получается, все завалены текущей работой.
      Есть ли способы как-то улучшить ситуацию?
        +1
        Ищите другую работу.

        А если серьёзно, то попробуйте объяснить шефу важность (и профиты) пользования гитом. Скорее всего, это не сработает, поэтому параллельно ищите другую работу.
          0
          Спасибо.
          Пройденный этап. Пояснял, оба говорят что нужно, да, вот разберемся с текучкой и сделаем.
          Уходить не хочет, плюшки вкусные.

          PS. Мопед не мой)
            0
            А что делают, на чем пишут? От чего офигевает новичок?
              0
              Пишут на дельфи, что именно — я не в курсе.
              Офигевает от культуры работы в целом, нет Гита, нет комментариев, нет документации, каждый работает со своими исходниками, никакой автоматизации и т.п.
                +4
                Так а в чем проблема, собственно? Такие команды иногда имеют запредельную эффективность. Оверхед 0. Пока конкуренты думают о том, как бы присобачить новый паттерн, фреймворк или тулинг, эти ребята генерят ценность. Иногда инвестиции в снижение бас фактора стоят дороже, чем сработавший бас фактор. Но, вообще, все от ситуации зависит.
          0
          Общие совещания — раз в полгода
          Всмысле эти три общаются раз в пол года?
            0
            Решают, что делать дальше, какие встретились или косяки.
            Вроде общих планерок.
              0

              Ну это если я поравильно понял такой feedback loop длинной в полгода? ;) Ну слов просто нет.
              Я думаю тут надо начинать с азов. Причем организация наверняка это может только Top down сделать… Как-бы с культуры начать.

          0
          del, промахнулся веткой

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

          Самое читаемое