Скрам — самый деструктивный карго-культ в российском IT

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

В целом можно сказать, что написать [почти] любой код не сложно. Сложно понять, какой код нужно написать, и грамотно организовать этот процесс.

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

И Аджайл, подразумевающий гибкий и постоянно меняющийся процесс разработки. Примерно на 60% аджайл в нашей  стране — это Скрам-методология. (Почитать о ней можно, например здесь -  Scrum,

Спойлер — в чистом виде ни та, ни другая методология в разработке сложных IT-систем не работает. Но… Скрам-методология не просто не работает, она еще и крайне деструктивна.

И прежде чем рассмотреть, почему она деструктивна, давайте посмотрим, какие есть IT-проекты.

Пять основных типов проектов

1. Простые проекты, с простыми задачами и почти полностью понятными требованиями.

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

2. Очень сложные проекты, с огромным количеством интеграций, большим количеством зависимостей, сложным функционалом, но более-менее качественно, полно и понятно описанными бизнес- и функциональными требованиями.

Это не значит, что каждая запятая должна быть досконально разобрана, обсуждена, согласована и описана. Достаточно, если есть эксперты, понимающие общую структуру проекта, архитектуру проекта, все крупные функциональные блоки, приоритизацию работ и доскональное понимание ближайшего плана работ на пару ходов вперед.

Достаточно редкий, к сожалению, тип проектов. Так как чем проект больше и сложнее, тем он больше содержит неопределенности. Но если такой проект находится, то он может быть реализован только по ватерфолу. Причем чем проект больше, тем больше он должен отходить от простого, линейного ватерфола и сдвигаться к гибридной итерационной форме ватерфола.

3. Простые проекты, с очень примитивными задачами, но… бизнес (здесь и далее под словом «бизнес» понимается коллектив бизнес-заказчиков для задачи) не понимает, что он хочет, а если ему кажется, что он понимает, то он не способен это адекватно изложить в требованиях, и их «требования» могут произвольно меняться несколько раз в ходе реализации проекта или даже одной задачи.

Примерно каждый первый (наверно) отдел маркетинга в крупных корпорациях состоит из сборища безголовых куриц, которые носятся по офису с криками «Хочу дождя», при этом вообще не понимая, что они на самом деле хотят. К сожалению, имел опыт работы с таким проектом. Это реальный трешь…

Я читал (и склонен с этим согласиться), что скрам был изначально придуман именно для решения проблемы по развитию корпоративных сайтов в ситуации, когда «творческие» личности постоянно вносят изменения в свои требования и их приоритизацию.

Без малейших сомнений, данный вид проектов имеет право на существование (Как говорится: «Иного бизнеса у меня для вас нет».) и может реализовываться только по Скрам-методологии. Только по более приземленной версии, крайне далекой от той, что расписывают инфоцыгане в скрам-гайдах. И нужно сказать, что это крайне депрессивный тип работы, заниматься которым могут только люди, которым абсолютно наплевать на свою работу и результаты. Сказали «Красим в синий цвет» — Покрасим. Сказали «Нет. Срочно перекрашиваем в зеленый». Пофиг, красим в зеленый. «Нет... давайте обратно в синий». Пофиг. Красим обратно в синий. Уважающий себя разработчик в таком режиме работать, конечно же, откажется.

4. Простые проекты, с очень простыми задачами, но… постоянно объективно изменяющимися требованиями к проекту.

Разница с третьим видом в том, что здесь изменения требований происходят не потому, что девочка-маркетолог не способна понять, чего она сегодня хочет, а по внешним независимым, объективным причинам. Рынок меняется, регуляторы чудачат, партнеры по интеграции все время меняют функционал и так далее. На самом деле, так как каждая задача по отдельности понятна и достаточно проста, то все это легко реализуется в рамках итерационного ватерфол-подхода. Но если будет вменяемая команда, привыкшая работать по скраму, — это тоже вполне допустимо. И в данном случае смена требований не является депрессивной. Возможность быстро отреагировать на объективное изменение требований — это предмет гордости для такой команды.

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

Зачастую это усугубляется тем, что основная бизнес-идея, заложенная в проект, изначально является бредовой и нереализуемой.

Вишенкой на торте выступают инвесторы или топ-менеджеры, бегающие вокруг процесса с криками: «Давайте скорее дайте нам MVP (продукт с минимальной ценностью), чтобы опередить конкурентов, а уж потом будем думать».

Такой проект в принципе вообще не должен быть реализован, потому что, как известно, попытка автоматизации хаоса не приводит к автоматизированному порядку. В случае успеха она приводит к автоматизированному хаосу. Правильным действием в данном случае является привлечение команды бизнес-аналитиков-экспертов, которые попробуют понять цели, стоящие перед компанией, насколько они вменяемы и достижимы. И в случае их адекватности могут попробовать свести проект пятого типа к проекту второго типа. После чего проект может быть реализован по гибридной ватерфол-методологии.

К огромному сожалению, именно в проектах пятого типа проявляется огромный реальный вред от карго-культа наших топ-менеджеров. Ведь найти аналитиков экспертного уровня — крайне сложно. Можно нарваться на команду полупрофессионалов, которые будут красиво петь на презентациях, но после полугода-года работы дадут результат крайне низкого качества. Или как вариант, они окажутся реально экспертами и попробуют объяснить, что идеи, предложенные генеральным директором (девочкой, назначенной по причине того, что она любовница основного акционера), являются запредельно бредовыми. Это прям вообще недопустимый вариант работы экспертов.

И поэтому, когда инфоцыгане (Аджайл-коучи, то есть) рассказывают о том, что проблемы IT-департамента связаны исключительно с тем, что они не используют волшебную Скрам-методологию, — то им очень хочется верить.

И действительно существует четыре причины, почему топ-менеджеры обожают скрам.

Первая причина: Как раз потому, что менеджеры знают, что их бизнес — это сборище куриц. (Ну, с точки зрения IT-проекта, во всяком случае. Исключения бывают, и вполне можно встретить бизнес-менеджеров, которые прекрасно понимают, что и как нужно сделать (Настя — Привет!), но… это скорее исключения), и топ-менеджеры уже имеют печальный опыт попытки сделать какой-либо продукт с этим бизнесом как с заказчиком.

Но Топ-менеджеры знают, что других бизнес-сотрудников у него нет и не будет. Да — эти девушки и парни, возможно, не гении, у них, скорее всего, отсутствуют навыки критического и аналитического мышления, но в условиях узкой специализации каждый из них удовлетворительно, а иногда и блестяще справляется со своей основной работой. И поэтому существует вторая причина любви к скраму…

Вторая причина: Это как раз чистый и незамутненный карго-культ. Это когда топ-менеджеры проводят «Дейли-скрам-митинг» на 150 человек на два часа (коллега мне рассказывала о такой реальной ситуации), когда менеджер с умным видом спрашивает: «А вы точно на дейли-митинге задаете «Три Главных Вопроса»?». А почему вы называете «Демонстрация для бизнеса»? Обязательно нужно называть «Скрам Спринт Ревью».

То есть люди искренне верят, что если из фанеры и бамбука сделать самолет, то он принесет новую хорошо работающую CRM. Главное, чтобы он был сильно-сильно похож на самолет.

И как же не верить, когда вполне профессиональные инфоцыгане объясняют, что решением проблемы является современная, прогрессивная, западная («Западная» — понимать надо) методика, которая в разы лучше «совкового» ватерфола и позволяет успешно решить проблемы «слабой зрелости бизнес-заказчиков» (так вышеозначенная проблема с курицами называется на языке инфоцыган).

И это дает нам третью причину для любви.

Третья причина: Топ-менеджеры обожают успешный успех. И они обожают быть вовлеченными в процесс создания успешного успеха.

Что такое разработка по ватерфолу с точки зрения топ-менеджера? Как правило, это выглядит как череда сплошных проблем и неудач… Почему? А все очень просто… В любой компании проекты конкурируют между собой. Ну просто потому, что количество потенциальных проектов бесконечно (нет пределов совершенству), а количество ресурсов всегда конечно. И как следствие, люди, заинтересованные в инициации и успехе проекта, склонны на этапе планирования занижать трудоемкость, сложность и сроки проекта. Или по-другому, через фильтр проектных комитетов склонны проходить проекты, которые выглядят более простыми, чем они есть на самом деле. Это объективный процесс. В нем бывают исключения, но в целом средний запущенный ватерфол-проект всегда недооценен по сложности.

И поэтому проект через некоторое время будет вынесен на рассмотрение топ-менеджеров с каким-то набором оправданий и просьбой увеличить бюджет, ресурсы и сроки проекта. На самом деле, объективно это нормально. Мы можем установить срок проекта в три месяца, затем дважды сдвинуть его на месяц, и за пять месяцев завершить проект быстрее и с лучшим качеством, чем если бы изначально поставили срок в шесть месяцев. Команды в таком режиме работают более собранно и производительно, но…, как я уже сказал, для менеджеров это выглядит как плохая работа и постоянные провалы. И что самое для него неприятное, даже если он сам понимает, что ничего страшного в таком подходе нет, у него есть вышестоящие начальники, которым он вынужден докладывать о переносе сроков проекта, и он крайне не любит выглядеть бледно и оправдываться за свой «плохой контроль» ситуации.

В сравнении с этим — скрам дает топ-менеджерам иллюзию быстрой и успешной работы. Скрам-команда берет краткосрочные обязательства, которые заведомо более-менее реализуемы. При этом команда не имеет никаких мотиваций работать качественно, потому что некачественная работа сегодня станет проблемой относительно далекого будущего (год-два-три вперед), и, скорее всего, конкретные разработчики уже и не будут работать в этой компании. Но зато команда имеет массу причин и мотиваций работать быстро и демонстрировать качественную работу. Демонстрация качества и скорости достигается за счет своевременного формального выполнения требований о приемке задачи (Definition of Done). Чистый постмодерн — «Не быть, а казаться».

И только цифровой бог знает, сколько при этом дерьма и костылей остается под капотом системы. В скраме это называется специальным термином «технический долг». Как правило, этот долг затем копится до ситуации, когда разгрести его уже невозможно… но это потом. И понимают это только IT-специалисты.

И, как я сказал, внешне это выглядит как непрерывный «успешный успех», и топ-менеджер имеет возможность докладывать наверх о прекрасной работе команды, постоянной поставке «ценности» на продуктив и прочем счастье. Для простых проектов это в принципе прекрасно… Команда работает, задачи решаются, выглядит это крайне красиво. Ну а то, что при наличии хороших грамотных бизнес-заказчиков и аналитиков этого можно добиться, затрачивая намного меньше ресурсов, — так ты еще попробуй найти тех аналитиков…

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

Четвертая причина: Скрам дает топ-менеджеру иллюзию управления процессом благодаря большому количеству метрик. Почти все они абсолютно ничего не измеряют, но их много, и они выглядят очень наукообразно.

Например — прекрасная метрика Time2market — время от начала разработки до выхода на рынок. О чем говорит метрика T2M, равная 90? Правильно, ни о чем. Ну, выводим мы в среднем за 90 дней идеи на рынок, ну и пусть. А о чем нам говорит изменение метрики в следующем квартале на 110? Правильно, опять ни о чем. А о чем нам говорит величина этой метрики, равная 80 у соседней команды? И снова правильно… снова ни о чем.

Почему? Потому что топ-менеджеры пытаются использовать эту метрику как показатель качества работы команды. Метрика стала больше, следовательно команда работает хуже. У другой команды метрика меньше, значит, они молодцы.

И это полный и незамутненный бред… Потому что на эту метрику влияют порядка десятка факторов (размер задач, текущий размер команды, приоритет задач, зависимости от других команд, сложность задач и т. д., т. д.), и качество или скорость работы команды — это только часть и не самая важная часть в расчете. Собрать все данные о влиянии всех факторов на изменение метрики просто невозможно. Как минимум, для этого пришлось бы несколько раз прогнать команду через машину времени, изменяя и измеряя влияние разных факторов. А без этого делать какие-либо выводы абсолютно бессмысленно. Но возможность задать вопрос «Почему изменилась метрика?» дает топ-менеджеру иллюзию влияния на процесс. Никто не знает, почему она изменилась, и какой она должна быть в этом квартале, и что нужно сделать, чтобы она стала другой. Для этого просто нет необходимых данных, но как приятно топорщить усы и строить команду за рост метрики.

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

Как видно, все причины «любить» скрам являются абсолютно бестолковыми, и чем более бестолковый топ-менеджер, чем он меньше понимает в управлении проектами, — тем больше он склонен любить скрам.

Почему не работают чистый ватерфол и чистый скрам

Как сказано в начале, ватерфол чистый и незамутненный не работает.

И причины следующие… Реализовать функционал системы, как правило, не сложно; сложно реализовать нужный функционал. Но бизнес обычно не знает, что нужно сделать, или не понимает, что он хочет, или потребности меняются раньше, чем закончен проект. В ватерфол эту проблему пытаются решить упором на предварительную тотальную аналитику, стараясь на первом этапе проекта написать «Войну и мир» на тему того, что нужно сделать. Эти несколько томов текста называют техническим заданием, которое потом месяцами (а иногда и годами) перепинывают из отдела в отдел для согласования и доработки.

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

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

Почему скрам не работает

Выше я рассказал, почему топ-менеджеры обожают скрам. Давайте теперь посмотрим, почему они должны ненавидеть скрам, почему скрам не работает.

1) Поверхностная аналитика.

