Scrum
А расскажите про ваш опыт работы со скрамом
Как вы к нему относитесь, что он изменил, в чем помог, чем помешал.
Как вы к нему относитесь
Есть в этой жизни вещи, которые нужно просто пережить: детский день рожднения с 10ю детьми, поход в магазин со своей половиной, недельный визит тёщи/свекрови ну и скрам. ;-)
Де-факто стандарт в организации процессов в ИТ.
В принципе полезная вещь, позволяет упорядочить деятельность, наладить обратную связь от всех членов команды.
Включает ритуалы типа регулярных митингов, стикеры с идеями и т.д.
Проблема в том, что если основное руководство (PO) хреновое, то Скрам заполняет собой вакуум и становится вещью в себе, т.е. пустой тратой времени на эти самые ритуалы.
Очень даже полезная штука при правильном применении. Особенно если действительно использовать ретро для файнтунинга процесса.
Я тут собрала негативные отзывы про скрам, что скажете?:
1. Скрам-менеджеры, которые закончила трехнедельные курсы и мнят себя гуру, при этом не в курсе специфики разработки и не интересуются судьбой продукта, а пытаются укрепить свое влияние.
2. Ритуалы как самоцель - митинги как например ретро, где каждый должен что-то сказать, даже если по сути ему сказать нечего, и поэтому изрекает что-то вроде "мне понравилась взаимопомощь в команде и не понравилась гетерогенность команды". А потом скрам-мастер важно зачитывает с листочка все эти реплики.
3. Искусственные деадлайны (конец спринта), вжимающие разработчика, работающего над комплексной проблемой, в слишком тесные рамки.
4. Идея о универсальности разработчика ("в команде каждые должен мочь делать все"). В результате вместо того, чтобы глубоко вработаться в одну тему и в один проект, люди вынуждены прыгать по верхам и "учиться всему понемножку", делая то дно, то другое. В итоге нет и Codeownership, никто не чувствует себя по настоящему ответственным.
1. Скрам-мастера скорее имеются ввиду. Они просто модераторы на всех этих митингах, никакого влияния.
2. Ретро бесит по многим причинам:) Стараюсь избегать по возможности.
3. Если нереально успеть сделать что-то к сроку, то нереально. Значит, переносится на следующий спринт. Ошибка планирования.
4. Да. Это попытка избежать наличия "незаменимых людей".
Я тут собрала негативные отзывы про скрам, что скажете?
Проблематика раскрыта довольно точно.
Я видел скрам-мастерицу, после курсиков-шмурсиков, облающая нулевыми знаниями в ИТ и в people management, возомнила себя начальницей. Пыталась командовать закалёнными в боях ИТ-шниками, в т.ч. с 15-ти летним опытом. Пришлось ставить на место. Но допускаю, что встречаются мастера и поумнее.
Ритуалы как самоцель - точно. Если ПО никакущий, ни стратегии, ни тактики, а скрам мастер активный.
Ретро на самом деле довольно полезен. Если человеку вообще нечего сказать после 2-х недельного спринта, то наверное человек в команде не нужен.
По поводу искусственных дедлайнов и универсальности - да, нужно договариваться.
Многое зависит от product owner, он должен быть лидером, а скрам-мастер как помощник без лишнего гонора. ИМХО.
1,2 - все так. Прошли это лет 5-10 назад. Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает. В итоге через примерно год этой суеты руководство понимает, что лучше не стало, и от него избавляются.
1. Скрам-мастер - это обслуга. Его должно быть как хорошего официанта не видно и не слышно, но при этом он должен возникать из небытия при первой же организационной проблеме и решать её.
2. Цель ретро - улучшение процесса. Естественно, что не каждый должен высказываться. И высказывания должны быть типа "мы тут применили метод Х и получили классные результаты, надо внедрить его более широко". Или "наш билд косячит и блокирует процесс, надо выделить в следующем спринте время для устранения проблем".
3. Комплексные проблемы разбиваются на части, которые умещаются в один спринт. Максимальная оценка задачи - один спринт. Иногда это невозможно, и это нормально. В последнем проекте я три спринта работал над одной задачей один, ибо никто другой не имел достаточной квалификации для её
решения. Разбивка на подзадачи формально была, но фактически большого смысла не имела. Такие задачи переносятся на планировании в следующий спринт.
4. Codeownership и не должно быть, но при наличии специализаций их надо просто учитывать при планировании. В итоге мы планировали достаточное количество пунктов для бекенда, фронтенда, и для меня отдельно, если были сложные темы.
На самом деле, имхо сложнее всего правильно организовать дейли чтобы не бесил. Дейли нужен для координации ежедневных задач, не надо там рассказывать романы о деталях проделанной работы.
Я видел скрам-мастерицу, после курсиков-шмурсиков, облающая нулевыми знаниями в ИТ и в people management, возомнила себя начальницей. Пыталась командовать закалёнными в боях ИТ-шниками, в т.ч. с 15-ти летним опытом. Пришлось ставить на место. Но допускаю, что встречаются мастера и поумнее.
Речь о немцах? Давно я не видела немцев, ставящих кого-то, кто это заслужил, на место. У нас матерые специалисты сидят и молчат в ответ на произвол скрам-публик
Многое зависит от product owner, он должен быть лидером, а скрам-мастер как помощник без лишнего гонора.
Скрам-мастер аргументирует правилами скрама и например обьявляет ПО, что те и эти вещи он решать не имеет права. Если скрам-мастер из рядов команды, то с ним легко договориться, а вот засланные мастера гнут свою линию. Их ситуацию облегчает непонимание специфики и желание расширить влияние скрамаи тем самым усилить свою роль
1,2 - все так. Прошли это лет 5-10 назад. Нанимается скрам-мастер за кучу денег, который создаёт видимость бурной деятельности, генерит кучу бесполезных митингов и всем мешает. В итоге через примерно год этой суеты руководство понимает, что лучше не стало, и от него избавляются.
Эх, хорошо бы. Часто сначала уходят все полезные люди, прежде чем всем станет ясно, что от бесполезных людей и процессов надо избавляться
Речь о немцах?
Нет, я тоже замечаю что немцы те ещё терпилы. Я сам вежливо обясняю, что уважаемая мастерица, ты несёшь херню, я буду делать так как правильно, а не как ты придумала. Она "сложила уши" очень быстро.
Скрам-мастер аргументирует правилами скрама и например обьявляет ПО, что те и эти вещи он решать не имеет права.
Ну вобщем правильно. В определённом смысле разделение властей. Но только скрам не должен касаться принципиальных продуктовых вопросов. Шедулить митинги, timeboxing, букирование проектора и прочая дребедень. А продукт трогать не надо.
Нет, я тоже замечаю что немцы те ещё терпилы. Я сам вежливо обясняю, что уважаемая мастерица, ты несёшь херню, я буду делать так как правильно, а не как ты придумала. Она "сложила уши" очень быстро
Вот у нас я единственная не-терпила, но толку малоНо только скрам не должен касаться принципиальных продуктовых вопросов.
Но только скрам не должен касаться принципиальных продуктовых вопросов.
Например по скраму ПО не имеет права решать, какие войдут в спринт, а какие нет. А это принципиальный вопрос
1. Скрам-мастер - это обслуга. Его должно быть как хорошего официанта не видно и не слышно, но при этом он должен возникать из небытия при первой же организационной проблеме и решать её.
Мечта! Но обычно такие типы не любят держаться в тени.
Codeownership и не должно быть, но при наличии специализаций их надо просто учитывать при планировании. В итоге мы планировали достаточное количество пунктов для бекенда, фронтенда, и для меня отдельно, если были сложные темы.
Мне кажется, чем лучше специалист, тем меньше ему нравится метаться между отдельными карточками, а хочется заниматъся своим проектом, углубляясь как можно сильнее в него. Пкм у моих коллег так.
Не знаю, мне понятно желание иметь "свой код", чтобы никто кроме тебя в нем никто ничего не мастерил. И чтобы иметь возможность нести полную ответственность за него и пронимать решения.
