5 распространённых заблуждений о Скраме

Отвечаем за инкремент и привнесенную ценность. Не делаем холостых (без ценности) спринтов. Фиксируем факапы и стараемся их недопустить в дальнейшем..

Мне скорее понравилось: со всеми заблуждениями в жизни уже повстречался, наверное у всех так

Добро пожаловать в мир разработки. Ради эксперимента попробуйте на эту же тему расспросить какого-нибудь проектировщика гражданского строительства. Он вам скажет, что у них есть нормы по скорости, но они работают только для типовых проектов и только в этом случае есть хоть какая то объективная метрика за которую можно спрашивать. В разработке ПО дело обстоит гораздо сложнее - типовых проектов нет вообще (зачем делать тоже самое, что уже создано, когда это можно просто копировать) Отсюда вывод, что как только вы начнёте ставить сроки сверху, появятся проблемы. И тем их больше, чем жёстче постановка сроков (не приведи вас галактика начать за это "штрафовать" на деньги - попрощаетесь с лучшей половиной команды). Спрашивать же человека серьёзно за сроки, которые он ставит себе сам тоже не особо выход - он будет брать срок с запасом. Отсюда и родился скрам - есть план, который команда ставит совместно с "продукт овнером" (Обычно в компаниях эту роль исполняет менеджер ) Предполагается что этот план плюс/минус объективен, т к в его выработке сами исполнители определяют объëм работ и в конечном итоге косвенно срок окончания. Но реальный мир сложнее любого плана. Поэтому есть "ретроспектива" с разбором "факапов" и корректировкой следующего планирования. Причём тут под " Факапом" может пониматься что угодно, а не обязательно косяк разработчиков. В том числе, когда сроки берутся с запасом. Т е команда сделала больше, чем планировала. Потенциальные "факапы" команда со временем учится учитывать в фазу планирования. Повлиять на этот процесс тяжело. Единственный действенный способ - это самомотивация каждого участника команды. Ну и если он безответственный или ещё как то не подходит к команде, то команда его со временем исторгнет из себя. Что однако не означает, что он не может быть эффективен в другой команде. Нужно понимать, что для всего описанного в организации должны быть условия. На мой взгляд это главное о чем обычно забывают в российских организациях "эффективные менеджеры", внедряющие скрам формально "по методичке" или советам "бизнес -коуча"