Скрам придуман для экспериментов, проект - не эксперимент. Окей, коммуникации через

Дейли, краткосрочной планирование через Планирование спринта.
Остальное вам зачем?
Роль ПО, Роль Скрам мастера, Обзоры спринтов, как минимум (хотя и Ретро под вопросом) . Это или надо выкинуть, но тогда это не Скрам, или оставлять, но для чего?

Никто не делает эксперименты fixed time. Эксперименты это всегда fixed scope

Контрпример - "У нас две недели, чтобы проверить реализуемость идеи"

Тайм - Спринт ограничен по времени. Скоуп - утверждается на Планировании. Извините, но с телефона гуглить Скрам-гайд не горю желанием

А мне нет. Читайте: «Commitment: Sprint Goal The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.»

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

А что существует стратегия для бесконечности? У стратегии всегда конечный срок. Стратегия - это просто высокий уровень планирования. Это в принципе правильный подход к планированию - определяете видение цели проекта (продукта), стратегию внедрения (до конца проекта), тактику внедрения (например работаем по Скрам) а потом просто декомпозируете стратегические цели на цели спринта и обновляете все по мере аналища результатов спринта

Аналище результатов Спринта звучит сильно, запомню, будем с командой использовать, спасибо))

Про эксперименты это скорее мое. Скрам говорит про evidence based подход, что в общем-то не отрицает эксперименты, но это скорее про бизнесовое бла-бла, а не серьёзные эксперименты. Про то как ранить настоящий ресеч лучше почитать у Асхата: https://leands.ai

https://t.me/agile_ru/228358 >В changelogs 2011 скрам гайда написано - Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint. Прогноз вместо обязательств. Различие тонкое, но очень важное

Кажется, тема сообщения Алексея - попытка мэтчинга скрама с проектом. И да, ты прав)

Все credits - Левону, я вот это артикулированное указание только сейчас узнал, уже пользуюсь )

Обязательства или прогноз не сильно важно. важно то что при план-фактном анализе при расхождении будет заданы вопросы: - Планировали сделать это ... а делали это...., так? - Агась - говорит команда - То есть сделали меньше чем планировали, да? - Агась, но это же был прогноз! - Ну раз прогноз, то обсудите на ретроспективе, как сделать так, чтобы лучше в них попадать. - Э.. ну ладно - говорит команда - И еще, у вас тут плановая скорость команды должна быть 5 единиц в день, а вы работаете со скоростью 3 единицы в день, и точность планирования у вас 0,3 и проект уже в красной зоне - Эм.. - говорит команда. - Не "Эм" А найдите способ вернуть проект в зеленую зону, и как повысить скорость и точность планирования. Или ищите добровольцев кто поедет на объект сдавать Изделие, там как раз лето будет, температура минус 20 всего.

Ок, теперь наш прогноз - 0.1 единицы в день. И теперь это проблема ПО.

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

Как раз прогноз. А термин "скорость планирования" не несёт смысловой нагрузки.

>Обязательства или прогноз не сильно важно. >важно то что при план-фактном анализе Важно, важно и ещё раз важно В план-фактном случае, как вы и пишете, начинается обработка команды, давайте факт А при прогноз-фактном анализе мы думаем, что с нашим прогнозом не так Диаметрально противоположные оси Ваш подход он анти-Agile, потому что в Agile наоборот: следование изменениям ценнее следования плану А у вас план на плане и планом погоняет Да вы вольны выбирать подход в своей компании, но не называйте это «тем же Agile, но просто по другому называется», вы вводите понятийную путаницу, ведёте себя как волк в овечьей шкуре )

А теперь внимательно прочитайте первую строку этого сообщения https://t.me/agile_ru/228820 Ваши прогнозы, мне как бизнесу нафиг не нужны. Мне важно чтобы все что нужно было сделано к контрактному сроку. При нарушении это ставит под угрозу уже мои обязательства.

Если вы "бизнес" и у вас фиксированный скоуп и срок - не играйте в Скрам, возьмите толкового РП и пусть он менеджит толковых спецов

Вот, кстати, электронные торги это про проекты, а не про продукты)) В электронных торгах есть чёткий описанный результат, который нужен)

Далеко не всегда, кстати. А, ещё чаще- результат есть только в бумаге отчётной, а не на деле.