• Такая предварительная разбивка заметно увеличивает эффективность ежедневного Scrum'а (см. стр. 46 «Как мы проводим ежедневный Scrum»).
• Даже неточная разбивка, которая будет изменяться по ходу работ, всё равно даёт нам все перечисленные выше выгоды.
Итак, чтобы успеть разбить истории на задачи, мы стараемся выделить достаточно времени на планирование спринта. Однако, если время поджимает, то разбиение на задачи мы можем и пропустить (см. следующую главу «Когда пора остановиться»).
Примечание: мы практикуем TDD (разработку через тестирование), из-за чего первой задачей почти каждой истории является «написать приёмочный тест», а последняя — «рефакторинг» (улучшение читабельности кода и удаление повторений кода).
Выбор времени и места для ежедневного Scum’а
Все часто забывают, что на планировании спринта, помимо всего прочего, необходимо выбрать время и место проведения ежедневного Scrum'а. Без этого ваш спринт обречён на неудачный старт. Ведь первый ежедневный Scrum — это, по большей части, ввод мяча в игру, когда каждый решает с чего начать работу.
Я предпочитаю проводить ежедневный Scrum утром. Хотя, должен признаться, мы особо и не пробовали проводить его в обед или ближе к вечеру.
Недостатки обеденного 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’у
Мы называем это «техническими историями».
Например:
Установить сервер непрерывной интеграции
o Почему это надо сделать? Потому, что это сэкономит много времени разработчикам и снизит риск проблемы «большого взрыва» при интеграции в конце итерации.
Описать архитектуру системы
o Почему это надо сделать? Потому, что разработчики часто забывают общую архитектуру и поэтому пишут несогласованный код. Нужен документ, предоставляющий всем одинаковую общую картину.
Рефакторинг слоя доступа к данным
o Почему это надо сделать? Потому, что слой доступа к данным стал очень запутанным, и разработчики теряют много времени на то, чтобы разобраться и исправить возникающие дефекты. Рефакторинг сохранит время всей команды и повысит устойчивость системы.
Обновить Jira (систему учёта дефектов)
o Почему это надо сделать? Текущая версия очень нестабильная и медленная: обновление сохранит время всей команде.
Имеют ли смысл эти истории? Или это задачи не связанные ни с одной историей? Кто задаёт приоритеты? Нужно ли вовлекать сюда Product owner’а?
Мы попробовали различные варианты работы с техническими историями. Мы пробовали считать их самыми обычными user story. Это была неудачная идея: для Product owner’а приоритезировать их в product backlog’а было всё равно, что сравнить тёплое с мягким. По очевидным причинам технические истории получали самый низкий приоритет с объяснением: «Да, ребята, несомненно, ваш сервер непрерывной интеграции — очень важная штука, но давайте сперва реализуем кое-какие прибыльные функции? После этого вы можете прикрутить вашу техническую конфетку, окей?»
В некоторых случаях product owner действительно прав, но чаще все-таки нет. Мы пришли к выводу, что product owner не всегда компетентен, чтобы идти на компромисс. И вот что мы делаем:
1. Стараемся избегать технических историй. Ищем способ превратить техническую историю в нормальную историю с измеряемой ценностью для бизнеса. В таком случае у Product owner’а больше шансов найти разумный компромисс.
2. Если мы не можем превратить техническую историю в обычную, смотрим нельзя ли включить эту работу в уже существующую историю. Например, «рефакторинг доступа к данным» мог бы стать частью истории «редактировать пользователя», поскольку она подразумевает работу с данными.
3. Если оба подхода не прошли, отмечаем это как техническую историю и храним список таких историй отдельно. Пусть product owner видит список, но не редактирует. В переговорах с product owner'ом используем параметры «фокус-фактора» и «прогнозируемой производительности» и выделяем время в спринте для реализации технических историй.
Пример (диалог очень похож на то, что случилось во время одного из наших планирований спринта).
Команда: «У нас есть кое-какие внутренние технические работы, которые должны быть сделаны. Мы бы хотели заложить на это 10 % всего времени, т. е. снизить фокус-фактор с 75 % до 65 %. Это возможно?»
Product owner: «Естественно, нет! У нас нет времени!»
Команда: «Хорошо, давайте посмотрим на наш последний спринт (все бросают взгляд на график производительности на белой доске). Наша прогнозируемая производительность была 80, но реальная производительность оказалась 30, верно?»
Product owner: «Именно! У нас нет времени на внутренние технические работы! Нам нужен новый функционал!»
Команда: «Хорошо. Но причина ухудшения нашей производительность в том, что мы тратим слишком много времени на создание полной сборки для тестирования».
Product owner: «Ну и что?»
Команда: «А то, что производительность и дальше будет такой низкой, если мы ничего не сделаем».
Product owner: «Да … и что вы предлагаете?»
Команда: «Мы предлагаем выделить примерно 10 % следующего спринта на установку билд сервера и другие вещи, чтобы сделать интеграцию менее болезненной. Это, скорее всего, увеличит производительность всех последующих спринтов как минимум на 20 %!»
