User story use case в чем разница
Разница между User Stories, Use Cases и Scenarios
Прежде, чем отвечать, нужно сделать паузу и признать, что в сегодняшней терминологии есть некоторая путаница — под Сториз, Сценариями или Юзкейсами могут понимать разные инструменты.
Авторы культовой Designing Interactive Systems — People, Activities, Contexts, Technologies выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории (сториз), концептуальные сценарии, конкретные сценарии и варианты использования (юзкейсы).
Важно заметить, что есть еще Эджайловские Юзер сториз товарища Паттона, что описываются по шаблону As a <>, I want <> so that <> и находятся где-то между Concrete Scenario и Use case.
Зависимость содержания деталей
Сториз, они про потребность пользователя. Raw user needs.
Юзкейсы же про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности. What the software needs to do.
Сториз пишутся человеческим языком = легко читаются и бизнесом и разработчиками. Express understanding of User needs.
Написание Юзкейсов это designing a functional solution.
Разберемся на примерах
User story
Стартуем с самого масштабного уровня, уделяем внимание контексту и всем поведенческим особенностям. Рассказ ведется не от лица абстрактного пользователя, и даже не от лица персонажа, а от лица реального человека (либо от лица того, кто ведет наблюдение/проводит интервью).
Выиграли билеты на концерт Radiohead в Риме, сборы проходили в последний момент, нанервничались и чуть не поругались 🙂 Решили, лететь налегке.
Когда поехали в аэропорт, то очень торопились и решили не заезжать на заправку, чтобы сэкономить время. В тот момент нам казалось, что бензина достаточно и хватит добраться до аэропорта, но в наши планы вмешались непредвиденные обстоятельства.
Вообщем встряли в пробку и, спустя некоторое время, загорелась лампочка низкого уровня топлива. Пришлось спешно искать заправки поблизости. Как назло, нашу машину можно заправлять только 98-ым бензином, что только добавило накала страстей.
По итогу, нам повезло — заправку нашли, в аэропорт успели, но пришлось сильно поволноваться. Благо Том Йорк сгладил впечатления о поездке, да и Рим крут.
Conceptual scenario
Снижаем планку контекста и движемся к конкретике за счет абстрагирования. Conceptual scenario важны для генерации идей и поиска ответа на вопрос «Как улучшить существующий опыт?».
Алан Купер рекомендует представить, что интерфейс волшебный и в нем можно реализовать всё, что угодно, чтобы выйти за рамки привычного.
Люди в стрессовых ситуациях нуждаются в дополнительном внимании и заботе. В процессе ввода в навигатор конечного адреса маршрута можно определять расстояние до финиша, проверять текущий уровень топлива с учетом актуального среднего расхода и определять, хватит ли нам топлива добраться до заданной точки. Если нет, оповещать об этом водителя.
Если же лампочка низкого уровня топлива уже загорелась, то показывать в навигаторе ближайшие заправки (с возможностью сортировки голосовыми командами, например по октановому числу).
Concrete scenario
Concrete scenarios пополняются деталями реализации и используются для проектирования, в них появляются технические подробности. Пишутся они от лица конкретного персонажа, дабы проявить эмпатию.
Когда Сергей вводит адрес в навигатор, то он хочет быть уверенным, что ему хватит топлива доехать до указанной точки. Если нет, то автомобиль предупредит об этом Сергея.
Если в момент движения, Сергей отклонится от маршрута и поедет другим путем (или будет ехать очень быстро), то с включением лампочки низкого уровня топлива, он увидит на карте навигатора ближайшие заправки и сможет выбрать подходящую по особенностям топлива.
Во время движения соединение с интернетом может прерываться.
Agile User story
Примерно на этом уровне находятся и Эджайловские Юзер стори.
Я, как водитель, в момент включения лампочки низкого уровня топлива, хочу заправить свою машину на ближайшей заправке.
Use case
Далее уже можно написать Юзкейсы, описывающие все взаимодействия системы с пользователем. Пишутся они от лица абстрактных пользовательских ролей.
Из всех видов сценариев Юзкейс — наиболее технический и напоминающий алгоритм, а не историю.
Я, как пользователь-водитель (с включенной лампочкой низкого уровня топлива) смогу:
У Юзкейсов есть свой стандартизированный шаблон:
Потом собираете вместе ваши Сценарии, Сториз и Юзкейсы в один документ, рисуете Флоу и получаете полное описание каждого взаимодействия между пользователем и продуктом, которое вы планируете создать.
Когда и что использовать?
Все виды сценариев придуманы в угоду определения требований: что система должна делать в принципе и как она должна вести себя для того, чтобы удовлетворить запросы пользователей.
Конечно это требует дополнительных усилий и времени, поэтому на простых информационных продуктах можно пожертвовать сценариями, а без вариантов использования можно обойтись там, где взаимодействие достаточно прямолинейно, отсутствуют альтернативные и исключительные сценарии (или их проще и быстрее продемонстрировать в прототипе).
Но чем сложнее взаимодействие, тем желательнее начинать с контекста и поведенческих особенностей, двигаясь к конкретике по решениям. Иначе, есть риск вложить 80% усилий в 20% сценариев, с которыми пользователи будут работать мало и редко, а внимание дизайнера будет размазано по всем возможным сценариям, что снизит их качество.
WEBURSITET.RU
Онлайн-курсы профессиональной разработки ПО
Сравнение методов разработки пользовательских требований
Текстовая расшифровка одного из уроков курса Введение в профессию аналитика.
Мы с вами познакомились с несколькими методами разработки пользовательских требований. На самом деле, методов было два: это Use cases (юзкейсы) и User stories. И плюс дополнительный метод — наверное, не столько разработки, сколько выявления пользовательских требований: персонажи. он называется Personas, а на русский язык его обычно переводят как «персоны» или «персонажи».
У нас была сравнительная табличка, когда мы сравнивали ролевые модели методов Use cases и User stories. Я здесь добавил ещё одну табличку. Иногда возникает вопрос: какой метод лучше применим в нашем проекте, каким из них воспользоваться? Для того, чтобы эту оценку правильно сделать, нужно сравнить их достоинства и недостатки. Мы о них говорили достаточно много в процессе курса, начиная с самых первых вебинаров, и более детально, когда мы изучали эти методы. Здесь, на этой табличке, подведен итог.
Если сравнивать юзкейсы и user stories, то, первое и, наверное, самое существенное отличие состоит в том, что метод юзкейсов требует достаточно долгой фазы предварительного анализа для проработки целей, которые мы будем автоматизировать, и разработки сценариев. То есть он приближает нас в к водопаду. Конечно, их тоже можно разрабатывать итерационно, но, тем не менее, в каждой итерации нужна отдельная большая работа аналитиков для того, чтобы эти юзкейсы для очередной итерации подготовить. Поэтому в тех местах, где используются юзкейсы как метод, итерации довольно длинные. От одного месяца до максимум трёх месяцев (если итерация длится больше 3 месяцев, то уже само понятие итерации утрачивает свой смысл). Но это не недельные или двухнедельные спринты, как в Agile. Это связано с тем, что здесь требуется более глубокий и детальный анализ.
Отличие user stories в том, что, как правило, этот формат можно применять практически сразу. Не погружаясь в детализацию, потому что сам формат предполагает, что он будут использоваться для дальнейшего обсуждения. То есть мы сначала user story формулируем достаточно коротко, обсуждаем с заказчиком, и затем в команде обсуждаем детальную реализацию. И поэтому он такой, более лёгкий, более быстро его можно использовать в коротких итерациях, чем, собственно, практически все и пользуются.
Различия в модели требований, о которой мы тоже говорили с самого начала. Юзкейсы предполагают, что мы создаём практически полное описание нашего продукта в терминах юзкейсов, за исключением, может быть, его нефункциональных аспектов, которые не описываются сценариями. А user stories — это постоянно меняющаяся модель продукта. То есть мы каждый раз сосредотачиваемся именно на том, что нужно сделать в данный момент.
По поводу хороших требований. Мы, опять же, в начале курса говорили, что для user stories разработан фактически свой способ оценки качества историй: INVEST. А для юзкейсов применяется другой метод, больше похожий на те, что изначально было сформулированы для требований при их разработке в виде спецификации. Главное отличие — это полнота требований. Не буду повторяться, я просто подвожу итог: критерии качества для юзкейсов и user stories различаются, и я надеюсь, что у вас уже сложилось представление о том, почему это так, и почему не нужно набор критериев качества одного метода применять к другому.
И очень важное различие, которое иногда неочевидно для аналитиков, состоит в том, что при разработке юзкейсов большую часть работы выполняют те, кто разрабатывают сценарии, и эти юзкейсы потом можно как полную модель продукта передавать в команду, чтобы они их программировали. В случае с user story формат сам по себе — это только повод для обсуждения, и самые важные решения о реализации, о том, как эти user stories правильно реализовать в продукте, принимает команда разработки. Это её неотъемлемое право, и ей нельзя навязать определенные методы.
Глядя на этот список, может быть, вы теперь более чётко представляете, в какой ситуации какой метод применим. По итогам курса это представление должно у вас уже окончательно сложиться: для каких ситуаций какие методы лучше подходят.
Что в этой книге предлагается? Как адаптировать метод юзкейсов для разработки в коротких итерациях, которыми, в первую очередь, и отличается Agile. Я несколько картинок просто приведу, потому что в двух словах объяснить это довольно просто. Ну, а если придётся применять это на практике, тогда, собственно, вот в этой книге и написано, как это лучше сделать. Сам Айвар Якобсон периодически проводит вебинары, на которых объясняет разные нюансы и суть этого метода.
Я много слышал от разных тренеров об этом методе, потому что он такой, концептуально красивый. Но, честно говоря, пока не видел людей, которые применяют его на практике. Но, может быть, вам повезёт его применять.
Вот ещё одна табличка. Эта табличка у нас в курсе уже была, но я добавил в неё третью колонку. Здесь подытожено различие ролевых моделей при использовании юзкейсов, user stories и метода персонажей.
В случае с user stories, которые появились, в первую очередь, в ответ на вызов со стороны интернета в связи с появлением массовых пользователей, роли выделяются по другим признакам. Мы анализируем некоторый набор целей пользователей по отношению к нашему продукту (это то, чем мы занимались при разработке концепции) и разбиваем их, например, по интересам, по ожиданиям от продукта, по частое использования и по уровню подготовки, и у нас появляются такие кластеры пользователей, которые мы можем использовать как роли в user stories.
Это такой подход, который вполне могут использовать аналитики или, в случае Agile, вся команда, выявляя свои представления о том, кто будет пользователем продукта, и фиксируя эти представления в виде такого набора ролей. При этом одна роль представляет группу пользователей. Роль в user story — это не участник процесса, а модель типичного пользователя нашей системы, при том что эти типичные пользователи разбиты на группы.
По поводу персон можно сказать, что это дальнейшее развитие метода user stories. Главная особенность или отличие в том, что персонажи появляются по результатам достаточно серьёзных исследований. Это, конечно, оправданно только в случае, если чёткое выделение этих персон даёт вам понятную выгоду при создании вашего продукта. Алан Купер постоянно говорит: если вы придумали персон без исследования, то это, скорее всего, будут стереотипы пользователей, что больше похоже на предыдущий вариант ролей в user stories.
Одна персона представляет собой не группу пользователей, а так называемый архетип, то есть характерного представителя, и фактически моделирует при этом конкретную личность. Для этого и дают персонам имена и фотографии: для того, чтобы команда не просто использовала абстрактного мёртвого человечка, как часто называют картинки на диаграмме вариантов использования, а представляла себе конкретную личность, проникалась к ней эмпатией и сочувствием. И тогда появляется возможность оценивать с точки зрения этой личности те сценарии, которые мы для неё реализуем.
За последнее время множество раз столкнулся с непонимаем того, что же общего между сториз и юзкейсами, а чем они всё-таки отличаются? Что есть пользовательские сценарии и причем тут Эджайл?
Прежде, чем отвечать, нужно сделать паузу и признать, что в сегодняшней терминологии есть некоторая путаница — под Сториз, Сценариями или Юзкейсами могут понимать разные инструменты.
Авторы культовой Designing Interactive Systems — People, Activities, Contexts, Technologies выделяют 4 вида сценариев в зависимости от этапа проекта и целей их создания: пользовательские истории (сториз), концептуальные сценарии, конкретные сценарии и варианты использования (юзкейсы).
Важно заметить, что есть еще Эджайловские Юзер сториз товарища Паттона, что описываются по шаблону As a <>, I want <> so that <> и находятся где-то между Concrete Scenario и Use case.
Сториз, они про потребность пользователя из его повседневной жизни. Если вы никогда не создадите для него программное обеспечение, эта потребность все равно будет существовать. Raw user needs.
Юзкейсы же описывают поведение, которое вы встроите в ПО, чтобы удовлетворить эти потребности. What the software needs to do.
Сториз пишутся человеческим языком = легко читаются и бизнесом
и разработчиками. Express understanding of User needs.
Юзкейсы = пошаговые алгоритмы. Designing a functional solution.
Разберемся на примерах
User story
Стартуем с самого масштабного уровня, уделяем внимание контексту и всем поведенческим особенностям. Рассказ ведется не от лица абстрактного пользователя, и даже не от лица персонажа, а от лица реального человека (либо от лица того, кто ведет наблюдение/проводит интервью).
Выиграли билеты на концерт Radiohead в Риме, сборы проходили в последний момент, нанервничались и чуть не поругались 🙂 Решили, лететь налегке.
Когда поехали в аэропорт, то очень торопились и решили не заезжать на заправку, чтобы сэкономить время. В тот момент нам казалось, что бензина достаточно и хватит добраться до аэропорта, но в наши планы вмешались непредвиденные обстоятельства.
Вообщем встряли в пробку и, спустя некоторое время, загорелась лампочка низкого уровня топлива. Пришлось спешно искать заправки поблизости. Как назло, нашу машину можно заправлять только 98-ым бензином, что только добавило накала страстей.
По итогу, нам повезло — заправку нашли, в аэропорт успели, но пришлось сильно поволноваться. Благо Том Йорк сгладил впечатления о поездке, да и Рим крут.
Conceptual scenario
Снижаем планку контекста и движемся к конкретике за счет абстрагирования. Conceptual scenario важны для генерации идей и поиска ответа на вопрос «Как улучшить существующий опыт?».
Алан Купер рекомендует представить, что интерфейс волшебный и в нем можно реализовать всё, что угодно, чтобы выйти за рамки привычного.
Люди в стрессовых ситуациях нуждаются в дополнительном внимании и заботе. В процессе ввода в навигатор конечного адреса маршрута можно определять расстояние до финиша, проверять текущий уровень топлива с учетом актуального среднего расхода и определять, хватит ли нам топлива добраться до заданной точки. Если нет, оповещать об этом водителя.
Если же лампочка низкого уровня топлива уже загорелась, то показывать в навигаторе ближайшие заправки (с возможностью сортировки голосовыми командами, например по октановому числу).
Concrete scenario
Concrete scenarios пополняются деталями реализации и используются для проектирования, в них появляются технические подробности. Пишутся они от лица конкретного персонажа, дабы проявить эмпатию.
Когда Сергей вводит адрес в навигатор, то он хочет быть уверенным, что ему хватит топлива доехать до указанной точки. Если нет, то автомобиль предупредит об этом Сергея.
Если в момент движения, Сергей отклонится от маршрута и поедет другим путем (или будет ехать очень быстро), то с включением лампочки низкого уровня топлива, он увидит на карте навигатора ближайшие заправки и сможет выбрать подходящую по особенностям топлива.
Во время движения соединение с интернетом может прерываться.
Agile User story
Примерно на этом уровне находятся и Эджайловские Юзер стори.
Я, как водитель, в момент включения лампочки низкого уровня топлива, хочу заправить свою машину на ближайшей заправке.
Use case
Далее уже можно написать Юзкейсы, описывающие все взаимодействия системы с пользователем. Пишутся они от лица абстрактных пользовательских ролей.
Из всех видов сценариев Юзкейс— наиболее технический и напоминающий алгоритм, а не историю.
Я, как пользователь-водитель (с включенной лампочкой низкого уровня топлива) смогу:
— посмотреть все ближайшие заправки на карте
— посмотреть все ближайшие заправки списком
— выбрать заправки нужного бренда
— посмотреть на выбранной заправке наличие нужного топлива
— построить до выбранной заправки маршрут
У Юзкейсов есть свой стандартизированный шаблон.
User story use case в чем разница
Сравнение типов требований: пользовательские истории
Пользовательские истории отличаются от вариантов использования и традиционных системных требований более повествовательным характером. Они предназначены для описания пожеланий пользователя в плане его возможностей. Кроме того, пользовательские истории фокусируют свое внимание скорее на ценности, полученной от использования системы, чем на детализированной спецификации ее возможностей. Пользовательские истории часто называют метафорой для работы, выполняемой системой. Целью является фиксация как можно большего количества информации с тем, чтобы Agile команда смогла оценить пользовательскую историю и достаточно в ней разобраться для того, чтобы подготовить черновой дизайн проекта. Детали истории коллективно разрабатываются в процессе общения, поэтому сама пользовательская история становится залогом продолжения общения в течение всего проекта. Пользовательские истории служат инструментом, стимулирующим общение.
Хотя сами по себе пользовательские истории не относятся к Agile сфере, они все же акцентируют внимание на коллективной работе, что усложняет использование пользовательских историй в не-Agile проектах. Я видел команды, которые, испытывая определенные проблемы в разработке по Agile, в конечном итоге пришли к применению пользовательских историй, напоминающих высоко детализированные традиционные требования. Чрезмерная спецификация может привести к ряду итераций, которые трансформируются в мини водопады на каждой стадии (осуществление анализа, разработка дизайна, написание кода и проведение тестирования), превращаясь в своеобразное упражнение по записыванию огромного количества деталей. Это противоречит принципу Agile Манифеста, а именно что “самым работоспособным и эффективным методом передачи информации команде разработчиков и внутри нее является личное общение”.
Подводя итоги по существующим различиям можно отметить, что: традиционные требования фокусируют свое внимание на вариантах эксплуатации системы, склоняясь к детализированной спецификации системы; варианты использования фокусируют свое внимание на взаимодействии между пользователем и системой, опять-таки склоняясь к детализированной спецификации; а пользовательские истории фокусируются на ценности клиента со встроенной неопределенностью, нацеленной на стимулирование общения.
Примеры пользовательских историй
Поиск кандидатов по должности, специализации и географической локации.
Являясь пользователем, выполняющим поиск кандидатов, я нуждаюсь в возможности поиска кандидатов по специализации с тем, чтобы я смог более эффективно направлять пациентов к специалистам.
Механизм поиска кандидатов имеет возможность ввода должности.
Механизм поиска кандидатов имеет возможность ввода специализации.
Поиск специализации будет иметь перечень специализаций кандидата, в рамках которого будет выполняться выбор.
При осуществлении поиска по специализации кандидата, будет возобновлен перечень соответствующих специализаций, или появится сообщение, информирующее об отсутствии найденных соответствий.
Если количество найденных соответствий превышает количество, доступное для отображения на одной странице, система предоставит возможность просмотра списка на нескольких страницах или секциях.
Выводы
Имеют ли пользовательские истории преимущества перед другими видами спецификации требований? Все зависит от ситуации, но в среде коллективного взаимодействия, мой опыт подсказывает мне положительный ответ на этот вопрос.
Пользовательские истории не сделают ваш проект Agile проектом, а их отсутствие вызовет определенные сложности при его трансформации в Agile проект. Тем не менее, пользовательские истории мотивируют определенное количество принципов из Agile Манифеста:
Если у вас есть определенная не-Agile среда разработки, помогут ли вам пользовательские истории? Опять-таки, это зависит от команды. Если команда уже вовлечена в водопадный или сложный итеративный тип процесса и использует подход “заблаговременного планирования больших требований”, то такая команда, скорее всего, сама повлияет на пользовательские истории и превратит их в традиционные требования. Пользовательские истории несколько расплывчаты и поддаются последующему уточнению; заблаговременное планирование и создание дизайна отнюдь не относится к их сильной стороне. Детализированная спецификация часто практикуется в управляемой среде тяжелых процессов перед началом написания программного кода с тем, чтобы требования можно было использовать для планирования бюджета и всего проекта. В связи с этим требования становятся источником записи для системы с достаточно ограниченным пространством для коллективного сотрудничества.
Пользовательские истории (при правильном использовании экспертами, такими как Коен и Коберн) просто имеют слишком свободный формат, чтобы подвергнуться полному документированию. С другой стороны, если команда открыта для коллективного сотрудничества с аналитиками и владельцами бизнеса, а спонсоры проекта согласятся с изменением, пользовательские истории смогут помочь коллективному сотрудничеству.
swpm
swpmOriginally published at Software Product Management. Please leave any comments there.
Перевод статьи из блога tynerblain.com (Scott Sehlhorst).
User Stories – один из ключевых Agile артефактов, который позволяет командам разработчиков создавать наиболее важные возможности системы в первую очередь. Они отличаются от Use Cases по ряду значительных причин, но у них есть гораздо больше общего, чем вы можете подумать.
User Stories на практике
Майк Кон написал книгу User Stories Applied: For Agile Software Development. Это книга о том, как писать, оценивать и использовать User Stories. Если вы думаете о том, чтобы попробовать Agile в первый раз и не читали эту книгу, то вам необходимо это сделать. Автор очень подробно и с забавными историями рассказывает о том, как писать, управлять и использовать User Stories.
Что такое User Stories?
User Story – это пользовательско-ориентированное описание целей, которые люди смогут достичь, используя ваш продукт. User Stories применимы всегда, когда есть человек, взаимодействующий с интерфейсом продукта для достижения цели. Они применимы не только к программному обеспечению, хотя характер данной статьи предполагает это (в силу того, что я живу в мире программного обеспечения большую часть времени).
User Story пишется в формате
Вот и все. Ничего больше. Совершенно атомизированно, очень кратко и недвусмысленно. Откуда эта элегантная идея появилась?
User-Centered Design (UCD, пользовательско-ориентированный дизайн) – это подход к дизайну продуктов, который также может рассматриваться как философия. В колледже у меня была привычка говорить, что индустриальные дизайнеры проектируют вещи «снаружи внутрь» (from the outside in), а инженеры проектируют вещи «изнутри наружу» (from the inside out). Идеальные продукты – это такие продукты, в которых соединены форма (то, что снаружи) и функции (то, что внутри) в виде элегантного решения, в котором размывается разделяющая форму и функцию граница. Первые дизайнеры инженерных продуктов были инженерами, а первыми дизайнерами программного обеспечения были программисты – только они знали, что может быть сделано. Любой, кто использовал приложение с интерфейсом, созданным специалистам по базам данных, помнит, что оно из себя представляло. В итоге, кто-то успешно адаптировал образ мыслей проектирования продукта, основанный на том, что кто-то может использовать его, чтобы что-то сделать вместо того, чтобы смотреть на то, что оно умеет делать и пытаться понять, как его использовать. Это подчеркивает важность UCD, ну вы поняли идею.
Из подхода UCD следует много выводов, которые реально определяют то, как мы создаем продукты сегодня. Kessler и Sweitzer сфокусировались на понимании этих целей пользователей в книге Outside-In Software Development. Цели стейкхолдеров задают требования (возможно, это и есть требования). Но тяжело создавать практические планы из целей. Вам необходимо что-то, чтобы преодолеть этот разрыв.
User Story в Agile процессе преодолевает этот разрыв. В мире структурированных требований Вигерса, этот разрыв покрывается с помощью Use Cases.
Концептуально User Story преодолевает ту же пропасть, что и Use Case. User Story определяет, что люди должны сделать (например, более быстрое осуществление звонков) для того, чтобы достигнуть целей компании (например, снизить затраты на кол-центр), с определенным подходом к решению (написать программное обеспечение вместо того, чтобы использовать дешевых сотрудников в кол-центре).
Сейчас мы находимся в запутанной ситуации: у нас есть User Srories, Use Case Scenarios и по крайней мере три различных типа Use Cases – формальные и неформальные Use Cases и Use Case Briefs. В чем они отличаются друг от друга и в чем они схожи?
Описание использования системы
Use Cases, Use Case Scenarios и User Stories представляют собой документированное описание того, как продукт будет использован. Они могут быть отображены на одной прямой в зависимости от затрат, необходимых для их создания.
Use Case Scenarios несколько из другого рода. Как и User Story, Use Case Scenario описывает один путь в Use Case с несколькими путями. Но вы не можете (по крайней мере, я никогда не видел, чтобы кто-то делал это) создавать Use Case Scenario без предварительного создания формальных Use Cases. Этот артефакт сочетает слабость формальных Use Cases (высокая документированность) со слабостью User Stories (ограниченный контекст). Они могут быть очень удобны для разработки Test Cases, если ваша команда тестирования не очень хороша в написании Test Cases. Мы не будем рассматривать Use Case Scenarios в дальнейшей дискуссии.
Высокая документированность с соответствующими издержками несет определенное преимущество – возросшую детализированность.
Т.к. User Story описывает один путь в Use Case, при меньшей затратности она включает также и меньше деталей. Это нормально, т.к. Agile ставит коммуникацию выше исчерпывающей документации. Вы попадете в ситуацию неэффективности, когда объем обсуждений (особенно повторяющихся) станет обременительным. Необходимый объем обсуждений задается как функция от количества знаний о предметной области или контекстов, которые уже были выявлены командой разработчиков.
Мне стоит использовать User Stories или Use Cases?
Это зависит от вашей аудитории. Формальные и неформальные Use Cases помимо того, что более затратны в реализации, также предоставляют больше контекста и позволяют вам описать более сложные варианты использования вашего продукта. Некоторые пользователи настолько сложны, что вам необходимо использовать Use Cases для их описания. Некоторые настолько просты, что что-либо сложнее User Story является бесполезной тратой усилий. Интерпретация того, что является сложным, а что простым, тем не менее, не является просто оценкой того, что пользователи хотят делать, она также зависит от уровня владения предметной областью вашей командой разработчиков.
Некоторые команды просто не готовы к восприятию User Stories и Use Case Briefs. Вы должны писать ваши требования для читателей, поэтому вы должны знать, когда у людей возникают проблемы с реализацией решений, основанных на User Stories или Use Case Briefs и предоставить им больше структуры и формализованности. Вы должны адаптироваться к реалиям вашей текущей ситуации и опыта вашей команды.
Вы можете заменить слова «компетентность читателя в предметной области» (Reader Domain Expertise) на слова «уровень доверия к команде», если хотите, и диаграмма будет выглядеть примерно так же. Это другая концепция, которая критична для того, чтобы команда работала эффективно: уровень доверия приравнивается к уровню делегирования.
Если вы доверяете своей команде создать решение, которое будет соответствовать User Story, делегируйте этот «следующий уровень детализации» им. Если вы не доверяете им, тогда не стоит этого делать. Но вы должны. Одно из преимуществ Agile состоит в том, что ваша команда быстро предоставит вам решение и вы сможете дать им обратную связь. Если они не предоставят вам решение, которое было бы отражением потребностей пользователей, предоставьте им обратную связь и они изменят его. Agile процесс фактически основан на этой возможности сохранять эффектинвость «немногословных» артефактов. Кто-то из команды в общих чертах опишет, как будет выглядеть решение и получит обратную связь до начала реализации. Чем больше будет такого взаимодействия, тем более эффективной будет легковесная документация.
Заключение
Не надейтесь на банальное описание User Stories и Use Cases. Понимайте природу различных артефактов. Думайте об их сильных и слабых сторонах. Рассмотрите, как вы взаимодействуете со своей командой. Должны ли вы доверять вашей команде? Доверяете ли вы вашей команде? Определите, что им нужно и дайте им это.