Этот переезд называется SAFe (Scaled Agile Framework).

Если Scrum — это джаз-банд в прокуренном кабаке, где трое играют, а один фальшивит, то SAFe — это симфонический оркестр государственной филармонии. Музыкантов сотня, дирижеров пятеро, ноты утверждены в министерстве, и импровизация карается расстрелом (или увольнением, что при ипотеке одно и то же).

Вот как устроен этот колосс.

1. Метафора: Поезд, идущий в никуда (Agile Release Train)

В Scrum была команда. В SAFe придумали ART (Agile Release Train) — Поезд Релиза.

Это не просто метафора, это диагноз. Представьте себе состав, в который загнали 5–10 команд (человек 100–120). Все они должны ехать в одну сторону и с одной скоростью.

• Если одна команда (вагон) сойдет с рельсов — под откос летит весь состав.

• Остановить поезд нельзя. Он едет по расписанию, которое называется Program Increment (PI).

• Обычно этот PI длится 8–12 недель. Это время, за которое поезд должен доехать от станции «Мы ничего не понимаем» до станции «Вроде работает, но трогать страшно».

2. Главный спектакль: PI Planning

Раз в два-три месяца случается событие, по масштабу сравнимое с первомайской демонстрацией. Называется PI Planning.

Сгоняют всех: программистов, начальников, заказчиков и тех, кто просто зашел погреться. Два дня подряд сотня людей в душном помещении (или в Zoom, что еще хуже, так как нельзя выйти покурить с коллегой) планируют будущее.

• Суть ритуала: Команды пытаются угадать, что они будут делать следующие три месяца.

• Доска зависимостей (Program Board): Это такой алтарь SAFe. На стену вешают ватман, лепят стикеры и соединяют их красными нитками.

  Выглядит это как схема раскрытия мафиозного заговора в дешевом детективе. Красная нитка означает, что Вася не может начать работу, пока Петя не закончит свою, а Петя ждет, пока Коля вернется из запоя.

Задача мероприятия — убедить руководство, что красные нитки не затянутся у нас на шее.

3. Новые персонажи (Роли)

В Scrum было трое. В SAFe, как в бюрократическом аппарате, количество начальников растет в геометрической прогрессии.

1. RTE (Release Train Engineer).

   Это Скрам-мастер, который вырос, заматерел и перестал улыбаться. Начальник поезда. Его задача — свистеть, махать флажком и следить, чтобы вагоны не отцеплялись на ходу. Он управляет хаосом на уровне сотни людей. Человек с железными нервами и, вероятно, язвой желудка.

2. Product Management (Управление Продуктом).

   Один Владелец Продукта (PO) уже не справляется. Появляется целая каста менеджеров. Они решают, куда едет поезд. Простые смертные разработчики их видят редко, как небожителей.

3. System Architect (Системный Архитектор).

   Человек, который знает, как в теории всё это должно работать. Он рисует красивые схемы облаков и микросервисов. Когда схемы сталкиваются с реальностью (легаси-кодом 1998 года), Архитектор обычно грустит или говорит: «Это детали реализации».

4. Уровни (Levels)

SAFe любит иерархию.

• Team Level (Уровень команды): Тут всё по-старому. Сидят ребята, пишут код, ругаются на дейли. Их жизнь почти не меняется, только давления больше.

• Program Level: Тут живут менеджеры среднего звена и RTE. Тут решают судьбы фич.

• Portfolio Level (Портфель): Самый верх. Там сидят люди в дорогих костюмах и делят бюджеты. Слов «рефакторинг» и «технический долг» там не знают. Там знают слова «Стратегические Темы» и «ROI».

5. Инновации и Планирование (IP Iteration)

В конце каждого квартала есть специальная итерация — IP (Innovation and Planning).

По задумке авторов методички, в эти две недели команда должна заниматься образованием, инновациями и отдыхом.

В реальности (как и в Советском Союзе) в это время мы в мыле доделываем то, что не успели за предыдущие два месяца. «Инновация» заключается в том, чтобы придумать, как сдать сырой проект и не покраснеть.

