Ребята, привет) в СГ сказано что длинна спринта (продолжительность)

должна быть фиксирована, но нет запрета на изменение этой продолжительности. В связи с этим вопрос может ли длинна спринта быть динамичной (команда хочет менять длину спринта каждый спринт)? Заранее благодарен за ответ)

Всё можно, если понимаешь зачем. Если не понимаешь - работай как написали те, которые понимают.

Привет. А какая цель у этого шедевра? Команда может хотеть не работать, например, или хотеть нанять ещё 15 человек, но это же не значит, что нужно это делать. Действительно, нет никаких жёстких ограничений, относительного этого, но это ж бред 😅

Ограничение спринта нужно в том числе и для ощущения конечности работы. Если будешь менять спринт часто - ощущение сотрется. И если кратко, то люди быстро начинают выгорать от такого ощущения бесконечной работы. В каком то из сг было написано, что длина спринта раз и навсегда.

Для постоянной смены сроков я вижу только одну причину - нестабильный скоуп работ, и в одном спринте задач может быть на две недели, а в другом на одну. Это значит, что ПО хреново работает, а devteam ещё хуже рефайнит для декомпозиции б

Менять длину каждый спринт, чтобы что?

Истиной цели я пока не знаю)) но ребята этим самым хотят оправдать невыполнение целей спринта, якобы сейчас есть набор задач под цель на 2 недели, а в следующем будет на 3 ))

Чтоб выполнять цели))

Это очень плохо. Ребята пытаются натянуть сову на глобус и поработать, чтобы поработать. Трехнедельную цель надо значит дробить 🤷🏼‍♂️

Когда при внедрении Scrum что-то кажется неудобным, это значит что Скрам высветил вашу дисфункцию. И общий подход в большинстве случаев - надо подгонять вашу реальность под стандарт Скрам, а не наоборот. В данном случае очевидно подсветилось некачественное планирование и/или деливери. Скрам создаёт давление по завершению задач к определенному сроку и если команда не успевает, надо смотреть почему не успевает и менять это, а не продлевать спринт

Трехнедельную цель надо дробить (причем так, чтобы двухнедельный кусок был законченным, с соответствующим увеличением итоговой стоимости цели) - чтобы что?

Скрам высвечивает "дисфункции", мешающие идеальному соответствию Скраму. Совпадают ли они с реальными проблемами бизнеса, вопрос отдельный и серьезный.

А есть пример, когда не совпадают?

Вот выше был вариант: бизнесу не интересно получать ценность по кускам каждые 2 недели и дороже. Ему важнее получать ценность целиком и немного дешевле "на круг".

Что значит "не интересно"? И кого вы называете "бизнес"?

То и значит. Владелец бюджета, который оплачивает весь банкет, не покупает историю с поэтапной передачей. Ему она объективно не выгодна. Ему выгодно целиком за один раз. Причем, "выгодно" здесь тоже в прямом смысле, экономически и может быть рассчитано.

Интересно - это не критерий. Поставки ритмичными короткими интервалами повышают качество поставленного функционала, увеличивают скорость поставок и обеспечивают удобство и предсказуемость планирования, которое можно масштабировать и на стратегическое планирование - отсюда вопрос ради чего вы хотите отказаться от этих преимуществ. В чем конкретно выгода, кроме того, что какому-то конкретному человеку так "интересно"?

А почему тогда гайд не содержит требование "не меняйте длину спринта"? Может все не так однозначно?

А потому что гайд - это не исчерпывающая инструкция, а лишь короткий максимально обобщённый мануал

просто попробуйте и поймете насколько это вам подходит), нам было неудобно

На каких-то проектах так и делаем. Мы просто перестали давно внутри спорить "скрам/не скрам" и за редким исключением не имеем выделенной роли СМ в командах. Мне в целом интересно именно это - можем ли мы что-то получить от того что начнем вместо на наш взгляд реально гибких подходов более жёстко придерживаться скрам практикам

Поэтому мне гораздо ближе перевод Agile как "проворный", а не "гибкий". Потому что люди начинают трактовать "гибкость" как удобство, гнуть фреймворки под свои "костыли". А на самом деле если готовый фрейворк чувствуется как "неудобный" - это потому что нарушает ваш существующий неэффективный костыльный метод. Впрочем я уже это тут писал

