Сначала пишем Epic'и про самолёт, затем их причёсываем, затем разделяем на User Stories, которые оцениваем, приоритезируем, комплектуем ими спринты. Затем прогоняем спринты (хватит времени на 4 спринта) с учётом ретро
Ну сначала надо понять, что мы вкладываем в понятие "реализовать мотогонки" или "реализовать авиаперелёты". То есть что именно является продуктом. Дальше - определиться с уровнем неопределённости. Ну и выбрать себе подход по душе 🙂
Разработка системы управления авиаперевозками, например, прекрасно делается по Скраму. А вот её рядовая изо дня в день эксплуатация - наверное, нет, зачем там Скрам?
А вот массированное изменение этой системы (например, появился конкурент и активно отжимает рынок, а мы не знаем, что у него за киллер-фича и не знаем пока, что именно сделать чтобы рынок себе вернуть) - снова ложится на Скрам.
В общем, где много R&D - Скрам шикарен. Где нужно просто "тупо исполнять регламенты", он будет оверкиллом. Там, где регламенты надо пересматривать - снова подойдёт. И в этих процессах могут быть заняты одни и те же люди 🙂
Сначала пишем Epic'и про самолёт, затем их причёсываем, затем разделяем на User Stories, которые оцениваем, приоритезируем, комплектуем ими спринты. Затем прогоняем спринты (хватит времени на 4 спринта) с учётом ретро
Если я что нибудь в чем нибудь понимаю, то Scrum не снабжен механизмами чтобы одновременно и соблюсти бюджет и сроки и реализовать все содержание. Ошибаюсь?
и к заданной дате успеете? у бюджет соблюдете? и все фичи реализуете?
Ну, мнэээ, стандартное проектное управление тоже не успевает в срок и в разы просирает бюджет. И с фичами напряжёнка бывает ;) Особенно в авиастроении :)