Комментарии 11
То, что скрам - это "всего" 4-5 встреч, еще не значит, что скрам нужен. Скрам - это слишком жесткий фреймворк, не учитывающий контекст. Он наносит вред.
Планирование спринта - это просто жесть.
Во-первых, стори-поинты, которые по канонам не должны оцениваться в часах, но при этом мы их набираем столько, чтобы успеть за 2 недели. Т.е. можно поделить 2 недели на количество сторипоинтов, и получить часы. У разумного человека происходит шизофрения. А еще эти фибоначи, просто смех
Во-вторых, планирование спринта - это постановка самому себе дедлайна. Дедлайн - это источник багов, срезаний углов и т.д. А также у некоторых чувство вины на ровном месте.
В-третьих, оценка сроков никогда не работает правильно в хоть сколько-нибудь сложной системе: если есть задачи на исследование или есть зависимость от других команд. Даже если задачи простые и однотипные, появление нового члена команды или убирание старого ломает все исторические наработки
В-четвертых, по-любому прилетают более срочные задачи, которые ломают план. Если же их не делать - это ломает бизнес.
В-пятых, в разношерстных командах (дизайнер, фронт, бек, админ) бесполезно делать общие сторипоинты, но обычно все равно делают.
Ну и вообще, никого agile (гибкости) в скраме нет. Это жесткий бюрократический механизм.
Скрам хорош только для иллюзии контроля: чтобы нарисовать график работоспособности команды (сторипоинты/чел/мес), а потом пытаться гадать на нём (это естественно неадектватно тоже).
А если обобщить, то это попытка разделить/переложить ответственность менеджеров за провал на плечи исполнителей и приучить их мысли, что они ответственны не только за разработку, но за весь процесс менеджмента.
Полностью согласен!
Любое мало-мальское дело можно завалить путем проведения достаточного количества совещаний и цеременой. Это вот точно про скрам и всех этих пиявок в виде коучей,скрам мастеров и т.д.
Программисты самостоятельные люди, они сами знаю как лучше им организовать работу, а всякие скрам-сектанты просто сидят на нашей шее и получают деньги за воздух.
Тут вот какой инфоцыганский фокус: если взять пример студии из 3 человек, что клепают двустраничные лендинги на продажу, то скрам у них зайдет на ура со всеми представленными в статье моментами:) А дальше уже этот "успешный кейс" будут натягивать на все глобусы в поле видимости независимо от исходных данных по взаимозаменяемости специалистов в команде, присутствия тестирования и наличия клиенстких обращений для не-стартапа.
Во-вторых, планирование спринта - это постановка самому себе дедлайна. Дедлайн - это источник багов, срезаний углов и т.д. А также у некоторых чувство вины на ровном месте.
Если человеку не поставить дедлайн, то задача может решаться вечность. Это я вам говорю, наблюдая во второй монитор задачи, висящие с 2020 года и переползающие из релиза в релиз просто потому что их не хочется делать и есть что-то более интересное.
Уже успели директора поувольняться, которые их ставили.
если есть задачи на исследование или есть зависимость от других команд. Даже если задачи простые и однотипные, появление нового члена команды или убирание старого ломает все исторические наработки
Так автор же и сказал, что существуют процессы, в которых скрам просто не нужен. Если вам его впихивают в такие процессы, то это печально.
по-любому прилетают более срочные задачи, которые ломают план. Если же их не делать - это ломает бизнес.
Тут с одной стороны см. пункт 2, а с другой выходит что Скрам-мастер (если он есть) на пару в Продактом не доработали и не объяснили бизнесу, что по скраму команда на 100% занимается одним проектом, что такое спринты вообще и как это устроено. Это тоже печально.
никого agile (гибкости) в скраме нет
А что вы подразумеваете под гибкостью? Возможность сегодня делать одно, а завтра другое? Так этого и в других подходах нет. Есть цель, есть сроки. Гибкость скрама в том, что после каждого спринта направление разработки может полностью поменяться. Гибкость скрама в том, что можно каждый день на стендапах корректировать процесс. Гибкость в том, что можно после ретро и плэнинга оценить работоспособность команды. Попробуйте в ватерфоле вот так погнуть и поменять без остановки процесса.
встречал ситуацию, где стендапы были по 1,5 часа
Как раз одна из задач скрам-мастера это подобный перфоманс пресекать.
Частое недовольство, которое касается ретроспектив — это обсуждение проблем без непосредственной реализации идей, которые на ней поднимаются, а также поднятие вопросов, которые могут находиться вне зоны влияния команды.
У вас почему-то "ретроспектива" объединена с "ревью". Обсуждение проблем/идей это тема для "спринт-ревью", а встреча с заказчиком/стейкхолдером это "ретроспектива".
Есть ли примеры где со скрам мастером стало лучше чем было до него? Я за свою карьеру разработчика ниразу не видел. Обычно скрам пытаются ввести при нехватке рессурсов. Для оптимизации производства, но как задачу не дели если на неё нужно 2 недели, то она возмёт 2 недели, а срезание углов может только доставить проблем.
Оценки задач нужны для планирования, но если например к концу года надо сделать все задачи, то планирование спринтов за год отберёт кучу времени, а время на разработку никак не измениться и в итоге мы опять не успели.
Ретроспектива вроде как полезна, но почти всегда проблемы внешние, а значит не решаемы коммандой вобще. Ну и самое главное комманда это рессурс и он такой по качеству какой есть, сильно поменять качество людей низя, можно только поменять самих людей. Так что не важно кто и в чём виноват приходиться работать с тем что есть.
Для облегчения понимания скрам мастера и скрама. Представьте команда разработки это город, а скрам это ПДД, соответственно скрам мастер это гибдд, обязующее соблюдать всех правила. Так вот представьте город, в котором исчезли, знаки, светофоры и гибдд с правилами пдд. Все встанет, экономика остановится, развитие прекратится, все взвоют, начнётся хаос. Вот то же самое будет, если в развитой зрелой продуктовой команде убрать скрам со скрам мастером.
Просто скрам не заходит в команды, потому что они находятся на уровнях развития колхоза, где скрам вообще то мало помогает, из за слабой квалификации команд и отсутствия грамотных скрам-мастеров. Как и пдд мало требуется в колхозах, ввиду низкой производительности и интенсивности взаимодействия участников движения. Там хватит одного председателя колхоза типа менеджера проекта, который все разрулит.
Отсюда трудности понимания почему скрам мастер не прямой руководитель, он как и гаишник никому прямо не указывает куда кому ехать, все сами решают, свои задачи, а курс развития продукта задаёт владелец продукта, который формирует беклог с эпиками и историями. Ну типа мэра в городе.
Я совмещаю должность КСМ и тестировщика. К нам пришла недавно новая девочка СМ и теперь она курирует нашу команду. И она решила зайти сразу с ноги. В принципе у нас в команде более менее налажены процессы, но она все что-то пытается улучшить. При этом за 2 месяца так и не разобралась, что такое тетрис. Зато мы решили командой, что ретро будем проводить в пятницу утром, вместо вечера.
И тут начался конкретный вынос мозга. Нет, нужно ретро проводить в конце спринта, обязательно вечером в пятницу. Это не я придумала, вот почитай.
Вообщем полный трындец какой-то. У меня складывается ощущение, что она только мешает работать.
При этом в других командах не проводят ретро и ничего, зато до нашей команды докапалась, что мы должны проводить только так и никак иначе. У меня все. Просто наболело.
Скрам мастер. Кто это и нужен ли он вообще?