Ролевая игра · Конспекты по бизнес-анализу

Что это#

Леффингуэлл и Уидриг описывают ролевую игру (role playing) как технику выявления (elicitation) с простым обоснованием: каждый смотрит на мир через собственный концептуальный фильтр, и наблюдение или интервью не дают того понимания, которое приходит, когда выполняешь работу сам.

Авторы называют четыре причины, по которым наблюдения и интервью недостаточны:

Многие пользователи не могут описать собственные процедуры или потребности, потому что раньше их никто об этом не спрашивал. (Попробуйте объяснить словами, как вы завязываете шнурки.)
Пользователи могут скрывать, в чём отступают от официальной процедуры: слова и дела расходятся.
Личные обходные приёмы пользователя могут скрывать от наблюдателя настоящие проблемы.
Ни одна сторона не знает всех вопросов: разработчик не знает, о чём спросить, а пользователь — чего от него ждут.

У ролевой игры есть два «бумажных» родственника — для ситуаций, когда выполнить работу самому нельзя:

Сценарный просмотр (scripted walkthrough). Каждый участник следует сценарию, который отводит ему роль. Разыгрывание сценария вскрывает неверно понятые роли, информацию, которой не хватает действующему лицу или подсистеме, и поведение, которое никто не описал. Сценарий можно изменить и разыграть заново, а также использовать для обучения новых членов команды — поэтому сценарный просмотр работает как своего рода «живая» раскадровка.
CRC-карточки (Class–Responsibility–Collaboration, «класс — обязанности — взаимодействие») — техника из объектно-ориентированного анализа. Каждый участник получает карточку на один класс или объект, где перечислены его обязанности (что он делает) и партнёры по взаимодействию (с кем он работает). Инициирующее действующее лицо запускает поведение, и каждый действует по своей карточке. Когда ход событий останавливается из-за нехватки информации или неопределённого взаимодействия, карточки исправляют и разыгрывают снова. Авторы отмечают, что техника подходит и для выявления (внешнее поведение), и для проектирования (внутренняя структура) и часто вскрывает ошибочные или пропущенные требования.

Когда применять#

Пользователям трудно объяснить свою работу, или их объяснения не совпадают с тем, что вы видите.
Аналитики или разработчики считают, что понимают проблему пользователя лучше, чем он сам. Леффингуэлл и Уидриг рекомендуют ролевую игру как средство именно от этой стороны синдрома «пользователя и разработчика».
Существующая система провоцирует ошибки, и нужно почувствовать, откуда они берутся.

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

Как это делать#

Выберите роль и задачи. Выберите класс пользователей и две-три повседневные задачи, важные для проекта.
Договоритесь с пользователями и их руководителем. Согласуйте, что вам можно делать, с кем и кто подстрахует вас, если вы ошибётесь.
Выполните работу. Используйте настоящие инструменты и настоящие входные данные. Пример авторов — ввести несколько заказов на закупку в существующую систему, чтобы почувствовать, где возникают ошибки. Часто хватает от получаса до часа.
Отмечайте неудобства по ходу дела: ожидания, обходные приёмы, повторный ввод, информацию, которую пришлось искать.
Разберите итоги в тот же день вместе с пользователем: подтвердите находки и расспросите о том, чего вы не могли увидеть.
Если выполнить работу нельзя, напишите сценарий. Опишите ситуацию с ролями, раздайте роли (или CRC-карточки), разыграйте, останавливайтесь на каждом пробеле, исправляйте сценарий и разыгрывайте снова.
Превратите находки в требования и вопросы и свяжите их с сессией, на которой они появились.

Пример#

Для «Мастерской», вымышленной сети веломастерских, аналитик проводит субботнее утро за стойкой приёма одной из мастерских: под присмотром старшего администратора принимает записи по телефону в бумажный журнал. Меньше чем за час он замечает три вещи, о которых никто не говорил на интервью: звонящие часто не знают модель своего велосипеда, поэтому длительность записи назначают наугад; у стойки есть собственный список «быстрых работ», которые втискивают между записями; звонки о статусе ремонта приходят волнами — после того как родители забирают детей из школы. Каждое наблюдение становится вопросом или черновым требованием.

Клиентов так не сыграешь, а в цепочке поставки запчастей участвует внешний поставщик, поэтому команда проводит сценарный просмотр ситуации «запчасти нет на складе». Участники играют Клиента, Стойку приёма, Механика, Поставщика запчастей и Систему записи. Сценарий застревает, когда Механик спрашивает: «Кто сообщит клиенту, что ремонт задерживается?» — и оказывается, что этого нет ни в одной роли. Следующий раунд с CRC-карточками для Записи, Ремонтного заказа, Заказа запчастей и Уведомления показывает, что ни одна карточка не отвечает за пересчёт ожидаемой даты готовности.

Частые ошибки#

Наблюдать вместо того, чтобы делать → садитесь на место пользователя, а не на стул рядом с ним.
Играть «причёсанную» версию работы → используйте реальные входные данные и реальные объёмы, где это безопасно.
Пропускать разбор итогов → часть ощущений вы истолкуете неверно; сверьтесь с пользователем.
Напрямую играть рискованные роли → переходите на сценарный просмотр или CRC-карточки.
Проводить сценарный просмотр один раз → польза появляется, когда сценарий исправляют и разыгрывают снова.
Не записывать находки → фиксируйте каждую как требование, вопрос или правило.

Чек-лист#

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

Источники и что почитать#

D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 14.