А какое значение имеет перевод названия? Смысл идеи раскрыт в манифесте, а не названии

Дак а кто ж его читает этот манифест? Сколько из прочитавших его понимает? И сколько из понявших корректно применяет?

Наверное сложно одновременно топить за уважение к коллегам и считать их не очень умными?

Поставки ритмичными короткими интервалами (нюанс!) ДАЮТ ВОЗМОЖНОСТЬ повысить качество поставленного функционала, увеличить скорость поставки реальной ценности и обеспечить удобство и предсказуемость планирования, которое можно масштабировать и на стратегическое планирование. Для реального получения вышеописанного профита одного лишь ритма коротких поставок недостаточно. Те же выгоды можно получить и при отсутствии ритма, но при коротких поставках. А можно и с длинным ритмом. В чем конкретно выгода, кроме того, что какому-то конкретному человеку так "интересно"? Представьте такую гипотетическую 😉 возможность, что заказчику себестоимость фичи важнее, чем скорость поставки. Или поставка вообще с фиксированной датой и скорость не имеет значения вообще. Если этот заказчик не оплатит фичу, на какие деньги будет существовать скрам команда? Обычно на этом месте просят пример. Давайте в пример. Специально без аппаратной части, для наглядности. До конца года 3 месяца. Это 6 двухнедельных спринтов. Заказчик хочет прикрутить к продукту фичу для выполнения требований нового закона. Раньше не надо, позже никак нельзя. Команда оценивает фичу и по известному велосити прикидывает: фича одним куском займет 3 спринта. Но для "потенциально поставляемого инкремента" надо в конце каждого спринта собирать продукт в готовом виде, поэтому добавляются работы на интеграцию каждого добавляемого куска фичи. Итого 4 спринта. Запас по времени есть, успеваем, все вроде ок. И тут грамотный заказчик спросит: а зачем мне платить 4 спринта за фичу, если можно платить3? Какой мне будет профит от этого?

1) не дают возможность а конкретно снижают обьем ошибок и переделок, которые всегда есть 2) отсюда не только повышение качества и скорости поставки НО и сниженная себестоимость 3) спринты не привязаны к дате поставки и нарборот - вы можете вполне себе поставить фичу в середине спринта, тут нет ограничений 4) для того чтобы разбирать конкретный кейс нужно гораздо больше деталей и контекста

1) каким именно образом? 2) Откуда? Если из п.1, то с ним еще не разобрались. 3) Для поставки фичи нужен аппрув от РО (по гайду). Это происходит на обзоре спринта, который случается в конце спринта. Вы предлагаете делать какие-то промежуточные обзоры спринта? (Это реально "дырка" в СГ. Ее вот такой мантрой про "не запрещено" заткнули. Так себе подход на мой взгляд). 4) Куда уж конкретнее? Фича по частям не нужна, только целиком. Зачем платить за поставку по частям, если целиком дешевле? При том же уровне качества и всего такого.

1) если у вас разраб неправильно понял задачу и на протяжении 2 недель делает не то что надо, то это ровно в два раза дешевле чем если он делает неправильное месяц. 3) ПО должен общаться с командой не только на обзорах спринта , а устанавливать релизные даты вообще на поанировании должен то есть заранее

по 3 вполне рабочий вариант, что релиз хоть несколько раз в день, а на обзор инкремент за спринт

если в этом есть практический смысл, конечно

3) Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Из какого Гайда пункт 3 вырос? Какой аппрув от ПО? Почему именно на Обзоре? 🤔

Короткий спринт не лучше решение проблемы с разрабом который делает задачу 2 недели. Скрам гайд например рекомендует сделать декомпозицию таких задач на много коротких, желательно до 1 дня. Мы же чтим гайд?

1) А почему мы сразу уходим в негативную ветку "неправильно понял и неправильно сделал"? Есть инструменты, кjторые позволяют правильно понять и сделать не дожидаясь конца спринта. Я больше скажу, если по такому принципу и спринты в Скраме вести, это будет офигенно дорого, выбрасывать даже по 2 недели работы команды. Общение РО с командой не толькона обзорах - сюда же.