Вместо морали

SAFe — это попытка натянуть уютный свитер Agile на слона корпорации. Свитер трещит, слону неудобно, но выглядит солидно.

Если вам говорят: «У нас SAFe», знайте: будет много встреч, много красивых слов, красных ниток и длинных таблиц в Excel. Но в глубине, под толщей этой бюрократии, всё так же сидит одинокий программист, который просто хочет, чтобы его код скомпилировался без ошибок.

И в этом, пожалуй, есть какая-то надежда.

Другие подобные рассказы тут https://dovlatov-ai.web.app/

Scrum — это не спорт и не ругательство. Это способ коллективного выживания в условиях неопределенности. Суть его сводится к простой мысли: лучше ошибаться часто и понемногу, чем один раз и фатально.

Вот как это выглядит изнутри.

Действующие лица

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

1. Владелец Продукта (Product Owner). Человек с фантазией. Он знает, что мы делаем, но понятия не имеет, как. Его задача — хотеть. Хотеть много, сразу и желательно вчера. Он приносит список требований, который деликатно называют Бэклогом, хотя правильнее было бы назвать его «Списком несбыточных надежд».

2. Скрам-мастер. Это не начальник. Начальников мы не любим. Это, скорее, массовик-затейник с грустными глазами. Он следит за тем, чтобы ритуал соблюдался. Чтобы никто никого не убил во время спора. Он убирает препятствия. Например, если у программиста закончился кофе или вера в человечество, Скрам-мастер должен это исправить.

3. Команда (Developers). Люди, которые работают. Молчаливые, угрюмые профессионалы. Они превращают фантазии Владельца в суровую реальность кода. Их задача — сделать так, чтобы оно заработало, и уйти домой вовремя (что почти никогда не удается).

Метафизика оценки: Часы и Сторипоинты

Самый тонкий момент — оценка труда. В часах измеряют тюремные сроки и время до закрытия винного отдела. Творческую работу в часах измерять пошло.

Поэтому придумали Story Points (SP). Это такие условные «попугаи».

• Суть: Мы не говорим: «Я буду делать это два дня». Мы говорим: «Эта задача тянет на 5 попугаев».

• Почему так? Потому что человек слаб и со временем у него сложные отношения. А вот сравнивать он умеет. Сказать, что одна задача в два раза гаже другой — это мы можем.

• Числа: Используют числа Фибоначчи: 1, 2, 3, 5, 8, 13... Почему их? Чтобы жизнь медом не казалась.

  • 1-3 SP: Ерунда. Дело на перекур.

  • 8 SP: Придется попотеть. Возможно, пожертвовать выходным.

  • 13 SP: Это уже не задача, это эпопея. Ее нужно рубить на куски, иначе она раздавит вас своим величием.

Часы мы оставляем для интимных подробностей. Когда спринт уже начался, и вы наедине с собой планируете день — тогда считайте часы. Но заказчику про часы ни слова. Он все равно переведет их в деньги и расстроится.

Ритуалы (Events)

Жизнь в Scrum делится на отрезки — Спринты. Обычно это две недели. Две недели надежды, завершающиеся неизбежным дедлайном.

1. Планирование (Planning). Собираемся и играем в покер. Серьезно. Называется Planning Poker. Берем задачу. Каждый кидает карту с цифрой (те самые попугаи). Если у одного «3», а у другого «13» — начинается беседа. Один утверждает, что там работы на час, другой — что там надо переписывать вседро. Истина, как обычно, где-то посередине, но ближе к пессимизму.

2. Ежедневный Скрам (Daily). Пятнадцать минут позора каждое утро. Стоя. Говорим три вещи:

   • Что я сделал вчера (обычно — меньше, чем хотел).

   • Что сделаю сегодня (обычно — больше, чем смогу).

   • Что мне мешает (обычно — всё).

