Уже 15 лет я помогаю организациям перейти на agile. И вот что я заметил: в компаниях, которые пытаются внедрить гибкие подходы самостоятельно, неизбежно повторяются одни и те же ошибки. Причём больше всего от них страдают именно сотрудники.
У меня есть показательная история про одну организацию, которая до моего прихода уже какое-то время самостоятельно «нарезала» бэклог на спринты и не углублялась в суть гибкой разработки, из-за чего видела только верхушку айсберга.
Как это выглядело
Во-первых, некоторые церемонии — ретроспективы, стендапы и планирование спринта — проводились формально. По расписанию, да. Но менеджер тратил первую половину встречи на рассказ о KPI, а к моменту, когда пора было переходить к важным вопросам, время заканчивалось, и все участники просто расходились. Никакого пространства для обсуждения реальных проблем не было.
Во-вторых, внутри компании ощущалось сильное сопротивление изменениям, причём не только от сотрудников, но и от топ-менеджеров. Некоторые просто не понимали, зачем им вникать в новые процессы, если «всё и так работает».
В-третьих, руководители искренне верили, что делают всё правильно и выбирали те части agile, которые по описанию были похожи на то, что им нужно. И честно выполняли все пункты от А до Б.
Взгляд «снизу»
В одной из продуктовых команд я познакомился с разработчиком Славой. Отдел, в котором он работал, ещё полгода назад полностью придерживался последовательного подхода к разработке — принципа водопада. А после самостоятельного внедрения Scrum всем сотрудникам пришлось подстраиваться под новые организационные требования, которые постепенно обрастали свежими слоями регламентов и новыми workflow в Jira. Но не давали результата.
И вот что Слава рассказал мне:
«Нас разделили на «кросс-функциональные» команды. То есть теперь мы работаем в группах по 7 человек вместе с тестировщиками и аналитиками. Конечно непривычно, но удобно — можно решать вопросы «здесь и сейчас» и не бегать по разным отделам. Сели, обсудили и быстренько сделали.
Ещё мы стали разбивать задачи на user stories — что нужно сделать и зачем с точки зрения пользователя, и перестали зашивать слишком много требований в одну задачу. Короче, смогли быстрее доводить до ума отдельные фичи. Это конечно плюс.
Но были и минусы
Да, формально мы собираемся на планирование спринта и утренние стендапы, но приоритеты всё равно спускают «сверху» и не учитывают нашу скорость работы и потенциальные риски. В итоге требования к нам прилетают почти так же, как это было до перехода на Scrum.
Недавно во время планирования спринта я предложил сократить объём фич или отложить часть до следующей итерации, но услышал: «Сделайте как-нибудь, уложитесь в дедлайн, а потом обсудим». Но понятно, что после завершения спринта никто ничего обсуждать не собирался.
С одной стороны, нас подталкивают брать на себя ответственность, а с другой — сваливают противоречивые требования. При этом почти никогда не спрашивают, как нам проще и эффективнее их выполнять.
Получается такая не смешная шутка:
Проджект: Как успеть сделать все фичи к релизу?
Разраб: Давайте удалим локализацию на испанский и push-уведомления с обновлениями.
Проджект: Мы не можем этого сделать, мы уже пообещали это заказчикам!
В итоге работают выгоревшие разработчики, на которых лежит ответственность за все проблемы. Хотя у нас нет ни нужных инструментов, ни условий для их решения. При этом мы должны уложиться в сроки, а они никак не соотносятся с работой, которую нас просят выполнить. Мы просто устали жить в двойной реальности: на бумаге у нас agile, а по факту тот же водопад с постоянной чехардой в приоритетах и процессах».
И это проблема не одной команды, и не одной компании
Аджайл — это, по сути, не «каждые две недели релизить новые фичи», а процесс постепенной трансформации культуры компании: учиться вести непрерывный диалог и доверять команде самостоятельно принимать решения.
В agile-манифесте сказано, что люди и взаимодействие важнее процессов и инструментов. Однако сотрудники, которые наблюдают трансформацию «снизу», никак не приблизятся к философии гибкой разработки и не принесут новых результатов, пока компания не начнёт по-настоящему работать над культурой взаимодействия между ними.
Поток уже унёс проблему дальше
Основной минус водопадной модели в том, что у заказчика постоянно меняются хотелки по ходу проекта. Хорошо было бы знать заранее, как будут меняться требования к продукту, который мы разрабатываем, но это нереально:
«Пользователям удобнее видеть вкладку «Задачи» слева, а не сверху. Еще нам нужна интеграция вот с этой системой. И перекрасьте кнопку в синий».
Просто представьте, что слышите такое на демо после того, как завершились все этапы разработки. Знакомая ситуация? А теперь давайте как-то подпишем акт и согласуем с заказчиком, в какие сроки мы будем это дорабатывать.
Модель водопада хороша, например, в строительстве — там мы на этапе проектирования можем сделать все чертежи и 3D-модель здания. Тем самым почти до нуля снизив риски, что заказчик в процессе передумает или захочет что-то изменить. Например, вместо 5-этажки построить 24-этажный дом. Но в разработке ПО всё немного иначе.
Меняйте направление, когда захочется
Чтобы дать разработчикам больше пространства для манёвра и помочь справиться с постоянным вращением флюгера, и появился agile-подход. Пользуясь гибким методом управления проектами, вы будете чаще получать полезную обратную связь от заказчика, поэтапно собирать все хотелки, и улучшать продукт до релиза. Кстати, именно аджайл принёс с собой понятие MVP (минимально жизнеспособного продукта), который помогает быстро протестировать гипотезы, и при этом экономить бюджет.
Но когда компания хочет внедрить не ценности agile, а только его внешние атрибуты, то продолжит также выходить за рамки сроков, как это было при каскаде. Новый результат появится только при продуктовом мышлении.
Гладко было на бумаге, да забыли про овраги
Если так трудно внедрить гибкий подход правильно (судя по тому, как много компаний делают это неправильно), может, логичный вывод в том, что, хотя идея и крутая, на практике она просто не работает?
Многие компании под лозунгом «мы делаем аджайл» продолжают старую каскадную культуру и, естественно, сталкиваются с несотыковками. Но если подходить к изменениям системно и последовательно, то вы быстро совершите квантовый скачок, как Citibank.
В России многие крупные бигтех-компании давно перешли на agile: МТС, Тинькофф, Сбер, Яндекс, VK, Авито, HeadHunter — и это только часть списка. Однако, учитывая, что в таких компаниях работают сотни команд, не всем из них удается полностью внедрить гибкий подход, и в некоторых до сих пор возникают вышеописанные проблемы. Но всё поправимо.
Чтобы стать гибкой компанией, ваш руководитель — CEO (или директор департамента) — должен не только понимать необходимость перехода, но и сам активно подавать пример. Если сотрудники увидят, как изменилось поведение их лидера, и как изменились требования и ожидания от их работы, то они сами будут охотнее участвовать в планировании спринтов и проведении стендапов.
Мы не делаем ошибок, мы создаем возможности для улучшения
Agile и waterfall — как яблоки и помидоры. Они оба красные и оба очень полезные, но вы можете их не любить, и с этим ничего не сделать. Каждый из подходов эффективен по-своему, и если пользоваться ими без понимания различий, то в лучшем случае получится модель спринтов в рамках привычного процесса.
Но и не стоит упрощать выбор между аджайл и водопадом, полагая, что один метод подходит всем и всегда, а другой — только когда все гладко. По-настоящему заметные результаты получаются при системном внедрении каждой из методик целиком — не только на уровне инструментов, но и в соответствии с ее принципами.
Отсюда и возникает впечатление, что agile «не работает». Если компаниям не нравится результат внедрения аджайл, значит, они неправильно его используют. Или их продукт больше подходит для каскадной модели, как в примере с домом, что на самом деле тоже неплохо.
Дмитрий Лобасев
Managing Partner консалтинговой компании OnAgile
А как у вас проходил процесс перехода с на Agile? Насколько спокойно вы это пережили?
Комментарии (46)
AVSDoom
28.01.2025 11:57О да, мтс "перешел" на аджаил как и сбер на уровне внешних атрибутов) Как было там совковое управление без документации, планирования и родмапов так и осталось... истории когда все завязано на техлиде который постоянно накидывает правки потому что у него сроки по его кпи горят - нормальное дело, а постоянные полугодичные защиты проектов перед топ менеджментом делает абсолютно бессмысленным планирование дальше чем на пару спринтов...
ldmitry Автор
28.01.2025 11:57Да, вы правы - это специфика крупной огранизации, ее практически невозможно целиком дотащить до уровня крутой продуктовой компании. Главная причина - много руководителей (так как компания огромная), и у каждого свой опыт и свое видение как правильно.
Но как человек, который начинал Agile-движ в МТС в 2015 году, могу вас заверить - тот МТС что есть сейчас и тот, который был 10 лет назад - это просто небо и земля. В разработке было прямо совсем плохо, ровно как и в Сбере того времени.
sse
28.01.2025 11:57Если компаниям не нравится результат внедрения аджайл, значит, они неправильно его используют.
Нет, необязательно. Это значит, что то, что получилось, не соответствует их ожиданиям, даже если внедрено правильно. Например, стало сложнее бюджетировать, сложнее вести наём, и это не окупается более быстрым внедрением изменений в продукт
ldmitry Автор
28.01.2025 11:57Да, отличное замечание! Недавно я работал с компанией, вот там изменения процессов остановилось на моменте, когда культура начала реально изменяться от авторитарной (все решения принимает директор) к культуре сотрудничества (каждый на своем уровне начинает задавать вопросы - а правильно ли мы делаем, а может лучше сделать вот так?).
Директор начал понимать, что теряет привычные ему рычаги управления и просто решил для себя, что это ему не подходит, лучше оставить как было.
koreychenko
28.01.2025 11:57На самом деле в этой статье автор "проговорился", упомянув, что "у заказчика постоянно меняются хотелки".
Если заказчик "внешний", и продавливает хотелки, которых не было в первоначальном договоре, то это значит, что у менеджера проекта не хватило яиц подписать доп соглашение на дополнительную работу.
Если заказчик "внутренний", то тут даже ничего подписывать не надо - вся работа через тикеты и если будут вопросы "Почему так долго/дорого" всегда будет понятно кто виноват.
Выбор между аджайлом и водопадом это не вопрос способа управления, на самом деле. Это вопрос неопределенности.
Когда у тебя есть осмеченный типовой проект дома, зачем там аджайл? Берешь и делаешь!
Но представим, что нужно построить дом для инопланетян о которых ты ничего не знаешь. И вот тут врубается аджайл. На первой итерации мы предполагаем, что они примерно как люди и строим дом как для людей. Прилетели.... Оказалось, что они ростом 3 метра.
На следующей итерации переделываем все дверные проёмы, окна, кровати и и.п. Надеюсь аналогия понятна.ldmitry Автор
28.01.2025 11:57Все так - весь вопрос в неопределенности. И если добавить сюда еще "мягкость" software, то есть возможность менять что угодно в коде условно достаточно дешево, то мы и получаем ситуацию, когда в любых проектах по разработке ПО разумно применять именно agile подход.
koreychenko
28.01.2025 11:57Не-не, не надо мягкость на сову натягивать. Есть огромное количество областей, в которых софт это прям буквально отлитая в граните штука. Начиная от авионики, автомобильного ПО и прочих систем с высокой критичностью, заканчивая всякими прошивками станков, которые так просто не обновишь. Ну и прочие штуки, живущие в закрытых контурах. Например, банки, госы, военка. Так что не все то мягкое, что софт :-)
ldmitry Автор
28.01.2025 11:57Я бы здесь поспорил немного.
Софт с высокой критичностью заставляет нас особенно внимательно подходить к вопросам его качества в плане багов и незадокументированного поведения - это факт.
Но давайте возьмем для примеру автопилот на машине. Критично? Очень. Отлит ли код в граните - вряд ли, иначе бы автопилоты не развивались семимильными шагами.
А вот процедуры QA такого кода точно супер-формальные и многоступенчатые, иначе никак.
dkfbm
28.01.2025 11:57Основной минус водопадной модели в том, что у заказчика постоянно меняются хотелки по ходу проекта.
Наоборот. В "рафинированной" водопадной модели заказчик и исполнитель встречаются дважды: при подписании ТЗ, и потом акта приёмки. Заказчик не видит текущего состояния продукта и никакие хотелки у него возникать не могут в принципе. В реальности чуть иначе, но всё равно базовая идеология сохраняется: мы делаем ровно то, что заказано, а если заказчик ошибся в требованиях, то это его проблема.
А вот в эджайле регулярные изменения хотелок не просто возможны – они ещё и приветствуются, ибо целью является поставка максимальной ценности заказчику.
DMGarikk
28.01.2025 11:57а как в аджайле дедлайны ставить?
у меня тоже такое было, делали учетную систему, дата сдачи отчёта через неё, условно 1 мая, постоянно вносим изменения хотелок и 20 апреля на отдельной встрече спрашиваем - ну что, 1 мая стартуем как планировали?...а у нас последние 5 спринтов шрифты в заголовке двигали и выгрузку в пдф прикручивали, вместо основного функционала..потому что ТЗ то нет..и продукт делаем в процессе..а сроки еще полгода назад все поехали..но ктож за ними следит то
DMGarikk
мне оч нравится фраза
"Сотрудничество с заказчиком важнее условий контракта"
Это вытекает что "делаем сейчас на все деньги, а потом обсудим изменений условий контракта"...а потом "как так что проект стал дороже на 100500млн? неее!! мы это оплачивать не будем!!"
AVSDoom
Жаль что в суде это не работает) что прописано в контракте должно быть реализовано либо формализовано доп. соглашениями какими то...
DMGarikk
что? это какраз "сотрудничество важнее" не работает, работают только условия контракта
если там самовольно без ТЗ исполнитель чёто напилил, это будут проблемы исполнителя
AVSDoom
Я про это и говорю) Сотрудничество хорошо в рамках ТЗ, не более...
koreychenko
Только не говорите, что подписывался контракт на разработку определенной функциональности за фиксированный бюджет, а делался он по скраму и по факту по T&M
DMGarikk
а как вы можете разрабатывать чтото без фиксированной вилки бюджета? подрядчик прожрет всё бабло и ничего не сделает в такой реальности, у него нет мотивации делать иначе
koreychenko
В договоре фиксируется стоимость часа разработки, постановка задач в трекере с оценкой там же, а дальше - любой каприз за ваши деньги.
DMGarikk
пока общий бюджет не кончится
у меня вот такой проект достался, 2 года разработки "вот вам безлимитное бабло, пилите", а на выходе нет даже интерфейса человеческого...и "оно както работает, но мы еще ниразу не запускали на реальных данных"...два бл.. года... капризы программили.
тут заказчик виноват конечно, но ограничения ТЗ и бюджетов еще и заказчика дисциплинируют, иначе работа никогда не будет закончена
koreychenko
А причем тут аджайл? T&M подход к бюджетированию и аджайл подход к управлению не должны превращаться в "психбольница в руках пациентов".
Кто всем этим безумием управлял-то?
Если взять канонический рафинированный скрам, то там декларируется, что "каждый спринт должен добавлять ценность". Грубо говоря мы каждый спринт чего-то выкатываем и в идеале проверяем на реальных пользователях. Вдруг мы выкатили то, что не заходит и разрабатывать его дальше смысла нет. Как могло получиться, что "мы что-то пилили два года и все еще не допилили и никто не видел что там у нас получилось"?
AVSDoom
Мне кажется все так работают) Заказчик хочет получить фиксированную функциональность за понятные деньги, а лиды повсеместно внедряют скрамы т.к. это "круто, модно, молодежно" и в итоге получаем запоротой проект или поделку на коленке со свистелками, как это нравилось заказчику который постоянно лез в разработку т.к. "Сотрудничество с заказчиком важнее условий контракта"
DMGarikk
ну как, "команда всем управляет, люди важнее процессов" (с)
ценность, а кто ставит приоритеты? команда где аналитик и ПМ не следят за роадмапом (который не нужен?), а каждый спринт новую вводную приносят
Это когда продукт позволяет так сделать, такое не всегда возможно, а в заказной разработке особенно.
тут вопрос в том что аджайл как концепт прокатит только если продукт уже есть, живой, работает и у него полноценный rolling release цикл есть и разработка под него подстроена и клиенты тоже
ну заказчик видел, ему нравилось, а когда дело до запуска в проде дошло, оказалось что клиенты заказчика вообще не понимают что это такое и как с этим работать...по частям всё что хотелось реализовано, а чтобы этим пользоваться надо учёную степень иметь.
koreychenko
В смысле "продукт уже есть". Он сам откуда-то возник или его все же кто-то сделал?
То, что вы описали - это классический бардак. Тут дело не в скраме.
DMGarikk
а как вы предлагаете делать продукт, если первый десяток спринтов его нельзя тестить на пользователях?
а скрам бардак скрывает и никак с ним не борется
я был в команде где аджайл и скрам работал, и будучи самоназначенным тимлидом бегал по другим командам в попытках както структурировать то что мы делаем...потому что ...такой бред получался в глобальном смысле...вплоть до того что 3-4 команды пилят одно и тоже с разным названием и от разных аналитиков...клиенты (от конкретных ПМов) очень довольны, а архитектурно получается такая мешанина...потому что есть направление, а ТЗ и прочего такого лишнего не было
koreychenko
Мы же вроде начали с того, что у вас был проект, в котором за 2 года вообще ничего сделано не было. Ну, возьмите спринты не недельные, а двухнедельньные и назначьте демо для стейкхолдеров через 2 спринта. Пусть PO и стейкхолдеры посмотрят что там получается. Может и не на пользователях тестировать, но есть же фокус группа, внутренний заказчик и всё такое.
А водопадный подход не исключает эту ситуацию. Здесь очевидно, что недостаточно хорошо построена коммуникация между командами, во-первых, и недостаточно продуман роадмап во вторых. Ну и плюс оказалось, что у владельцев продукта пересекающиеся зоны интереснов (что странно немного).
DMGarikk
я попал на проект где такое было, меня взяли чтобы "всё это *дство исправить"
а так то там и демо были и даже клиентов умудрились найти и продать одному (что вылилось в срочном пилении на коленке минимальной версии нашего продукта с нуля, потому что то что было - пользоваться этим было невозможно))
можно много умных слов говорить, но аджайл без контроля, превращается бесконтрольный бардак, особенно в сложных проектах где разные модули делают разные команды с разными бюджетами и представителями заказчика. когда держать в голове весь продукт целиком у конечных разработчиков - невозможно, каждый отвечает за свой модуль...но никто не отвечает за всё сразу потому что это не вписывается в концепцию и налагает бюрократические процедуры
я это уже наблюдаю на втором проекте, на первом оно так работает долгие годы и команда сама себе мины замедленного действия пилит, а в другом мне пришлось стать тем кто следит за всеми ветками разработки сразу, чтобы попасть рамки когда проект должен НАКОНЕЦТО заработать
koreychenko
Дык все без контроля превращается в бардак. Тут я прям ваще не спорю :-) Просто не надо всякий бардак аджайлом называть, тогда и недопонимания не будет.
GospodinKolhoznik
Суть аджайла не в том, чтобы выигрывать суды. И не в том, чтобы уложиться в бюджет. И вообще ни в чём. Суть аджайла в том, что сотрудничество с заказчиком важнее согласования условий контракта.
koreychenko
Суть аджайла в том, чтобы на выходе получить продукт идеально соответсвующий критериям, которые неизвестны в начале разработки. Пример - стартап проверяет гипотезы. Если все известно заранее, то аджайл там нафиг не нужен.
GospodinKolhoznik
Почему вы так думаете?
koreychenko
Почему я что именно думаю? Что если нет неопределенности, то не нужен аджайл? А зачем он там?