И прежде всего это опять же проблема аналитики. Но если в ватерфол мы сталкиваемся с попыткой слишком жесткой, объемной  и «далекой» аналитики (зачастую из-под палки и без реального понимания, что делать), то в скраме мы получаем принципиальную ориентацию на решение краткосрочных и фрагментарных задач (так называемые юзер-стори) без глубокого понимания проекта и требуемой архитектуры в целом. Периодические поставки функционала в минимальном объеме помогают проверке гипотез и помогают бизнесу понять, что он хочет, но на длинной дистанции (в сложных проектах) это скорее мешает.

2) Развитие через MVP продукт.

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

На самом деле, эта картинка выглядит убедительной только для людей, которые совершенно не разбираются в процессе создания сложных IT-систем. Это так НЕ РАБОТАЕТ. Невозможно в системе сначала написать код под примитивную функциональность, а затем на его основе написать более сложную функциональность. 

В какой-то период, вы действительно будете пользоваться вполне приличным велосипедом, но в результате вы получите не автомобиль, а трехколесный пепелац с рамой от мотоцикла, колесами от москвича и кузовом от садовой тачки. И все это будет держаться вместе за счет многих километров «синей изоленты».

3) Отсутствие документации

Честно говоря, неактуальность документации — это проблема почти любого сложного проекта. Но в скраме неважность документации ставится как один из основных принципов. С учетом постоянной нехватки времени (всегда ведь «цигель, цигель, скоро демо») написание внятной документации откладывается в технический долг и почти никогда не реализуется. Как следствие, уход ключевых специалистов из команды может оказаться катастрофическим, так как никто не знает, как это все работает и какие костыли напихал под капот ушедший разработчик.

