Бэклог здорового продукта очень похож на здорового человека: ухожен, организован и живет в открытую.
Приоритетный Agile список необходимых требований (backlog) не только упрощает планирование выпуска релиза и итерации, но и транслирует все то, на что ваша команда собирается потратить время, включая внутреннюю работу, которую клиент никогда не заметит. Это помогает установить ожидания среди заинтересованных сторон и других групп, особенно когда они приносят вам дополнительную работу, и делает время разработки постоянным активом.
Что такое список необходимых требований (backlog) продукта?
Список необходимых требований (backlog) продукта - это приоритетный список работы для команды разработчиков, извлеченный из дорожной карты и ее требованиях.
Самые важные элементы отображаются в верхней части список необходимых требований (backlog) продукта, поэтому команда знает, что предоставить первым. Команда разработчиков не работает с списком необходимых требований (backlog) в темпе владельца продукта, и владелец продукта не подталкивает работу в команде разработчиков. Вместо этого команда разработчиков извлекает работу из списка необходимых требований (backlog) продукта, поскольку для этого есть возможность, либо непрерывно (kanban), либо итеративно (scrum).
PRO TIP:
Храните все в одном трекере задач - не используйте несколько систем для отслеживания ошибок (багов), требований и пункты технической работы. Если это работа для команды разработчиков, держите ее в одном списке необходимых требований (backlog).
Начните с двух "R"
Дорожная карта команды и требования обеспечивают основу для списка необходимых требований (backlog) продукта. Инициативы «Дорожная карта» разбиты на несколько эпиков, и у каждого эпика будет несколько требований и пользовательских историй. Давайте посмотрим на дорожную карту для вымышленного продукта под названием «Команды в космосе».
Поскольку веб-сайт «Команды в космосе» является первой инициативой в дорожной карте, мы хотим разбить эту инициативу на эпики (показаны здесь зеленым, синим и бирюзовым цветом) и пользовательские истории для каждого из этих эпиков.
Затем владелец продукта объединяет каждую пользовательскую историю в единый список для команды разработчиков. Владелец продукта может сначала поставить полный эпик (слева). Или, может быть, для программы важнее проверить бронирование авиабилетов со скидкой, для чего нужны истории из нескольких эпиков (справа). Посмотрите на оба примера ниже.
Что может повлиять на расстановку приоритетов владельца продукта?
- Приоритет клиента
- Срочность получения обратной связи
- Относительная сложность реализации
- Симбиотические отношения между рабочими элементами (например, B легче, если мы сначала сделаем A)
Хотя перед владельцем продукта стоит задача расставить приоритеты в списке необходимых требований (backlog), это не делается в вакууме. Эффективные владельцы продукта ищут информацию и отзывы от клиентов, дизайнеров и команды разработчиков, чтобы оптимизировать рабочую нагрузку для каждого работника и предоставление продукта.
Сохраняя список необходимых требований (backlog) здоровым
После того, как создан список необходимых требований (backlog), важно регулярно его поддерживать, чтобы идти в ногу с программой. Владельцы продукта должны проверять бэклог перед каждым совещанием по планированию итераций, чтобы убедиться в правильности расстановки приоритетов и включении отзывов о последней итерации.
Регулярный обзор (ревью) списка необходимых требований (backlog) в сфере Agile часто называют «уходом за бэклогом» (некоторые используют термин «уточнение бэклога»).
Как только объем списка необходимых требований (backlog) увеличивается, владельцы продукта должны сгруппировать его в краткосрочные и долгосрочные позиции. Ближайшие пункты должны быть полностью конкретизированы, прежде чем они будут помечены как таковые. Это означает, что полные пользовательские истории были составлены, сотрудничество с проектированием и разработкой было улажено, и оценки от разработки были сделаны. Более долгосрочные пункты (элементы) могут оставаться немного расплывчатыми, хотя неплохо бы получить приблизительную оценку от команды разработчиков, чтобы помочь расставить приоритеты. Ключевое слово здесь - «грубый» (приблизительный): оценки изменятся, как только команда полностью поймет и начнет работать над этими более долгосрочными пунктами.
Список необходимых требований (backlog) служит связующим звеном между владельцем продукта и командой разработчиков. Владелец продукта может в любое время изменить приоритеты работы в списке необходимых требований (backlog) в соотвествии с обратной связью с клиентами, уточнить оценки и новые требования. Однако, как только работа начнется, сведите изменения к минимуму, так как они нарушают работу команды разработчиков и влияют на повышение внимания, поток и моральный дух.
PRO TIP:
Как только список необходимых требований (backlog) выходит за рамки долгосрочных возможностей команды, можно закрывать задачи, к которым команда никогда не доберется. Отметьте эти задачи с определенным разрешением, таким как «вне области» в системе отслеживания задач группы, чтобы использовать ее для дальнейшего исследования.
Анти-паттерны (шаблоны), за которыми нужно следить
- Владелец продукта приоритизирует список необходимых требований (backlog) в начале проекта, но не корректирует его по мере поступления отзывов от разработчиков и заинтересованных сторон.
- Команда ограничивает позиции в списке необходимых требований (backlog) теми, которые ориентированы на клиента.
- Список необходимых требований (backlog) хранится как документ, хранящийся локально и редко используется, что не позволяет заинтересованным сторонам получать обновления.
Как список необходимых требований (backlog) продукта поддерживает гибкость команды?
Опытные владельцы продукта, тщательно ухаживают за списком необходимых требований (backlog) программного продукта, что делает его надежным и доступным для совместного использования и общим наброском элементов работы для проекта.
ТВИИТ: Списки необходимых требований (backlog) подсказывают дебаты и решения, которые поддерживают программу в хорошем состоянии - но не все может быть главным приоритетом.
Заинтересованные стороны будут оспаривать приоритеты, и это хорошо. Стимулирование дискуссии о том, что важно, синхронизирует приоритеты каждого. Эти дискуссии формируют культуру групповой расстановки приоритетов, гарантируя, что все участники придерживаются одинакового мышления в программе.
Список необходимых требований (backlog) продукта также служит основой для планирования итераций. Все рабочие элементы должны быть включены в очередь: пользовательские истории, баги, изменения дизайна, технические долги, запросы клиентов, элементы действий из ретроспективы и т. д.
Это гарантирует, что все рабочие элементы будут включены в общее обсуждение для каждой итерации. Члены команды могут затем пойти на компромисс с владельцем продукта, прежде чем начинать итерацию с полным знанием всего, что необходимо сделать.
PRO TIP:
Владельцы продуктов определяют приоритет элементов работы в списке необходимых требований (backlog), а команда разработчиков определяет скорость через список необходимых требований (backlog). Это может быть непростое отношение для новых владельцев продуктов, которые хотят «подтолкнуть» работу в команде. Узнайте больше в нашей статье об лимитах незавершенного производства и ходе работ.
По материалам Agile Coach "Backlogs"