Истории пользователей для функций, которые пересекают несколько режимов презентации?

Question

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

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

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

Теперь это может быть история одного пользователя («As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time»). Но это кажется неправильным (и, вероятно, будет эпической историей, так или иначе).

Вы можете сделать это отдельные пользовательские истории («As a desktop user...», „As a smartphone user...“, и т.д.), которые я сделал в прошлом, и команда знает только оценить первый включить все функциональности, а последующие - для оценки только реализации пользовательского интерфейса.

Третий вариант заключается в том, чтобы сделать базовую функциональность историей, изолированной от уровня представления, а затем иметь истории пользовательского интерфейса: «As a flight info system front end, I want to get flight status information so that I can present it to the user», «As a desktop user, I want to see flight arrival... etc». Но это кажется искусственным.

Мысли?

DWH

Answer 1

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

Например, если разбить его в простой истории:

Пользователь может хотеть знать статус полета дал номер рейса.

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

Таким образом, служба REST решает первую историю выше.

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

Или, если пользователь просто вводит номер рейса, и именно это, то почему бы просто не сделать это как веб-страницу, поскольку это самый простой подход, который поддерживает обе концепции. Затем, если у вас есть URL-адрес, который поддерживает GET, и выводится как HTML, вы можете легко отображать.

Итак, моя первая история была слишком простой, вы можете подумать, можно ли возвращать разные типы данных, поэтому пользователь может захотеть иметь HTML, PDF, json или xml, но для каждого из них должен быть деловой необходимостью.

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

Answer 2

Я бы порекомендовал второй вариант.

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

С третьим вариантом большая проблема заключается в том, что вы не доставляете ценность для бизнеса в конце истории, что, как правило, является плохой практикой.

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