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