Краткий ответ
Качественная пользовательская история в Salesforce описывает, кто, что он пытается достичь и каков будет результат после действия, а не какое поле появится на каком экране. Простая проверка: если критерии приемки можно сформулировать без знания того, будет ли реализация выполнена с помощью Flow, Validation Rule или Apex, история написана правильно.
Распространенная ошибка — это история, которая уже содержит решение. Как только написано «Добавить поле Picklist на экран сделки», обсуждение процесса завершается, не успев начаться.
Рабочая структура
| Компонент | Роль | Критерий качества |
|---|---|---|
| Контекст | Кто пользователь и когда он здесь | Реальная роль, а не «пользователь» |
| Намерение | Что он пытается достичь | Сформулировано на языке бизнеса |
| Критерии приемки | Что проверяется | Можно выполнить как сценарий с тестовыми данными |
| Крайние случаи | Что намеренно не удалось | Хотя бы один отрицательный |
| Вне Scope | Что явно не включено | Предотвращает споры при приемке |
Последняя строка предотвращает большинство конфликтов. Явное заявление о том, что не включено, стоит больше, чем три абзаца описания.
Декомпозиция: вертикальный срез, а не слои
При реализации CRM-проекта возникает соблазн декомпозировать его по техническим компонентам — сначала модель данных, затем автоматизация, в конце отчеты. Результат: нечего показать до самого конца, и никто не знает, работает ли процесс.
Правильная декомпозиция — вертикальная: один полный сквозной сценарий для одного профиля пользователя. Одна транзакция, которая открывается, развивается, закрывается и появляется в отчете, ценнее десяти определенных объектов без процесса. Далее добавляются профили и сценарии вокруг того же каркаса.
Приоритизация, когда все срочно
Трех критериев достаточно, в следующем порядке:
- Блокирует запуск? — Без него процесс неполный. Места для переговоров нет.
- Сколько пользователей в день? — Частота превосходит интенсивность жалобы. Элемент, затрагивающий 80 агентов ежедневно, имеет приоритет над запросом одного руководителя.
- Какова стоимость отсрочки? — Увеличится ли стоимость реализации, если мы сделаем это после запуска? Изменение в модели данных — да, изменение в отчете — нет.
То, что не проходит эти три критерия, отправляется в Parking Lot. Это разделение предотвращает превращение бэклога в архив желаний. Подробности об управлении изменением объема представлены в Scope Creep и контроль изменений.
Долг по требованиям: тихая ошибка
Долг по требованиям возникает, когда user story завершается без решения о том, что происходит в крайнем случае — «разберемся с этим позже». После запуска такие крайние случаи составляют большинство обращений в службу поддержки.
Простое решение: элемент не закрывается без документированного решения по каждому открытому вопросу, который в нем был зафиксирован, даже если решение — «намеренно не обрабатывать». Документирование отказа ценнее отсутствия документации.
Связь с тестированием
Правильно написанные критерии приемки — это, по сути, сценарии UAT. Когда они пишутся после разработки, UAT становится демонстрацией того, что было создано, а не проверкой того, что требовалось. Последовательность подробно описана в руководстве UAT.
Заключение
Качественный бэклог не длинный, а понятный: каждый элемент указывает, для кого он предназначен, что будет считаться успехом и что явно не включено. Эти три вопроса, заданные до начала разработки, а не после, определяют практически все качество приемки в конце проекта.