Как справиться с написанием первых историй при применении схватки к игре?

Question

Я начинаю добавлять первые рассказы пользователей к моему отставанию в игре. Моя команда имеет приблизительное представление о той игре, которую мы хотим создать, и мы готовы собрать требования верхнего уровня. Как ты делаешь это? Я имею в виду, например, вы можете начать с мега эпического (верхнего уровня), который гласит: «Как издатель я хочу создать игру, в которой игрок должен кормить монстра, чтобы они провели действительно весело». Это правильная отправная точка? Должны ли мы теперь разделить эту эпопею на более мелкие истории пользователей и разделить эти истории пользователей на более мелкие и, наконец, на задачи? Является ли это «подобным дереву» способом сбора требований хорошим или вы обычно используете «более плоский» способ?

Заранее спасибо.

Answer 1

Хорошей отправной точкой для написания хороших историй пользователей является the book by Mike Cohn. Есть также множество полезных ресурсов в Интернете, как писать хорошие истории пользователей и как работать с отставанием в качестве владельца продукта и как привлечь команду к постоянному хранению отставания в хорошей форме, чтобы вы могли эффективно проводить сеансы планирования спринта, делать разумные прогнозирование дат, когда функции будут доступны и т. д.

Всегда важно оставаться практичным и экспериментировать. Начните с чего-то, а затем осмотрите &, адаптируйте это так, чтобы вы улучшались. В этом суть любого гибкого инструмента/рамки.

Если вы хотите, начните с большой эпопеи и посмотрите, как это происходит.

Возможно, это не стоит иметь этот эпический характер, но, скорее, обсуждать различные вещи, которые игрок игры может сделать, более конкретно. Эти вещи - истории пользователей, т. Е. Вещи, которые добавляют ценность пользователя во всем продукте. Вертикальный срез системы.

Некоторые выдуманные примеры для иллюстрации идеи вокруг историй в обстановке игры:

• Игрок, который получает 100k точек будет получить награду с золотым медальоном.
• Игрок должен заполнить X и Y, чтобы открыть секретный проход в Z.
• Игрок может использовать портал для телепортации на любой уровень, который он выбирает.

Да, вы можете видеть это как дерево или более и более конкретные истории, которые являются детьми других историй или эпосов. Практически, вы заботитесь только о листьях, так как это продукт совместной работы в команде и PO для работы с элементами отставания во время планирования спринта или других сеансов.

Экспериментируйте и начинайте с чего-то и улучшайте оттуда.

Answer 2

Это то, что мы делаем. Начните с эпиков, которые довольно высокого уровня и разложите их на более технические истории пользователей. Обычно мы останавливаемся на одном уровне, но иногда пользовательская история слишком велика, и ее нужно разделить на более мелкие куски.

На верхнем уровне находятся эпики, а справа внизу - рассказы пользователей, и все. Это может помочь вам сломаться дальше как упражнение в разложении - но построить массивное дерево зависимых историй может быть много, чтобы отслеживать. Мы пытаемся уловить потребности заинтересованных сторон. Эпохи AS (и да, может быть какое-то совпадение, но все в порядке.) Мы, как правило, хотим, чтобы наши истории пользователей были «легкими требованиями». Разработчик может создавать столько задач, сколько необходимо для выполнения истории. И если разработчик обнаруживает, что задач слишком много, мы возвращаемся и видим, можем ли мы сломать историю.

Наш владелец продукта управляет «функцией backlog», которая является просто причудливым способом сказать «эпопеи». Мы связываем рассказы об истории с рассказами нашей команды. Существует не ОДИН высший уровень эпических, Есть много эпических эпоса, представляющих функции потребностей. Таким образом, мы можем группировать функции логически вместе ради «релизов».

Answer 3

Возможно, вы захотите взглянуть на технику под названием «User Story Mapping» Джеффом Паттоном.

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

что-то, чтобы иметь в виду, что рассказы написаны с точки зрения пользователей системы. В приведенном ниже примере мне приходит в голову, что издатель определенно является заинтересованной стороной для проекта, но не пользователем (если вы не создаете приложение для создания игр на лету.)

Начните с анализа пользователей вашей игры. Вероятно, «игроком» будет главная роль, но вы можете думать о разных видах игроков: продвинутых игроков против новичков, игроков ПК против игроков игровой консоли, игроков, которые хотят исследовать, просто быстро пройти игру и т. Д. Это будет предложите вам различные функции, которые необходимо поддерживать игре.