User story и критерии приёмки

Ценность важнее формы

Шаблон «как роль, я хочу действие, чтобы результат» ценен третьей частью, и только ею. Первые две - просто вежливый способ записать задачу, а вот «чтобы» открывает пространство для разговора.

Пример. Заказчик просит выгрузку заказов в таблицу. Записываем цель: «чтобы быстрее находить нужный заказ». И тут же выясняется, что фильтр по номеру прямо в интерфейсе решает ту же задачу вдвое дешевле и без ежедневной выгрузки файлов. Без «чтобы» команда сделала бы выгрузку - ровно то, что попросили, и не то, что было нужно.

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

// Аббревиатура INVEST перечисляет свойства хорошей истории: независимая, обсуждаемая, ценная, оцениваемая, небольшая, тестируемая. Самая рабочая буква первая: если истории сильно связаны между собой, почти наверняка их нарезали по слоям, а не по ценности.

Критерии приёмки и формат Given-When-Then

Критерий приёмки отвечает на вопрос, когда историю можно считать сделанной, и живёт на уровне поведения. Тест-кейс - способ в этом убедиться: конкретные данные, шаги, окружение. Из одного критерия обычно рождается несколько тест-кейсов, и это нормальное соотношение.

Формат Given-When-Then разводит три вещи: given - состояние до, when - произошедшее действие, then - проверяемый исход. Разделение дисциплинирует и сразу показывает, если чего-то не хватает.

Главная ошибка формата - протащить результат в given. «Дано: заказ оформлен. Когда пользователь оформляет заказ. Тогда заказ оформлен» - критерий, который проходит всегда и не проверяет ничего. Выглядит смешно в примере и абсолютно незаметно в документе на сорок страниц.

// Критерии только на счастливый путь - типичная дыра, и лечится она тем же вопросом «а если нет». Незаданное поведение при ошибке всё равно будет реализовано, просто решение примет разработчик и никому об этом не скажет.

Нарезка по вертикали

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

Нарезка по слоям - отдельно фронтенд, отдельно бэкенд, отдельно база - выглядит удобнее и остаётся антипаттерном. Ни один слой в отдельности нельзя показать и принять: пользователь не видит бэкенд. Ценность появляется только когда всё сойдётся, а до этого момента риск копится молча.

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

// Оценивать слои действительно проще, и в этом вся ловушка: удобство оценки покупается отложенной обратной связью. Причём платит за это не тот, кто оценивал.

Как отвечать: «История Личный кабинет не влезает в спринт. Как разрежешь?»

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

Кандидат показывает принцип нарезки, обосновывает порядок бизнес-ценностью со ссылкой на проверяемые данные и явно отказывается от популярного антипаттерна, объясняя почему.

На чём валятся

• −− Пишут историю без «чтобы» и лишают команду возможности предложить решение дешевле.
• −− Режут по слоям архитектуры: обратная связь откладывается до схождения всех частей.
• −− Путают критерий приёмки с тест-кейсом и тащат в историю конкретные тестовые данные.
• −− Фиксируют в истории техническое решение, хотя ограничением оно не было.
• −− Протаскивают результат в предусловие и получают критерий, который проходит всегда.