Используются ли только несколько историй пользователей?
В чем преимущества использования пользовательских историй в случаях использования... и наоборот... Когда использовать один над другим... Все ли гибкие методологии используют истории пользователей?
На самом деле, оригинальные сценарии использования (см. Jacobson OOSE) были довольно легкими, как и пользовательские истории. Со временем они развивались до тех пор, пока общий формат "вариантов использования" теперь не стал сложным документом с входными данными, выходными данными, наследованием, использованием отношений, псевдокодом и т.д. Программисты, как правило, пытаются преобразовать все в программирование.
В любом случае, попытка определить, что отличает "вариант использования" от "пользовательской истории" от "сценария", довольно тщетна, так как трудно найти двух авторитетных экспертов, которые согласны.
Лично я считаю, что шаблон "[Actor] [глаголы] [существительное], чтобы получить [ценность для бизнеса]" полезен. Если он перебирает абзац текста, он может быть слишком большим.
Когда дело доходит до этого, "гибкий" - это всего лишь ярлык, и люди не согласны с тем, что именно это означает. Точно так же люди называют очень разные вещи "прецедентами".
В моем опыте основное различие между ними состоит в том, что пользовательская история ориентирована на пользователя и обычно короче и менее формальна - в идеале она должна легко помещаться на открытке. Вероятно, он не содержит подробных сведений об обработке ошибок и т.д.
Случаи использования могут быть гораздо более формальными (хотя некоторые люди также пишут их неформально) - они сосредоточены на каждом взаимодействии с системой и могут подробно рассказать о нескольких разных системах/актерах/и т.д. в одном и том же варианте использования.
Вот только мой опыт - все шансы, что все будут использовать эти инструменты по-разному. Я не стал бы слишком болтаться над ярлыками - просто используйте то, что работает для вашего проекта.
Случаи использования не являются сборниками пользовательских историй.
Истории пользователей обычно намного проще, чем варианты использования. Я думаю, что случайные случаи пытаются охватить абсолютно все, что связано с поведением какого-либо аспекта системы. То есть все поведение, все пути ошибок и вся обработка исключений.
Рекомендуемый шаблон для пользователя:
Как (роль) я хочу (что-то), чтобы (польза)
(Спасибо, Майк Кон, за предоставление этого простого шаблона)
Описания поведения, выраженные таким образом, более гибкие.
Этот шаблон позволяет описывать поведение с использованием разных уровней детализации. Например:
ИМХО. Случаи из камня гораздо больше вырезаны! И, следовательно, может быть проблемой для обновления после начальной версии.
НТН
веселит,
Rob
Одним словом, нет.
Случаи использования обычно представляют собой подробные спецификации, описывающие, как будет работать определенная часть функциональности, или как конкретный пользователь будет использовать систему. Обычно это голос определенного пользователя (или актера) и довольно автономный.
С другой стороны, история пользователей - это "приглашение для обсуждения". Обычно это одно или два предложения. Здесь - один из хороших ресурсов для этого. И Майк Кон Пользовательские истории, которые были применены, стоит того.
Типичный синтаксис: "Как < пользователь > мне нужно < функциональность > для достижения < бизнес-значение > " или "Для достижения < бизнес-значение > как < пользователь > мне нужны < функциональность > " который приводит домой значение истории.
Истории пользователей не предназначены для самостоятельной работы, но предназначены для обсуждения истории между разработчиком и клиентом (или прокси-сервером).
Вы можете думать о usecase как истории пользователя, но не наоборот. Усекаса будет охватывать несколько "концов" истории, особые требования (например, поля формы должны вводиться в формате xyz и показывать сообщение об ошибке 123, если пользователь вводит поле в неправильном формате). Кроме того, usecase может включать дополнительные ссылки на внешние документы, такие как рекомендации по безопасности.
Я согласен с большинством ответов на этой странице, особенно с Эли, но я все же думаю, что стоит завершить эту идею.
Итак, пример использования - это UserStory, состоящий из, вероятно, набора взаимосвязанных пользовательских историй, который доставляет бизнес-ценность пользователю.
Позвольте мне пояснить себе: ключевое различие - это "соответствующая деловая выгода". результат.
Например, пример использования ATM-ATM может быть "пользователь использует ATM для получения наличных". Существует пользователь, система и четкий прецедент с результатами. Теперь, если мы разрабатываем банкомат в гибкой команде, у нас, вероятно, будет рассказ "пользователи подключаются к банкомату". Таким образом, пользовательская история может быть "интересным" тестируемым и соответствующим набором действий, которые пользователь выполняет при взаимодействии с системой, но без четкого результата. Никто не "подключается" к системе просто для удовольствия. В этом нет пользы. В диаграмме вариантов использования UML, возможно, мы все еще используем для этого... возможно, используя отношение "включить"... но я думаю, что это будет грохотать диаграмму использования. Итак, как говорит Эли, прецедент - это история пользователя с результатом, с целью. И, таким образом, вы хотите быть "Use Case Driven", а не "User Story". Потому что, возможно, лучший способ реализовать пользовательскую историю без результата - удалить ее из вашей системы:). Если банкомат может посмотреть на мое лицо и включить меня без ввода пароля, который может быть велик.
User Stories - это инструмент, который используется в Agile-разработке, чтобы убедиться, что вы создаете продукт, в котором действительно нуждается ваш пользователь.
В отличие от США вариант использования ориентирован на использование вашего продукта ВОЗ. Здесь есть разница.
Я бы сказал, что для Agile-разработчика нет другого такого инструмента, как User Stories. Если вы хотите научиться писать их успешно, прочитайте этот пост.