4) Слабая управляемость команды

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

Чаще набирают или слабых фуллстек-специалистов, или обычную команду из специалистов разного профиля и уровня.

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

В ситуации с обычной командой, она не может самоуправляться, так как роли каждого члена команды слишком отличаются. В такой команде должен быть квалифицированный режиссер, понимающий, кто, что, в какой последовательности должен делать, чтобы добиться хорошего результата и максимальной загрузки конвейера разработки. Это отдельная роль, отдельные навыки и, скажем, фронт-разработчик, как бы он не был хорош, не может квалифицированно управлять распределением задач. И голосованием (самоуправлением) такие функции так же не реализовываются.

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

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

5) Непроизводительные потери времени

По требованиям скрама, вся команда должна присутствовать на планировании спринта, на демо (ревью) спринта, на грумингах и т. д. Это вроде как дает нам самоуправление команды. В простых проектах, это приемлемо.

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

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

6) Заточенность на демонстрацию вместо реальности.

Как следствие, все вышесказанное приводит к тому, что команда не имеет возможности делать качественный, продуманный, оттестированный код. Но есть и хорошая новость: никто это от команды и не требует. Команда обязана в жестко обозначенный срок (окончание спринта двигать нельзя) продемонстрировать бизнесу, что они «достигли цели спринта», вывели на продуктив ценность (именно в таких терминах), и эта, прости господи, «ценность» внешне соответствует немногим заранее определенным параметрам приемки.

