Наш менеджер говорит, что мы слишком особенные для скрам-гайда. Извините.

Ну CCPM там не настоящий. Про отсутсвтие фидбека - понял, но не согласен. В идеальном случае да, RS подразумевает, что у тебя есть фиксированный скоуп, а буфер покрывает только вариации в оценке. Но собственно в самом RS так не говорят, а говорят, что буфер покрывает любые вариации - оценка, смена скоупа, вот это вот все. опять же, никто не заставляет делать предварителную оценку на весь срок проекта, достаточно понять размах вариации по одной оценке и использовать модель для получения буфера (т.е. оценить один раз, например, на первых два спринта. Потом на основе разброса по этим оценкам - получить предположения о размере бэклога, и на этом основании вычислить буфер) Точно так же можно работать с фидбэком, можифицируя бэклог. Единственное, что в этой ситуации тебе придется договариваться о предельном размере бэклога, но так и RS предназначен для работы именно в проектной среде, в которой срок важен, а скоуп вариабелен :)

мой поинт - юзайте подход в проектной среде, но не называйте это скрамом. только и всего

ну и CCPM не с любым размером неопределенности может работать

так там от CCPM осталось только концепция буфера.

С другой стороны, в проектной работе со скоупом, оговоренным контрактом, скрам в принципе работает так себе.

Быть может он сможет привести вам примеры в чем вы особенные и что по его мнению, если оно важно, будет нормальным и/или подходящим для скрамгайда?

просто впихивая скрам туда куда он не впихивается мы только инструмент обесцениваем

Он уволен со вторника, так что скорее всего уже нет. Павел, Игорь, большое спасибо за помощь 🌷

Так впихивается же. Ну да, это как возить картошку с дачи на рынок в двухдверном спортивном купе.

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

В том то и дело, что в RS он не вариабельность оценок отражает, а вариабельность velocity :)

которая производная от вариабельности оценок :)

Ну да, но CCPM то именно вариабельность оценок использует. Velocity это такое... очень сильное упрощение.

ну вот меня смущает этот манёвр. CCPM хотя бы численно обоснованный метод

забыл ему сказать что бурндауна в скрамгайде нету и его вести необязательно :D и у нас он был по стольку по скольку его генерировала жира :D

Кажется он там был в одной и прошлых версий...

Кажется он там был в одной и прошлых версий...

burndown необязателен уж 7 лет как. его выпилили в 11 году.

Ценностей тогда еще не было, можно было не соблюдать и гнуть всех под берндаун :) И никакая цель спринта не помешает, ибо ее нет ещё)

этот чувак назвал PBR грумингом. так что возможно его скрамгайд немного протух

Стендапы еще есть :)

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

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

Мы пробовали делать промежуточный обзор по обоюдному решению команд и РО. Не прижилось. Получается проще позвать РО и в каждом конкретном случае получить обратную связь, если она необходима.

Мы по итогам обратной связи после обхора договорились так. Если замечания небольшие, в 1-2SP (это 99.9% случаев), то тут же готовим элемент Бэклога с этими изменениями и ставим на следующий Спринт в эту же команду. Если изменения более глобальные, то они остаются в Бэклоге на усмотрение РО. Фича в любом случае заходит или нет в релиз по решению РО. Несколько спринтов так работаем, вроде заходит.

Бардак. Демо когда попало, назначается максимум за полдня. Релиз когда попало, на 7-11й день. Ладно, если мы релизим на 7й, не понятно, что дальше делать, спринт досрочно заканчивать? Разработчик говорит "я уже взял таску из бэклога, я в контексте, не хочу на фиксы регрессии переключиться.

А как это технически совместить с тем, чтобы на демо показывать полностью готовую версию (если регрессия - это часть dod)? То есть вот если мы собрали релизный билд с фичей, показываем его, а ро говорит, что фичу не релизим. Пересобирать, чтобы эту фичу выковырять?

По моему вам скрам вообще не нужен У вас сформирован продукт, искать там нечего Просто брать и делать Scrumban или просто kaban Приоретищируйте беклог, оценивайте задачи и делайте их Как будет что показать важное можно запланировать демо и выделить на это время

У нас 11:36