“Запретите мне, Я торчу на одном и том же! Запретите мне, Всё равно уже кайф прошел!”
И.Ф. Летов “Наваждение”
Трендом в проектном управлении на протяжении двух последних десятилетий стал переход на SCRUM-процессы. Года с 2020-го возросло число людей, которые стали активно критиковать т.н. “чистый” SCRUM. Сейчас, под давлением обстоятельств, некоторые компании активно отказываются от этого фреймворка, т.к. SCRUM, который совершенствовался в теории, на практике во многих компаниях превратился в своеобразный культ, не влияющий на эффективность или даже снижающий её.
В мире победившего эджайла, SCRUM, как один из наиболее популярных методологических фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков она стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами. Более того, сегодня строгая приверженность принципам SCRUM нередко становится маркером профнепригодности для людей, которые имели неосторожность переродиться из полноценных проектных методологов и руководителей в фанатично зацикленных на ритуалах скрам-мастеров (речь не обо всех, но о об очень многих).
Что не так со SCRUM?
Для начала пройдемся по тому, что в целом не так с тем, что должно привести к максимально быстрому появлению полезных фич инкрементов бизнес-ценности, череде постоянных релизов продукта и гибкому управлению хотелками заказчика или пользователя.
1. Зависимость проекта, команды и эффективности от скиллов скрам-мастера
Большинство из нас привыкли, что успех разрабатываемого продукта зависит, в первую очередь, от квалификации программистов, иногда от профессионализма PMов, дотошности аналитиков. В классическом подходе к SCRUM есть скрам-мастер или некто, выполняющий его роль. С этой ролью возникают дополнительные риски. Они актуализируются, если скрам-мастер свято соблюдает всё прописанное в SCRUM-гайде, слепо верит в эффективность за счет чистоты ритуалов, при этом навязывает явно неподходящие проекту принципы организации работы. До 40% рабочего времени уходит на болтовню на дейликах, грумингах и ретроспективах.
Встречи почти всегда растягиваются, а команда тратит время на многократное и бесполезное обсуждение всем, кроме скрам-мастера, понятных задач. Отдельно напрягаются PO и PMы, которые стремятся, ради соблюдения методологических догм формулировать user story там, где в этом нет необходимости, бесконечно декомпозируют эпики и т.д. Любой, кто участвовал в команде с такими евангелистами понимает о чем речь. SCRUM требует высокой степени самоорганизации и дисциплины, что не всегда возможно в реальных условиях. Лучший скрам-мастер - тот, кто умеет модифицировать фреймворк как под условия проекта, так и особенности команды (я даже таких встречал… целых два раза в жизни).
2. Сложности с адаптацией
SCRUM не всегда можно адаптировать под все типы проектов. В первую очередь, речь идёт о ситуациях, где наиболее разумным будет решить всё за одну итерацию, а попытка декомпозировать не приведет к появлению бизнес-ценности.
Это, например, касается разработки и обучения нейросетей. Когда речь идёт о подготовке ML, с разработкой самой модели, сбором данных, а затем обучением. Также любые проекты, где результаты задач сложно или невозможно получить при параллельной разработке.
В первом случае имеет смысл использовать KANBAN или экстремальное программирование. Во втором — старый добрый Waterfall. Автомобиль никто не производит, создавая и поставляя заказчику или покупателю отдельные детали, важен конечный результат. Попытки выделить отдельные инкременты в подобных проектах гарантировано усложняют процесс разработки, приводя либо к огромным спринтам, либо к тому, что конечные цели итерации никогда не достигаются.
3. Не про гибкость
На практике SCRUM не приветствует изменения задач в ходе спринта. Любой скрам-мастер скажет, что это допустимо, но такие изменения потребуют дополнительных издержек в виде оценки, планирования и декомпозиции. Доходит до абсурда, когда для добавления простой и интуитивной понятной фичи, на всякий “маловероятный пожарный случай” создаются новые артефакты анализа, проводятся встречи по оценке задачи и т.д.
В итоге, изменяется планирование, переоцениваются ранее созданные задачи, что занимает в разы больше времени отдельных специалистов или всей команды. В связи с такими проблемами как PMы, так и скрам-мастера всячески избегают включения новых задач в спринт и стараются запланировать, нередко срочные и высокоприоритетные задачи, на следующий. Почти неизбежно это приводит к задержкам и снижению качества продукта. Если продолжить аналогии с производством - это та ситуация, когда добавление надписи над кнопкой требует согласования 10 человек и изменения 5 этапов процесса. Избыточность побуждает не менять планы сразу, но дожидаться очередной итерации.
4. Высокие затраты на обучение и внедрение
SCRUM может быть эффективным для некоторых проектов (несмотря на всё описанное выше и то, что я напишу дальше), но для успешного внедрения требуется длительная и дорогая подготовка и обучение команды. Особенно болезненно внедрение проходит в компаниях, которые раньше не использовали Agile-методологии, но по прихоти руководителя, наслушавшегося обещаний продавцов воздуха курсов по SCRUM, решил “увеличить эффективность”.
Более того, речь не идет об эффективности, когда при обучении навязывают “чистый SCRUM без примеси”, изменения для которого “смерти подобны”, а отход от стандартных приёмов вероятен настолько же, насколько изменения в классической китайской чайной церемонии. Итог — сытый продавец воздуха, недовольная команда, сорванные сроки, нулевой прирост эффективности.
5. Зависимость от частой обратной связи
В SCRUM нужна постоянная обратная связь. С одной стороны — это сильная сторона методологии, на практике это делает заказчиков, PO и(или) пользователей максимально безответственными к требованиям для бизнес-ценности. Они просто знают, что завтра они могут потребовать новую фичу, форму, кнопку, они этим активно пользуются.
Частая обратная связь от заказчика или владельца продукта позволяет вносить большое количество изменений в требования, но не функции в продукт, требования фиксируются, но в дальнейшем бюрократический ад методологии затягивает поставку ценности на месяцы.
Другая сторона медали — не все заказчики готовы к такому уровню взаимодействия. В Российских реалиях они часто предпочитают видеть готовый продукт целиком, а не по частям, что делает использование SCRUM вообще бессмысленным.
“Скрипач не нужен” или что не так со скрам-мастером
Отзывы коллег о скрам-мастерах, которые я получаю, у меня ассоциируются со старым добрым советским фильмом “Кин-дза-дза”, где регулярно звучала фраза о том, что “скрипач не нужен”. Редкие исключения касались очень опытных специалистов в компаниях, которые со старта начинали со SCRUM процессами, продуктовой PandaDoc и аутсорсинговом гиганте EPAM.
Там специалисты отзывались о роли скрам-мастера, как о полезной и повышающей эффективность, но даже там скрам-мастер не воспринимается как нечто священное и неприкосновенное. Однако, если мы посмотрим на средние и малые команды, то можем обнаружить, что эта роль не только бесполезна, но практически всегда вредна. Давайте разберемся, почему.
Скрам-мастер — лишний посредник
В малых и средних командах, где все участники процесса тесно связаны и регулярно взаимодействуют друг другом, скрам-мастер становится лишним. Представьте себе, что вы находитесь на кухне, где готовите ужин с друзьями. Все знают, что делать, и тут появляется человек, который начинает раздавать указания, в каком порядке нарезать овощи, когда ставить кастрюлю на плиту и сколько соли добавить. В итоге все только раздражаются, а процесс готовки становится сложным и медленным. Именно таким «кухонным начальником» становится скрам-мастер.
Деньги ради процесса
Содержание скрам-мастера требует дополнительных затрат, которые могут быть значительными для малых и средних компаний. Эти деньги можно было бы потратить на что-то более полезное, например, на покупку нового оборудования или на обучение сотрудников. Это как если бы вы наняли личного тренера для своей кошки – затраты есть, а пользы никакой.
Скрам-мастер и микроменеджмент
Скрам-мастер может легко превратиться в микроменеджера, и это вредно не только для малых и средних команд, но и для крупных компаний. Полноценный специалист вполне способен эффективно работать без постоянного контроля, “церемониальной магии грумингов и ретроспектив”.
Микроменеджмент со стороны скрам-мастера зачастую демотивирует сотрудников и снижает продуктивность, а если в команде предусмотрена роль PMа и последний склонен к “беспокоящему контролю”, то участники проекта отправляются на очередную обязательную встречу с энтузиазмом пациента, которому необходимо пройти колоноскопию. Рыбу не нужно учить плавать, она знает как это делать.
Скрам-мастер и бюрократия
Скрам-мастер почти всегда отягощает процесс разработки бюрократией сомнительной ценности. Agile выбирают там, где важна гибкость и скорость. Работа скрам-мастера часто приводит к тому, что обязательные встречи и церемонии замедляют работу, также добавляют бюрократической описательной работы.
Хорошим образным сравнением может стать попытка организации семейного пикника в корпоративном планировщике. Большое количество формальностей, теряющих смысл в живом процессе превращают разработку в достаточно рутинный процесс, в котором его участники неизбежно теряют энтузиазм.
Нежизнеспособность абстрактной оценки задач
Еще одной ахиллесовой пятой SCRUM является оценка трудозатрат. Такая оценка – одна из ключевых практик. По идее она должна помочь команде лучше планировать и управлять своим временем. На практике абстрактные единицы, во-первых, сложны для использования теми, кто привычно оценивал работу по времени, во-вторых, слабо коррелируют с другими процессами в ИТ-компаниях.
Например, заказчик аутсорсинговой компании, как правило, просит оценить сроки, аналогично в продуктовых командах важно понимать, когда новые функции станут доступны пользователям. Стори поинты могут помочь на раннем этапе сопоставить сложность задач со временем, которое уходит на их реализацию, но, как правило, это касается относительно простых задач, которые и без стори поинтов могут получить корректную оценку.
Poker SCRUM не решает проблему от слова совсем и превращает процесс оценки в гадание на кофейной гуще. Менеджмент пытается занизить сроки для скорейшей поставки ценности. Разработчики регулярно увеличивают сроки, пытаясь предугадать сколько уйдёт на тестирование. В итоге и те и другие у себя в голове привязывают стори поинты ко времени. Эффективность снижается или, как минимум, не растет, процесс усложняется, евангелисты SCRUMа аплодируют стоя.
Итак, обобщив, получаем следующие проблемы оценки (иногда неочевидные при беглом подходе к выбору методологии, но очевидные на практике):
1. Субъективность равносильна оценке удава в попугаях, когда один участник оценки представляет себе здоровенного какаду, а второй небольшого волнистого попугайчика, при этом единицы измерения попугаев также остаются абстрактной сущностью. На деле это приводит к тому, что одинаковые оценки задачи в результате могут оказаться принципиально разными. Использование “фибы” (последовательности Фибоначчи) ситуацию на практике не улучшает.
2. Проблемы с мотивацией команды
Абстрактные оценки почти всегда негативно сказываются на мотивации команды, если нет общей договорённости о том, сколько часов (дней, лет) закладывается в условный стори поинт). Создаётся ощущение неопределенности и непредсказуемости.
5. Сложности с объяснением заказчикам
Объяснение заказчикам, особенно не связанным с отраслью и незнакомым со SCRUM, что такое стори поинты и “с чем их нужно есть” крайне непросто. Абстрактные оценки, особенно в российских реалиях, всегда вызывают недоумение и недоверие. С тем же успехом можно сказать, что проект будет готов через “несколько бананов”.
Что есть полезного в SCRUM?
Несмотря на всё описанное выше, SCRUM в модифицированном виде жизнеспособен и полезен. Его главное преимущество - это комбинирование итеративного и инкрементного подходов.
1. Спринты: Постоянное улучшение
Итеративный подход в SCRUM (использование спринтов) позволяет удобно декомпозировать работу. “Разрезать торт на части, проще чем есть его целиком”. Ретроспективы, на которых анализируются спринты реально позволяют улучшать процессы и сам продукт разработки. Так можно легче адаптироваться к изменениям и избежать масштабных ошибок. При этом важно модифицировать канонические процессы таким образом, чтобы не получить все проблемы, описанные выше.
2. Инкрементальный подход: Постепенное добавление ценности
Инкрементальный подход в SCRUM предполагает, что каждая итерация завершается поставкой ценности. Во многих (но не во всех) проектах - это позволяет демонстрировать результаты и получать обратную связь от заказчиков и (или) пользователей. Проблемы возникают только тогда, когда инкремент по определению не может влезть в заранее определенный спринт, а срам-мастер не готов или не хочет выходить за рамки процесса.
3. Адаптивность
В идеальных условиях SCRUM позволяет командам быстро адаптироваться к изменениям требований и условий, а также вносить изменения в каждый следующий спринт. Проблемой является то, что, с одной стороны, изменения возможно понадобиться внести в уже спланированный спринт, что не кошерно. Во-вторых, процесс может превратиться в бесконечный и какая-то фича будет вечно кочевать из спринта в спринт, обрастая всё новыми требованиями, при этом не попадая в релиз.
4. Прозрачность
SCRUM действительно обеспечивает высокую степень прозрачности процесса. Дейлики, спринт-обзоры и ретроспективы позволяют всем участникам проекта быть в курсе текущего состояния дел и прогресса. Как я уже писал выше, они не всегда нужны и полезны, часто команда и так всё хорошо видит.
Когда SCRUM может быть полезен?
1. Большие проекты
В больших проектах, где требуется координация множества задач и участников, SCRUM помогает структурировать работу и обеспечить регулярные поставки ценности.
2. Проекты с равномерными и (или) типовыми задачами ограниченной длительности
Если большинство задач в проекте занимают приблизительно одинаковое время, SCRUM позволяет эффективно планировать и управлять ресурсами. Это помогает избежать перегрузок и простоев, обеспечивая равномерное распределение работы (естественно речь об идеальных или почти идеальных условиях).
3. Создание ценности за равные промежутки времени
SCRUM позволяет команде регулярно доставлять ценность заказчику, что особенно важно в проектах, где требуется частая обратная связь(когда её можно получить без танцев с бубном) и возможность вносить изменения (если левел бюрократии у скрам-мастера и PM близок к 100lv и внесение изменений не требует 100500 артефактов с сопоставимым количеством согласований для каждого).
Риски отказа от SCRUM там, где процесс удалось выстроить
Когда компании решают отказаться от SCRUM после того, как команды уже адаптировались к этой методологии и выстроены процессы, они также сталкиваются с рядом проблем:
1. Потеря структурированности и ясности
SCRUM предоставляет четкую структуру и ясность в распределении ролей и обязанностей. Когда команды привыкли к этой структуре, отказ от нее может привести к хаосу и неразберихе. Оркестр лишается дирижера – музыканты могут знать свои партии, но без координации результат будет крайне проблемным.
2. Снижение мотивации и продуктивности
Команды, привыкшие к регулярным спринтам и ретроспективам, могут потерять мотивацию и продуктивность без этих элементов. Обратная связь реально помогает командам оставаться на правильном пути и постоянно улучшаться. Можно сравнить это с теми, что на оживленной трассе отключили светофоры и убрали дорожные знаки.
3. Ухудшение коммуникации
SCRUM часто способствует улучшению коммуникации внутри команды и с внешними стейкхолдерами. Это особенно критично в больших проектах, где важно, чтобы все участники были в курсе текущего состояния дел.
4. Проблемы с адаптацией к изменениям
SCRUM позволяет командам быть гибкими и быстро адаптироваться к изменениям. Отказ от этой методологии может затруднить адаптацию к новым требованиям и условиям.
Критикуешь – предлагай
Риски, описанные выше, показывают, что полный отказ от скрам-процессов не рационален и логично предложить альтернативу, которая сохраняет его преимущества и устраняет его недостатки. Условно такую методологию можно назвать PostSCRUM. Давайте рассмотрим, какими свойствами должен обладать такой фреймворк.
Фокус на результате, а не на процессе
Одним из недостатков SCRUM является его чрезмерный фокус на процессе, что может отвлекать команду от выполнения реальной работы. Новый фреймворк должен быть ориентирована на результат, а не на процесс, чтобы команда могла сосредоточиться на достижении целей, а не на выполнении ритуалов.
Минимизация бюрократии
SCRUM может добавить ненужную бюрократию в процесс разработки. PostSCRUM должен минимизировать бюрократию и формальности, чтобы команда могла работать более эффективно и быстро.
Поддержка долгосрочного планирования
SCRUM ориентирован на краткосрочные цели и итерации, что может затруднить долгосрочное планирование. PostSCRUM должен поддерживать как краткосрочные, так и долгосрочные цели, чтобы команда могла эффективно планировать и прогнозировать. Отчасти таким свойством обладает гибридный SCRUMBAN.
В качестве заключения
Сейчас можно констатировать, что в практике разработки SCRUM превратился в пародию на самого себя, особенно в том случае, если методологию используют в канонически чистом “халяльном” не модифицированном виде. При этом его особенности способствовали появлению огромного количества команд, фиксированных на SCRUM-процессах, продавцов воздуха принципов “правильного” подхода к проектному управлению, церемониально фиксированных скрам-мастеров. Вангую, что активное использование SCRUM в мире стало одной из причин катастрофической статистики успешности agile-проектов (исследование показало, что у agile-проектов на 268% выше процент неудач) https://johnfarrier.com/agile-failure-what-drives-268-higher-failure-rates/.
Очевидно, что при всех теоретических преимуществах, SCRUM провалился на практике и требует значительной модификации для того, чтобы стать эффективным.
Комментарии (39)
denis-isaev
21.08.2024 19:24Мне кажется вы свой ограниченный опыт проецируете на всю отрасль. Это как если бы человек, которого в море покусала акула, начал утверждать, что купание - зло.
Mi_sha256 Автор
21.08.2024 19:24Мой опыт, опыт коллег, анализ публикаций по теме, данные статистики об успешности проектов, сведения об отказе от SCRUM в крупных компаниях (что интересно даже в тех, где методология показала себя неплохо) полагаю дают достаточно репрезентативную картину. Я не хейтер методологии и управлял проектами в её рамках (правда без скрам-мастера), более того завершал успешно, но есть проблемы её применения без модификации, как я их вижу - описал в посте. Я не первый об этом пишу, в т.ч. на Хабре.
https://habr.com/ru/articles/430890/
https://habr.com/ru/articles/430890/
https://news.ycombinator.com/item?id=34742515
https://www.quora.com/Can-you-please-elaborate-on-why-Scrum-Agile-is-bad-for-developers-from-a-developer-s-perspective (тут особенно интересно, что пишет магистр компьютерных наук Александр Атанасов из Болгарии)
https://blog.mb-consulting.dev/scrum-sucks-9960011fc5cf
https://www.reddit.com/r/Frontend/comments/vs3w1z/i_hate_scrum_is_it_only_me_or_other_programmers/
Я могу продолжать долго, очень долго. Я не отрицаю, что в scrum есть много привлекательных вещей, которые полезны в разработке, но в чистом виде они нивелируются врождёнными бесполезными, а иногда вредными недостатками.
Если речь о ситуации в которой акулы нападают на каждого второго купающегося, то, думаю очевидно, что купание - зло. А не злом оно является лишь в изолированных бассейнах и водоёмах, где нет акул.denis-isaev
21.08.2024 19:24+2Предполагаю, что ваш опыт и опыт коллег скорее всего касается крупных производств в которых зачастую преобладает кровавый неэффективый энтерпрайз и в них очень тяжело приживается любой agile (не всегда) и в этой тусовке много хейтеров как скрама так и вообще всего agile.
А если вы возьмете b2c с его высококонкурентной средой, то там сплошь и рядом будут успешные кейсы работы по scrum и прочим agile-ам.
Что касается ваших ссылок, то я ради интереса зашел сюда https://johnfarrier.com/agile-failure-what-drives-268-higher-failure-rates/ и тут можно сразу не читать послеThe study, conducted by Dr. Junade Ali and reported by Engprax (who offers a commercial alternative to Agile)
Исследование схоже на коммерческий булшит. Я уверен, можно найти сотню других исследований с противоположными выводами. Это лишний раз подтверждает то, что в различных отраслях различный опыт.
Если посмотреть на b2c web, то в нем скрамоподобные процессы сами собой зарождались еще в начале нулевых, когда слова agile и scrum особо никто и не употреблял. Просто потому что web сильно упрощал доставку ценности клиенту (svn up и готово), сильно удешевлял цену ошибки (svn up -r и вуаля) и подталкивал конкурирующие гибкие команды к короткому релизному циклу, что влекло за собой остальные моменты, свойственные скраму. И эта отрасль все эти годы успешно живет на подобных фреймворках.Mi_sha256 Автор
21.08.2024 19:24+2В b2c web с небольшой командой, как мне кажется, можно просто брать Agile-манифест и следовать принципам, а не заряжать структурированную методологию с кучей ритуализированных нагромождений, но это ИМХО. Опять же есть ли говорить об абстрактной оценке задач и покер скраме, то они полноценно применимы там, где все и так корректно соотносят условный сторипоинт с часами или днями. Итеративная поставка ценности - да, и я упоминал, что это пожалуй лучшее, что есть в скрам.
А вот регулярная обратная связь - уже ситуативно, это опять может стать проблемой на практике, иногда, даже в упомянутых b2c проектах лучше максимально полно собрать и документировать требования, и заряжать источники требований на их более тщательное обдумывание на старте, чтобы их массированное изменение в процессе не превратило разработку в сумбур и не повело по пути бесконечного улучшения. Так как при гибких изменениях требований в процессе уже запланированного спринта, особенно если речь идёт о неких блокирующих задачах, стройное планирование итерации может полететь в тартар.
В таких проектах также можно выстроить порядок сбора требований (подготовки артефактов) и проектирования (блок-схемы, вайрфреймы, дизайн интерфейса страниц и т.п.) таким образом, чтобы минимизировать изменения в процессе. Иными словами есть много факторов, которые затрудняют универсализацию подходов, если конечно проекты не совсем конвейерно-типовые.
dph
21.08.2024 19:24+2Вообще, в скраме еще и очень медленная обратная связь (и нет никаких требований к ее ускорению). И это крайне грустно для любых более-менее нормальных процессов и продуктов.
usego
21.08.2024 19:24+1Изменения - это данность, почти в любом плюс минус сложном бизнесе, с этим надо жить, эджайл потому и появился, как признание этого факта. Другой вопрос, что действительно, не надо приучать "бизнес", что любые изменения легко даются и можно хотелки в беклог всовывать легко и непринуждённо.
dph
21.08.2024 19:24+1Хм, в небольших командах скрам особенно избыточен и негибок. Там проще брать канбан, минимизировать количество ритуалов и нормально работать. Скрам там и дорог и неэффективен. Ну и, конечно, считать скрам - аджайл-методологией довольно странно, в гайде отчетливо "процессы важнее людей".
Да, хороший менеджер, играя роль скрам-мастера, может выкинуть или переосмыслить скрам-гайдт и нарисовать нормальный рабочий процесс. Но без гайда у него получится еще быстрее и проще.Mi_sha256 Автор
21.08.2024 19:24Не готов согласиться. В малых командах он избыточнее чем в больших. Парадоксально, но успешно скрам работает в больших проектах, где много меняющихся требований. При этом на 5 команд можно нанять одного скрам мастера, а также сэкономить на внедрении процесса. Также в объёмном и длительном процессе можно увидеть и оценить изменения. Сами преимущества ощутимее в масштабе, даже если прирост скорости разработки или условного KPI отдельного сотрудника ничтожен. Большой проблемой в крупных командах является совместная оценка сложности задач, но это решаемо за счет отхода от базовых принципов и разделения команды на спринтплэннингах на субкоманды, фронты оценивают своё, бэкенд своё, девопс своё и т.д. Он не гибок по факту везде, но традиционно считается Agile-методологией.
Ainyru
21.08.2024 19:24+2SCRUM это не Agile, SCRUM это противоположность Agile мимикрирующая под Agile чтобы манагеры не способные (а скорее не нужные) в Agile могли внедрить у себя якобы Agile сохранив работу и при этом продолжая все максимально контролировать как и раньше.
alexhott
21.08.2024 19:24+2Мой опыт включает два противоположных результата
1 Команды работали внутри банка и разрабатывали ПОдля банка. Соответственно заказчик банк - исполнитель банк. Скрам с некоторой адаптацией прекрасно работал, дейли по 5 -10 минут не больше, ретро до часа.
2 Команды работают внутри ИТ компании, у которой договор с заказчиком и конкретное ТЗ. ТЗ написано так себе, сделанное по ТЗ иногда просто невозможно использовать, заказчик начинает осознавать и выкатывать новые требования - реально полезных вещей но их нет в ТЗ. Гибкая разработка говорит - ДА давайте делать полезное. Договор говорит - тебе заплатят N рублей только если ты сделаешь, то что написано в ТЗ, а за сделанное сверх хоть и полезное никто не заплатит. И если компания заказчик с Гос участием там еще и закупочные процедуры и бюрократия которая почти ничего в договоре поменять не позволяет, и иногда готовы вроде отдельный договор на доработку - но план бюджета не позволяет и т.д.
Тут начинается такая "гибкая" разработка, которая скрам методологии и не снилась.usego
21.08.2024 19:24+1Имхо фикспрайс и эджайл - это антонимы по определению.
urvanov
21.08.2024 19:24+2Только в реальности обычно так и бывает. На верхнем уровне проект оценен в XXX млн рублей и продан. Все документы подписаны и спускается сверху команда: "Ребята, мы все продали, вы там внутри команды играйте в свой аджайл, но чтобы вот этот проект к такому сроку был готов."
usego
21.08.2024 19:24Клиенты поопытней и сами понимают, что так не работает, на выходе будет кака и тёрки по доплатам и начинают пробовать аутстафф и прочий не совсем фикспрайс.
Mi_sha256 Автор
21.08.2024 19:24Аутстаф сам по себе зло. "Продали" тут одного товарища в " рабоство" заказчику. По итогу недовольны все. Пока работал у нас и делал заказ для того же заказчика - всех всё устраивало. Проблема в том, что когда есть "голый" результат и деньги, которые ты за него заплатил - это совсем не то же самое, когда ты заплатил за специалиста и потом цацкаешся с ним чтобы получить этот результат.
atues
21.08.2024 19:24+7Кажется, Билл Джой как-то сказал (цитата не абсолютно точная, но по смыслу очень близко): великие программы создаются одиночками или очень маленькими группами единомышленников, а не толпой посредственностей, вкалывающих до усеру. Понятно, что великих (да и просто хороших) программистов очень мало. Степень сеньористости почти никогда не отражает истинный потенциал программиста. Я знаю очень скромных людей, не имеющих никаких званий, чьи знания и навыки вызывают оторопь и восхищение. Скрам, аджайл, груминги и иже с ними - это процесс, цель которого попытаться заставить посредственности (имя им - легион) что-то и как-то наговнячить более-менее работоспособное в минимально короткие сроки, дотащить до прода и приняться за новую поделку того же уровня качества.
Так что мне нисколько не жаль ни скрама, ни аджайла. Придумают что-то новое, в еще большей степени бессмысленное и бестолковое. Танцы с бубном не прекратятся. Просто будут танцевать под чуточку иную музыку.
Алан Чумак заряжал банки с водой, скрамота пытается сделать то же самое с программированием, заряжая головы разработчиков пышной болтовней.
Извините. Я знаю, что обижу многих. Минусуйте, что же поделаешь :)
usego
21.08.2024 19:24Скрам - это ещё про повышение прозрачности перед заказчиком (за что его исполнители и не любят). Внедрив некий гибрид скрама в один проект с ковбой-менеджментом, наконец удалось отшить бизнес с постоянными наездами "вы тут ни хрена не делаете, ничего не происходит, платим много, а результатов нет". Когда вся работа визуализировалась, стало проще тыкать бизнес в собственный бардак и хоть немного, но упорядочить работу.
Ivan22
21.08.2024 19:24+1может и так, только это все про "великие программы". А таких на всей планете штуки 3. Весь остальной софт пилится спокойно "толпой посредственностей, вкалывающих до усеру"
ozzyBLR
21.08.2024 19:24+4Тезисами и по делу:
Скрам не методология.
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Обнял.
Mi_sha256 Автор
21.08.2024 19:24+1Спасибо, ценно. И красиво написано. И всё же есть несколько комментов)
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
И это верно, но вопрос оправданы ли риски такого внедрения.
В Скраме нет проджект менеджера.
В теории, на практике эта роль существует, включена в процессы компании (команды) и почти никогда не пропадает при внедрении scrum.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме
Опять же, в Скрам Гайд не прописаны, на практике почти всегда есть. Как и покер скрам.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно.
Тогда возникает вопрос в чем в принципе его ответственность?
Скрам лишь запрещает отказываться от роли целиком.
Очень гибко)
Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты.
Процессы и артефакты - да, ритуалы - нет. Нет необходимости возводить обыденное до уровня сакрального.) Любые процессы могут и должны адаптироваться под цели и условия бизнеса(компании, команды), они первичны, содержание определяет форму, а не наоборот. Ритуалы же фиксируют команду на форме, даже в тех случаях, когда она избыточна.
"Минимизация бюрократии" - от создателей "документация не нужна".
Таки нет. Документация нужна, но если мы про Agile, она по определению вторична, что куда-то делось в SCRUM.
Если в вашей команде не умеют проводить эффективные митинги
В моей умеют, но их эффективность оценивается в конечном итоге заказчиком продукта и пользователями, а не скрам-мастером).
Или он ранее от тоже казался ненужным?)
Напротив, очень полезный человек)
либо "адаптаций"
По моему субъективному нерепрезентативному опыту, адаптации в 90% случаев эффективнее, т.к. ближе процессам конкретного бизнеса.
При этом я ни в коем случае не называю Скрам серебряной пулей
Проблема в том, что очень многие таки считают Скрам серебряной пулей
Искренне рад, что вы нашли свой путь. Обнял.ozzyBLR
21.08.2024 19:24Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Mi_sha256 Автор
21.08.2024 19:24Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где scrum не адаптирован и используется в точности как предписано скрамгайде?
c3gdlk
21.08.2024 19:24Тем не менее, все о чём пишет автор вполне справедливо. Современный повсеместный скрам это скорее какой-то монстр, который не имеет ничего общего с тем, каким его придумали. Это скорее говорит о его несостоятельности. Идея заменить методологию конструктором методологии сильно зависит от человека. Это как создать самый технологичный танк, не учитывая, что нужно будет за месяц научить им пользоваться условного вчерашнего тракториста.
Ivan22
21.08.2024 19:24Если это монстр, почему же он так популярен? Причем везде на планете, причем в очень высококонкурентном бизнесе, где попробуй только смузи не того цвета на кухне предложить - твой компании конец !!
p.s. у меня два варианта, либо это заговор рептилоидов, либо одно из двух
Mi_sha256 Автор
21.08.2024 19:24Где-то работает, где-то не работает. Например если речь идёт о бизнесе с крупными инкрементами (нейросети, анализ больших данных, промышленное программирование) не работает.
Популярность - не является критерием. Например в 19-м веке был очень популярен детский сироп от кашля с героином.
ozzyBLR
21.08.2024 19:24Это не какой-то конкретный монстр. У каждого этот монстр свой.
Как видится мне, основная проблема во внедрении Скрама заключается в изначальном желании "адаптировать" Скрам, а не инициировать изменения в компании.
В итоге компания, которая недовольна текущей орагнизацией работы, протаскивает эту неэффективность в свою "адаптацию" Скрама.
c3gdlk
21.08.2024 19:24+1Мне кажется все ровно наоборот. Изначальный скрам нельзя адаптировать. Потому что это не методология. Это набор кирпичиков Лего, строй из них что нужно.
И он скорее одинаковый, чем разный. Мне кажется причина в том, что менеджеру надо как-то оценивать качество своей работы. Даже правильные действия не всегда ведут к результату для бизнеса. Поэтому по результатам не получится. Вот и превращается это в процесс ради процесса.
Скрам мастер должен поставить процессы, которые будут приводить к результатам. Но, вместо этого просто фигачат кучу процессов, ведут дейлики и занимаются непоймт чем.
Недавно прочитал книгу автора скрам Джеффа Сазерленда. Оказалось, что тот скрам, по которому я 10 лет работал, это совсем не то, что придумали изначально. И, книга отвечает на все вопросы, которые вы поднимаете в статье. Там написано, как надо делать. Но, по факту в компаниях обычно все так, как вы в статье описали. Вы прям один в один описали тот скрам, по которому я работал 10 лет.
alexey_cardo
21.08.2024 19:24Да, про отсутствие планов и документации - огромная глупость; наоборот нужно супер грамотно и ультра быстро все рисовать-расписывать - иначе через две недели будет не релиз, а понимание, что надо сделать описание и чек лист)))
Agile гибок здесь только в том, что команда может это в удобной ей форме визуализировать/хранить/вести (по сравнению, например, с правилами головной компании - и то не во всем)
sogarkov
21.08.2024 19:24>> Почти неизбежно это приводит к задержкам и снижению качества продукта.
Извините, но неизбежно это приводит только к подгоранию пятых точек эффективных, а на качество продукции это часто влияет только позитивно, так как суперсрочная и важная фича со сроком "вчера" в 90% случаев оказывается маловажной прихотью, без которой все переживут еще пару спринтов без особых издержек для бизнеса.
MonkAlex
21.08.2024 19:24На практике SCRUM не приветствует изменения задач в ходе спринта. Любой скрам-мастер скажет, что это допустимо, но такие изменения потребуют дополнительных издержек в виде оценки, планирования и декомпозиции. Доходит до абсурда, когда для добавления простой и интуитивной понятной фичи, на всякий “маловероятный пожарный случай” создаются новые артефакты анализа, проводятся встречи по оценке задачи и т.д.
Так надо не внутрь спринта. На новый спринт планируйте. Текущий доделывайте как есть.
Короткие спринты позволяют это делать.
Единственный повод менять текущий спринт - поставленные задачи отменены.
Mi_sha256 Автор
21.08.2024 19:24А если спринт трёхнедельный, так как поставка ценности в другие сроки невозможна?
MonkAlex
21.08.2024 19:24И всё ещё - если все согласованные фичи актуальны, команда продолжает их делать.
Новые фичи - на новые спринты. Гибкость же не в возможности тасовать задачи каждый день. Гибкость в коротких спринтах, в противовес ватерфолу в полгода.
vkalenov
21.08.2024 19:24+1Спасибо за статью. Добавлю только, что проблема с относительными оценками связана с тем, что их воспринимают как оценку. Если отнестись к этому как к категоризации, с учётом прошлого опыта, и создать "калибровочную" таблицу, то возникает поле для обсуждения с заказчиком. Таблица - 5-7 категорий задач, в которые отнесены ранее сделанные задачи "эта по разработке 2-3 дня, но тестировать много и контрагенты тупят, поэтому 8SP, а не 3" позволяет анализировать поток (привет канбан) и говорить о пропускной способности команды на спринт
alexey_cardo
21.08.2024 19:24Так получилось, что я как раз весной проходил курс Agile в Berkeley Extension (доп курсы в UC Berkeley).
И мне особенно запомнились немного другие моменты (и это все полностью бьется с тем, что я вижу в нашем стартапе и своем прошлом опыта в компании). Для наибольшего успеха необходимо, помимо прочего:
1) разрешать Agile-команде меньше бюрократии (хотят, условно, телеграм и Гугл Диск вместо принятых в компании Слака и Дропбокса - да пожалуйста, документацию хотят заполнить после первых 5-6 итераций - не вопрос, лишь бы это хранилось адекватно и было понятно новым людям в команде)
2) сажать в одной комнате - так и вопросы быстрее решаются, и новости проще и быстрее распространяются
3) подбирать людей с классным общением друг с другом (в идеале с «химией»).
Это, кстати, круто вывели на новый уровень в Spotify - там целые «племена» сотрудников, собранных не только по специализации, но и по ценностям/драйву. Теперь эту модель так и называют - Spotify, и вот в университетах преподают.
Люди, разумная простота процессов и кайф от работы рождают продуктивность, часто недоступную «бюрократам».
K0styan
С 2020-го? Камон, я эти все истории с 2013-го слышу минимум....
Mi_sha256 Автор
Я только с 16-го управляю проектами. Первое время только и слышал о переходе на SCRUM-процессы. Очевидно критика была, но в СНГ в основном восторженные отзывы. Многие ориентировались на EPAM, забывая о специфике своих проектов и активно нанимали коучей.
K0styan
Ну тогда их действительно пытались пришить ко всему подряд. Но опять же, именно благодаря этому довольно быстро стала понятна ниша, в которой скрам работает, и краевые условия, по наступлению которых он работать перестаёт.
К сожалению, учитывать эти условия приходило в голову сильно не всем, что изрядно репутацию попортило.
dph
Я в 2008ом уже студентам рассказывал про проблемы Scrum и граничных условиях )