Урок 3 из 8 · 20 мин · обновлено

Бэклог и пользовательские истории

Как вести бэклог продукта, записывать задачи в виде пользовательских историй «как… я хочу… чтобы», формулировать критерии приёмки и делить большие истории на маленькие.

Бэклог продукта

Бэклог продукта — единый список всего, что может понадобиться в продукте: новые функции, улучшения, исправления ошибок, технические задачи. Его ведёт владелец продукта, а главное в нём — порядок: сверху то, что важнее сделать сейчас.

Бэклог неоднородный:

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

Бэклог живой: после каждого обзора спринта и каждого разговора с пользователями в нём что-то добавляется, меняется и удаляется. Подготовку задач заранее называют уточнением бэклога (backlog refinement) — команда регулярно обсуждает верхние задачи, задаёт вопросы и оценивает.

Пользовательские истории

Задачу «сделать кнопку повтора заказа» можно выполнить по-разному. Чтобы команда понимала смысл, задачи часто записывают в виде пользовательских историй (user story):

Как гость кофейни, я хочу повторить вчерашний заказ в одно нажатие, чтобы не собирать его заново каждое утро.

  • кто — для кого делаем;
  • что — что человек хочет сделать;
  • зачем — какую пользу получит.

«Зачем» — самая важная часть. Зная её, команда может предложить решение лучше: например, не кнопку, а предложение повторить заказ прямо на главном экране.

Критерии приёмки

История сама по себе расплывчата. Чтобы её можно было проверить, добавляют критерии приёмки — конкретные условия, при которых история выполнена:

  • на главном экране показывается последний заказ гостя с ценой;
  • кнопка «Повторить» добавляет все позиции в корзину с теми же параметрами;
  • если какой-то позиции нет в наличии, гость видит предупреждение до оплаты;
  • если заказов ещё не было, блок не показывается.

Критерии приёмки пишут вместе: владелец продукта, аналитик, разработчик, тестировщик. По ним тестировщик понимает, что проверять, а разработчик — что делать с краевыми случаями.

Эпики и деление историй

Большую историю, которая не помещается в один спринт, называют эпиком. Например: «Программа лояльности». Её делят на маленькие истории, каждая из которых даёт пользу сама по себе:

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

Делят по пользе для человека, а не по слоям работы. «Сделать базу данных для баллов» и «сделать экран» — плохое деление: ни одна часть отдельно не даёт пользы.

Попробуйте сами. Запишите историю «гость хочет выбрать время, когда заберёт заказ» в формате «как… я хочу… чтобы» и добавьте 3–4 критерия приёмки.

Пример

Как гость, я хочу выбрать время, когда заберу заказ, чтобы кофе был горячим к моему приходу.

Критерии приёмки:

  • при оформлении можно выбрать «Как можно скорее» или время с шагом 5 минут;
  • нельзя выбрать время раньше, чем через 7 минут, и позже закрытия кофейни;
  • выбранное время показывается в подтверждении заказа и на экране бариста;
  • если кофейня закрыта, гость видит время открытия и может заказать на утро.

Мини-тест: проверьте себя

Закрепите урок: несколько вопросов, разбор ответов — в конце.

  1. Какая формулировка — пользовательская история?

  2. Что такое критерии приёмки?

  3. История «Как гость, я хочу пользоваться программой лояльности» не помещается в спринт. Что делать?