Когда я вижу технические истории подобные этой, я обычно задаю product owner’у вопросы вроде «Да, но зачем?». Я делаю это до тех пор, пока не проявится истинная причина появления истории (в приведенном примере — повысить скорость поиска событий в панели управления). Первоначальное техническое описание проблемы можно поместить в колонку с примечаниями: «Индексирование таблицы Events может решить проблему».
Как мы готовимся к планированию спринта
Не успеешь оглянуться — как наступил день планирования нового спринта. Мы не раз приходили к одному и тому же выводу:
Вывод: Убедитесь, что product backlog находится в нужной кондиции, прежде чем начинать планирование.
Что значит в нужной кондиции? Что все user story отлично описаны? Что все оценки трудозатрат корректны? Что все приоритеты расставлены? Нет, нет и ещё раз нет! Это значит:
• Product backlog должен существовать! (Кто бы мог подумать?)
• У каждого продукта должен быть
• Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать.
a) Не волнуйтесь, если задачи с низким уровнем важности имеют одинаковые значения, скорее всего, они не попадут в текущий спринт, а, следовательно, не будут обсуждаться.
b) Все user story, которые, по мнению Product owner’а имеют гипотетическую возможность попасть в следующий спринт, должны иметь уникальное значение важности.
c) Уровень важности используется исключительно для упорядочивания историй. Т. е. если история А имеет уровень важности 20, а история Б важность 100, это означает что Б важнее A. Это
d) Полезно оставлять промежутки из целых чисел между значениями на тот случай, если появится история В, более важная, чем А, но менее важная, чем Б. Конечно, можно выкрутиться, присвоив ей уровень важности 20.5, но выглядит это коряво, поэтому для промежутков мы решили использовать только целые числа!
• Product owner должен
Примечание: Хотя заинтересованные лица могут добавлять user story в product backlog, они не имеют права присваивать им уровень важности. Это прерогатива Product owner’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды.
Мы также попробовали:
• Использовать Jira (нашу систему учёта дефектов) для хранения product backlog’а. Но для большинства Product owner’а навигация по Jira была слишком обременительна. В Excelе манипулировать историями намного проще и приятней. Вы можете раскрашивать текст, переставлять пункты, добавлять, в случае необходимости, новые колонки, комментировать, импортировать и экспортировать данные и т. д.
• Использовать программы, заточенные под Agile процесс, такие как VersionOne, ScrumWorks, Xplanner и т. д. Но толком до них руки так и не дошли, хотя, возможно, когда-нибудь мы их всё-таки попробуем.
Как мы планируем спринт
Как по мне, планирование спринта — наиболее важная часть Scrum'a. Плохо проведённое планирование может испортить весь спринт.
Цель планирования заключается в том, чтобы, с одной стороны, дать команде достаточно информации для спокойной работы в течение нескольких недель, а с другой — убедить Product owner’а в том, что команда сможет сделать свою работу.
Хорошо-хорошо, это было весьма расплывчатое определение. Давайте лучше поговорим о том, что должно быть итогом планирования:
• Цель спринта.
• Список участников команды (и степень их занятости, если она не стопроцентная).
• Sprint backlog (список историй, которые вошли в спринт).
• Дата демонстрации.
• Место и время проведения ежедневного Scrum'а.
Почему без product owner’а не обойтись
Иногда product owner с большой неохотой тратит своё время на планирование вместе с командой: «Ребята, я уже перечислил всё, что мне нужно. Я больше не могу тратить время на ваше планирование». Это, между прочим, очень серьёзная проблема.
Команде и product owner’у просто необходимо планировать вместе, потому что каждая user story имеет три параметра, которые очень тесно связаны между собой.
Объём работ и приоритеты задач определяются product owner'ом. Зато оценка трудозатрат — это прерогатива команды. Благодаря взаимодействию команды и product owner’а в ходе планирования спринта вырабатывается оптимальное соотношение всех трех переменных.
Чаще всего product owner начинает планирование следующего спринта с описания основных целей и наиболее значимых историй. После этого команда производит оценку трудозатрат всех user story, начиная с самой важной. В процессе у команды возникают очень важные вопросы по поводу объёма предстоящих работ. Например, «Подразумевает ли история „удалить пользователя“ удаление всех его незавершённых транзакций?». Иногда ответ на этот вопрос будет большим сюрпризом для команды и потребует пересмотра всех оценок для данной user story.
В некоторых случаях время, которое понадобится на выполнение user story, не будет совпадать с ожиданиями product owner’а. Следовательно, он захочет пересмотреть приоритет для story или изменить объём работы. Это, в свою очередь, заставит команду выполнить переоценку и так далее, и так далее.
Такая взаимная зависимость является основой Scrum'а, да, в принципе, и всего Agile’а.
Но что если product owner всё-таки упорно отказывается выделить пару часов на планирование спринта? В таком случае я обычно пытаюсь последовательно применить следующие стратегии:
• Попытайтесь донести до product owner’а, почему его участие крайне важно — а вдруг до него дойдёт.
• Попробуйте найти в своих рядах добровольца, который смог бы стать представителем product owner’а. Скажите своему product owner’у: «У вас нет времени на планирование, Джеф будет исполнять вашу роль. У него будут все полномочия на изменение приоритетов и объёмов работ. Советую вам обсудить с
