Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 7
Статья отличная, но слишком сложная для новичков, у которых почти не было опыта работы.
Было бы лучше добавить побольше определений (например вы сказали минусы 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 ответа на мой изначальный вопрос так и не нашлось. Я ведь спрашивал не про то, какие метрики вообще бывают, а как вы лично на практике решали эту проблему. Видимо, реальным кейсом поделиться не выйдет.
В любом случае, картина окончательно ясна. Спасибо за уделенное время, вопросов больше не имею!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum — не серебряная пуля. Почему «натянутый» Scrum на несколько команд ломает продукт — и что работает вместо него