Зачем вообще нужно было в разных потоках загружать одни и те же классы? Почему нельзя было выполнить их предзагрузку? Конечно, - это неоптимальное решение изначально. Я уж молчу про инстанцирование фабрики типов для каждого потока. Выглядит как мы сами создали оружие для выстрела себе в колено, а потом героически собрали коленную чашечку и закопали ствол на заднем дворе от греха подальше. Механизм загрузки классов не предназначен для быстрой обработки данных.
Ну, здесь нужно отделять "мух от котлет". В первом абзаце скрам, как он есть и каким должен быть. Во втором - микроменеджмент. Только в статье почему-то написано, что из-за наличия плохих менеджеров скрам - плохой инструмент. По мне так проблема в плохих менеджерах, а не в скраме.
Я - практикующий скрам-мастер в команде, я не менеджер ни разу, я сеньор фронтенд-разработчик с большим бэкраундом в бэкенд-разработке и разработке вообще. На роль скрам-мастера меня выбрала команда. Отвечу Вам ровно тем же сообщением, которым я ответил автору этой статьи в его ТГ-канале по ссылке выше. И, да, это не повторение заученных фраз из скрам-гайда, это ежедневное применение скрама и наблюдение за работой команды до введения этих практик и после их введения (производительность команды значительно выросла).
"Скрам - это лишь инструмент, набор практик, призванный облегчить работу замотивированной команды для достижения цели наиболее оптимальным способом. Если он доставляет команде боль, то это только потому, что команда использует его неправильно. Скрам полагается на 3 столпа: прозрачность, инспекция, адаптация. Прозрачность нужна команде, чтобы все чётко видели цель (как долгосрочную, так и краткосрочные). Инспекция, - чтобы все члены команды понимали, что они по-прежнему движутся к цели оптимально. Адаптация, - чтобы команда могла корректировать свой курс при движении к цели. Скрам - это не бюрократия, а инструмент разработки."
Причём, я добавлю, это инструмент самоорганизующейся команды в первую очередь, а не менеджеров, как указано в этой статье. И, да, если он вам доставляет боль, то значит просто это не тот инструмент, который вам нужен прямо сейчас (для задач или условий, в которых находится ваша команда) или вы неправильно его используете.
Эффективность Scrum была неоднократно доказана различными исследованиями и практическим применением в реальных проектах: Google, Spotify, Microsoft и др.
Всё это просто болтология. Как выполненные цели в срок 4 месяца доказывают, что скрам неэффективен? А где гарантия, что вы с командой не выполнили бы эти же цели быстрее, пользуясь скрамом? Ваш успешный опыт ничего не доказывает и ничего не опровергает. Хотите что-то доказать, поставьте научный эксперимент: 2 команды с примерно равными навыками и опытом и две примерно одинаковые или одинаковые задачи; в одной команде пользуйтесь скрамом, а другая пусть просто пишет код; кто быстрее и качественнее справиться с задачей, тот и победил.
Гениально! Спасибо за такую прекрасную статью! Я бы с удовольствием почитал Ваш учебник, а не тот, который мне преподавали на факультете прикладной математики и информатики. Всё в разы понятнее!
Революции никто не отменял. Вот все раньше силы качали, а сейчас вайбкодят, разве это не революционный трансформация сложности в разработке. Также может и со стандартом произойти.
Зачем вообще нужно было в разных потоках загружать одни и те же классы? Почему нельзя было выполнить их предзагрузку? Конечно, - это неоптимальное решение изначально. Я уж молчу про инстанцирование фабрики типов для каждого потока. Выглядит как мы сами создали оружие для выстрела себе в колено, а потом героически собрали коленную чашечку и закопали ствол на заднем дворе от греха подальше. Механизм загрузки классов не предназначен для быстрой обработки данных.
Ну, здесь нужно отделять "мух от котлет". В первом абзаце скрам, как он есть и каким должен быть. Во втором - микроменеджмент. Только в статье почему-то написано, что из-за наличия плохих менеджеров скрам - плохой инструмент. По мне так проблема в плохих менеджерах, а не в скраме.
Я - практикующий скрам-мастер в команде, я не менеджер ни разу, я сеньор фронтенд-разработчик с большим бэкраундом в бэкенд-разработке и разработке вообще. На роль скрам-мастера меня выбрала команда. Отвечу Вам ровно тем же сообщением, которым я ответил автору этой статьи в его ТГ-канале по ссылке выше. И, да, это не повторение заученных фраз из скрам-гайда, это ежедневное применение скрама и наблюдение за работой команды до введения этих практик и после их введения (производительность команды значительно выросла).
Причём, я добавлю, это инструмент самоорганизующейся команды в первую очередь, а не менеджеров, как указано в этой статье. И, да, если он вам доставляет боль, то значит просто это не тот инструмент, который вам нужен прямо сейчас (для задач или условий, в которых находится ваша команда) или вы неправильно его используете.
Эффективность Scrum была неоднократно доказана различными исследованиями и практическим применением в реальных проектах: Google, Spotify, Microsoft и др.
Всё это просто болтология. Как выполненные цели в срок 4 месяца доказывают, что скрам неэффективен? А где гарантия, что вы с командой не выполнили бы эти же цели быстрее, пользуясь скрамом? Ваш успешный опыт ничего не доказывает и ничего не опровергает. Хотите что-то доказать, поставьте научный эксперимент: 2 команды с примерно равными навыками и опытом и две примерно одинаковые или одинаковые задачи; в одной команде пользуйтесь скрамом, а другая пусть просто пишет код; кто быстрее и качественнее справиться с задачей, тот и победил.
Гениально! Спасибо за такую прекрасную статью! Я бы с удовольствием почитал Ваш учебник, а не тот, который мне преподавали на факультете прикладной математики и информатики. Всё в разы понятнее!
Революции никто не отменял. Вот все раньше силы качали, а сейчас вайбкодят, разве это не революционный трансформация сложности в разработке. Также может и со стандартом произойти.