В мире разработчиков и продуктового менеджмента есть популярная аббревиатура — INVEST. В этой статье давайте расшифруем то, что скрывается за этим сокращением, и проиллюстрируем это примерами.
Подход глубоко разработал Билл Уэйк в статье "INVEST in Good Stories, and SMART Tasks" («Инвестируй у хорошие истории и умные задачи»). Отсюда следует, что INVEST используется для создания пользовательских историй, одного из типа описания задач.
Обычно, пользовательская история содержит указания на вопросы: «Кто? Что? Почему?» Стандартная формула: Я, как <роль>, хочу <функция>, чтобы <ценность>.
Такая формулировка истории не содержит в себе всех критериев, важных для качественной разработки. Из-за этого при создании User Stories нужно оценивать их на соответствие INVEST.
I — независимый
Мы хотим, чтобы все истории были независимыми. Такая история должна быть небольшой частью большего эпика. Добиться независимости можно правильной вертикальной декомпозицией и обеспечением кросс-функциональности команды.
Как разбираться с независимостью? Нужно грумить задачу со специалистами, которые предусматривают весь процесс. Например, задача звучит так: «Я, как директор по эффективности, хочу, чтобы в на отдельной вкладке в CRM отражались графики работы сотрудников определенной точки продаж, чтобы я мог их анализировать».
Звучит неплохо. Но эта история в большинстве случаев не может быть независимой. Директор думает только о пользовательском интерфейсе, когда ставит такую задачу. На деле же нужно решать, откуда брать эти данные, есть ли соответствующие данные или API, заполняются ли они вообще и т. д. Если требуется «определённая точка», значит, нужна фильтрация и сортировка. В общем, история зависит от многих факторов. История попадёт под критерий I, только если база для неё полностью готова.
N — обсуждаемая
Обсуждаемая — это значит, что владелец продукта и команда разработки могут обсудить её. В результате этого они должны прийти к компромиссу касательно приоритета и критериев приёмки.
Вот как звучит общая история, которая ещё не обсуждалась:
Я, как аналитик, хочу видеть несколько наборов данных, чтобы определить, есть ли между ними корреляция.
Каки наборы данных? Какие данные конкретно и чем ограничено это число? Как исходя из этого определить критерии приёмки? Что требовать у команды? Начинаем конкретизировать:
- Я, как аналитик, хочу сравнить возраст покупателя и его средний чек, чтобы определить ЦА с лучшей покупательной способностью.
Это более детальная история. Она может дополниться другими историями, например, «Я, как аналитик, хочу сравнить район покупки и средний чек» и т. д.
Теперь владелец продукта может определиться с тем, какая история важнее. Разработчики могут уточнить про уровень детализации данных и прочие детали. Всё это подлежит обсуждению, чтобы определить критерии, которые «должны» быть сделаны, а также те, которые желательные (если останется время).
V — ценная
Ценность истории — это значение для бизнеса. Каждая история должна так или иначе нести в себе ценность. Это не только функция, которая имеет маркетинговый эффект, но и оптимизация бизнес-процесса, сокращение работы программиста.
Обычно критерий «ценности» находится во второй части пользовательской истории — это ответ на вопрос «Зачем?» Если не задавать этот вопрос для каждой пользовательской истории, команда рискует не понять её смысл, а тем самым ограничить возможные решения.
E — возможная для оценки
Показатель того, что история понята разработчикам, — это возможность оценить её. Мы ставим относительную оценку, не цепляясь за время, но всё же она есть. Чем выше оценка, тем меньше определенности, и наоборот. В какой-то момент неопределённость будет настолько высокая, что задачу нужно разделить.
Например, задача «Я, как директор, хочу ввести документооборот» имеет высокую степень неопределённости. Без уточнения её невозможно оценить.
- Я, как руководитель направления, хочу использовать документооборот на возврат товара в программе учёта, чтобы оптимизировать процесс.
В таком виде история обретает детали, так что команда может прикинуть, куда двигаться.
S — компактного размера
Критерий Sized граничит с предыдущим. Если история слишком большая, сложная, то её нужно разбить на более компактные части. Таким образом с ней будет легче работать, истории будут перемещаться по доске, будет проще отслеживать прогресс и не блокировать работу по другим задачам.
T — тестируемая
Тестируемость определяется критериями приёмки. Эти критерии должны быть прописаны у каждой истории, чтобы разработчик сверился с ними и протестировал задачу на соответствие минимальному набору требований.
Например, критерии по задаче «Я, как аналитик, хочу сравнить возраст покупателя и его средний чек, чтобы определить ЦА с лучшей покупательной способностью»:
- Показать параметры как пункты меню,
- Отображать параметры в порядке убывания,
- Показать результаты ниже порога красным цветом,
- Вывести результаты не более, чем за 0,2 секунды и так далее.
Эти требования легко тестируются, вручную или автоматически. Написание требований по тестам даёт программисту дополнительное понимание, позволяет не сбиться в пути в момент разработки. По прохождению тестов мы понимаем, достигнута ли цель.
Когда задача имеет нефункциональные требования (производительность, удобство), то нужно всё равно прописать тесты.
Каждый из параметров INVEST формирует цикл обратной связи, помогает в оценке и реализации, устанавливает необходимый уровень прозрачности.