Зачастую основные ошибки/недочеты/неточности обнаруживаются в критериях приемки к требованиям, хотя именно в них отражается основная информация для разработчиков и тестировщиков.
Это встречается у молодых специалистов, где оценка качества юзер стори заканчивается на проверке формулировки самой юзер стори. Но в большинстве случаев этого недостаточно.
Привет, меня зовут Алёна, я бизнес-аналитик в Red Collar. В этой статье я собрала частые ошибки при написании критериев приемки к пользовательской истории. Предлагаю советы, которые стоит учесть при при разработке требований.
1. Идём от общего к частному
Определяем блоки функциональности, из которых будет состоять продукт, затем определяем конкретные функции. После чего пишем истории и критерии приемки к ним. Нет смысла закапываться в детали продукта на этапе дискавери или этапе определения видения и границ проекта.
Антипример: На первом созвоне с клиентом выяснять, какого цвета кнопку «Купить» он хочет видеть на сайте своего магазина.
Пример: Определить, что вообще будет уметь система, очертить границы. После чего приступить к подробной проработке каждой функциональности и описанию требований и критериев приемки.
2. Не используем в требованиях слова, отражающие субъективную оценку (небольшой/хороший/яркий и т д)
Антипример: «Заголовок должен быть кратким».
Пример: «Заголовок должен быть длиной не более 20 знаков с пробелами».
3. Описываем подробности только по согласованию с заказчиком, дизайнером и разработчиком. Если не знаем — ставим «TBD (To Be Determined)» и идем узнаем
Антипример: «При нажатии кнопки “Создать заказ” открывается всплывающее окно розового цвета с фанфарами и песней Валерия Меладзе на фоне».
Пример: При нажатии кнопки «Создать заказ» появляются поля создания заказа. Формат TBD.
4. Дотошность и внимательность — главные друзья БА
Часто в ПО с несколькими похожими экранами/функциональностями возникает ситуация, когда требования отличаются по тексту крайне незначительно. Бывает удобно скопировать уже написанное подобное требование и просто внести правки в отличающиеся пункты.
Важно внимательно вычитать все скопированное и убрать «лишние» слова из других требований. В работе БА количество требований и скорость их написания ничего не значат, если в итоге в требованиях много ошибок и опечаток, которые могут повлиять на разработку конечного продукта.
5. Пишем названия юзер стори (чтобы при беглом взгляде на заголовок понять, о чем речь)
Антипример: User Story №1. Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить онлайн заказ.
Пример: US1 - Регистрация. Как клиент магазина бытовой техники, я хочу зарегистрироваться на сайте магазина, чтобы оформить он-лайн заказ.
6. Не смешиваем разные функциональности
В каждом требовании должен быть результат, который завершает юзер стори и начинает новую. При изменении каких-то параметров требований актуализировать их будет гораздо проще, когда каждая функциональность описана отдельно, а связанные требования просто ссылаются на нее. Избегаем ненужного дублирования и раздувания документации.
Антипример: В US про регистрацию написать: «После нажатия кнопки “Зарегистрироваться” открывается личный профиль клиента. Профиль состоит из …».
Пример: В US про регистрацию написать: «После нажатия кнопки “Зарегистрироваться” открывается личный профиль клиента. Функциональность профиля клиента описана в US2 - Профиль».
7. Не дублируем одну и ту же информацию
Ситуация аналогична предыдущему пункту. В случае внесения каких-то изменений, допустим, в правила валидации, не придется искать все требования, в которых они были указаны. Снижается риск что-то пропустить и оставить требования неактуальными.
Антипример: Повторно описывать правила валидации параметров, которые уже были описаны в другой US.
Пример: Сослаться на другую US или сделать отдельную страницу для всех валидируемых полей и всегда ссылаться на нее.
8. Описываем результаты как положительного сценария, так и отрицательного
Антипример: «При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа».
Пример: «При заполнении всех полей в соответствии с правилами валидации, указанными в таблице 1, после нажатия кнопки “Создать” открывается окно создания заказа. При заполнении хотя бы одного поля не в соответствии с правилами валидации после нажатия кнопки “Создать” появляется сообщение об ошибке. Возможный текст:…».
9. Добавляем диаграммы, схемы, вайрфреймы, но только если они несут ценность для понимания данной US
У оформления критериев приемки нет четких правил. Вы можете описывать функциональность, как считаете нужным, но только если это действительно важно для понимания принимающей стороной
Антипример: «US1 Регистрация. Диаграмма движения популяции морских котиков прилагается».
Пример: «US1 Регистрация. Диаграмма процесса регистрации с учетом интеграций со сторонним сервисом прилагается».
10. Добавляем ссылку на дизайн или прототип, обновляем по мере готовности
Антипример: Мысли разработчика при виде требований без ссылок на визуал: «Гора текста, ниче не понятно, еще и картинки нет».
Пример: Мысли разработчика при виде требований со ссылками на прототип: «Гора текста, ниче не понятно, хоть картинка есть, слава Богу».
11. Всегда думаем головой в каждом конкретном проекте
Антипример: «В статье читал(а), что можно только так, поэтому лучше напишу, как там было указано».
Пример: «Автор статьи не видит этот конкретный проект и, если мне кажется, что здесь стоит применить другой подход, но я не уверен(а), стоит посоветоваться с коллегами».
Выводы: всегда есть место развитию
Вероятно, у каждого бизнес-аналитика есть свой арсенал подобных критериев. Такие вещи приходят с опытом. Предполагаю, что и я с годами дополню этот список советами, которые упростят жизнь мне и многим начинающим специалистам в сфере бизнес-анализа и технического писательства.
Данные пункты «не высечены в камне»: в разных компаниях в зависимости от уровня специалистов и других критериев подобный список может меняться. Надеюсь, что рекомендации помогут вам избежать ошибок при разработке требований к ПО и стать тем самым аналитиком, работать с которым на проекте — одно удовольствие!
