Scrum и XP: заметки с передовой
Шрифт:
Product owner: «Естественно, нет! У нас нет времени!»
Команда: «Хорошо, давайте посмотрим на наш последний спринт (все бросают взгляд на график производительности на белой доске). Наша прогнозируемая производительность была 80, но реальная производительность оказалась 30, верно?»
Product owner: «Именно! У нас нет времени на внутренние технические работы! Нам нужен новый функционал!»
Команда: «Хорошо. Но причина ухудшения нашей производительность в том, что мы тратим слишком много времени на
Product owner: «Ну и что?»
Команда: «А то, что производительность и дальше будет такой низкой, если мы ничего не сделаем».
Product owner: «Да … и что вы предлагаете?»
Команда: «Мы предлагаем выделить примерно 10 % следующего спринта на установку билд сервера и другие вещи, чтобы сделать интеграцию менее болезненной. Это, скорее всего, увеличит производительность всех последующих спринтов как минимум на 20 %!»
Product owner: «Серьёзно? Почему же мы это не сделали на предыдущем спринте?!»
Команда: «Хм… потому что вы не захотели, чтобы мы это сделали…»
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.
4
я, если честно, тоже:) (прим. переводчика)
Затем, конечно, всё может пойти криво, но вы, как минимум, не сможете списать всю вину на планирование спринта: o)
Как мы доносим информацию о спринте до всех в компании
Важно информировать всю компанию о том, что происходит в вашей команде. Если этого не делать, то остальные начнут жаловаться, или — что ещё хуже — придумывать всякие ужасы про вас.
Мы для этой цели используем «страницу с информацией о спринте».
Иногда мы также добавляем к названию истории поле «как продемонстрировать»
Сразу же после встречи по планированию спринта эту страницу создаёт ScrumMaster. Он помещает её в wiki, и тут же спамит на всю компанию:
Кроме этого у нас есть «панель» в wiki, в которой содержаться ссылки на текущие спринты всех команд.
В дополнение ко всему этому наш ScrumMaster распечатывает страницу информации о спринте и вывешивает её на стену в коридоре. Таким образом кто угодно, проходя мимо, может взглянуть на эту страницу и узнать, чем же занимается наша команда.
Когда спринт подходит к концу, ScrumMaster напоминает всем про приближающуюся демонстрацию
Если всё это делать, то ни у кого не получится сказать, что он не мог узнать, чем занимается команда.
Как мы создаем sprint backlog
Уже добрались до этой главы? Отлично!
Итак, мы только что закончили планирование и протрубили на весь мир про начало нашего новоиспечённого спринта. Теперь настал черёд ScrumMaster'а создать sprint backlog. Это необходимо сделать после планирования спринта, но до начала первого ежедневного Scrum’а.