Как мы отслеживаем детали истории пользователя?[закрыто]

Question

Итак, если история пользователя - это что-то туманное, например:

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

Я даже не уверен, что это достоверная история пользователя, но я уверен, что она достаточно близка к истине.

Затем есть детали / задачи для реализации этой пользовательской истории.И я уверен, что "Торговый представитель должен иметь возможность переводить вкладки из одного текстового поля в другое" - это одно из требований.Как мы фиксируем / отслеживаем это?Является ли это частью истории пользователя или это что-то, что следует рассматривать отдельно?

Answer 1

История пользователя отражает суть функции, а не детали, история - это поддержка обсуждения.

Итак, чтобы ответить на ваш вопрос, подробности передаются устно во время обсуждения, потому что обсуждение лицом к лицу - это самые эффективные средства коммуникации.Если вы чувствуете необходимость, детали могут быть записаны в виде заметок на обратной стороне карточки (если вы используете карточки) или...в "Примечания"поле, если вы используете электронный инструмент.На самом деле, я обычно использую "как создать демо-версию"поле также для высокоуровневого описания того, как эта история будет продемонстрирована в демоверсии sprint, и используйте очень краткие "примечания" для любой другой информации, разъяснений, ссылок на другие источники информации и т.д. (кредиты знаменитому Хенрику Книбергу Генератор индексных карточек).Я нахожу это очень удобным, особенно при использовании исполняемых спецификаций.

PS:ваша история абсолютно достоверна, и хорошей практикой является включение преимуществ в ваш шаблон ("Как Роль, Я хочу Экшен так что Преимущества").

Answer 2

Истории пользователей должны представлять собой короткие утверждения от 1 до 3 предложений.

http://en.wikipedia.org/wiki/User_story

Я хочу иметь возможность переходить из одного текстового поля в другое - это другая история пользователя.

Вы можете отслеживать эти вещи с помощью такого инструмента, как www.rallydev.com, или просто любого инструмента отслеживания задач (SharePoint, даже Excel...и т.д.).

Следующее, что вы делаете, - это расставляете приоритеты.

Answer 3

Просто принимаю грубый удар...

В качестве торгового представителя,
Я хочу, чтобы весь ввод данных и навигация осуществлялись с помощью клавиатуры
чтобы мне не приходилось убирать руки с клавиатуры
(и чтобы мы соблюдали правила доступности).

Или

Как бизнес,
Мы хотим, чтобы все наши продукты можно было полностью использовать, используя только ввод с клавиатуры
Чтобы мы могли продавать клиентам, которым требуется доступное программное обеспечение.

Answer 4

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

http://www.tdan.com/view-articles/6089

Вторая часть (о табуляции) является частью другого документа - "Спецификация UX" (показывает все экраны и описывает взаимодействие с пользователем).Этот обычно пишется другим человеком / командой (Product team или UX team).

http://uxdesign.com/ux-defined-2

http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php

Answer 5

Да, с этим проблем у нас тоже немало.С одной стороны, истории пользователей должны быть осознанными, с другой стороны, все мельчайшие детали должны быть изложены где - то.

Мы используем XPlanner и решаем эту проблему, помещая краткое описание в текстовую часть истории пользователя.Затем мы используем функцию XPlanners "заметки" (произвольный текст или файлы, которые могут быть прикреплены к истории пользователя) для уточнения деталей.

Таким образом, мы можем добавить в историю пользователя столько информации, сколько необходимо, не загромождая сам текст истории пользователя.Вы также можете обратиться к внешней документации, если вы не хотите иметь все в XPlanner.

Этот подход работает для нас довольно хорошо.

Answer 6

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

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

Устное общение может быть эффективным, но эффективность зависит от способности получателя услышать и понять смысл сообщения.Именно здесь устное общение может потерпеть неудачу. Различные виды коммуникации предлагая более или менее формальные формы общения.Голосовое общение - это "неформальная форма общения", которая чревата риском того, что сообщение будет неправильно услышано, истолковано неверно и возникнет недопонимание.Совсем как в игре, в которую играли в детстве, где один ребенок шепчет сообщение другому ребенку, который рассказывает другому, пока все его не услышат...Когда последний дочерний элемент передает сообщение группе, оно обычно было неверно истолковано, а затем снова неверно истолковано, что приводит к ухудшению качества сообщения.