Главная » Хабрахабр » Тёмная сторона 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 Интересное!

[Из песочницы] Валидация сложных форм React. Часть 1

Для начала надо установить компонент react-validation-boo, предполагаю что с react вы знакомы и как настроить знаете. npm install react-validation-boo Чтобы много не болтать, сразу приведу небольшой пример кода. import React, from 'react'; import {connect, Form, Input, logger} from 'react-validation-boo'; class ...

[Перевод] Микросервисы на Go с помощью Go kit: Введение

Эта статья — введение в Go kit. В этой статье я опишу использование Go kit, набора инструментов и библиотек для создания микросервисов на Go. Первая часть в моем блоге, исходный код примеров доступен здесь. Когда вы разрабатываете облачно-ориентированную распределенную систему, ...