Недостатки обеденного Scrum'a: приходя на работу утром, вам надо попытаться вспомнить, чем вы обещали команде заниматься сегодня.
Недостатки утреннего Scrum'a: приходя на работу утром, вам надо попытаться вспомнить, чем вы занимались вчера, чтобы можно было отчитаться об этом.
Мне кажется, первый недостаток хуже, так как наиболее важно то, что вы собираетесь делать, а не то, что вы уже сделали.
Мы обычно выбираем самое раннее время, которое не вызывает стонов ни у кого в команде. Обычно это 9:00, 9:30 или 10:00. Очень важно, чтобы все в команде искренне согласились на это время.
Ну вот, время заканчивается. Чем мы можем пожертвовать из всего того, что мы собирались сделать на планировании спринта, если время поджимает?
У меня, например, приоритеты для встречи по планированию спринта такие:
Приоритет № 1: Цель спринта и дата демонстрации. Это тот минимум, с которым можно начинать спринт. У команды есть цель и крайний срок, а работать они могут прямо по product backlog’у. Да это нехорошо, и нужно запланировать ещё одну встречу по планированию sprint backlog’а на завтра, но если вам крайне необходимо стартовать спринт, то это, скорее всего, сработает. Хотя, если быть честным, я так никогда и не стартовал спринт, имея всего лишь цель и дату.
Приоритет № 2: Список историй, которые команда включила в sprint backlog.
Приоритет № 3: Оценки для каждой истории из sprint backlog’а.
Приоритет № 4: Поле «Как продемонстрировать» для каждой истории из sprint backlog’а.
Приоритет № 5: Расчёты производительности и ресурсов в качестве «испытания реальностью» для плана на спринт. Также нужен список членов команды с указанием их степени участия в проекте (без этого нельзя рассчитать производительность).
Приоритет № 6: Определённое время и место проведения ежедневного Scrum'а. Вообще, выбрать время и место можно за одну минуту, но если время собрания уже закончилось, то ScrumMaster просто выбирает их сам после собрания и оповещает всех по электронной почте.
Приоритет № 7: Истории, разбитые на задачи. Разбивать истории на задачи можно также и по мере их поступления в работу, совмещая это с ежедневным Scrum'ом, но такой подход слегка нарушает течение спринта.
А теперь ещё одна сложная проблема: технические истории. Это нефункциональные требования, или как их там ещё называют.
Я имею в виду всё, что должно быть сделано, но невидимо для заказчика, не относится ни к одной user story, и не даёт прямой выгоды product owner’у
Мы называем это «техническими историями».