Пользовательская история
Что это такое
Пользовательская история — это короткая формулировка потребности, обычно в виде «Как роль, я хочу что-то, чтобы выгода», рядом с которой записаны критерии приёмки. Спецификацией такая история не является: это заглушка для разговора, а артефактом становятся карточка вместе с её критериями.
Почему это важно
Форма заставляет назвать три вещи, которые список требований часто опускает: кто этого хочет, что именно ему нужно и почему это стоит строить. Работу здесь делает клауза «чтобы»; именно в ней запрос, не способный назвать свою выгоду, ставят под вопрос, и там же команда может предложить более дешёвый способ достичь того же результата. Однако у формы есть и режим отказа, и о нём стоит сказать так же прямо, как о выгоде: история, записанная в трекер и никогда не обсуждённая, превращается в миниатюрную спецификацию, которая наследует все слабости спецификации и при этом слишком коротка, чтобы быть полной.
Ключевые идеи
«Чтобы» — клауза, принимающая решения
Напишите её первой и словами того, кто просит. Если написать не получается, перед вами решение в поисках проблемы.
Слабо: Как пользователь, я хочу панель, чтобы видеть происходящее.
Лучше: Как кладовщик-супервайзер, я хочу видеть, кто из сборщиков
отстаёт больше чем на час, чтобы переставить кого-то до того,
как дневная отправка опоздает.
Вторую версию можно удовлетворить как минимум тремя способами, и один из них может оказаться отчётом, а не экраном.
Критерии приёмки — проверяемая часть
Это условия, которые проверяющий может проверить, по одной строке каждое и словами пользователя. Именно они становятся мостом к тестам и делают историю завершаемой.
- показывает только сборщиков, отстающих от плана больше чем на час
- сортировка по величине отставания, сначала самые отставшие
- обновляется не реже чем каждые пять минут
- ничего не показывает, когда все сборщики идут по плану
Дробите по шагу рабочего процесса, а не по техническому слою
История, разбитая на «API» и «UI», не даёт ничего, пока не сделаны обе части. Дробите так, чтобы каждую часть можно было продемонстрировать независимо.
Разговор — и есть результат
Карточка существует, чтобы назначить обсуждение между человеком с потребностью и теми, кто будет строить: уточнение и есть этот разговор, а написанные слова — лишь его краткое изложение.
Держите бэклог упорядоченным по ценности, а не по размеру историй
Маленькие истории легче брать, поэтому неупорядоченный бэклог сползает к мелочам. Порядок, который задаёт владелец продукта, держит маленькое и ценное впереди маленького и лёгкого.
Практика
Перепишите три запроса как истории
Возьмите три элемента, записанных сейчас как задачи, — например, «добавить сортировку в таблицу заказов», — и перепишите каждый как историю с названной ролью, выгодой и тремя критериями приёмки.
Готово, когда: выгода каждой истории предполагает как минимум две возможные реализации, а каждый набор критериев можно проверить, не спрашивая автора.
Разбейте одну историю по рабочему процессу
Возьмите историю, которую вы уже оценили как большую трети итерации, и разбейте её так, чтобы каждую часть можно было продемонстрировать отдельно.
Готово, когда: вы можете описать демонстрацию каждой части, не упоминая остальные.
Частые ошибки
- История без «чтобы» — потребность заявлена, и более дешёвый вариант предложить нельзя; исправить: напишите выгоду словами просителя или поставьте элемент под вопрос.
- Истории как спецификации — деталь написана, а разговора не происходит; исправить: относитесь к карточке как к заглушке и уточняйте в обсуждении.
- Дробление по техническому слою — ничего не демонстрируется, пока не приземлится последняя часть; исправить: дробите по шагу рабочего процесса или по видимому пользователем результату.
- Критерии приёмки, которые нельзя проверить — «должно быть быстро» или «удобно»; исправить: напишите условия, которые проверяющий может подтвердить.
- Неупорядоченный бэклог — команда берёт что попало, лишь бы поменьше; исправить: держите один упорядоченный список, которым владеет владелец продукта.
Что читать дальше
- Методология Agile (04-product-process/02-agile-methodology) — прочитайте это первым: история — единица планирования для этих ценностей.
- Оценка и story points (04-product-process/17-estimation-story-points) — как истории соизмеряются друг с другом.
- Бэклог и поток спринта (04-product-process/10-scrum-software-development/02-the-backlog-and-sprint-flow) — где истории упорядочивают и уточняют.
- Инженерия требований (04-product-process/05-requirements-engineering) — более формальный путь, когда систему нужно специфицировать проверяемо.