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 % следующего спринта на установку билд сервера и другие вещи, чтобы сделать интеграцию менее болезненной. Это, скорее всего, увеличит производительность всех последующих спринтов
Product owner: «Серьёзно? Почему же мы это не сделали на предыдущем спринте?!»
Команда: «Хм… потому что вы не захотели, чтобы мы это сделали…»
Product owner: «О! Ммм…, ладно, тогда логично, если вы это сделаете сейчас!»
Конечно, есть и другой вариант: не вести переговоры с product owner'ом по поводу технических историй, а просто поставить его перед фактом, что у нас фокус-фактор такой-то. Но это не правильно даже
Если product owner оказался сообразительным и компетентным (нам в своё время с этим действительно повезло), я бы рекомендовал информировать его как можно лучше и дать ему возможность определять общие приоритеты. Ведь прозрачность — это один из основополагающих принципов Scrum'а, верно?
Как мы используем систему учёта дефектов для ведения product backlog’а