В результате скрам-команда…

- Во-первых, категорически отказываются делать что-либо, не входящее в их текущий спринт, даже если это действие обеспечит экономию сотен и тысяч часов на следующих этапах. У них на это всегда один ответ: «Нее… У нас спринт, у нас демо через три недели, у нас цигель, цигель, ай люлю… мы не можем об этом сейчас думать». В моей практике это, в частности, пару раз привело к тому, что коллеги вместо того, чтобы потратить сотню часов на ранней стадии проекта, потратили около двух-четырех тысяч часов на переделку на более позднем этапе. И это еще хороший вариант; в некоторых ситуациях последующая переделка уже просто невозможна. Но девиз «Мы подумаем об этом завтра» кажется наколотым на груди каждого истинного скрам-разработчика.

- Во-вторых, все, что под капотом скрам-разработки, — это, как правило, костыли, фекалии и солома. Так как требуется только показать, что программа работает в минимальном варианте, и показать срочно, то используются все способы упрощения жизни сегодня. Разумеется, что, как правило, это в ущерб жизни завтра.

Это весьма красочно описано, например, в этой статье -  Почему «мы потом перепишем» — это самая дорогая ложь?.

Почему скрам деструктивнее ватерфола

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

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

Какая альтернатива?

Аналитика, аналитика и еще раз аналитика.

