Создание списка продуктов — одна из наиболее важных обязанностей в рамках фреймворка Scrum. Он служит единственным источником истины относительно того, что необходимо создать, улучшить и доставить. В отличие от простого списка дел, список продуктов — это динамический, постоянно развивающийся артефакт, отражающий меняющиеся потребности рынка и пользователей.
Это руководство предоставляет подробное пошаговое руководство по созданию вашего первого списка продуктов. Мы выйдем за рамки базовых определений и рассмотрим механизмы приоритизации, написания историй и доработки. К концу этого обучающего курса вы поймете, как поддерживать список продуктов, который создает ценность и способствует гибкой разработке.
Понимание списка продуктов 📋
Список продуктов — это упорядоченный список всего, что может понадобиться в продукте. Это основной артефакт, используемый для отслеживания прогресса и планирования работы. В Scrum ответственность за эффективность списка продуктов лежит на владельце продукта. Это означает, что он отвечает за порядок элементов с целью максимизации ценности.
Ключевые характеристики здорового списка продуктов включают:
- Упорядочен:Элементы сортируются по ценности, риску, приоритету или необходимости.
- Эволюционирующий:Он развивается вместе с продуктом и окружающей средой.
- Доработанный:Элементы в верхней части четко сформулированы и готовы к выбору во время планирования спринта.
- Прозрачный:Любой может увидеть, что рассматривается и почему.
Предварительные условия: роли и обязанности 👥
Прежде чем заполнять список, необходимо понимать, кто участвует и каков их вклад. Список продуктов не создается в вакууме.
Владелец продукта
Владелец продукта отвечает за содержание и порядок элементов. Он выступает голосом клиента и бизнеса. Он решает, что попадает в список продуктов и когда это должно быть сделано.
Команда разработчиков
Команда предоставляет техническую перспективу. Они помогают оценивать усилия, выявлять технические риски и уточнять критерии приемки. Их вклад обеспечивает реалистичность элементов.
Мастер Scrum
Мастер Scrum обеспечивает процесс. Он помогает гарантировать прозрачность списка продуктов и гладкое проведение сессий доработки. Он наставляет команду в вопросах применения гибких практик.
Шаг 1: Определите видение продукта 🎯
Прежде чем добавить первый элемент, вам нужно определить цель. Видение продукта описывает будущее состояние продукта. Оно задает четкое направление для списка продуктов.
Чтобы сформировать это:
- Определите целевую аудиторию.
- Определите проблему, которую вы решаете.
- Определите уникальное торговое предложение.
- Установите стратегические цели на ближайшие 6–12 месяцев.
Это видение выступает фильтром. При рассмотрении нового элемента спрашивайте: «Соответствует ли это нашему видению?» Если ответ «нет», этот элемент не должен находиться в списке продуктов.
Шаг 2: Сбор требований и создание эпиков 📝
Эпики — это крупные объемы работы, которые слишком велики, чтобы быть выполнены за один спринт. Они выступают в качестве контейнеров для более мелких частей работы. Представьте эпики как главы в книге.
Чтобы создать эпики:
- Обзор продукта.
- Определите основные темы или функциональные области.
- Напишите описания высокого уровня для каждой темы.
- Убедитесь, что у каждого эпика есть четкая цель.
Пример эпика: «Система аутентификации пользователей». Это слишком велико, чтобы построить за один раз. Ему нужно будет разбить дальше.
Шаг 3: Написание пользовательских историй 🧩
Пользовательские истории — это основная единица работы в бэклоге продукта. Они описывают функцию с точки зрения пользователя. Стандартный формат помогает сохранить ясность.
Формат пользовательской истории
Используйте следующий шаблон для написания ваших историй:
Как [тип пользователя],
Я хочу [выполнить действие],
Чтобы [я смогу достичь цели].
Эта структура заставляет вас сосредоточиться на ценности, а не на технической реализации. Это гарантирует, что команда понимает почемуза работой.
Примеры пользовательских историй
- Как зарегистрированный пользователь, Я хочу сбросить свой пароль, чтобы я смогу получить доступ к своей учетной записи, если забуду пароль.
- Как менеджер, Я хочу просмотреть еженедельный отчет, чтобыя мог отслеживать производительность команды.
- Как гость, Я хочу просматривать каталог, чтобыя мог найти продукты до регистрации.
Шаг 4: Техники приоритизации ⚖️
Сортировка бэклога — это непрерывный процесс. Вы не можете создать всё сразу. Вам необходимо приоритизировать на основе ценности, затрат и рисков. Вот три распространённых подхода.
1. Метод MoSCoW
Этот метод классифицирует элементы на четыре группы:
- MДолжны иметь: Критически важны для релиза. Без этого продукт не пройдёт.
- SДолжны иметь: Важно, но не критично. Может быть отложено при необходимости.
- CМогли бы иметь: Желательные функции. Приятно иметь, если позволит время.
- WНе должны иметь: Элементы, явно исключённые из текущего охвата.
2. Взвешенный первый кратчайший процесс (WSJF)
Это полезно в масштабируемых средах. Оно рассчитывает ценность с учётом:
- Ценность бизнеса
- Критичность времени
- Снижение рисков
- Возможность реализации возможностей
Элементы с наивысшим баллом располагаются в верхней части бэклога.
3. Матрица ценности против усилий
Разместите элементы на сетке 2×2. Сначала приоритет у элементов с высокой ценностью и низкими усилиями (быстрые победы). Элементы с высокой ценностью и высокими усилиями — это крупные инициативы. Элементы с низкой ценностью откладываются.
Шаг 5: Уточнение и оценка 📏
Уточнение (ранее называлось «прогонка») — это процесс добавления деталей, оценок и порядка к элементам бэклога. Это происходит на протяжении всего спринта, а не только перед планированием.
Чек-лист уточнения
- История понятна и кратка?
- Определены ли критерии приемки?
- Технический подход понятен?
- История достаточно мала для спринта?
Методы оценки
Команды часто используют относительные размеры вместо часов. Это снижает тревогу по поводу точности.
- Планировочная покер-игра: Команда обсуждает историю и голосует за сложность с помощью карт.
- Размеры по футболкам: Метки элементов как XS, S, M, L, XL в зависимости от усилий.
- Баллы истории: Назначьте числовое значение, представляющее сложность и усилия.
Шаг 6: Определение критериев приемки ✅
История пользователя без критериев приемки является неполной. Эти критерии определяют условия, которые должны быть выполнены, чтобы считать историю завершенной.
Эффективные критерии приемки должны быть:
- Конкретными: Четкими и однозначными.
- Проверяемыми: Тестировщик должен иметь возможность проверить условие.
- Независимыми: Каждый критерий может быть проверен отдельно.
Пример:
История: Экран входа
- Система принимает действительное имя пользователя и пароль.
- Система перенаправляет на панель управления при успешном завершении.
- Система отображает сообщение об ошибке при неверных учетных данных.
- Поле пароля маскируется во время ввода.
Поддержание бэклога 🧹
Бэклог, который не поддерживается, превращается в кладбище незавершенной работы. Для поддержания его в хорошем состоянии необходима регулярная работа.
Показатели здоровья бэклога
| Показатель | Почему это важно | Цель |
|---|---|---|
| Возраст топ-пунктов | Обеспечивает отражение недавних изменений приоритета | Менее 2 спринтов |
| Скорость доработки | Измеряет объем работы, готовой к планированию | 20% емкости спринта |
| Размер истории | Обеспечивает, что элементы можно реализовать в спринте | 10–20 очков истории |
Распространенные ошибки, которых следует избегать ⚠️
Многие команды испытывают трудности с продуктовым бэклогом из-за распространенных ошибок. Будьте внимательны к этим ловушкам.
1. Слишком много элементов
Сохранение тысяч элементов создает шум. Сосредоточьтесь на топ-20% элементов, которые приносят 80% ценности.
2. Неясные описания
Элементы, такие как «Улучшить производительность», не являются выполнимыми. Разбейте их на конкретные задачи или истории.
3. Пренебрежение техническим долгом
Не скрывайте технический долг в отдельном ящике. Включите его как элемент бэклога, чтобы он мог быть приоритизирован вместе с функциями.
4. Статическая сортировка
Бэклог должен меняться. Если меняются рыночные условия, порядок должен меняться. Не рассматривайте верхний список как постоянный закон.
Бэклог против бэклога спринта
Крайне важно различать продуктовый бэклог и бэклог спринта. Смешение двух понятий приводит к расширению объема работ и сбоям в планировании.
| Функция | Продуктовый бэклог | Бэклог спринта |
|---|---|---|
| Владелец | Владелец продукта | Команда разработки |
| Область охвата | Весь продукт | Только текущий спринт |
| Стабильность | Гибкий (изменения в любое время) | Стабильный (без изменений в течение спринта) |
| Детализация | Переменная (наиболее важные элементы детализированы) | Высокая (все элементы детализированы) |
Часто задаваемые вопросы ❓
Сколько элементов должно быть в продуктовом бэклоге?
Количество элементов не фиксировано. Это зависит от жизненного цикла продукта. Однако убедитесь, что первые 10–20 элементов полностью проработаны и готовы к следующему спринту.
Может ли команда разработки добавлять элементы в бэклог?
Да. Хотя владелец продукта устанавливает приоритеты, команда разработки может предлагать элементы на основе технических потребностей или обратной связи пользователей. Эти предложения будут рассмотрены совместно с владельцем продукта.
Что происходит с элементами, не выбранными в спринте?
Они остаются в продуктовом бэклоге. Их приоритет будет пересмотрен на следующей сессии планирования. Они не исчезают и не устаревают.
Нужно ли оценивать каждый элемент в бэклоге?
Нет. Оценка всех элементов — это потеря времени. Оценивайте только те элементы, которые находятся ближе к верху и, скорее всего, будут выполнены в ближайшее время. Для элементов с низким приоритетом используйте приблизительные оценки.
Как часто нужно прорабатывать бэклог?
Проработка бэклога должна быть постоянной деятельностью. Обычной практикой является выделение отдельной сессии раз в спринт. Это обеспечивает готовность команды к следующей сессии планирования.
Завершение 🏁
Создание продуктового бэклога — это итеративный процесс. Он требует постоянного общения, приоритизации и проработки. Следуя шагам, описанным в этом руководстве, вы сможете создать бэклог, который станет надежным путеводителем для вашего продукта.
Помните, цель — не создать идеальный список сразу. Цель — создать живой документ, который направляет вашу команду на создание ценности. Начните с малого, часто итерируйте и сохраняйте фокус на потребностях пользователя.
При хорошо поддерживаемом бэклоге ваша команда Scrum сможет уверенно справляться со сложностью и последовательно предоставлять продукты высокого качества.
