Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
Статья отличная, но слишком сложная для новичков, у которых почти не было опыта работы.
Было бы лучше добавить побольше определений (например вы сказали минусы SAFe и Scrum@Scale не описав их суть).
Конечно статья, как я понял, написанна не для новичков, но мне всё равно было интерестно её читать.
Спасибо за отзыв! Замечание принимаю - статья писалась для тех, кто уже успел поуправлять несколькими командами, поэтому местами она тяжеловата.
Попробую простыми словами объяснить то, что в статье осталось за кадром:
SAFe - это способ организовать работу очень большой компании, где над одним делом трудятся сотни людей. Он строит «этажи»: наверху решают, куда идём; ниже - большие группы команд; ещё ниже - сами команды. Все живут по общему расписанию: примерно раз в квартал собираются и вместе планируют следующий кусок работы. Плюс - сотни людей двигаются согласованно и руководству всё видно. Минус - очень много правил, ролей и собраний: легко увязнуть в процессе и растерять скорость.
Scrum@Scale - придумал один из авторов Scrum. Идея другая: не строить этажи, а соединять обычные Scrum-команды между собой. Представители команд регулярно встречаются и решают общие вопросы - и так на каждом уровне, до самого верха. Главное правило: добавлять новые встречи и роли только там, где без них по-настоящему больно.
Если совсем на пальцах: SAFe строит завод с цехами и регламентами. Scrum@Scale - сеть небольших бригад, которые договариваются между собой. А LeSS (про который статья) предлагает третье: вообще не добавлять лишнего, а наоборот - убирать.
Идею про версию «для входящих в тему» забрал в работу - возможно, сделаю отдельный ликбез с картой фреймворков и простыми определениями. Спасибо, что дочитали!)
Статья интересная теоретически, но хочется немного "приземлить" её на суровую реальность. Вы много говорите про масштабирование и сложные подходы.
Подскажите, а по каким метрикам вы оценивали реальную эффективность своей работы и работы команд при внедрении всех этих подходов? Если представить ситуацию, что команда не может оценить сложность задач (так как нет планирования/покера) и нет регулярной демонстрации инкремента бизнесу, как вы доказываете стейкхолдерам, что разработка эффективна и вы не жжете бюджет впустую? Были ли в вашей недавней практике случаи, когда выстроенный вами процесс признавался бизнесом неэффективным, и как вы с этим работали?
Спасибо, запрос справедливый - давайте приземлю)
Небольшая ремарка: как раз середина статьи - не теория. Восемь команд, разработка отдельно, поддержка отдельно, баг из прода съедает у инженера полтора-два дня спринта - это мой собственный департамент (правильнее сказать, реальная ситуация в нескольких компаниях из моего реального опыта), а не пример из книжки.
Но соглашусь вот в чём: в статье мало сказано, чем такая перестройка оплачена. Если совсем по-суровому:
Ни один фреймворк не внедряется «по книжке». В реальности берёшь принципы (один бэклог, команда отвечает за свой кусок от и до) и адаптируешь под своих людей, свой легаси и своё начальство. У нас тоже был не «чистый LeSS», а рабочая версия под наш контекст.
Самое сложное - не механика, а люди. Инженеры не хотят брать поддержку («я разработчик, а не саппорт»), менеджеры боятся потерять контроль, у кого-то привычная роль исчезает. На это уходит больше сил, чем на все схемы вместе взятые.
Если "мандата" на большую перестройку нет - и не надо «внедрять фреймворк». Начните с одной боли: например, объедините разработку и поддержку в одной пилотной команде на одном участке продукта - и посмотрите на результат через пару месяцев. Это приземлённее любого фреймворка и именно так оно обычно и начинается.
А какая реальность у вас - сколько команд, и что болит сильнее всего? Интересно прикинуть, с чего начинал бы я.
Спасибо за развернутый ответ! Вы совершенно правы, что самое сложное — это люди и сопротивление изменениям.
Вы спросили, какая реальность и что болит. Реальность как раз такая: есть процесс, в котором под предлогом адаптации постепенно “отвалились” оценка задач (команды не эстимируют) и общие демо.
Основная боль — бизнес начинает сомневаться в эффективности разработки, так как теряется прозрачность, а инженерам не хватает понимания ценности продукта, потому что они не видят итоговый инкремент.
Раз уж вы предложили прикинуть, с чего бы начали вы: как возвращать прозрачность и измерять эффективность в таких условиях? Как бы вы аргументировали бизнесу, что разработка работает хорошо, если нет классических метрик вроде burn-down, а результатами нельзя поделиться на демо? Проще говоря, какие бы метрики вы использовали?
Отличный вопрос - Вы нащупали самую больную и самую интересную часть темы. Отвечу развёрнуто, потому что коротко тут легко соврать.
Сначала соглашусь: если «под предлогом адаптации» отвалились и оценки, и демо, а взамен не появилось ничего, то тревога бизнеса абсолютно законна. Это не «бизнес не понимает Agile», это реальная потеря прозрачности, и её надо закрывать. Вопрос только - чем?
Возвращать burndown и story points я бы не спешил: они и раньше давали иллюзию контроля, а не контроль (хотя признаюсь, я истинный поклонник относительных оценок/SP, но...). Я бы заменил выпавшие «якоря» на более честные.
Прозрачность без оценок - flow-метрики. Throughput (сколько ценных задач реально довезли за период), cycle time/lead time (сколько задача живёт от старта до прода), WIP и work item age (что «застряло»). Story points не критически нужны (опять же повторюсь, я их очень уважаю, но как один из инструментов, который работает тогда, когда действительно есть в нём необходимость) - throughput считает готовое, а не гипотетические очки. Прогноз бизнесу даём вероятностно: «по нашей истории с ~85% эти N задач выйдут к дате». Это язык бизнеса: как быстро, как стабильно, когда.
Здоровье доставки - DORA-4: частота релизов, время изменения до прода, доля неудачных изменений, время восстановления. Это про систему и поток, не про людей. И наглядно показывает бизнесу, что «машинка едет ровно».
«Показать инкремент» - вернуть, но дёшево. Потерянное демо - вот это реальная потеря. Не обязательно возрождать живое демо каждый спринт: хватит короткого async-чейнджлога «что вышло и какую ценность несёт». Дёшево и закрывает сразу и прозрачность, и вторую вашу боль.
Связать инженеров с ценностью. Раз «не видят инкремент» - в каждой задаче фиксируем «зачем» и ожидаемый эффект, а после релиза возвращаем команде цифры использования/adoption и отзывы клиентов (здесь, в том числе, в очень большой степени зависит от прОдукта (Product Ownera) - его постоянной работой с продуктом (в т.ч. и после релиза фичи) и взаимодействия с командой). Инженер, который видит, что его фича живёт - сам себе мотивация.
Про «измерять людей». Тут практика на удивление единодушна: мерить стоит систему, поток и исходы - не выработку конкретных людей. SPACE (Microsoft/GitHub), DORA и свежий DX Core 4 прямо предупреждают: индивидуальные output-метрики (строки, коммиты, velocity на человека) гарантированно геймятся (закон Гудхарта) и рушат командную работу. Даже McKinsey в 2024 попробовали продать «продуктивность на разработчика» - и получили публичную отповедь от Кента Бека и практиков ровно за это. Для человека метрики полезны как зеркало для роста, а не как линейка для оценки.
И, пожалуй, главное - важнее любой конкретной метрики то, кто ею владеет и зачем. Метрика, которую команда выбрала сама и крутит, чтобы улучшать поток - работает. Та же метрика, спущенная сверху как инструмент контроля, превращается в театр: её начинают рисовать, а не улучшать. Поэтому первый шаг: не «внедрить метрику», а договориться, что измеряем ради решений, а не чтобы кого-то поймать. Хорошее руководство даёт команде найти и обкатать то, что реально работает в её контексте, и спрашивает за исход, а не диктует единственно верную линейку сверху.
Вы, по сути, накидали план моей следующей статьи - «прозрачность и метрики без story points». Честно уместить её в комментарий не выйдет, так что, с вашего позволения, разверну отдельно. Спасибо за по-настоящему хороший вопрос!)
P.S. Отдельно отмечу: приятно видеть бэкенд-разработчика, который так предметно копает в управленческие метрики - обычно этим по-настоящему проникаешься уже из кресла руководителя. Если метите туда, то Вы заметно впереди графика 🙂
Спасибо за ответ. Правда, выглядит он скорее как хорошая выдача нейросети по запросу “современные метрики в Agile” :) Жаль, что за теорией про DORA и SPACE ответа на мой изначальный вопрос так и не нашлось. Я ведь спрашивал не про то, какие метрики вообще бывают, а как вы лично на практике решали эту проблему. Видимо, реальным кейсом поделиться не выйдет.
В любом случае, картина окончательно ясна. Спасибо за уделенное время, вопросов больше не имею!
Спасибо! Отвечу коротко - Вы, кажется, уже всё для себя решили)
Уточню лишь, что те пункты выше и были моим личным порядком действий, просто без имён команд и внутренних цифр бывшего работодателя (в публичный комментарий их не выношу - это профгигиена, а не отсутствие кейса).
Рад был обменяться; вопросы реально помогли докрутить будущую статью. Успехов! 🙂
P.S. а насчёт «похоже на нейросеть»: если структурно и со ссылками читается как «слишком гладко», то приму за комплимент. За гладкостью года практики, а отсылки - чтобы Вы не верили мне на слово.
С тезисом согласен: Scrum слишком часто обвиняют в последствиях карго-культа, компонентных команд и локальных KPI. Восемь команд могут идеально провести восемь спринтов и всё равно не выпустить работающий результат. Но это уже не проблема Scrum – организация сама разрезала ценность между подразделениями, а потом пытается склеить её церемониями.
А вот переход от диагноза к рецепту у вас получился слишком быстрым. «Несколько команд и один продукт» ещё не означает автоматически LeSS плюс Team Topologies. Сначала надо доказать, что это действительно один продукт, определить его границы, владельца результата, полномочия Product Owner, характер зависимостей и причины, по которым команды не могут передавать ценность end-to-end. Иначе повторяется та же ошибка, только лекарство теперь называется не Scrum, а LeSS: решение уже выбрали – осталось найти под него болезнь.
Спасибо за Ваш комментарий! И да, Вы правы в главном: я сжал шаг между диагнозом и рецептом, а он-то и есть самый важный, а в статье он подан слишком коротко. Кратко постараюсь исправиться здесь, ниже:
На практике до LeSS я вообще не дохожу, пока не пройден ровно указанный гейт. Первый вопрос - это правда один продукт или несколько потоков ценности, склеенных организационно? Проверка простая: релиз имеет ценность, только когда все команды выкатились вместе или команда способна довезти ценность своему пользователю сама? Если второе, то это не масштабировать Scrum, а наоборот, расщеплять то, что продуктом никогда не было.
Дальше уже идет Ваш список целиком: границы продукта, единый владелец результата, реальные полномочия PO (а не прокси без полномочий, "на бумаге") и, конечно же, природа зависимостей. И решение/лекарство абсолютно разное: организационные лечатся feature/stream-aligned-командами, а вот структурные командами не лечатся в принципе (там надо расцеплять систему или честно платить за координацию).
Но самое интересное, но и ироничное здесь в слендующем: LeSS сам "отказывается стартовать", пока не отвечены именно на те вопросы, которые Вы перечислили в своем коменте: "что есть продукт" и "кто тот единственный PO с властью приоритизации". Так что Ваша критика не против LeSS - это первый гейт честного LeSS (и правильно начинать искать болезнь ровно тогда, когда этот гейт проскакивают!).
Спасибо большое за действительно глубокий разбор (редкий по качеству)!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum — не серебряная пуля. Почему «натянутый» Scrum на несколько команд ломает продукт — и что работает вместо него