Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где 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, забывая о специфике своих проектов и активно нанимали коучей.
Слишком широкое допущение. Точнее сказать некоторые суды, в некоторых вопросах учитывают решения других судов (можно также добавить "но это не точно". Что касается "формально" - нет, реально, так как там где прецедентное право существует оспорить решение принятое с опорой на практику невозможно, в России полно кейсов, где это делают, иногда сравнительно легко, иногда со сложностями(если каэшн дело не "...ки мотивированное" - но это не наш случай явно.
Тем не менее, два юриста читают НПА и имеют три мнения.
Опять не уместное допущение. Два юриста читают НПА И видят там текст НПА, три мнения у них могут возникнуть только в том случае если формулировки в НПА не является однозначно интерпретируемыми, таких формулировок в 63-ФЗ нет, булевы переменные, либо случай true, либо false. Если бы было иначе, мы бы не стали тратить ресурсы на разработку и подождали бы более подходящего момента, т.е. изменений в НПА.
У вас ложная аналогия с ошибкой выжившего. В России нет прецедентного права. Т.е. конкретное решение суда не является источником права (исключением, лишь подтверждающим общее правило, можно считать решение пленумов ВС), => аппелирование к практике тут не работает. Это не тот вопрос в котором у двух юристов 3 мнения. Даже если предположить применение принципов прецедентного права и опору на ранее принятые решения, в отсутствии практики как таковой (практики с электронными НД попросту нет) всё упирается в тексты НПА, и в этих текстах всё предельно однозначно: если нет прямого запрета использования ЭП и электронного документооборота, то он разрешён.
Безусловно можно крайне эффективно рубить дерево каменным топором, разводить огонь при помощи кресала и использовать бумажный наряд-допуск. То, что это получается у кого-то не означает, что получается у всех, равно как и то, что там, где это не получается есть якобы "явные проблемы орг. характера". В разных компаниях разные процессы и разные условия. Искренне рады, что у вас всё здорово получается с бумагой.
У заказчика явные проблемы орг характера, а Вы пытаетесь представить, что внедрение эцп решило эти проблемы.
Предположение неверное. Практика с бумажными нарядами , особенно в случаях со срочным проведением опасных работ (внеплановых, аварийных) всегда вызывает сложности. Когда нарядная система автоматизирована, даже частично, как сейчас, этих сложностей не возникает. Мы опираемся на фидбек заказчика, а не на предположения о "гипотетических проблемах орг. характера".
Я так и не понял: система работает, сканы инструктажа загружаются и хранятся либо ждем снятия запрета?
Система работает. Инструктаж технически реализован как цифровая сущность, на практике ждём отмены запрета, инструктажи продолжают подписываться в бумаге, т.к. существует юридический запрет. Тут нет противоречий. Наличие юридического запрета, на техническом уровне работе системы никак не мешает. В данный момент ЭП подписывается всё, кроме инструктажа. Последний быстро печатается из приложения и подписывается в бумаге (пока так)
Не читают иначе (на практике), т.к. регулирующие НПА, в частности ФЗ-63 однозначны и не противоречивы, их нельзя трактовать двусмысленно. Заказчик, у которого внедрён продукт уже проходил проверки и с проблемами не сталкивался (мы об этом написали).
А пройдет ли ЭНД проверку при несчастном случае, когда вместо обычных инспекций будет прокуратура со следователями (не дай бог)?
Как я уже писал, мерилом является практика, на практике инцидентов, требующих участия прокуратуры и СК - не возникало, но в соответствии с буквой закона претензий к работающей сейчас системе вопросов возникнут не может, в силу того, что она полностью соответствует действующим законодательным нормам (на них я сослался в статье).Правоприменение вне буквы закона (как гипотетическую вероятность, связанную с юрисдикцией, из серии "можно докопаться и до столба") мы ведь не рассматриваем, верно?)
а вот различные проверяющие могут читать иначе.
Предполагать можно что угодно, но "различные проверяющие" опираются на действующие нормы, а конкретно эти нормы не могут быть истолкованы двояко.
К счастью у наших заказчиков пока не было такого рода инцидентов, но главным требованием СК в отношении нарядов допусков является собственноручная рукописная подпись для целевого инструктажа (на сколько мне известно, ограничение на применение ЭЦП и электронной формы этого документа лоббировалось именно СК), всё остальное в НД может подписываться ЭП. К самому электронному наряду-допуску у СК и Ростехнадзора вопросов нет, как и к использованию в нём ЭП.
Спасибо, я стремился описать именно этот скрам. Только автор статьи я, а не @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, забывая о специфике своих проектов и активно нанимали коучей.
Слишком широкое допущение. Точнее сказать некоторые суды, в некоторых вопросах учитывают решения других судов
(можно также добавить "но это не точно". Что касается "формально" - нет, реально, так как там где прецедентное право существует оспорить решение принятое с опорой на практику невозможно, в России полно кейсов, где это делают, иногда сравнительно легко, иногда со сложностями(если каэшн дело не "...ки мотивированное" - но это не наш случай явно.Опять не уместное допущение. Два юриста читают НПА И видят там текст НПА, три мнения у них могут возникнуть только в том случае если формулировки в НПА не является однозначно интерпретируемыми, таких формулировок в 63-ФЗ нет, булевы переменные, либо случай true, либо false. Если бы было иначе, мы бы не стали тратить ресурсы на разработку и подождали бы более подходящего момента, т.е. изменений в НПА.
У вас ложная аналогия с ошибкой выжившего. В России нет прецедентного права. Т.е. конкретное решение суда не является источником права (исключением, лишь подтверждающим общее правило, можно считать решение пленумов ВС), => аппелирование к практике тут не работает. Это не тот вопрос в котором у двух юристов 3 мнения. Даже если предположить применение принципов прецедентного права и опору на ранее принятые решения, в отсутствии практики как таковой (практики с электронными НД попросту нет) всё упирается в тексты НПА, и в этих текстах всё предельно однозначно: если нет прямого запрета использования ЭП и электронного документооборота, то он разрешён.
Безусловно можно крайне эффективно рубить дерево каменным топором, разводить огонь при помощи кресала и использовать бумажный наряд-допуск. То, что это получается у кого-то не означает, что получается у всех, равно как и то, что там, где это не получается есть якобы "явные проблемы орг. характера". В разных компаниях разные процессы и разные условия. Искренне рады, что у вас всё здорово получается с бумагой.
Предположение неверное. Практика с бумажными нарядами , особенно в случаях со срочным проведением опасных работ (внеплановых, аварийных) всегда вызывает сложности. Когда нарядная система автоматизирована, даже частично, как сейчас, этих сложностей не возникает. Мы опираемся на фидбек заказчика, а не на предположения о "гипотетических проблемах орг. характера".
Система работает. Инструктаж технически реализован как цифровая сущность, на практике ждём отмены запрета, инструктажи продолжают подписываться в бумаге, т.к. существует юридический запрет. Тут нет противоречий. Наличие юридического запрета, на техническом уровне работе системы никак не мешает. В данный момент ЭП подписывается всё, кроме инструктажа. Последний быстро печатается из приложения и подписывается в бумаге (пока так)
Не читают иначе (на практике), т.к. регулирующие НПА, в частности ФЗ-63 однозначны и не противоречивы, их нельзя трактовать двусмысленно. Заказчик, у которого внедрён продукт уже проходил проверки и с проблемами не сталкивался (мы об этом написали).
Как я уже писал, мерилом является практика, на практике инцидентов, требующих участия прокуратуры и СК - не возникало, но в соответствии с буквой закона претензий к работающей сейчас системе вопросов возникнут не может, в силу того, что она полностью соответствует действующим законодательным нормам (на них я сослался в статье).Правоприменение вне буквы закона (как гипотетическую вероятность, связанную с юрисдикцией, из серии "можно докопаться и до столба") мы ведь не рассматриваем, верно?)
Предполагать можно что угодно, но "различные проверяющие" опираются на действующие нормы, а конкретно эти нормы не могут быть истолкованы двояко.
К счастью у наших заказчиков пока не было такого рода инцидентов, но главным требованием СК в отношении нарядов допусков является собственноручная рукописная подпись для целевого инструктажа (на сколько мне известно, ограничение на применение ЭЦП и электронной формы этого документа лоббировалось именно СК), всё остальное в НД может подписываться ЭП. К самому электронному наряду-допуску у СК и Ростехнадзора вопросов нет, как и к использованию в нём ЭП.