ее достижение при не выполнениее скоупа спринта? Разве Sprint Goal - это не есть high-level юзер-стори сама по себе, а стори в спринте - декомпозиция этой стори?
Простой кейс Начали спринт, наметили бэклог спринта, через дня что-то происходит, часть бэклога становится невыполнимой, но цель осталось актуальной, нам нужен новый план, спринт продолжается
Давайте будем не трогать внутрение задачи, которые не относятся к цели спринта напрямую. А возьмем те стори, которые мы делаем для достижение Sprint Goal. Мое утеврждение в том, что Sprint Goal - это такая же стори как и все и подчиняется тем же законам. Мы ее можем успеть в спринт, а можем нет. То есть что бы достигать цели каждого спринта нужно успевать делать все релевантные юзер-стори
и кажется надо продолжить....вопрос-то в чем?)
Смотрите, есть распросранненная мантра от скрам мастеров, что выполнения скоупа спринта не равно выполеннию цели. А я говорю, что выполенение спринта цели равно выполнениею скоупа всех релевантных стори.
Чтобы достичь цели спринта, надо достичь цели спринта, а не сделать ВСЕ релевантные стори.
Так а почему? Это повторяется как мантра, но я не пойму почему Sprint Goal должна вести себя отлично от Юзер Стори. Вот есть большая сторя мы ее или сразу сделаем или режем. Но так или иначе она готова, когда Acceptance Criteria обшая выполнена
"выполнения скоупа спринта не равно выполеннию цели"....это где такое говорят? звучит странно
Вот Игорь например говорит.
Не соглашусь, цель - это "зачем" (накормить человека), скоуп это "что" (первое, воторое и так далее), план спринта это "как" (начистить картохи,сварить бульон и так далее)
Если по ходу спринта выяснится, что картохи нет и не предвидится, твой клиент останется голодным, или ты ему что-то другое всё же предложишь?
Проблема в том, что а как я узнаю сыт ли клиент? Я же говорю, не возможно в конце спринта мнгновенно померить сытость. Можно заделиверить скоуп, и отправить кушать его. Через спринт-другой узнаем наелись ли им или нет.
Так у тебя сытость зависит от картохи или от клиента? Спроси, всего делов-то :)
Так мы же хотим ранить спринты и достигать целей каждый спринт. Не сделаете вы это на 2-х недельном интервале, не работает так продуктовая разработка.
Могу себе представить, что в заказной разработке можно. Но тут еще вопрос, а почему в Скрам Гайде не прописано, когда конкретно и как мы проверяем выполнения достижения спринта? Мне видится злой умысел, что бы скрыть что фреймворк какой-то бесцельный, не гарантирует ничего, что бы никто не мог предьявить.
Потому что тогда это был бы не легковесный фреймворк, а PMBoK или RUP Guide :)
Доказывать кому-то что-то в интернете - занятие неблагодарное. Если тебе хорошо, то и слава Богу. Ты спросил, тебе ответили. То, что тебе ответ не понравился, не значит, что он неверный. Перевербовывать из одной веры в другую я точно никого не собираюсь. Пока не горит, денег много, рынок стабильный, клиенты платят, ничего не трогай, ничего не меняй. Возможно, компания протянет ещё лет 10-15, пока молодые да быстрые не сожрут. Выживание - дело добровольное. Не я сказал.
Спасибо за мнение, но я молодые и быстрые как раз имеют свойсвто задавать вопросы и фокусироваться на том, что производит измеримый результат
Так в чем же дело? Проведи эксперимент, измерь результат, сделай вывод, вернись на шаг 1. Что не так?
Ещё Богданов объяснял почему так работает, как одни команды побеждают проблемы и другие команды
Иногда с возрастом приходит мудрость. Иногда возраст приходит один. Так же и с молодостью, молодость и фокусировка на измеримом результате - это ортогональные понятия, существующие отдельно друг от друга
+ пришел к такому же вопросу. Цель сделать лучше скажем онбординг, проверить стал ли он лучше можно скажем по метрике usage (тупой утрированный пример). Данные для вывода через а/б тест копятся месяц. В итоге мы вроде чото сделали. Стейкхолдеры сказали молодца. А клиенты потом, а фиг вам.
Обсуждают сегодня