3. Обзор (Review). Конец спринта. Показываем, что наработали. Важно: показывать надо работающую вещь, а не презентацию. Заказчик тыкает кнопки, хмурится или радуется. Мы стоим, потеем и ждем вердикта.

4. Ретроспектива. Самое русское мероприятие. Сидим, говорим о судьбе. Вопрос «Кто виноват?» стараемся не задавать. Задаем вопрос «Что делать?». Решаем, как в следующем спринте жить лучше. Обычно решаем меньше курить и писать чистый код. В следующем спринте, конечно, все повторяется, но сам разговор имеет терапевтический эффект.

Вместо эпилога

Есть такое понятие — Velocity (Скорость). Это сколько «попугаев» команда умудряется прожевать за спринт. Сначала цифра скачет, как курс валют. Потом стабилизируется.

Главное в этом деле — Definition of Done (Критерий Готовности). Договоритесь на берегу: что значит «Сделано». «Сделано» — это не «я написал, вроде компилируется». «Сделано» — это «проверено, протестировано, залито, и за это не стыдно».

Вот, собственно, и весь Scrum. Система простая, как граненый стакан, и такая же необходимая для душевного равновесия в коллективе

Другие подобные статьи тут https://dovlatov-ai.web.app/

Спустя несколько сотен тысяч GPT-токенов, несколько милионов нервных клеток, десятка промптов и строгой декларации порядка проведения первого планирования удалось заставить их вести себя нормально, а не как зажравшаяся команда сбежавшая из BigTech. Теперь это действительно похоже на хорошее разбиение задач. По моим подсчетам, стоимость в отличии от реального планирования примерно в 304 раза меньше. Правда все равно придется раскошеливаться на новые токены. Не представляю, что меня ждет, когда им придется не общаться, а делать уже реальную работу

Привет, дорогой читатель! Хочу поделиться историей о том, как за 6 лет работы тимлидом в разных компаниях я понял, что наибольшую эффективность работы команды стоит ждать тогда, когда ты служишь своей команде. Сейчас объясню на примерах.

Кстати, термин «servant leadership» ввёл в 1970-х годах Роберт Гринлиф в своём эссе «Слуга как лидер». Он работал топ-менеджером в AT&T, и я понял то же, что и он, только спустя полвека.

Статья – чисто моё мнение и видение ситуации исходя из опыта. В роли тимлида я руководил различными командами: от 1 разработчика до группы из 20 человек (разработчики, тестеры, аналитики).

НАЧАЛО ПУТИ: ОТ ОДНОГО РАЗРАБА ДО ДВАДЦАТИ

Когда я дорос до тимлида, я попал в классическую ловушку. Думал: «Ну всё, теперь я главный, буду раздавать указания и следить за их выполнением». Но реалии были таковыми, что выполнять задачи – это полдела, а вот делать их эффективно – это надо попотеть и примерить на себя роли психолога, «старшего товарища» и лидера, которому доверяют коллеги, кто может свободно общаться с начальством о нуждах команды. По сути, такое связующее звено между эффективной командой и заказчиками. Это и есть суть servant leadership – служить команде, а не командовать ею.

Эту-то эффективность и надо выстраивать тимлиду, приводя команду к максимальной точке эффективности. Микроменеджмент долой!

К слову, обязанности тимлида, руководителя проекта и руководителя продукта в небольших компаниях переплетаются.

АВТОМАТИЗАЦИЯ РУТИНЫ

Первое, что я стараюсь сделать в этой роли – избавить команду от рутины. Настроить автоматизацию в Jira: сценарии для создания задач, автоматические переходы по статусам, уведомления, шаблоны новых задач. Разработчики, тестировщики и аналитики перестают тратить время на заполнение полей вручную, а рабочий процесс по описанию задач поставлен на рельсы.

Дальше берусь за GitLab (а в основном его сейчас используют) – включил линковку задач Jira с MR, проверки code style (линтер + SonarQube), запуск тестов. Также, MR проверяется в полуавтоматическом режиме с помощью AI.

Для тестировщиков будет удобным настроить систему логирования ошибок в проде – Sentry.

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

