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