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

Question

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

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

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

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

Answer 1

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

Итак, чтобы ответить на ваш вопрос, детали передаются в устной форме во время обсуждения, потому что обсуждение лицом к лицу the most effective communication media. Если вы чувствуете необходимость, детали могут быть записаны в виде заметок на обратной стороне карты (если вы используете карты) или ... в поле «примечания», если вы используете электронный инструмент. На самом деле, я обычно использую поле «как демо» », чтобы захватить описание на высоком уровне того, как эта история будет демонстрироваться на демонстрации спринта и использовать очень короткие« заметки »для любой другой информации, разъяснений, ссылок на другие источники информации и т. д. (кредиты знаменитому Хенрику Книбергу Index card generator). Если это очень удобно, особенно при использовании исполняемых спецификаций.

PS: ваша история вполне допустимо, и его хорошая практика, чтобы включать преимущества в шаблоне («Как роль, я хочу действия так, чтобы преимущества»).

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Этот подход подходит для нас.

Answer 5

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

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

Или

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

Answer 6

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

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

Устные сообщения могут быть эффективными, но эффективность зависит от способности приемников слышать и понимать смысл сообщения. Здесь устное сообщение может потерпеть неудачу. Different types of communication предлагает более или менее формальные формы общения. Вокальное общение - это «неофициальная форма общения», которая рискует, что сообщение ошибочно, неверно истолковано и непонимание. Точно так же, как игра, играемая в качестве ребенка, где один ребенок шепчет сообщение другому ребенку, который говорит другому, пока все не услышали его ... Когда последний ребенок сообщает сообщение группе, он обычно неверно истолковывается, а затем неправильно интерпретируется, вызывая ухудшение сообщения.