Выбрать главу

Команда: «Хм… потому что вы не захотели, чтобы мы это сделали…»

Product owner: «О! Ммм…, ладно, тогда логично, если вы это сделаете сейчас!»

Конечно, есть и другой вариант: не вести переговоры с product owner'ом по поводу технических историй, а просто поставить его перед фактом, что у нас фокус-фактор такой-то. Но это не правильно даже не попытаться достичь компромисса.

Если product owner оказался сообразительным и компетентным (нам в своё время с этим действительно повезло), я бы рекомендовал информировать его как можно лучше и дать ему возможность определять общие приоритеты. Ведь прозрачность — это один из основополагающих принципов Scrum'а, верно?

Как мы используем систему учёта дефектов для ведения product backlog’а

Есть ещё одна непростая задача. С одной стороны, Excel очень хороший формат для product backlog’а. С другой стороны, вам всё равно нужна система учёта дефектов, и Excel здесь явно не тянет. Мы используем Jira.

Итак, как мы переносим задачи из Jira в планирование спринта? Не можем же мы просто их проигнорировать и сосредоточиться только лишь на историях.

Мы пробовали следующие подходы:

1. Product owner распечатывает самые высокоприоритетные задачи из Jira, выносит их на планирование спринта и вешает их на стенку с другими историями (неявно указывая их относительный приоритет).

2. Product owner создаёт истории, соответствующие задачам из Jira. Например, «Исправить самые критические ошибки отчётности в админке, Jira-124, Jira-126, и Jira-180».

3. Работы по исправлению ошибок не включаются в спринт, то есть команда определяет довольно низкий фокус-фактор (например, 50 %), чтобы хватало времени на исправления. Затем, вводится предположение, что команда в каждую итерацию будет тратить определённую часть времени на ошибки в Jira.

4. Заносим product backlog в Jira (просто переносим из Excelе). Считаем баги обычными историями.

Мы ещё не определились, какой подход для нас самый лучший; в действительности он может отличаться в разных командах и меняться от спринта к спринту. Я больше склоняюсь к первому подходу: он прост и понятен.

Свершилось! Планирование спринта закончено!

Ух, я и не думал, что глава по планированию спринта будет такой длинной [4]! Полагаю, этот факт отражает моё мнение: планирование спринта — самая важная вещь в Scrum’е. Вложите побольше усилий в планирование — и всё остальное пойдёт как по маслу.

Планирование спринта прошло успешно, если все (и команда, и product owner) с улыбкой завершают встречу, с улыбкой просыпаются следующим утром и с улыбкой проводят первый ежедневный Scrum.

Затем, конечно, всё может пойти криво, но вы, как минимум, не сможете списать всю вину на планирование спринта: o)

Как мы доносим информацию о спринте до всех в компании

Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или — что ещё хуже — придумывать всякие ужасы про вас.

Мы для этой цели используем «страницу с информацией о спринте».

Иногда мы также добавляем к названию истории поле «как продемонстрировать»

Сразу же после встречи по планированию спринта эту страницу создаёт ScrumMaster. Он помещает её в wiki, и тут же спамит на всю компанию:

Кроме этого у нас есть «панель» в wiki, в которой содержаться ссылки на текущие спринты всех команд.

В дополнение ко всему этому наш ScrumMaster распечатывает страницу информации о спринте и вывешивает её на стену в коридоре. Таким образом кто угодно, проходя мимо, может взглянуть на эту страницу и узнать, чем же занимается наша команда.

Когда спринт подходит к концу, ScrumMaster напоминает всем про приближающуюся демонстрацию

Если всё это делать, то ни у кого не получится сказать, что он не мог узнать, чем занимается команда.

Как мы создаем sprint backlog

Уже добрались до этой главы? Отлично!

Итак, мы только что закончили планирование и протрубили на весь мир про начало нашего новоиспечённого спринта. Теперь настал черёд ScrumMaster'а создать sprint backlog. Это необходимо сделать после планирования спринта, но до начала первого ежедневного Scrum’а.

Формат sprint backlog’а

Мы поэкспериментировали с разными форматами sprint backlog’а, включая Jira, Excel, не забыли попробовать и обычную настенную доску. Сперва в основном использовали Excel, в интернете можно найти довольно много Excel'евских шаблонов для sprint backlog’а, с авто-генерацией burndown диаграмм и всякими другими примочками. Я мог бы долго рассказать про sprint backlog’а, созданные при помощи Excel, но я не буду. Даже не стану приводить примеров.