Сделайте длинный но не меняйте его длину

Как долго эту длину надо не менять? Какой у нас должен быть горизонт планирования?

Именно так и написано: created != delivered 😉

However, an Increment may be delivered to stakeholders prior to the end of the Sprint

Вообще не так

По-моему, в версии 17 года еще было. В текущей вроде убрали.

Потому что это очень распространенный риск. Я очень сильно сомневаюсь что у вас его нет, так как обычно он есть у всех. Ну а вообще как я и говорю так можно в полный релятивизм скатиться. Я говорю про общее положение вещей которое я наблюдаю в организациях, если вы уникальное исключение, то вообще непонятно зачем вы обсуждаете его в общих терминах и пытаетесь доказать что Скоам плох в принципе. Просто скажите - у нас все не так мы уникальны

А зачем обсуждать устаревшую версию?

Хороший вопрос. Наверное, незачем.

Этот риск не убирается просто частой поставкой. Для работы с ним есть другие инструменты. Познакомить нужных персон с планируемыми изменениями, понять их правильно и т.д. можно и без поставки.

Как это не убирается, вы приносите и показываете фичу на демо, вы 100% увидите, что вам сделали не то. Да другие инструменты есть, но по 100% надежности ограничения таких потерь всего лишь конкретным коротким периодом этот - лучший

Ничто так не проверяет гипотезу о потенциальной ценности для аудитории, как получение от них прямой обратной связи

Если про демо, то есть пара вопросов. Можно ли делать демонстрации не в конце спринта? (Даже поставку можно! ага))) А можно ли делать демо, если спринтов нет вообще? А регулярные демо?

Аудитория это кто именно в данном случае? Заказчик? Спонсор? Пользователи? Кто-то еще?

Можно все. Правильный вопрос - эффективно ли? Ответ - нет, не эффективно.

Почему это не эффективно? Я считаю, что вполне эффективно.

Вот вы и должны решить это для конкретного продукта :) Можно даже карту стейкхолдеров составить. Но она будет уникальной для вашей организации и вашего продукта

"Я считаю" - это не критерий. Но опять же - вы конечно вольны поступать как знаете. Работать продуктивно и эффективно - это не обязанность, а выбор

Вот опять. Вроде не напрямую, но вы стараетесь донести мысль, будто "продуктивно и эффективно" == "по Скраму", а если Скраму не соответствие, тогда ни продуктивности ни эффективности не получится. А ведь это не так. Поэтому я постарался навести вас на мысль, что Скрам не единственный вариант. И что он не везде даст наилучшую эффективность.

Если это приносит пользу - почему нет? Обзор - хорошая практика синкануться со стейками

Я понимаю, что у вас есть эта мысль - но только аргументов демонстрирующих её состоятельность вы не привели. Конкретные преимущества Скрам я вам назвал. Назовите конкретные преимущества вашей альтернативы и обсудим. Но желательно без "я считаю", "норм/не норм" и "интересно/не интересно"

Это не преимущества, это лозунги. Периодическая поставка это не эксклюзив Скрама. Демо и планирование - тоже. В итоге, у Скрама "своего" только ограничения.

Что мешает сделать следующий логический шаг и просто не задавать длинну спринта вообще равной ничему?

Попытка работать фиксированными таймбоксами гарантировано снижают качество поставленного функционала, увеличивают сроки поставок, ухудшают производственную культуру и приводят к множеству дисфункций. Старайтесь всеми силами этого избегать.

Не выполняются коммиты в двух недельном спринте, есть гипотеза что если убрать спринты то увеличится время работы над задачами.

Смотря какие ещё лишние практики вы отмените вместе со спринтами. Чем меньше лишних практик - тем быстрее поставка, очевидно

Где-то потерялся смайл или я не уловил глубины мысли?

Это на серьезных щах. Не только на этом канале от него.

Стикер

А ты как думал? Это эксперт.

Да,.в общем-то, особой глубины и не нужно - всё на поверхности. Ну и многолетняя практика только подтверждает очевидное.