В качестве шутки: "фронтендеры ждут, пока сделают бэкенд" Странное утверждение, а у вас точно Agile?) Если серьёзно, то ждут они только в случае если надо интегрировать одно с другим, т.е. в конце спринта (если речь про скрам), когда нужно выдать инкремент с готовой функциональностью, а могут и не ждать и к моменту интеграции нужные эндпоинты могут быть уже готовы. Если планирование адекватное, требования достаточно полные (однозначные, непротиворечивые ect) то так даже получается). Чаще ждут UI-дизайнеров и UX-специалиста, чтобы стартовать с вёрсткой. Что до sp, то в моей практике работало в 1-м проекте из 10, и только с феноменально скиллованным скрам-мастером (который, не кисло так, кушал ФОТ). Мой вывод - использование sp чаще приводит к необъективной оценке сроков, что выливается в недовольство заказчиков и боссов, чем к ожидаемому гибкому управлению процессами оценки, иными словами - инструмент малоэффективный в суровой действительности, при всех потенциальных достоинствах абстрагирования. Ни в коей мере не хочу умалить достоинства автора, как опытного скарм-мастера, вероятно у него получается использовать абстрактные оценки в sp, попугаях и т.п., лучше чем у меня и многих моих коллег. Однако есть ключевая и фундаментальная проблема sp, субъективность в оценке сложности, что неизбежно приводит к невозможности стандартизации процесса оценки в отдельно взятом проекте, а значит снижает его управляемость.
Да, вы правы, но возможно вы не верно поняли посыл материала. Есть порог необходимой сложности. И в промышленных системах он безусловно выше, я лишь пишу о том, что с такие системы: первое - должны быть минимально удобными в смысле структуры организации данных в интерфейсе (это не означает упрощения до уровня интернет-магазина), второе - близкими по расположению, внешнему виду элементов управления, демонстрации данных и т.п. к тому с чем оператор системы привык работать, особенно если речь о замене физических устройств интерфейсом, третье - безопасными, минимальная защита от идиота также всегда нужна - это касается визуального отражения критических ошибок, режимов, прочих ахтунгов, а также полноценной обратной связи и логирования. Остальное вариабельно и зависит от конкретных задач системы.
Т.е заново проводим груминг, спринтплэнинг, вносим в спринт уже вносившиеся задачи, занимаемся перерасчетом времени команды, вместо оптимизации текущего спринта?
Почитал о том, адепты чистого скрам считают причинами скрамбатов. Там огромное количество "истинных причин" вполне соответствуют распространённому когнитивному искажению - предвзятости подтверждения. Т.е. любую попытку модифицировать методологию под конкретные условия и отойти от догмы, объявляют следствием причины, которая существует лишь в рамках парадигмы того, что скрам в чистом виде лучший фреймворк на земле и обладает достоинствами, которых нет у других фреймворков и методологий (главное правильно молиться соблюдать ритуалы). Т.е. таки "серебряной пулей", но то, что "осиновый кол" с "чесноком" в ряде случаев работают значительно лучше и без танцев с бубнами скрам-мастера, никто не из них не пишет.
Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где scrum не адаптирован и используется в точности как предписано скрамгайде?
Где-то работает, где-то не работает. Например если речь идёт о бизнесе с крупными инкрементами (нейросети, анализ больших данных, промышленное программирование) не работает. Популярность - не является критерием. Например в 19-м веке был очень популярен детский сироп от кашля с героином.
Спасибо, ценно. И красиво написано. И всё же есть несколько комментов)
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
И это верно, но вопрос оправданы ли риски такого внедрения.
В Скраме нет проджект менеджера.
В теории, на практике эта роль существует, включена в процессы компании (команды) и почти никогда не пропадает при внедрении scrum.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме
Опять же, в Скрам Гайд не прописаны, на практике почти всегда есть. Как и покер скрам.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно.
Тогда возникает вопрос в чем в принципе его ответственность?
Скрам лишь запрещает отказываться от роли целиком.
Очень гибко)
Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты.
Процессы и артефакты - да, ритуалы - нет. Нет необходимости возводить обыденное до уровня сакрального.) Любые процессы могут и должны адаптироваться под цели и условия бизнеса(компании, команды), они первичны, содержание определяет форму, а не наоборот. Ритуалы же фиксируют команду на форме, даже в тех случаях, когда она избыточна.
"Минимизация бюрократии" - от создателей "документация не нужна".
Таки нет. Документация нужна, но если мы про Agile, она по определению вторична, что куда-то делось в SCRUM.
Если в вашей команде не умеют проводить эффективные митинги
В моей умеют, но их эффективность оценивается в конечном итоге заказчиком продукта и пользователями, а не скрам-мастером).
Или он ранее от тоже казался ненужным?)
Напротив, очень полезный человек)
либо "адаптаций"
По моему субъективному нерепрезентативному опыту, адаптации в 90% случаев эффективнее, т.к. ближе процессам конкретного бизнеса.
При этом я ни в коем случае не называю Скрам серебряной пулей
Проблема в том, что очень многие таки считают Скрам серебряной пулей
Не готов согласиться. В малых командах он избыточнее чем в больших. Парадоксально, но успешно скрам работает в больших проектах, где много меняющихся требований. При этом на 5 команд можно нанять одного скрам мастера, а также сэкономить на внедрении процесса. Также в объёмном и длительном процессе можно увидеть и оценить изменения. Сами преимущества ощутимее в масштабе, даже если прирост скорости разработки или условного KPI отдельного сотрудника ничтожен. Большой проблемой в крупных командах является совместная оценка сложности задач, но это решаемо за счет отхода от базовых принципов и разделения команды на спринтплэннингах на субкоманды, фронты оценивают своё, бэкенд своё, девопс своё и т.д. Он не гибок по факту везде, но традиционно считается Agile-методологией.
Аутстаф сам по себе зло. "Продали" тут одного товарища в " рабоство" заказчику. По итогу недовольны все. Пока работал у нас и делал заказ для того же заказчика - всех всё устраивало. Проблема в том, что когда есть "голый" результат и деньги, которые ты за него заплатил - это совсем не то же самое, когда ты заплатил за специалиста и потом цацкаешся с ним чтобы получить этот результат.
На самом деле заметят все, так как на разработку свалится прорва работы с требованиями, да и прямая коммуникация разработчика с источниками требований скажется не лучшим образом на скорости поставки ценности.
В b2c web с небольшой командой, как мне кажется, можно просто брать Agile-манифест и следовать принципам, а не заряжать структурированную методологию с кучей ритуализированных нагромождений, но это ИМХО. Опять же есть ли говорить об абстрактной оценке задач и покер скраме, то они полноценно применимы там, где все и так корректно соотносят условный сторипоинт с часами или днями. Итеративная поставка ценности - да, и я упоминал, что это пожалуй лучшее, что есть в скрам.
А вот регулярная обратная связь - уже ситуативно, это опять может стать проблемой на практике, иногда, даже в упомянутых b2c проектах лучше максимально полно собрать и документировать требования, и заряжать источники требований на их более тщательное обдумывание на старте, чтобы их массированное изменение в процессе не превратило разработку в сумбур и не повело по пути бесконечного улучшения. Так как при гибких изменениях требований в процессе уже запланированного спринта, особенно если речь идёт о неких блокирующих задачах, стройное планирование итерации может полететь в тартар.
В таких проектах также можно выстроить порядок сбора требований (подготовки артефактов) и проектирования (блок-схемы, вайрфреймы, дизайн интерфейса страниц и т.п.) таким образом, чтобы минимизировать изменения в процессе. Иными словами есть много факторов, которые затрудняют универсализацию подходов, если конечно проекты не совсем конвейерно-типовые.
Категорическая глупость. Я пришёл в IT в 30. До этого работал в медицине катастроф. Регулярно работаю с олдскульными "тру прогерами", у некоторых по 20 лет в профессии, никогда не сталкивался с тем, что кого-то бомбит или раздувает от ЧСВ. Я работаю PM (совмещаю с ролью BA, в перспективе хочу дорасти до архитектора данных), у меня скромные хардскилы. Я регулярно обращаюсь к коллегам для того того, чтобы эти скиллы улучшать благодаря их посильной помощи и за**бываюсь обучаясь новому.
Основной причиной хейта "галерных старожил" является не то, что кто-то пришёл за баблом, но в том, что многие, кто приходит в профессию сейчас, не способны банально выполнять свои задачи, при этом громко именуют себя "программистами", хотя во времена более зелёной травы к ним бы и унизительный термин "кодер" был неприменим. Порог входа стал крайне низким, что приводит к огромному количеству недоученных специалистов крайне узкого профиля и низкого уровня. При этом кадровый голод вынуждает компании их брать на борт, часто с навешиванием на сеньоров и мидлов дополнительной преподавательской работы, которую забыли провести продавцы воздуха и(или) сам счастливый обладатель оффера.
Мой опыт, опыт коллег, анализ публикаций по теме, данные статистики об успешности проектов, сведения об отказе от 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 есть много привлекательных вещей, которые полезны в разработке, но в чистом виде они нивелируются врождёнными бесполезными, а иногда вредными недостатками. Если речь о ситуации в которой акулы нападают на каждого второго купающегося, то, думаю очевидно, что купание - зло. А не злом оно является лишь в изолированных бассейнах и водоёмах, где нет акул.
Я только с 16-го управляю проектами. Первое время только и слышал о переходе на SCRUM-процессы. Очевидно критика была, но в СНГ в основном восторженные отзывы. Многие ориентировались на EPAM, забывая о специфике своих проектов и активно нанимали коучей.
В качестве шутки: "фронтендеры ждут, пока сделают бэкенд" Странное утверждение, а у вас точно Agile?)
Если серьёзно, то ждут они только в случае если надо интегрировать одно с другим, т.е. в конце спринта (если речь про скрам), когда нужно выдать инкремент с готовой функциональностью, а могут и не ждать и к моменту интеграции нужные эндпоинты могут быть уже готовы. Если планирование адекватное, требования достаточно полные (однозначные, непротиворечивые ect) то так даже получается). Чаще ждут UI-дизайнеров и UX-специалиста, чтобы стартовать с вёрсткой.
Что до sp, то в моей практике работало в 1-м проекте из 10, и только с феноменально скиллованным скрам-мастером (который, не кисло так, кушал ФОТ). Мой вывод - использование sp чаще приводит к необъективной оценке сроков, что выливается в недовольство заказчиков и боссов, чем к ожидаемому гибкому управлению процессами оценки, иными словами - инструмент малоэффективный в суровой действительности, при всех потенциальных достоинствах абстрагирования. Ни в коей мере не хочу умалить достоинства автора, как опытного скарм-мастера, вероятно у него получается использовать абстрактные оценки в sp, попугаях и т.п., лучше чем у меня и многих моих коллег. Однако есть ключевая и фундаментальная проблема sp, субъективность в оценке сложности, что неизбежно приводит к невозможности стандартизации процесса оценки в отдельно взятом проекте, а значит снижает его управляемость.
Да, вы правы, но возможно вы не верно поняли посыл материала. Есть порог необходимой сложности. И в промышленных системах он безусловно выше, я лишь пишу о том, что с такие системы: первое - должны быть минимально удобными в смысле структуры организации данных в интерфейсе (это не означает упрощения до уровня интернет-магазина), второе - близкими по расположению, внешнему виду элементов управления, демонстрации данных и т.п. к тому с чем оператор системы привык работать, особенно если речь о замене физических устройств интерфейсом, третье - безопасными, минимальная защита от идиота также всегда нужна - это касается визуального отражения критических ошибок, режимов, прочих ахтунгов, а также полноценной обратной связи и логирования. Остальное вариабельно и зависит от конкретных задач системы.
Полезно, спасибо за материал!
Спасибо, судя по интересу комьюнити целевых хабов, не слишком популярная тема)
Т.е заново проводим груминг, спринтплэнинг, вносим в спринт уже вносившиеся задачи, занимаемся перерасчетом времени команды, вместо оптимизации текущего спринта?
Почитал о том, адепты чистого скрам считают причинами скрамбатов. Там огромное количество "истинных причин" вполне соответствуют распространённому когнитивному искажению - предвзятости подтверждения. Т.е. любую попытку модифицировать методологию под конкретные условия и отойти от догмы, объявляют следствием причины, которая существует лишь в рамках парадигмы того, что скрам в чистом виде лучший фреймворк на земле и обладает достоинствами, которых нет у других фреймворков и методологий (главное правильно
молитьсясоблюдать ритуалы). Т.е. таки "серебряной пулей", но то, что "осиновый кол" с "чесноком" в ряде случаев работают значительно лучше и без танцев с бубнами скрам-мастера, никто не из них не пишет.Ну в нашем случае со скилованностью заказчика были таки сложности.
Спасибо, я стремился описать именно этот скрам. Только автор статьи я, а не @ozzyBLR
Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где scrum не адаптирован и используется в точности как предписано скрамгайде?
А если спринт трёхнедельный, так как поставка ценности в другие сроки невозможна?
Где-то работает, где-то не работает. Например если речь идёт о бизнесе с крупными инкрементами (нейросети, анализ больших данных, промышленное программирование) не работает.
Популярность - не является критерием. Например в 19-м веке был очень популярен детский сироп от кашля с героином.
Спасибо, ценно. И красиво написано. И всё же есть несколько комментов)
И это верно, но вопрос оправданы ли риски такого внедрения.
В теории, на практике эта роль существует, включена в процессы компании (команды) и почти никогда не пропадает при внедрении scrum.
Опять же, в Скрам Гайд не прописаны, на практике почти всегда есть. Как и покер скрам.
Тогда возникает вопрос в чем в принципе его ответственность?
Очень гибко)
Процессы и артефакты - да, ритуалы - нет. Нет необходимости возводить обыденное до уровня сакрального.) Любые процессы могут и должны адаптироваться под цели и условия бизнеса(компании, команды), они первичны, содержание определяет форму, а не наоборот. Ритуалы же фиксируют команду на форме, даже в тех случаях, когда она избыточна.
Таки нет. Документация нужна, но если мы про Agile, она по определению вторична, что куда-то делось в SCRUM.
В моей умеют, но их эффективность оценивается в конечном итоге заказчиком продукта и пользователями, а не скрам-мастером).
Напротив, очень полезный человек)
По моему субъективному нерепрезентативному опыту, адаптации в 90% случаев эффективнее, т.к. ближе процессам конкретного бизнеса.
Проблема в том, что очень многие таки считают Скрам серебряной пулей
Искренне рад, что вы нашли свой путь. Обнял.
Не готов согласиться. В малых командах он избыточнее чем в больших. Парадоксально, но успешно скрам работает в больших проектах, где много меняющихся требований. При этом на 5 команд можно нанять одного скрам мастера, а также сэкономить на внедрении процесса. Также в объёмном и длительном процессе можно увидеть и оценить изменения. Сами преимущества ощутимее в масштабе, даже если прирост скорости разработки или условного KPI отдельного сотрудника ничтожен. Большой проблемой в крупных командах является совместная оценка сложности задач, но это решаемо за счет отхода от базовых принципов и разделения команды на спринтплэннингах на субкоманды, фронты оценивают своё, бэкенд своё, девопс своё и т.д. Он не гибок по факту везде, но традиционно считается Agile-методологией.
Аутстаф сам по себе зло. "Продали" тут одного товарища в " рабоство" заказчику. По итогу недовольны все. Пока работал у нас и делал заказ для того же заказчика - всех всё устраивало. Проблема в том, что когда есть "голый" результат и деньги, которые ты за него заплатил - это совсем не то же самое, когда ты заплатил за специалиста и потом цацкаешся с ним чтобы получить этот результат.
Гибриды - топ, чистый скрам - зло, дно и мрак.
На самом деле заметят все, так как на разработку свалится прорва работы с требованиями, да и прямая коммуникация разработчика с источниками требований скажется не лучшим образом на скорости поставки ценности.
В b2c web с небольшой командой, как мне кажется, можно просто брать Agile-манифест и следовать принципам, а не заряжать структурированную методологию с кучей ритуализированных нагромождений, но это ИМХО. Опять же есть ли говорить об абстрактной оценке задач и покер скраме, то они полноценно применимы там, где все и так корректно соотносят условный сторипоинт с часами или днями. Итеративная поставка ценности - да, и я упоминал, что это пожалуй лучшее, что есть в скрам.
А вот регулярная обратная связь - уже ситуативно, это опять может стать проблемой на практике, иногда, даже в упомянутых b2c проектах лучше максимально полно собрать и документировать требования, и заряжать источники требований на их более тщательное обдумывание на старте, чтобы их массированное изменение в процессе не превратило разработку в сумбур и не повело по пути бесконечного улучшения. Так как при гибких изменениях требований в процессе уже запланированного спринта, особенно если речь идёт о неких блокирующих задачах, стройное планирование итерации может полететь в тартар.
В таких проектах также можно выстроить порядок сбора требований (подготовки артефактов) и проектирования (блок-схемы, вайрфреймы, дизайн интерфейса страниц и т.п.) таким образом, чтобы минимизировать изменения в процессе. Иными словами есть много факторов, которые затрудняют универсализацию подходов, если конечно проекты не совсем конвейерно-типовые.
Категорическая глупость. Я пришёл в IT в 30. До этого работал в медицине катастроф. Регулярно работаю с олдскульными "тру прогерами", у некоторых по 20 лет в профессии, никогда не сталкивался с тем, что кого-то бомбит или раздувает от ЧСВ. Я работаю PM (совмещаю с ролью BA, в перспективе хочу дорасти до архитектора данных), у меня скромные хардскилы. Я регулярно обращаюсь к коллегам для того того, чтобы эти скиллы улучшать благодаря их посильной помощи и за**бываюсь обучаясь новому.
Основной причиной хейта "галерных старожил" является не то, что кто-то пришёл за баблом, но в том, что многие, кто приходит в профессию сейчас, не способны банально выполнять свои задачи, при этом громко именуют себя "программистами", хотя во времена более зелёной травы к ним бы и унизительный термин "кодер" был неприменим. Порог входа стал крайне низким, что приводит к огромному количеству недоученных специалистов крайне узкого профиля и низкого уровня. При этом кадровый голод вынуждает компании их брать на борт, часто с навешиванием на сеньоров и мидлов дополнительной преподавательской работы, которую забыли провести продавцы воздуха и(или) сам счастливый обладатель оффера.
Мой опыт, опыт коллег, анализ публикаций по теме, данные статистики об успешности проектов, сведения об отказе от 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 есть много привлекательных вещей, которые полезны в разработке, но в чистом виде они нивелируются врождёнными бесполезными, а иногда вредными недостатками.
Если речь о ситуации в которой акулы нападают на каждого второго купающегося, то, думаю очевидно, что купание - зло. А не злом оно является лишь в изолированных бассейнах и водоёмах, где нет акул.
Я только с 16-го управляю проектами. Первое время только и слышал о переходе на SCRUM-процессы. Очевидно критика была, но в СНГ в основном восторженные отзывы. Многие ориентировались на EPAM, забывая о специфике своих проектов и активно нанимали коучей.