Забудьте про скрам, забудьте про подход «Мы подумаем об этом завтра», «Мы потом все перепишем», «Нам нужна быстрая поставка ценности».

Что делать:

Если вы на старте проекта не понимаете, что вы будете делать, — не делайте ничего. Начните предпроектную работу, соберите нормальных бизнес-аналитиков и архитекторов.

Поймите, что вы хотите добиться (но не пишите многотомные подробные технические задания);

сделайте архитектуру системы «на вырост» с учетом всех будущих добавлений и развития;

делайте много «лишней» работы, никогда не говорите «Мы подумаем об этом завтра»;

стройте структуры данных и интеграции с полями, которые вам понадобятся «завтра»;

постройте план реализации всего проекта на годы вперед, но при этом степень детализации и глубина анализа должны плавно меняться: от максимальной на ближайшие полгода до поверхностной на период двух-трех лет.

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

Не ставьте количество найденных ошибок как метрику качества работы команды. Менеджеры это очень любят, так как это дает им очередную иллюзию управления процессом. На практике это приводит к тому, что команда теряет мотивацию к поиску ошибок (и их исправлению), и они копятся в коде системы. Метрикой может являться количество блокирующих ошибок, выявленных на продуктивной среде. Вот эта метрика должна стремиться к нулю, и так как ее выявление не зависит от команды, она не влияет на их будущую мотивацию.

Работайте двух-трех-шести месячными итерационными циклами, по завершении которых команда аналитиков, архитекторов и заказчиков должна собираться, переоценивать приоритизацию всех будущих задач, при необходимости вносить изменения в общий план работ, формировать план на ближайший период и работать далее.

В комментариях, конечно, появятся люди, которые скажут, что я не прав, и они лично видели успешно реализуемые скрам-проекты.

И я, конечно, в это верю. Я искренне верю, что где-то на просторах бесконечной вселенной существуют команды скрам-гениев, которые идеально реализуют сложный IT-проект. Я лично такое не встречал, но в конце концов, вселенная же бесконечна…

К сожалению, все остальные «успешные» скрам-проекты попадают в три категории:

1. Простые, примитивные (и не путайте "длительность" и "сложность") проекты, которые успешны несмотря на то, что делаются по Скрам-методологии. Это вполне нормально и ожидаемо. В некоторых случаях даже необходимо;

2. Так называемые «гибридные» скрам-проекты. И их довольно много. Это ситуация, в которой команда и реальный руководитель вполне осознанно работают по обычной итерационной ватерфол-методологии, но при этом для руководства демонстрируют все внешние признаки скрама (команда измеряет метрики, проводит скрам-события, делает поставки на продуктив через регулярные промежутки времени, называя это спринтами и т. д.). То есть для топ-менеджеров на краю поляны строят самолет по дендрофекальной технологии, а за ним команда спокойно работает над проектом. Успешность таких проектов (как и любых других) в большой степени зависит от качества аналитиков в проекте. Проблема только в том, что изображение скрама для руководства, само по себе требует затрат времени и ресурсов;

3. Ну и наличие третьей категории «успешных» скрам-проектов связано с тем, что почти любой скрам-проект выглядит успешным — ровно до того момента, когда он рассыпается под грузом непродуманных архитектурных решений, накопленных костылей и ошибок. Если ваш проект выглядит успешным и его реализуют грамотные аджайл-коучи прям по священным текстам скрама, значит, этот проект временно находится в стадии «успешного успеха».

Топ-топ-менеджерам компаний стоило бы с прищуром (как через прицел) посмотреть на своих IT-топ-менеджеров, и если они чего-то блеют про аджайл-трансформацию, внедрение святого скрама и поиск высокооплачиваемых жрецов аджайл-коучей, — то нужно взять палку и гнать этих менеджеров к чертям. А вместо них набрать тех, кто говорит о поиске высококлассных (и дорогих) бизнес-экспертов, бизнес-аналитиков и толковых руководителей проектов.

Вывод:
Скрам - прекрасная узкоспециализированная методология, предназначенная для разработки простых, примитивных проектов (с бюджетом до 30 миллионов в год) в ситуации, когда бизнес-заказчики не способны оперировать аналитическими концепциями более сложными, чем юзер-стори.

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

2025, Станислав Безгин