Адекватном менеджере, у которого достаточно компетенций в продукте (проекте, портфеле проектов)
Менеджере с достаточным уровне проф. эмпатии.
Наличии у менеджера хард скиллов, чтобы объяснять и доказывать что-то подчинённым, если речь о техническом вопросе (обычно уровень технических компетенций ниже).
И ещё.Признаки в таблице реакций на обратную связь крайне спорные. Причины описанных реакций могут быть очень вариативными, жестко привязывать к "принял" "не принял" , большая ошибка, которая ведёт к ненужной формализации реакций сотрудников и ошибкам в понимании фидбека от сотрудника.
Коллеги, мы в том же положении, ожидаем пока вендор (дорогой наш 1С) исправит эту ошибку. Мы будем признательны если вы проголосуете за её решение https://bugboard.1c.ru/?state=prj-plt8gen-er-70123389 / Смею надеяться, что это ускорит процесс.
В качестве шутки: "фронтендеры ждут, пока сделают бэкенд" Странное утверждение, а у вас точно 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, в перспективе хочу дорасти до архитектора данных), у меня скромные хардскилы. Я регулярно обращаюсь к коллегам для того того, чтобы эти скиллы улучшать благодаря их посильной помощи и за**бываюсь обучаясь новому.
Основной причиной хейта "галерных старожил" является не то, что кто-то пришёл за баблом, но в том, что многие, кто приходит в профессию сейчас, не способны банально выполнять свои задачи, при этом громко именуют себя "программистами", хотя во времена более зелёной травы к ним бы и унизительный термин "кодер" был неприменим. Порог входа стал крайне низким, что приводит к огромному количеству недоученных специалистов крайне узкого профиля и низкого уровня. При этом кадровый голод вынуждает компании их брать на борт, часто с навешиванием на сеньоров и мидлов дополнительной преподавательской работы, которую забыли провести продавцы воздуха и(или) сам счастливый обладатель оффера.
Это всё работает, при:
Адекватном менеджере, у которого достаточно компетенций в продукте (проекте, портфеле проектов)
Менеджере с достаточным уровне проф. эмпатии.
Наличии у менеджера хард скиллов, чтобы объяснять и доказывать что-то подчинённым, если речь о техническом вопросе (обычно уровень технических компетенций ниже).
И ещё.Признаки в таблице реакций на обратную связь крайне спорные. Причины описанных реакций могут быть очень вариативными, жестко привязывать к "принял" "не принял" , большая ошибка, которая ведёт к ненужной формализации реакций сотрудников и ошибкам в понимании фидбека от сотрудника.
В посте слишком много вредных упрощений.
Это я как практикующий PM, если что...)
Коллеги, мы в том же положении, ожидаем пока вендор (дорогой наш 1С) исправит эту ошибку.
Мы будем признательны если вы проголосуете за её решение
https://bugboard.1c.ru/?state=prj-plt8gen-er-70123389 /
Смею надеяться, что это ускорит процесс.
В качестве шутки: "фронтендеры ждут, пока сделают бэкенд" Странное утверждение, а у вас точно 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, в перспективе хочу дорасти до архитектора данных), у меня скромные хардскилы. Я регулярно обращаюсь к коллегам для того того, чтобы эти скиллы улучшать благодаря их посильной помощи и за**бываюсь обучаясь новому.
Основной причиной хейта "галерных старожил" является не то, что кто-то пришёл за баблом, но в том, что многие, кто приходит в профессию сейчас, не способны банально выполнять свои задачи, при этом громко именуют себя "программистами", хотя во времена более зелёной травы к ним бы и унизительный термин "кодер" был неприменим. Порог входа стал крайне низким, что приводит к огромному количеству недоученных специалистов крайне узкого профиля и низкого уровня. При этом кадровый голод вынуждает компании их брать на борт, часто с навешиванием на сеньоров и мидлов дополнительной преподавательской работы, которую забыли провести продавцы воздуха и(или) сам счастливый обладатель оффера.