возникает желание расспросить где у вас тут комплексность?
Имхо, многие это аспект даже не учитывают, а другие не могут или ошибочно идентифицируют её
Не согласен. Задача комплексная, не отличающаяся от организации разработки софта, IMHO. Ну и кстати в больших ресторанах, насколько я знаю уже работают командно, и у них уже есть аналоги всех событий и планирования (раз в месяц повара придумывают новые блюда - не ищут рецепты в интернете, а именно создают) и ретроспективы (разбор с шефом и командой, что не так) и дейли (стандартный митинг перед началом рабочего дня, в зависимости от успешности логистики) и даже ревью, когда они презентуют новые разработанные ими блюда руководству, ожидая фидбэка (слышал от знакомых шеф-поваров). Только названия ивентов другие, но это работа похожая по ритму на скрам. Аргументы, что события это всего лишь малая часть фреймворка - согласен. Но их принцип работы ближе к скраму, чем многих разработчиков софта, просто мало кто об этом задумывался. И даже Scrum values (Commitment, Focus, Openness, Respect, Courage) у них уже именно эти и действуют в командах.
Всегда считала, что ценность Скрама в быстрой проверки продуктовой гипотезы. В данном примере какая гипотеза проверяется?
Что поциент умер от вскрытия очевидно
Скрам в принципе ничего не говорит о проверке гипотез. Я бы сказал, чтобы быстро проверить гипотезу, это работа продактов, дискавери команд, зачастую по настоящему валидную проверку гипотезы быстро сделать очень сложно. А скрам это про процесс, обратную связь, ритм, распределение зон ответственности и коллаборацию(ценности).
Разве Юзер Сторя - это не гипотеза о том, что может оказаться ценным для пользователя?
Это скорее не так чем так, потому что разработка это самый дорогой и долгий способ проверки. Плюс скрам завязан на эмпирике, а она считается не самым лучшим способом апробации гипотез
Планёрки, летучки, разбор полётов?
Обсуждают сегодня