Комментарии 36
В целом согласен, но...
"Несмотря на это, его часто пытаются использовать там, где этот подход совсем не нужен. Например, при разработке информационных или ERP-систем ... "
Вот тут я не соглашусь. В процессе разработки ERP системы частенько вылезают доработки или прочие штуки которые не были учтены. Можно сказать что это недостаток обследования - да. Но порой, подобные вещи нельзя предвидеть пока пользователи (или начальство) не начнут использовать части системы. Также, могу заметить, что частенько реализовываются фичи что потом почти не используются на практике (а в начале они казались очень нужными). Кроме того, при получения опыта использования системы, требования к ней могут поменяться.
О, спасибо за комментарий, учтем, просто обычно как раз связывают сложность работы по Scrum в этой области со строгостью структуры ERP-систем. Да, адаптировать можно, правда, судя по опыту, это не у многих получается)
Но тут согласна, немного некорректно выразились, речь скорее о сложности внедрения.
Безусловно у многих не получается! Потому что внедрение EPR оно хорошо ложится на водопад. Для применения данной методики, желательно, закладывать гибкость еще на уровне контракта. Подробней можно прочить в книге "Scrum. Революционный метод управления проектами" автор Джефф Сазерленд.
Не сложности, а ненужности внедрения. И да, системы такой сложности по скрам разрабатывать не рекомендуется и это плохой подход.
Для доработок в таких системах скрам подход как раз и не нужен.
Это обычная разработка с доработкой, багтрекингом и аудитами.
Работай по Scrum. Кажется, что эта методология стала слишком популярной
Это фреймворк
традиционный Waterfall стал мифическим
Всё. Ещё бы слово "стал" убрать)
причина может быть в частых вмешательствах или недовольстве заказчика
Но Scrum guide говорит, что PO - полноценный участник команды..
Несмотря на это, его часто пытаются использовать там, где этот подход совсем не нужен. Например, при разработке информационных или ERP-систем, а также при миграции инфраструктуры. Все это — крупные проекты, которые затрагивают всю компанию и требуют детальной документации.
В ходе разработки нет инкремента и поставки ценности? Это невозможно сделать итерационно? Тогда не подходит. Для разработки крупных проектов - как раз таки самое то, особенно при наличии неопределённости. А при её отсутствии смысл никуда не потерялся - завершать итерацию и смотреть на то, что сделано, получать фидбек - это дофаминовая игла, которая в любом случае поможет команде ехать в долгосроке
Ну и совсем не понятно, почему scrum только для поддержания существующих продуктов? Если речь про быструю инкрементальную поставку и получения быстрой ОС от пользователей с целью корректировки вектора, разве речь это всё не про стратегию стартапа?
~~~
Я это всё к тому, что да, согласен, никто нигде (по крайней мере, по отзывам других и опыту лучному) не использует скрам в том виде, в котором о нём идёт речь в скрам гайде. Но зачем вносить ещё больший разрыв в умы людям?
Спасибо за комментрий! Применение гибких подходов там, где высокая степень неопределённости ещё одно заблуждение. Поясню, перед тем как что-то разрабатывать нужно подумать: провести исследование рынка, опрос целевой аудитории, запустить пилот. Это подход Lean startup, а не Scrum. MVP или пилот зачастую можно провести вообще без поставки кода, на ручнике. Цель данного этапа - снизить неопределнность перед тем как инвестировать в разработку.
Когда мы говорим о больших системах, в которых работает вся компания внедрение одного модуля не имеет смысла так как сотрудник не будет 90% работы выполнять в софте, а потом переключаться на другой. Не говоря о взаимосвязях: если данные созданы в одной системе по одному формату их должна "съесть" съесть другая система. Поэтому инкремент в подобных системах настолько большой, что его невозможно поставить в один спринт, и не в два и даже не в три. Иными словами есть только два состояния: работает целиком, либо не работает вовсе. Всякие улучшения, доп хотелки и прочее конечно потом можно дорабатывать спринтами.
Применение гибких подходов там, где высокая степень неопределённости ещё одно заблуждение
Не совсем понял в чём заблуждение.
Гибкий подход означает, что он устойчив и приветствует изменения (любые). Изменения в скоупе, например, как раз таки рождаются из неопределённости. Гибкий подход на то и гибкий, а не хрупкий, чтобы процесс не сломался под весом этих изменений, а адаптировался. Неопределённость это самое первое, что толкает к использованию гибких подходов. Или я не правильно трактую смысл гибких подходов и неопределённости в проекте/продукте?
Поэтому инкремент в подобных системах настолько большой, что его невозможно поставить в один спринт, и не в два и даже не в три
Об этом и речь, что критерии "Большой инкремент" и "Большая ERP система" это не тождественные понятия
тут нужно очень аккуратно использовать термин "неопределенность". Когда у нас есть продукт и наша неопределенность состоит в том, что какая из новых фич лучше зайдёт аудитории, то гибкие подходы с A/B тестами подходят идеально. Когда же речь идёт о "неопределенности" продукт с какими характеристиками мы делаем, то это исследования, MVP и пилоты, которые помогут снять неопределенность, поэтому не важно какой подход мы используем в разработке, потому что до разработки мы даже не дойдём.
В большинстве случаев нужно планировать не то что лучше зайдет, а то что будет эффективно, надежно и полноценно выполнять заранее определенный функционал. Эксперименты с заходами или не заходами иногда плохо заканчиваются как для аудитории, так и для тех кто делает продукт или проект. Вот результатом таких экспериментов является постоянно меняющийся привычный дизайн разных чего-либо, что ломает и путает клиентов намного сильнее, чем то что по мнению постоянных переделывателей хуже заходит аудитории. Про небезопасность разработки скрам и говорить не нужно, это еще более очевидно. Что происходит с постоянно меняющимися архитектурами инфраструктур и приложений, которые от этого остаются вечно сырыми и необкатанными - понятно любому адекватному специалисту. И вские там потоковые тесты и аудиты тут мало чем помогут.
Скрам не предполагает изменения самого скрам-) Так что в топку сразу этот скрам с его враньем про якобы гибкость.
Может нюанс таится в том, что скрам, по определению, собственно Сазерленда, не жесткая неизменная структура? Может виновен не сам подход, а его кривенькое использование?
В одном из моих комментариях как раз говорится, что проблема не в фреймворке, а в бездумном его использовании и вольной трактовке.
Применение аджайл/скрам в корпоративной разработке - вот это и есть вольная трактовка.
В теории есть один продукт, который пилит одна команда. Где такое бывает? Наверно, в стартапах ситуация похожая.
В корпорациях, если разбить 70 человек на 10 "команд" - на выходе получаем те же самые "отделы". Ни один отдел за продукт целиком не отвечает. И точно так же - каждый отдел/команда старается про любую задачу сказать "это не к нам". Отсюда, необходим какой-то диктатор над "командами", который будет таки заставлять их брать задачи. В конечном итоге те или иные иерархические структуры выстраиваются, только вот к каноничному аджайлу/скраму они отношения не имеют уже.
всё верно. Иногда можно встретить статьи аля "менеджеры не нужны", вот у нас в компании всё работает без них и всё классно. Потом смотришь, а у них в компании всего работает меньше 100 человек. На таком масштабе действительно, можно собрать несколько самоорганизованных, высокомотивированных команд. К примеру телеграм развивает и поддерживает команда из 50 человек. А что делать если у тебя несколько сотен или тысяч сотрудников и зоопарк систем? Тут и появляются процессы, регламенты и менеджеры, которые координируют работу нескольких команд.
>>Тут и появляются процессы, регламенты и менеджеры, которые координируют работу нескольких команд.
И о том, как это сделать, ни в аджайле ни в скраме нет ни слова. Потому что эти методологии рассматривают только процессы внутри команды и между командой и заказчиком.
В результате, если внутренние процессы в компании выстроены приемлемо, уже не так важно, есть ли этот самый скрам, или нет его. А если внутренние процессы ужасные - никаким скрамом это не поправить.
Отсутствие менеджеров-это жестокое и глупое заблуждение. Просто вам менеджера подсунули под соусом скрам-мастера, да и сверху задачи спускаются со сроками и требованиями. Без менеджеров никуда, и это очевидный факт, который ну никак не вычеркнуть да и вычеркивать его нельзя, так как везде должна быть выстроена и четко работать иерархия подчинения, иначе будет хаос, как вот с многими случаями неграмотного и огульного внедрения этих присловутых гибких методологий, который больше вреда принесли, нежели пользы. и скрам все-таки в его нынешнем применении в большинстве мест-скорее больше похож на тоталитарную секту с жестким подчинением и динамомашину по выкачиванию соков из клиентов и работников, а вовсе не на рабочее пространство с якобы отсутствием бюрократии.
Проблема как раз во фреймворке - в том, что он навязывает свой процесс и заставляет встраиваться в этот фрейм, при том что сам фреймворк не смог (и, похоже, даже не пытался) адаптироваться к изменениям, произошедшим в разработке за последние 25 лет. В итоге он превратился в медленный, неповоротливый, бюрократизированный подход, который мало кто может с пользой применить - просто потому, что в 2025 году его в принципе невозможно применить с пользой. Это как если бы кто-то разводил кур, а я пришёл к ним со скрамом — ну нет от него пользы, хоть как его ни применяй.
Этот Сазерленд похоже просто агент ЦРУ и вредитель, которому была поставлена цель развалить многие организации путем внедрения этой неработоспособной заразы. Хотя конечно не исключаю полностью, что такой подход применим в очень ограниченных случаях, а вовсе не где попало и для чего попало.
>>Если у вас не получилось внедрить Scrum или любой другой подход, то это вина того, кто его внедрял
А если не получилось построить коммунизм, то это вина тех, кто его пытался построить.
Но как чистая теория и коммунизм и скрам выглядят красиво.
я писал в одном из комментариев, что внедрение Scrum или любого другого подхода - это овтетная реакция топ-менеджмента компании. Если решили остановиться именно на внедрении Scrum, значит на то была причина и аргументация. Подобные изменения затрагивающие всю компанию происходят не сами по себе, есть человек который отвечает за внедрение, поэтому я и пишу, что именно он отвечает за результат. Возможно на старте он или она могли не предусмотреть мероприятия, к примеру как будут бороться с сопротивлением в командах или не заручились поддержкой топ-ов на старте.
>>Если решили остановиться именно на внедрении Scrum, значит на то была причина и аргументация.
Кому-то из топов эту идею продали, потому что модно и "сейчас все так делают". Ну топ и сказал - "внедряйте".
>> поэтому я и пишу, что именно он отвечает за результат.
Тоже вопрос дискуссионный. Аналогия - допустим мне нужны резервные мощности электроэнергии. У меня потребление много киловатт, так что по уму - это нужно мощный дизельный генератор. Но допустим, что у меня ума нет, и я иду к продавцу ИБП на аккумуляторе. И этот продавец выслушав мои потребности, без тени сомнения продает мне свой ИБП, мол, отличная вещь, не пожалеете.
Должен ли продавец предупредить покупателя, что этот товар ему не подходит? По человеческой этике - должен. По продаванской этике - и так сойдет.
порой решения о внедрении(ВРЕДрении)) таких методологий принимаются в состоянии неполного понимания целей внедрения и без грамотного просчета сопутствующих рисков, например под воздействием неких навязанных извне стандартов и клише, основанных на каких-то общих современных тенденциях и трендах, которые вводят руководство в заблуждения, что очень часто приводит к печальным последствиям в конечном счете.
Ну так да. Вина на строителях, а не на теории
Просто бывает Скрам, а бывает Срам с сорри поинтами
На мой взгляд, ничто за последние 25 лет так не повредило индустрии, как скрам.
Спасибо за статью, однако я каждый раз надеюсь, что уже кто-то напишет о вреде скрама или, как минимум, о его бесполезности. Но и вы в конце подытожили, что скрам при каких-то условиях может кому-то принести пользу, словно скрам не может быть просто плохим и не решать заявленных задач.
А скрам плох сам по себе и 14 страниц скрам-гайда в лучшем случае бесполезны, а чаще всего приносят команде вред.
Скрам со своими спринтами и церемониями очень медленный и не поворотливый. То, что без него могло занять два часа, теперь превращается в два часа дискуссий о том, можно ли затянуть задачу в этот спринт или в следующий. Это бюрократизированная версия аджайла, которая проблемы коммуникаций или овнершипа решает процессами и ролями.
Я думаю, скрам популярен отчасти из-за того, что у него есть имя. Ведь если ты не работаешь по скраму, то как ты работаешь? Просто гибко или итеративно? А это как? Получается, если у тебя нет скрама, то ты делаешь непонятно что. Будто у подхода к разработке или менеджерских практик обязательно должно быть имя. Но его не должно быть. Если ты не хочешь зарабатывать на сертификациях — тогда да, нужно имя, а иначе — нет.
Отрезвление приходит с количеством прочитанных книг по менеджменту, в которых вообще не упоминается скрам. Возьмём хотя бы Software Engineering at Google. Только подумать: ни разу не упоминается скрам, как же они без него. Да вот так. Посмотрите какой-нибудь курс по менеджменту команд от Netflix — опять ничего про скрам. Если не скрам, то у них канбан что ли? Нет, не нужно давать процессу имя, если все понимают, чем они заняты, у задач есть описание, есть roadmap, инженеры умеют и хотят коммуницировать и знают, что такое ownership.
Всё началось с того, что когда Бог создавал аджайл, рядом были ребята со своим скрамом, и когда после встречи, давшей начало аджайлу, все разъехались по домам, ребята стали продвигать свой информационный продукт (первые в истории инфоцигане) как реализацию и готовый фреймворк для того самого аджайла. Хотя скрам появился до него, хоть и на той же волне и с тем же желанием перемен, ровно как XP, DDD и т.п.
Может, в начале нулевых скрам и давал что-то полезное командам, но индустрия в следующие годы сделала такой скачок, что скрам не смог адаптироваться и застрял в нулевых, когда у команд не было рабочего чата для синка с коллегами, когда нужно было демо раз в две недели, потому что CI/CD не были развиты, как сегодня. Да и код никто не писал с такой скоростью, поэтому быть заблокированным до следующего стендапа было приемлемо тогда, но не в 2025 году. И скрам всё это проспал.
Я пробовал применять скрам в разных проектах, пробовал контрибьютить в процесс как инженер, был скрам-мастером и менеджером, читал книги, пытаясь разобраться в причинах его бесполезности или вреда, который он приносил. Всё тщетно. Он просто плох как идея, подход и фреймворк – целиком и по частям. Максимальный вред он приносит, когда применяется целиком.
Наверное, спринт – самая заметная составляющая скрама. По какой-то никому непонятной причине спринт должен дробить непрерывный процесс разработки на куски. Без спринтов не было бы работы у скрам-мастера. В условиях, когда новый код попадает на продакшн каждый день или несколько раз в день, а небольшая фича, о которой решили во вторник, уже в пятницу на проде, ни спринты, ни скрам никак не коррелируют. Скрам очень медленный и просто не в состоянии успеть за современным ритмом. Если в скраме что-то перенесли в следующий спринт, то не факт, что оно будет сделано. И, конечно, будет сделано много того, чего не было в спринте. Какой-то план лучше отсутствия плана, но чем десяток или два тикета в топе бэклога на те же две недели, зачем все церемонии и страдания с определением цели спринта по 20 несвязанных тикетам?
Daily – тоже утратил свой смысл с появлением мессенджеров и первой версии Jira. Это особенно сложно, если команда находится в разных таймзонах. Часто команды пробуют замену в виде чат-бота, но его ответы никто обычно не читает, и люди перестают репортить, чувствуя бессмысленность этой церемонии.
Роли – тоже заметная часть скрама. Скрам-мастер – непонятная роль, под которую легко «захайрить» профи с сертификатами, который не умеет ничего больше, кроме как сдавать экзамены. Он отвечает за то, как применяется скрам, значит, и за максимизацию вреда. В команде, где есть два синьера (а не «три года и синьер»), он вообще не нужен – ему просто нечего делать, кроме как считать стори-пойнты на человека в спринте.
Продукт-овнер в реальности обычно ничего не знает о скраме и считает его игрушкой разработчиков. У скрама было 25 лет, чтобы как-то их втянуть на борт, но он не справился. В результате разработчикам приходится убеждать продукт-овнера в необходимости перехода с Java 1.4 на что-то поновее, будто он компетентен принимать такие решения.
Как же я буду без скрама, ведь оценивать задачи в стори-пойнтах привычно и удобно. Но только стори-пойнты – это не скрам, и, скорее всего, то удобное, что вы используете в своей работе и чем вы наполнили скрам, тоже не из него. От самого скрама – пользы никакой.
О том как жить без скрама вам расскажут:
https://youtu.be/CD0y-aU1sXo?si=XMrfzfUjFzORZHOP Eric Brechner
https://youtu.be/_GJuwesBCgc?si=uXfxXd4A89gltEua Артем Расскосов
Поддерживаю.
>>Роли – тоже заметная часть скрама.
И роли в скраме ужасны. Нет ролей аналитик или тестировщик (хотя в реальных скрам командах эти люди есть). Нет ролей джун или сеньор - в результате на дейлике голос джуна равен голосу сеньора, и только ПО должен над ними обоими выступать в как арбитр. А у самого ПО технического бэкграунда может не быть.
Ну, аджайл не предполагает отдельных ролей тестировщика и аналитика – считается, что разработчик сам должен тестировать свой код и разбираться с требованиями лучше любого. С чем я согласен. И если скрам позиционирует себя как аджайл фреймворк, то эти роли там и не требуются. Моя претензия к скраму в том, что лучше было бы вообще не иметь никаких ролей, ведь за 25 лет он так и не смог адаптироваться под ситуацию, когда продукт-менеджер не хочет играть по правилам скрама.
>>разработчик сам должен тестировать свой код и разбираться с требованиями лучше любого
На мой взгляд - аналитик все-таки нужен обязательно. Если задачи делают программист вместе с аналитиком - оба вникают, этим уменьшается "bus factor". Уволился программист - аналитик может быстро нового программиста ввести в курс дела, показать: "Вот это было сделано, смотри код в таких-то задачах. А вот это нужно будет сделать".
Уволился аналитик - программист может нового аналитика консультировать.
А если сбором требований занимается сам программист, после его увольнения картина плачевная. Новый программист начинает общаться с заказчиками, и заказчики испытывают дикую фрустрацию - он же их не понимает! А вот со предыдущим программистом все было так хорошо (конечно, после нескольких лет работы - притерлись).
В зависимости от команды аналитик может стать узким местом, когда от его знаний и решений слишком многое зависит. Он также может ограничивать инициативность или вовлечённость команды в решения - ведь есть “мамка” аналитик, которая может стать последним словом во всех спорах. Поэтому bus factor решают, например, парным программированием, а если без экстрима - то обычный код-ревью тоже минимизирует этот фактор. Или даже просто наличие документации помогает. Но и то что Вы говорите и я - это уже не про скрам - это про то, как продуктивно работать. И есть много способов, и скрам не один из них. Потому что Скрам - это только бестолковые церемонии и видимость процессов.
1) Код ревью - потенциально очень конфликтогенная практика. Лицам с синдромом вахтёра либо не завершившим ещё период подросткового самоутверждения - доверять ревью нельзя, только хуже будет.
2) Очень часто, по недостатку времени у ревьюера, он проверяет только технические моменты, такие как соответствие кода внутренним стандартам. Без погружения в бизнес логику.
Наличие документации рулит. Но в ситуации, когда программист сам с заказчиком поговорил и сам сделал - такой программист либо вовсе на доки забьет, либо напишет чисто формально. А когда по докам от аналитика надо разрабатывать, это влияет на их качество положительно.
Наверное, любая работа в команде - потенциально конфликтогенная практика (даже если команда — это я и AI). Я не работал долго в командах с "вахтёрами" и "подростками", всегда выбирал сильные команды, где хорошо платят мне и другим, и где умеют увольнять или развивать людей, поэтому кодревью никогда не было проблемой. Однако замечал, что почему-то качественную документацию часто никак не соотносят с уровнем seniority разработчика, и компаниям, конечно, стоило бы включать это в требования к тайтлу "синьор".
Сейчас ещё подумал, что аджайл, как и многие сборники рецептов, ориентирован на высокопроизводительные команды квалифицированных разработчиков - этими же людьми он и написан. Мечтаю когда-нибудь увидеть книгу: «Скрам, или Как управлять низкопроизводительной командой выгоревших синьоров с тремя годами опыта». Вот скрам для меня про это.
Любой эджайл - это не про качество и сроки, он предназначен для другого, это скорее методология отработки чрезвычайных ситуаций, а не способ плановой работы для получения высококачественного и полностью готового результата. Если тот же скрам используется не по назначению, а в большинстве случаев его таки используют совсем не по назначению, на выходе получается высокопроизводительный хаос, и не более того.
Скрам абсолютно или почти абсолютно неприменим в большинстве задач где необходимо достичь конечного результата и/или получить полностью законченный продукт в четко установленные сроки в рамках четко определенных регламентов. Скрам-это не про регламенты и сроки. Это скорее управляемый хаос. Так же скрам почти неприменим на тех работах, где нужно непрерывно сопровождать инфраструктуру-это техническое администрирование. Кроме того, скрам отвлекает от основной работы и выполнения непосредственных обязанностей. Эта очередная мода которая в итоге превратилась в очередное безумие и этот несчастный скрам(как и другие методологии "гибкой" работы) пичкают везде где только можно, порой нанося большой вред многим организациям. Возможно что это целенаправленная диверсия.
Обратная сторона SCRUM