Погуглив в Интернете, Agile Sages считает, что варианты использования и пользовательские истории — это две разные вещи:

• Майк Кон:  Пользовательские истории — это не варианты использования
• Алистер Кокберн:  Пользовательская история относится к варианту использования, как газель к беседке
• Extreme Programming.org:  Пользовательские истории служат той же цели, что и варианты использования, но это не одно и то же.

Подход, основанный на прецедентах, был одним из самых горячих методов для сбора требований, и некоторые люди теперь считают, что это своего рода устаревший метод старого стиля, который связан с множеством проблем, из-за которых ваша команда НЕ «Гибкая» из-за проблем прецедентов. :

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

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

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

Теперь некоторые люди ставят знак равенства, относящийся к пользовательской истории и пользовательскому кейсу:

• Agile = пользовательская история или Agile = пользовательская история + Scrum
• Пользовательская история = достаточно и точно в срок
• Пользовательская история = удовлетворение ожиданий пользователя и удовлетворение
• Сценарий использования = Предварительный сбор подробной информации о требованиях
• Вариант использования = <<include>> + <<extends>> = функциональная декомпозиция
• Вариант использования: «пользовательский ввод» -> только стиль «ответ системы».
• Вариант использования = старый стиль и устаревший

Как поставщик инструментов, мы довольно нейтрально относимся к методам, инструментам и технологиям. Лично я хочу подчеркнуть, что я большой поклонник Agile-разработки, пользовательской истории и процесса Scrum. В частности, основные принципы и передовой опыт касаются таких концепций, как:

 

• Обнаружение требований вместо их доставки
• В соответствии с изложенным выше принципом это дает два важных свойства в процессе разработки Agile.
  • Как раз вовремя
  • Достаточно

(Я напишу больше постов, связанных с приведенными выше принципами, с моими собственными мнениями, которые тесно связаны с областью моих исследований доктора философии в 1992-1995 годах – преобразованиями метамодели и схемы)

Теперь вернемся к темам «вариант использования против пользовательской истории». Что ж, тяжелые Agile Sages уже проголосовали за это, неужели я так упрямо пытаюсь опровергнуть их «голоса», утверждая, что они похожи или даже одинаковы?

Позвольте мне показать вам пример, чтобы проиллюстрировать, настолько ли история пользователя «отличается» от случая пользователя:

Пример

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

Первая буква «C» каждой пользовательской истории должна соответствовать стандартному формату:

Как [роль] я хочу [что-то сделать], чтобы [выгода]

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

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

Последняя «C» пользовательской истории — это подтверждение, которое является критерием приемлемости, используемым для подтверждения того, что пользовательская история реализована, исправлена ​​и успешно доставлена.

Позвольте мне немного подробнее рассказать о том, как разработать подтверждающую часть пользовательской истории. Здесь мы используем самый известный шаблон под названием Gherkin, который использует формулу «Дано-когда-тогда» для руководства по написанию приемочных тестов для пользовательской истории:

• (Учитывая.. и) некоторый контекст
• (Когда.. и) выполняется какое-то действие
• (Затем.. и) Выполните некоторые действия

Такие инструменты, как среды тестирования Cucumber и Jbehave, поощряют использование шаблона Given/When/Then для проведения автоматизированного тестирования, хотя его также можно использовать исключительно в качестве эвристического, независимо от того, будет ли использоваться инструмент.

Соберем всю информацию для пользовательской истории «зарегистрироваться на курс» и оформим ее в формате 3Cs:

Я принял широко используемый формат 3 Cs для представления пользовательской истории «регистрация курса». Точно так же я также принял наиболее широко используемый формат для описания того же варианта использования «регистрация курса», который разработан в описании варианта использования. Я пронумеровал шаги раздела подтверждения (последний C) пользовательской истории, который связан с номером шага, который я указал в описании варианта использования. Это одни и те же «девятиступенчатые» сценарии, которые нужно прокладывать в каждом из подходов в разном порядке. Я считаю, что обе модели представления приемлемы для соответствующих им мудрецов и последователей. Затем снова вопрос: история пользователя очень похожа на случай пользователя, но все же они разные, или порядок шагов вызывает всевозможную критику подхода к варианту использования?

Семантически эквивалентен с другим значением?

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

Пример: семантически эквивалентен

В UML мы можем описать сценарий использования с помощью диаграммы последовательности, но обычно мы не используем диаграмму сотрудничества для той же цели; даже через обе диаграммы семантически эквивалентны. Другими словами, и диаграмма последовательности, и диаграмма взаимодействия имеют одинаковое количество объектов, участвующих в сценарии, с одинаковым количеством сообщений, передаваемых по одному и тому же набору объектов для выполнения задачи сценария. Однако первое — это фокус времени, а второй — фокус пространства. Диаграмма последовательности более интуитивно понятна при моделировании сценариев, тогда как диаграмма сотрудничества подходит для моделирования структурных взаимосвязей между объектами. т.е. вы хотите структурно представить сценарий участвующего объекта в структуре MVC (уровни модели/представления и управления).

Лично я не думаю, что использование пользовательской истории сделает мою команду более гибкой, а вариант использования заставит мою команду быть «авансом». Наиболее важно то, как мы применяем и используем эти инструменты, с каким мышлением и лучшими практиками. Я не слишком беспокоюсь о том, что люди считают меня «старомодным» или устаревшим, когда я действительно веду себя подвижно.

Я до сих пор вспоминаю времена структурированного анализа и проектирования, возможно, мы могли бы использовать абстрактный тип данных в ADA для применения принципов объектно-ориентированного анализа и проектирования без поддержки ООП в 198x, верно? К сожалению, вы можете вообще не сталкиваться с понятиями абстрактного типа данных! Ой! Боже мой, я случайно раскрываю – я стар? Или, я должен думать положительное – опытный?

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