Совместим ли пользовательский сценарий с использованием случая?

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

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

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

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

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

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

Теперь некоторые люди ставят знак равенства между пользовательским сценарием и случаем использования:

• Агил = пользовательский сценарий или Агил = пользовательский сценарий + Скрам
• Пользовательский сценарий = достаточно и вовремя
• Пользовательский сценарий = удовлетворение ожиданий пользователя и удовлетворительность
• Случай использования = сбор детальных требований заранее
• Случай использования = <<включает>> + <<расширяет>> = функциональная декомпозиция
• Случай использования — только стиль «ввод пользователя» → «ответ системы»
• Случай использования = старомодный и устаревший

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

• Обнаружение требований, а не их доставка
• В соответствии с вышеуказанным принципом возникают два важных свойства в процессе агил-разработки
  • Вовремя
  • Достаточно

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

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

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

Пример

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

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

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

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

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

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

Позвольте мне немного подробнее объяснить, как разрабатывать часть подтверждения пользовательской истории. Здесь мы используем наиболее известный шаблон, называемый Gherkin, который использует формулу Given-When-Then для руководства написанием тестов приемки для пользовательской истории:

• (Дано.. и) некоторый контекст
• (Когда.. и) выполняется некоторое действие
• (Тогда.. и) выполнить некоторые действия

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

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

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

Семантически эквивалентны, но с разным смыслом?

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

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

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

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

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