Истории пользователей и варианты использования

Ответ 1

На самом деле, оригинальные сценарии использования (см. Jacobson OOSE) были довольно легкими, как и пользовательские истории. Со временем они развивались до тех пор, пока общий формат "вариантов использования" теперь не стал сложным документом с входными данными, выходными данными, наследованием, использованием отношений, псевдокодом и т.д. Программисты, как правило, пытаются преобразовать все в программирование.

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

Лично я считаю, что шаблон "[Actor] [глаголы] [существительное], чтобы получить [ценность для бизнеса]" полезен. Если он перебирает абзац текста, он может быть слишком большим.

Ответ 2

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

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

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

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

Ответ 3

Случаи использования не являются сборниками пользовательских историй.

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

Рекомендуемый шаблон для пользователя:

Как (роль) я хочу (что-то), чтобы (польза)

(Спасибо, Майк Кон, за предоставление этого простого шаблона)

Описания поведения, выраженные таким образом, более гибкие.

Этот шаблон позволяет описывать поведение с использованием разных уровней детализации. Например:

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

ИМХО. Случаи из камня гораздо больше вырезаны! И, следовательно, может быть проблемой для обновления после начальной версии.

НТН

веселит,

Rob

Ответ 4

Одним словом, нет.

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

С другой стороны, история пользователей - это "приглашение для обсуждения". Обычно это одно или два предложения. Здесь - один из хороших ресурсов для этого. И Майк Кон Пользовательские истории, которые были применены, стоит того.

Типичный синтаксис: "Как < пользователь > мне нужно < функциональность > для достижения < бизнес-значение > " или "Для достижения < бизнес-значение > как < пользователь > мне нужны < функциональность > " который приводит домой значение истории.

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

Ответ 5

Вы можете думать о usecase как истории пользователя, но не наоборот. Усекаса будет охватывать несколько "концов" истории, особые требования (например, поля формы должны вводиться в формате xyz и показывать сообщение об ошибке 123, если пользователь вводит поле в неправильном формате). Кроме того, usecase может включать дополнительные ссылки на внешние документы, такие как рекомендации по безопасности.

Ответ 6

Я согласен с большинством ответов на этой странице, особенно с Эли, но я все же думаю, что стоит завершить эту идею.

Итак, пример использования - это UserStory, состоящий из, вероятно, набора взаимосвязанных пользовательских историй, который доставляет бизнес-ценность пользователю.

Позвольте мне пояснить себе: ключевое различие - это "соответствующая деловая выгода". результат.

Например, пример использования ATM-ATM может быть "пользователь использует ATM для получения наличных". Существует пользователь, система и четкий прецедент с результатами. Теперь, если мы разрабатываем банкомат в гибкой команде, у нас, вероятно, будет рассказ "пользователи подключаются к банкомату". Таким образом, пользовательская история может быть "интересным" тестируемым и соответствующим набором действий, которые пользователь выполняет при взаимодействии с системой, но без четкого результата. Никто не "подключается" к системе просто для удовольствия. В этом нет пользы. В диаграмме вариантов использования UML, возможно, мы все еще используем для этого... возможно, используя отношение "включить"... но я думаю, что это будет грохотать диаграмму использования. Итак, как говорит Эли, прецедент - это история пользователя с результатом, с целью. И, таким образом, вы хотите быть "Use Case Driven", а не "User Story". Потому что, возможно, лучший способ реализовать пользовательскую историю без результата - удалить ее из вашей системы:). Если банкомат может посмотреть на мое лицо и включить меня без ввода пароля, который может быть велик.

Ответ 7

User Stories - это инструмент, который используется в Agile-разработке, чтобы убедиться, что вы создаете продукт, в котором действительно нуждается ваш пользователь.

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

В отличие от США вариант использования ориентирован на использование вашего продукта ВОЗ. Здесь есть разница.

Я бы сказал, что для Agile-разработчика нет другого такого инструмента, как User Stories. Если вы хотите научиться писать их успешно, прочитайте этот пост.