В книге User Stories Applied содержится отдельная страница, посвященная Personas. Определение персоны из книги:
Личность - воображаемое представление роли пользователя.
Далее обсуждается определение персоны:
Создание персонажа требует больше, чем просто добавив имя в роль пользователя. persona следует описать достаточно, чтобы все в команде чувствует, что они знают персона.
Он также рекомендует найти фотографию в Интернете или в журнале и использовать эту фотографию для персоны, чтобы каждый мог ясно представить, как человек работает с приложением.
Ok. Все эти идеи звучат хорошо. Может быть интересно определить персонажи для пользовательских ролей, но стоит ли это? Есть ли реальное или измеримое качество или повышенная эффективность при их использовании?
Есть ли у вас хорошие примеры, когда персонажи действительно помогают команде разработчиков? Используете ли вы персонажи в истории пользователей?
Edit:
Я нашел хорошую статью о персонах в MSDN.
Это может помочь, когда есть много ролей и когда они очень сложны.
Чем больше у вас функций, тем сложнее их удовлетворить. У них разные потребности, ценности, мощность и т.д. Наличие картинки немного тривиально, но это тоже помогает.
Проверьте это действительно приятное видео от Джеффа Паттона по теме: http://www.infoq.com/presentations/pragmatic-personas
Его веб-сайт: http://www.agileproductdesign.com/
Причиной использования персонажа является то, что команда лучше понимает историю. Это облегчает для команды (программистов...) отношение к истории на более личном/эмоциональном уровне, который, я думаю, хорош.
Если у вашей команды есть привычка отправлять истории, которые не то, чего хочет клиент, то, во что бы то ни стало, попробуйте индивидуальный подход и посмотрите, как это работает для вас.
Проверяйте и адаптируйте, как обычно.
Персонажи могут быть полезны также для более четкого общения между командой разработчиков и бизнеса. Когда вы говорите больше в нетехнических терминах, бизнес может понять вас более четко.
Вместо описания
Администратор приложения будет поддерживать структуру db и код приложения
вы будете использовать persona Frank:
Фрэнк отвечает за технические вопросы нашего приложения. Он понимает базу данных. Он не учит пользователей, как работать с приложением, но в случае каких-либо проблем он может их решить.
Я все еще не уверен, следует ли описывать персонажей с настоящими эмоциями, например. "Фрэнк не очень-то рад помочь пользователям все время, чтобы пользователи не часто его беспокоили".
Я помню, как читал справочную статью Boston Consulting Group о персонах в растущем латиноамериканском среднем классе. Хотя интересно, я думал, что их уровень контроля совершенно не нужен. Лично я считаю, что люди - пустая трата времени и должны рассматриваться как вспомогательный инструмент, а не приоритетная задача. Я помню, как неделями занималась созданием персонажей для социальной сети для предпринимателей. Большая трата! Я думаю, что лучше открыть для себя миссию вашей компании или веб-сайта. Миссия компании может помочь вам рационализировать, как наилучшим образом обслуживать своих пользователей, независимо от их конкретных личностей. Думайте Facebook, "Мы хотим, чтобы пользователи могли делиться и общаться со своими друзьями" или Foursquare "Мы - социальная утилита, которая соединяет пользователей с их городами".
С другой стороны, у вас может быть персонаж "Петр".
"Петр любит пить много пива, а Петр использует свой компьютер, когда он пьян. Требования Петра зависят от его уровня алкоголя в крови. Петр любит программировать свой компьютер. Его лучший код написан после 12 литров Пилснера и он не пишет код, если он не потребляет по меньшей мере 6 литров Пльзнера".
Что делает Personas, помогает аналитикам понять, о чем они пишут. Это поможет вам обнаружить требования, которые вы обычно не замечаете.
Использование User Personas в истории пользователей действительно полезно для команды. Персонажи - очень подробные вымышленные персонажи, которые выступают в качестве представителя большинства пользователей и других заинтересованных сторон, которые не могут напрямую использовать конечный продукт. Создание персонажей, определение потребностей целевой базы пользователей становится легкой задачей для команды. Создание конкретных лиц может помочь команде лучше понять пользователей, их требования и цели. На основе Persona владелец продукта может более эффективно распределять приоритеты функций для создания приоритетного отставания продукта. Чтобы узнать больше о User Persona, вы можете прочитать эту статью - https://www.scrumstudy.com/blog/what-is-a-persona/