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