INVEST

Чек-лист хорошей User Story

INVEST – это аббревиатура, которая описывает шесть признаков хорошо написанной User Story. Каждая буква – одно качество.

• I – Independent (Независимая)
• N – Negotiable (Обсуждаемая)
• V – Valuable (Ценная)
• E – Estimable (Оцениваемая)
• S – Small (Маленькая)
• T – Testable (Тестируемая)

I – Independent (Независимая)

Что это значит

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

Почему это важно

Если истории сильно зависят друг от друга, планирование превращается в кошмар. Вы не можете выбрать, что делать в следующем спринте, потому что история А требует, чтобы сначала сделали историю Б, а та, в свою очередь, требует историю В.

Пример зависимости (плохо)

• История 1: Сделать форму регистрации.
• История 2: Сделать форму входа.
• История 3: Сделать личный кабинет.

Казалось бы, логично. Но что, если заказчик хочет в следующем спринте сделать личный кабинет? А его нельзя сделать без входа и регистрации. Получается, история 3 зависит от истории 1 и 2.

Как сделать независимыми (хорошо)

Можно переформулировать или перегруппировать:

• История 1: Сделать базовую регистрацию и вход через email/пароль.
• История 2: Добавить возможность входа через соцсети.
• История 3: Добавить в личный кабинет историю заказов.
• История 4: Добавить в личный кабинет редактирование профиля.

Теперь история 1 самодостаточна – после нее пользователь уже может регистрироваться и входить. А остальные истории можно делать в любом порядке.

На практике

Полной независимости добиться трудно. Но нужно стремиться, чтобы зависимости были явными и команда их понимала. Иногда зависимости можно уменьшить, создавая заглушки или моки (временные заменители) на время разработки.

N – Negotiable (Обсуждаемая)

Что это значит

User Story – это не жесткий контракт. Это тема для обсуждения. Детали могут и должны уточняться в ходе разговора команды.

Почему это важно

Если история записана слишком детально и жестко, теряется гибкость. В ходе обсуждения разработчики могут предложить более простое техническое решение, а тестировщики – подсветить риски, о которых никто не думал.

Пример необсуждаемой (плохо)

“На главной странице должна быть синяя кнопка размером 120x40 пикселей, расположенная в 20 пикселях от логотипа, с текстом “Купить сейчас” шрифтом Arial 14pt, которая при нажатии открывает форму заказа”.

Такая история не оставляет пространства для обсуждения. Дизайнер не может предложить лучшее решение, разработчик не может оптимизировать.

Пример обсуждаемой (хорошо)

“Как покупатель, я хочу быстро оформить заказ с главной страницы, чтобы не тратить время на поиск нужного товара”.

Теперь команда может обсуждать: может, это будет кнопка, а может, плавающая панель, а может, вообще быстрый заказ в один клик. Решение принимается коллективно, с учетом технических возможностей и дизайна.

На практике

В User Story записываем “что” и “зачем”, но не предписываем жестко “как”. “Как” обсуждается с командой.

V – Valuable (Ценная)

Что это значит

История должна приносить ценность пользователю или бизнесу. У нее должна быть понятная причина, зачем мы это делаем.

Почему это важно

Если ценности нет – зачем тратить время и деньги? Команда должна понимать, кому и зачем нужна эта функция. Это помогает правильно расставлять приоритеты.

Пример без ценности (плохо)

“Как пользователь, я хочу вводить свой ИНН при регистрации”.

А зачем? Если не указана ценность, непонятно. Может, для формирования чеков? Может, для отчетности? Может, это вообще лишнее поле, которое только отпугнет пользователей.

Пример с ценностью (хорошо)

“Как пользователь, я хочу указать свой ИНН при регистрации, чтобы автоматически получать чеки для бухгалтерии”.

Сразу понятно, зачем это нужно и кому это принесет пользу.

На практике

Часть “чтобы” в шаблоне User Story существует именно для этого. Если вы не можете сформулировать ценность, возможно, история не нужна или вы недостаточно глубоко поняли потребность.

E – Estimable (Оцениваемая)

Что это значит

Команда должна быть способна оценить объем работы по истории. Понять, сколько времени займет разработка, сколько это story points (очков) или человеко-часов.

Почему это важно

Если историю нельзя оценить, ее нельзя спланировать. Вы не знаете, влезет ли она в спринт, не конфликтует ли с другими задачами по срокам.

Пример неоцениваемой (плохо)

“Как пользователь, я хочу получать рекомендации товаров”.

Это огромная тема. Рекомендации могут быть простыми (на основе последнего просмотра) или сложными (на основе машинного обучения, анализа миллионов покупок). Непонятно, что именно имеется в виду, а значит, нельзя оценить.

Пример оцениваемой (хорошо)

“Как пользователь, я хочу видеть список товаров, похожих на тот, который я сейчас смотрю (на основе категории и цены)”.

Уже конкретнее. Команда может представить, как это реализовать, и прикинуть объем работ.

На практике

Если историю сложно оценить, обычно это признак того, что она слишком большая или слишком размытая. Нужно декомпозировать (разбить) или уточнить.

S – Small (Маленькая)

Что это значит

История должна быть достаточно маленькой, чтобы ее можно было сделать за один спринт. В идеале – за пару дней.

Почему это важно

Большие истории трудно планировать, они дольше делаются, в них больше рисков. Если история не влезает в спринт, вы не сможете показать результат заказчику в конце итерации.

Пример большой (плохо)

“Как покупатель, я хочу оплачивать заказы разными способами”.

Это огромная история (эпик). Способов оплаты много: банковские карты, электронные кошельки, СБП, наличные при получении и т.д. Это не влезет в один спринт.

Пример маленьких (хорошо)

Разбиваем на несколько маленьких историй:

1. “Как покупатель, я хочу оплачивать заказы банковской картой на сайте”.
2. “Как покупатель, я хочу оплачивать заказы через СБП по QR-коду”.
3. “Как покупатель, я хочу оплачивать заказы наличными при получении”.

Каждая из этих историй уже может быть сделана за несколько дней.

На практике

Хорошая история должна занимать не больше 2-3 дней разработки. Если больше - скорее всего, ее можно и нужно разбить на несколько.

T – Testable (Тестируемая)

Что это значит

Должно быть понятно, как проверить, что история сделана правильно. Должны быть четкие критерии, по которым тестировщик (или заказчик) может принять работу.

Почему это важно

Если историю нельзя проверить, вы никогда не узнаете, сделана она или нет. Это путь к бесконечным спорам и недопониманию.

Пример нетестируемой (плохо)

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

Что значит “удобный”? Для одного удобно одно, для другого – другое. Как это проверить?

Пример тестируемой (хорошо)

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

Уже можно проверить: посчитать количество шагов. А если добавить Acceptance Criteria (критерии приемки), станет совсем хорошо:

1. Шаг 1 – выбор товара и добавление в корзину.
2. Шаг 2 – ввод адреса доставки и контактных данных.
3. Шаг 3 – выбор способа оплаты и подтверждение заказа.
4. Между шагами можно перемещаться вперед и назад.
5. Все шаги занимают не более 2 минут при среднем заполнении.

Теперь тестировщик может четко проверить каждый пункт.

На практике

Тестируемость обеспечивается хорошими Acceptance Criteria. Если вы можете написать конкретные условия приемки - история тестируема.