А вам реально нужно пояснять что нет смысла учиться плавать. Когда автомобили пришли на замену лошадей, люди тоже первое время переживали что катаясь на авто не научатся ездить на лошадях, но... внезапно это оказалось и не нужно
Полностью согласен, сейчас все программисты на уровне ассемблера и уровней сигналов на микросхемах знают как работает код и без этих знаний мир разработки рухнет
Идеальных сотрудников не бывает. Бывают сбалансированные и продуктивные команды. Не пытайтесь найти идеальных сотрудников. Собирайте из имеющихся у вас и на рынке людей работающие и неконфликтные сборки.
По моему опыту (компания около 100 dev команд, где 60% собственная разработка и 40% внешняя) - собственная разработка где гибкость важнее - больше чаще выбирают скрам если проекты стабильные и переходят на канбан в период, когда проект только начинается или завершается. Команды которые в основном работают с внешними системами и выступают в роли постановщика задач/тестировщика - в канбане (но тоже не все). Очень интересная история с командами создания управленки на КХД. Живут по канбану но мы всё время задаёмся вопросом применим ли скрам. А в целом считаю правильным когда оба метода/фреймвока (если вы крупные, то вам и канбан приходится в фреймворк заворачивать иначе не взлетит) существуют в компании и команда САМОСТОЯТЕЛЬНО решает что ей удобнее с учётом жизненного цикла, проекта, технологий, скилов и интереса. Интерес тоже важно. Если команде интересно поработать в скраме - так пусть работают если нравится.
И что только не придумают, вместо того чтобы применять нормальный продуктовый подход и вводить роль PO и CPO... И ведь реально многие изобретают вот такие велосипеды... И вроде в интернете никого не банят, а нет ничего не меняется. Вместо того чтобы объединять бизнес и ИТ в одну кросс-функциональную команду придумывают роли чтобы можно было хоть как-то общаться через этого человека бизнесу и ИТ.
А вам реально нужно пояснять что нет смысла учиться плавать. Когда автомобили пришли на замену лошадей, люди тоже первое время переживали что катаясь на авто не научатся ездить на лошадях, но... внезапно это оказалось и не нужно
Полностью согласен, сейчас все программисты на уровне ассемблера и уровней сигналов на микросхемах знают как работает код и без этих знаний мир разработки рухнет
Идеальных сотрудников не бывает. Бывают сбалансированные и продуктивные команды. Не пытайтесь найти идеальных сотрудников. Собирайте из имеющихся у вас и на рынке людей работающие и неконфликтные сборки.
По моему опыту (компания около 100 dev команд, где 60% собственная разработка и 40% внешняя) - собственная разработка где гибкость важнее - больше чаще выбирают скрам если проекты стабильные и переходят на канбан в период, когда проект только начинается или завершается. Команды которые в основном работают с внешними системами и выступают в роли постановщика задач/тестировщика - в канбане (но тоже не все). Очень интересная история с командами создания управленки на КХД. Живут по канбану но мы всё время задаёмся вопросом применим ли скрам. А в целом считаю правильным когда оба метода/фреймвока (если вы крупные, то вам и канбан приходится в фреймворк заворачивать иначе не взлетит) существуют в компании и команда САМОСТОЯТЕЛЬНО решает что ей удобнее с учётом жизненного цикла, проекта, технологий, скилов и интереса. Интерес тоже важно. Если команде интересно поработать в скраме - так пусть работают если нравится.
И что только не придумают, вместо того чтобы применять нормальный продуктовый подход и вводить роль PO и CPO... И ведь реально многие изобретают вот такие велосипеды... И вроде в интернете никого не банят, а нет ничего не меняется. Вместо того чтобы объединять бизнес и ИТ в одну кросс-функциональную команду придумывают роли чтобы можно было хоть как-то общаться через этого человека бизнесу и ИТ.