Таким образом, команда получила больше времени на то, что действительно важно – на написание кода. И, хочу заметить, что всё это должен проконтролировать тимлид (ну и техлид, если имеется).

ЗАЩИТА КОМАНДЫ ОТ НАЧАЛЬСТВА

Отдельная история – это утилиты для сбора статистики по работе сотрудников. Начальство любит цифры, и мы их должны предоставить. Вместо того, чтобы заставлять разработчиков писать отчёты – обычно автоматизируются выгрузки отчётов о закрытых задачах, времени их выполнения в разрезе по каждому разработчику. Всё это можно настроить через Jira API, либо платные плагины. Получилось «два в одном»: менеджмент доволен красивыми графиками, а команда не отвлекается на отчётность.

РИТУАЛЫ БЕЗ ФАНАТИЗМА

Насчёт стандартного набора тимлида: дейлики, ретро, планирование с Planning Poker. Главное – не переусердствовать. Всё для команды, а не команда для процессов. Если какая-то практика не работает, меняем или убираем.

Встречи 1-на-1 могут оказаться особенно эффективными. Не для контроля, а для понимания проблем каждого разработчика и их решения. Особенно, если все на удалёнке и встречаетесь только на дейликах.

Также хорошей практикой будет совместный поход в бар/квест с коллегами.

SCRUMBAN КАК КОМПРОМИСС

Насчёт методологий – никто в чистом виде их не использует. Обычно в моей практике получается так называемый Scrumban – помесь Scrum и Kanban. Почему? Потому что чистый Scrum слишком жёсткий для фронтенда (особенно когда постоянно прилетают «горящие» задачи), а чистый Kanban не особо предназначен для планирования.

Scrumban даёт гибкость Kanban с планированием из Scrum. Команда может быстро реагировать на изменения, но при этом не теряет фокус на основных целях спринта.

ВСЁ ВЫШЕ И ВЫШЕ И ВЫШЕ…

Отдельный навык servant leadership – это умение защищать интересы команды перед руководством. Когда разработчик хорошо работает, но по каким-то причинам не получает повышение зарплаты, моя задача – это исправить.

Готовлю аргументы, собираю метрики производительности, иду к начальству и «выбиваю» повышения. Не всегда получается, но попытки нужно делать. То же касается и обновления оборудования, или повышения в должности. После ответа руководства для самого разработчика перспективы работы в этой компании будут видны чётче. Команда должна знать, что тимлид на её стороне, что тимлид первым принимает удары и берёт ответственность за подчинённых и их ошибки.

Разбор ошибок с командой – всё это делается на общих встречах, а частные проблемы разбираются один на один (не при всех).

ПОЧЕМУ ЭТО РАБОТАЕТ

Servant leadership работает по простой причине: когда разработчики видят, что ты работаешь для них, а не против них, они начинают работать лучше. Не из страха, а из уважения и желания не подвести.

Плюс, такой подход снимает множество конфликтов. Команда понимает, что тимлид – это не «надсмотрщик», а партнёр, который помогает решать проблемы и защитит, если необходимо.

ЗАКЛЮЧЕНИЕ

За примерно шесть лет тимлидерства я понял: лучший руководитель – тот, кого не замечают, потому что всё работает как часы. Моя задача в роли тимлида – создать систему, где команда может эффективно работать без постоянного контроля и не отвлекаясь на посторонние дела.

Servant leadership – это не про мягкотелость или попустительство. Это про создание условий для максимальной продуктивности команды. И да, иногда приходится быть жёстким – но всегда в интересах команды, а не для демонстрации власти.

Если ты ещё не в деле – попробуй этот подход. Возможно, твоя команда станет не только эффективнее, но и счастливее. А счастливые разработчики пишут лучший код.

PS: Я не описал здесь про решение конфликтных ситуаций, но это тоже надо уметь делать деликатно. О чём будет одна из последующих статей.

Эту и другие мои статьи можно всегда обсудить тут «Life Developer. Статьи»