Use case и user story в чем разница

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.

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

Use case и user story в чем разница

Начинающие аналитики постоянно спрашивают «Зачем нам эти варианты использования? Все уже давно пишут истории!» или «А мы должны и истории и сценарии писать? Чем они отличаются? Что более высокоуровнево?»

Я планировала написать свою статью по этой теме, чтобы не объяснять это каждый раз, но тут наткнулась на статью от Лоры, которая достаточно четко выразила главную причину, почему так важно понять оба инструмента. В переводе ее статьи я буду использовать сокращение UC и US, но если вы все еще путаетесь в этих терминах, то вот расшифровка:

(строго говоря, сценарии и варианты использования это не совсем одно и то же, но мы оставим это за рамками статьи)

Пользовательские истории против вариантов использования
User Stories Versus Use Cases

Если ваша команда работает по agile, пишете ли вы истории, сценарии или и то, и другое? Мое мнение (Лора — прим. переводчика), что пока вы не умеете думать сценариями, нужно писать их, чтобы убедиться, что вы имеете полное четкое представление о функциональных требованиях. Даже в agile команде. Вот почему мы продолжаем преподавать Use cases в качестве основного, фундаментального навыка в «Bridging the Gap» (название компании Лоры — при. переводчика).

UC против US — обдумывание против обсуждения

UC используются на протяжении буквально нескольких десятилетий. Если бы я застряла на необитаемом острове и вы заставили бы меня выбрать всего один инструмент аналитика для описания требований, я бы выбрала именно их. UC — это самый первый инструмент, который я узнала; первая техника, которой я научилась; первый способ анализировать и документировать функциональные требования, с которым я познакомилась. Я убеждена, что являюсь сильным аналитиком из-за того фокуса, который получила в начале своей карьеры, и из-за того, сколько UC я написала.

Это вовсе не означает, что я не могу писать пользовательские истории в рамках agile — иногда их даже легче писать, чем UC.

Позвольте мне подробнее рассказать о том, как UC и US работают вместе, и почему я считаю, что UC так важны.

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

В этом процессе, в процессе продумывания и описания вашего UC, вам придется

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

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

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

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

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

Да, будучи старшим аналитиком (написавшем сотни UC, как и я) вам, вероятно, не всегда нужно писать вариант использования. Вы делали это так много раз, что можете думать об этом почти бессознательно.

Когда вы пишете свои пользовательские истории из всего потока функциональности, то все равно думаете о UC, и у вас есть все, что нужно, потому что все это — в вашей голове. Это работает, когда вы делали это в течение некоторого времени, когда вы уверены в своих навыках и когда у вас есть другие способы управления такого рода информацией.

Новоиспеченному аналитику будет трудно сесть и погрузиться в это состояние. Вот почему мы в «Bridging the Gap» до сих пор учим использовать UC; почему я думаю, что это так сильно важно; и почему мы видим, что у люди говорят «о, так вот как мне нужно указать требования к программному обеспечению!». Так я придумываю вопросы, которые даже не знала, что должна задать. Именно так я могу быть уверена, что не пропустила важных требований. Это важно для уверенности и развития навыков начинающего аналитика. Это фокусирует наше внимание на прецедентном мышлении (мышлении юзкейсами — прим. переводчика).

Это вовсе не означает, что пользовательские истории не важны. Я думаю, что сейчас во многих компаниях, если вы работаете с agile-командой разработки, то собираетесь разбить вариант использования на пользовательские истории. Совсем недавно мы переиздали наш курс «Use Cases and Wireframes course», и мы добавили урок о пользовательских историях, чтобы поговорить об этом процессе.

Может быть вы — опытный аналитик, который пишет UC и пользовательские истории, или думает в UC и пишет пользовательские истории. А может, что более вероятно, вы все еще находитесь в более традиционной итеративной среде, которая пока недостаточно гибкая. Возможно вы просто пишете пользовательские истории — которые тоже хороши, пока вы работаете в этом итеративном отзывчивом режиме совместной работы (речь про agile-процесс — прим. переводчика), а не в водопаде, где шаг, еще шаг, затем следующий шаг, и передача, перебрасывание задач туда-сюда (часто это называют пинг-понгом — прим. переводчика). Истории — это отличный способ быть на одной волне с вашей командой (совместное общение, итеративность процесса и уверенность, что все одинаково понимают требования).

Я хотела поделиться своими мыслями о UC и пользовательских историях и услышать ваши мысли. Ниже вы найдете споры по этой теме в рамках профессии аналитика, а также в рамках agile-сообщества. Это очень важная тема. Я думаю, нам нужно говорить об этом, мы должны это понимать — почему мы учим разным техникам, и как все они работают вместе.

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

Итак, я Лора Бранденбург из «Bridging the Gap». Что бы вы ни писали — UC или US — я снимаю перед вами шляпу за то, что вы аналитик. Спасибо, что вы здесь.

Как мы делаем аналитику IT-проектов: прояснение требований

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

Аналитик — своего рода посредник между бизнесом, проектированием и разработкой, который периодически смещается в ту или иную сторону, но при этом удерживает процесс создания продукта в поле здравого смысла. Он обеспечивает коммуникацию между всеми участниками процесса, собирает, проясняет и приоритезирует требования и помогает принять обоснованные решения.

Для того чтобы взаимодействие между клиентом, аналитиком и разработчиками проходило эффективно, мы используем определённый набор артефактов. Важно понимать, что для каждого проекта мы подбираем свой набор, который необходим для исчерпывающего описания данного программного обеспечения. Типы и содержание документов зависит от желаемых результатов, стейкхолдеров и команды. Мы познакомим вас с основными артефактами, чтобы вы понимали, что представляет собой и зачем нужен каждый из них.

Это первый артефакт, который возникает в проекте. Представляет собой текстовый документ, который кратко описывает основную идею проекта. Он на верхнем уровне определяет продукт, который требуется разработать с учётом потребностей заинтересованных сторон.

Проще говоря, в Vision формулируется:

В Vision зафиксированы наиболее существенные требования, ограничения и приемлемые уровни качества.

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

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

Текст каждой формулировки — User Story — должен объяснять роль или действия юзера в системе, его потребность и профит, который он получит после того, как история случится.

Особенности User Stories:

Именно на основании User Stories проводится дальнейший анализ.

Так же как и User Stories описывают, как пользователь должен взаимодействовать с системой, чтобы достичь конкретной цели. В чём же тогда отличие? User Story помогает определить задачу и намерение. А Use Cases не сообщают о задачах и намерениях, они более подробно фиксируют функциональные возможности.

Посмотрим на эти различия на примере гипотетической разработки обычного калькулятора.

Формулировка User Story может быть такой: «Я как пользователь хочу иметь возможность совершать математические операции, чтобы упростить механические расчеты».

А кейсы, соответствующие данной User Story, могут быть такими:

Когда готово верхнеуровневое описание, аналитики переходят к более детальному описанию системы. Здесь выбор инструментов также основывается на особенностях конкретного проекта. Представим, что предполагается сложная система, где много документов, часть системы встраивается в более крупную или множество интеграций. В таком случае мы можем столкнуться с реальными функциональными ограничениями на то, что мы можем сделать за адекватный срок. Например, API, которую нам предоставляет внешняя система, накладывает обязательства на реализацию функционала регистрации пользователя. Это могут быть определённые поля, параметры или условия, которые мы должны включить в запрос. Иногда технические ограничения накладываются и на пользовательский интерфейс. Чтобы разобраться в существующих ограничениях и с их учётом создать удобный функционал, нужно разобраться, какие существуют и какие должны быть реализованы интеграционные сценарии, нарисовать диаграмму компонентов или развертывания.

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

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

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

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

Таким образом, диаграмма компонентов помогает:

В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты.

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

Элементами диаграммы развертывания являются узлы, компоненты и связи между ними. Узел — это некоторый физически существующий элемент системы. В качестве узла могут рассматриваться компьютеры, датчики, принтеры, модемы, цифровые камеры, сканеры и т.д.

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

Карта экранов схематично отображает экраны проекта и связи между ними. Она помогает сохранить целостность интерфейса, структурирует работу, делает её более прозрачной и прогнозируемой.

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

Когда нет интерактивных прототипов, карта экранов позволяет продемонстрировать логику бизнес-процесса.

Мы обычно используем блок-схемы, чтобы описывать процессы. Они полезны, когда требуется:

Ещё с помощью блок-схемы можно показать карту экранов или любую другую диаграмму — например, Use Cases. По сути блок-схема — это диаграмма с уникальной легендой. Она помогает визуально представить систему с определённой точки зрения.

Как писать функциональные требования

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

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

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

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

Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.

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

Функциональные требования: что это такое и зачем они нужны

Для начала давайте разберемся, что такое функциональные требования.

Функциональные требования — это постановка задачи разработчику. Все, что не указано в требованиях, делается на усмотрение разработчика, что часто расходится с представлением продакт-менеджер об ожидаемом результате. Поэтому требования должны содержать ответы на все возможные вопросы по задаче.

Функциональные требования, как правило, состоят из:

User story

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

Как правило используется шаблон:

Существуют различные примеры применения этой методологии. Например, так это работает в Trello:

В Retail Rocket мы создаем User Stories в Google Docs, используя таблицы. Это помогает упростить процесс коммуникации между различными командами, поскольку каждый может оставить комментарии и дать фидбек.

Например, так выглядит задача об отслеживании NPS для интернет-магазина:

Благодаря такой визуализации взаимодействия задача пользователя плавно и логично переходит в задачу для разработчиков. Затем наступает очередь use case’ов.

Use cases

Use cases описывает поведение пользователя по шагам при взаимодействии с разрабатываемым продуктом.

Задача пользователя — это то, что делает пользователь для достижения краткосрочных целей.

Если пользователь решает задачу на разрабатываемой странице несколькими путями, то на каждое решение должен быть написан свой use case. Например, если доступ к затрагиваемому функционалу находится на нескольких страницах, нужно написать отдельный use case на каждый способ перехода пользователя к функционалу.

Рассмотрим на примере нашей недавно выпущенной фичи — Галерее изображений и шрифтов для массовых рассылок.

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

Примеры use case’ов:

Почему функциональные требования так важны

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

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

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

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

Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.

А как вы подходите к постановке задач разработчикам?

Use Cases vs. User Stories: How They Differ and When to Use Them

by Sean Blake, Head of Marketing

The notable quote from Alistair Cockburn, co-author of the Agile Manifesto, reads, “A user story is to a use case as a gazelle is to a gazebo.” This sheds light on the immense differences between use cases vs. user stories for agile teams. They may sound similar in name, but they are very different and often used in completely different industries.

While both use cases and user stories help teams plan work and determine what’s needed to complete work, the format for how they are used is quite different. User stories are simple, short descriptions from the customer’s perspective. They are the beginning of a larger process that describes a customer’s actions as they use or interact with your product. Use cases contain much more context. Creating detailed use cases is a much more in-depth process that’s designed to help teams understand how a user or customer interacts with a system. We’ll dig deeper into both of these processes below.

If you’re in agile software development, chances are you’re more familiar with utilizing user stories. In this post, we’ll dig deeper into use cases vs. user stories differences, including why today’s development teams have migrated towards user stories and why there’s still valid reason for utilizing use cases in the development process.

What’s the difference between use cases vs. user stories?

Use cases vs. user stories: What’s the difference, and how do you decide what’s best for your team and development process?

Use case vs. user story: Past and present

Use cases were the standard for many years, and they were often used in business analysis, systems analysis, software requirements, and iterative development. With the rise of agile, software projects began to favor user stories in place of use cases because they allowed for improved incremental thinking and agility.

What is a use case?

A use case is a description of each of the ways a user may want to interact with a system, a device, or a piece of equipment. They describe how the system design will respond to requests from its end-user, commonly known as an actor. These actors could be human beings or other systems.

Take an online shopping site and a food delivery service, for example. A customer placing an order or checking if a restaurant is open are two different use cases. Or, on the less technical side, consider a toaster. Say someone (the actor) only wants their bagel toasted on one side. Choosing the “bagel” toaster setting is a use case.

Use cases help teams structure all of the different functional requirements and determine the scope of the project — which means they’re full of details.

These details include:

Take the “bagel” setting on a toaster.

What is a user story?

A user story is the who, what, and why of a goal or outcome that the user or customer wants to achieve. It’s the smallest piece of work that can give value back to the customer. It’s written from the point of view of the end user, often on an index card.

Here’s an example of how a user story is typically written: “As a [persona type], I want to [action] so that [benefit].”

A user story is designed to be as simple as possible, sparing the team as well as stakeholders from having to decode a lot of technical lingo. But, that doesn’t mean the process for creating a user story is easy. A lot of information is condensed into a single sentence. And before writing a user story, the team first has to identify and create their user persona and assemble all of the product requirements

Easy Agile co-founder Nick Muldoon describes user story mapping as “a facilitated, curated conversation that brings everyone along for the journey.”

A project or product developed in an agile environment will involve a lot of user stories that are each added to the product backlog. There, they can be arranged and prioritized on a user story map according to the scheduled release or sprint.

Use cases vs. user stories: The case for use cases

While use cases are far less common in agile development, they do have some advantages to consider. After all, the true spirit of agile means questioning your assumptions and trying new methods.

1. Use cases provide a summary and planning skeleton

Use cases provide anyone involved, such as managers, leadership, product owners, developers, or stakeholders, with a summary of what the system will offer. What will the system contribute to the users and the overall business? They provide a planning skeleton to help teams prioritize, estimate timing, and execute actions.

2. Use cases provide context for each requirement

The use case provides enough detail and context to ensure everyone is on the same page. It’s an agreement between team members about what the system will and won’t do.

3. Use cases provide a look ahead at what could slow work

The alternative paths portion of use cases provides an advanced look at what could go wrong. Small bottlenecks can take up a huge amount of time and money, so the sooner you can recognize and address these issues, the better.

4. Use cases provide answers for specific issues and scenarios

Use cases answer the specific questions developers or programmers could have along the way. The use case process ensures all questions about issues or possible scenarios are answered at the outset before these questions begin to bog down work or slow down a team’s progress.

5. Use cases provide a model to think through all aspects completely

The use case model ensures developers have fully thought through all aspects of development. Use cases dig into the details of user needs, system goals, possible issues, and various business variants.

Use cases vs. user stories: Bottom line

So, use cases vs. user stories? How do you decide which is better for your team? If you have a lot of experience with agile projects and working on agile teams, you know the undeniable value of user stories. They convey what the user or customer wants to achieve so that teams are always considering the needs of the user.

That said, even though use cases are a bit dated, they can provide much-needed context surrounding how a system is used. They describe how a user interacts with a system, answering many questions in advance to help manage complicated processes. Plus, it wouldn’t be very agile to discount a solution simply because you haven’t tried it before. 😉

Using Easy Agile User Story Maps

We’re passionate about building tools that help agile teams work better together. Easy Agile User Story Maps for Jira is designed to help product owners and development teams bring value to customers fast and frequently. With our user story mapping tool, you can plan core user activities, order stories by priority, manage epics inside the story map, edit story summaries, and more.

It integrates seamlessly with your agile boards in Jira for both Scrum and Kanban methodologies to create an impactful and visual representation of the customer journey. Our user story tool is the highest-rated story mapping app for Jira, trusted by companies such as Twitter, Dell, Oracle, AT&T, Amazon, Cisco, and Starbucks.

Learn how you can use Easy Agile User Story Maps for simple and collaborative story mapping. Try it absolutely free for 30 days.

За последнее время множество раз столкнулся с непонимаем того, что же общего между сториз и юзкейсами, а чем они всё-таки отличаются? Что есть пользовательские сценарии и причем тут Эджайл?

Прежде, чем отвечать, нужно сделать паузу и признать, что в сегодняшней терминологии есть некоторая путаница — под Сториз, Сценариями или Юзкейсами могут понимать разные инструменты.

Авторы культовой 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% сценариев, с которыми пользователи будут работать мало и редко, а внимание дизайнера будет размазано по всем возможным сценариям, что снизит их качество.

swpm

Originally 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. Понимайте природу различных артефактов. Думайте об их сильных и слабых сторонах. Рассмотрите, как вы взаимодействуете со своей командой. Должны ли вы доверять вашей команде? Доверяете ли вы вашей команде? Определите, что им нужно и дайте им это.

Проверенный шаблон пользовательских историй

Самый дорогой ресурс — время. Его всегда не хватает. Один из популярных способов экономии времени — шаблон. Например, в повседневной жизни у нас есть шаблоны поведения, когда мозг, чтобы не тратить энергию, действует по привычным схемам: мы ездим по одним и тем же маршрутам до работы, пьем кофе, к которому привыкли, берем выкройки для нового платья из журнала, или готовим презентацию по корпоративному шаблону.

В IT есть, например, паттерны проектирования или алгоритмы — математические шаблоны. Шаблоны — полезная «вещь»: позволяют меньше писать, подставляя что-то в уже сформированные рамки.

Мы в Ak Bars Digital тоже используем много собственных наработок, методологий и шаблонов, чтобы делать все быстро и качественно. В этой статье поделюсь прикладным шаблоном, который создали опытным путем для удобной работы с пользовательскими историями.

Автор: Дарья Плоскодняк — опытный продуктовый аналитик в Ak Bars Digital. Занимается развитием сквозных процессов Ак Барс Банка, связанных с банковскими картами. Один из лидеров внутреннего комьюнити аналитиков компании и участник многочисленных митапов и конференций. Статья подготовлена по мотивам выступления Дарьи на одном из таких мероприятий – митапе Three Amigos Talk.

Пользовательские истории

Сначала кратко о пользовательских историях.

Пользовательская история (или User Story, US) — это:

понятное описание функций системы от лица пользователя, набор пользовательских сценариев;

довольно удобный способ документирования требований клиента при разработке ПО.

С точки зрения agile-разработки, пользовательская история — это задача, которая должна помещаться в спринт.

Простая структура пользовательской истории:

Я как 1_ хочу 2, чтобы 3__.

1 – тип пользователя, персонаж

2 – действие или цель

3 – результат или ценность

Разберем некоторые кейсы с реальными пользовательскими историями:

#1. «Я, как клиент банка, хочу получать сообщение об изменении статуса заявки на кредит, чтобы скорее получить деньги».

Вопрос, который возникает, глядя на эту user story, какой статус ожидает клиент?

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

Такую историю хорошо бы было дополнить информацией по существующим статусам заявки.

#2. «Я как сотрудник магазина хочу проще заходить в складскую программу».

Первое, что бросается в глаза — не сформулирована ценность данной истории. Буквально, нет ответа на вопрос «Зачем?».

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

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

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

Пример детального и максимально наполненного описания пользовательской истории.

Разберем пример подробнее.

Описание

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

Пример нашей нумерации: ABOL-04-113.

ABOL — название команды Ak Bars Online;

04 — номер эпика;

113 — номер истории.

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

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

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

Пример: ABOL-04-113. »Я как действующий клиент банка, уже зарегистрированный в личном кабинете, хочу иметь возможность сменить пароль, чтобы иметь доступ к личному кабинету, если забыл пароль»

Сценарии использования, или Use case

Команды, особенно в бэкенд-разработке, часто сомневаются — писать ли пользовательские истории. Причина в том, что они не взаимодействуют с пользователями и могут придумать формулировки историй только от лица системы.

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

Юзкейсы нужны не всегда, но в командах бэкенд-разработки часто пользуются только ими. Описывать их можно в виде текста – так проще исправить. Диаграммы нагляднее, но тяжелее в производстве.

Пример нашего юзкейса.

Не стоит тратить ресурсы на описание юзкейсов, если у вас небольшие проекты — интеграционные сервисы, мало интерфейсов и пользователей, или вообще нет пользователей.

Правила бизнеса

Старайтесь максимально подробно записывать бизнес-требования, фиксировать любые новые обсуждения и уточнения требований от бизнеса. Можно оставить ссылки на коллег, которые отвечают за бизнес-направление. При этом важно фиксировать источник и дату требования для истории документа и просмотра версионности.

Запоминаем главное — правила бизнеса могут и будут меняться!

Ограничения бизнеса

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

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

Интеграция с внешними системами

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

Сюда отлично подойдет описание инфраструктуры, ER-диаграмма, примеры в формате JSON или XML, и все прочие детали интеграции с внешними системами. В общем, всё, что может пригодиться разработчикам.

Критерии приемки

Обязательное условие для работы с историей. Даже для тех команд, которые пользуются короткими формулировками пользовательской истории безо всяких шаблонов.

Минимальные требования для пользовательской истории — формулировка и критерии приемки. Без них мы не сможем понять, выполнили историю или нет.

Критерии приемки прописываются отдельно для каждой истории. Пример критериев приемки для нашей истории:

Пользователю доступна функция смены пароля на всех устройствах.

Функция смены пароля доступна на странице авторизации.

Новый пароль не может дублировать старый пароль.

Новый пароль имеет не меньше 8 символов.

Пароль не может начинаться и заканчиваться пробелом.

Есть еще один вариант описания критериев приемки, который очень любят тестировщики — модель Given-When-Then.

Given (дано) — состояние ситуации до начала действий пользователя.

When (когда) — пользователь совершает какие-то действия.

Then (тогда) — ситуация меняется и система реагирует на действия пользователя.

В критериях приемки есть только два варианта — да и нет.

Критерий не может быть выполнен, например, на 90%.

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

Важно не путать критерии приемки и DOD (definition of done). DOD — это общий чек-лист критериев – он может быть один на все пользовательские истории в рамках процесса.

Как отличить DOD и критериев приёмки? Очень просто. Представим доставку пиццы. DOD — пицца приготовлена, упакована, отправлена, вручена. Критерии приемки — пицца приготовлена из тех ингредиентов, которые заказал клиент.

На этом всё. Вы можете пользоваться шаблоном как есть или модернизировать его. Главное — формулировать понятно для всех участников и понимать ценность пользовательской истории для бизнеса.

Практика «три С» — card, conversation, confirmation

Ещё одна практика, которой можно пользоваться при работе с user story.

Card — фиксация истории для выполнения. Самое важное, чтобы история была доступна, и чтобы её могли найти все коллеги из команды разработки. Фиксировать истории можно в любом таск-трекере или даже на доске в офисе.

Conversation — обсуждения требований с командой. Если вы аналитик, то не используйте схему работы, в которой просто написали пользовательскую историю и передаете её разработке. Так не работает. Нужно обсудить требования с командой, в идеале выделить на это отдельную встречу.

Confirmation — прописать четкие критерии приемки.

А как на практике?

Давайте пофантазируем и представим заказчика, который передал требования на разработку и сказал «Хочу ракету». У нас есть две команды, в каждой — по одному аналитику: Соня и Степан. Они одновременно начали работать с требованиями.

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

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

Чья команда быстрее выполнит проект? Чей проект будет более качественным? Оставляйте свои мнения в опросе и пишите комментарии — давайте обсуждать.

Разница между 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% сценариев, с которыми пользователи будут работать мало и редко, а внимание дизайнера будет размазано по всем возможным сценариям, что снизит их качество.

The difference and relationship between Use case and User story

How and when to use each, how to apply the techniques and tools properly

User stories are not the same as a use case. Yes, both are terms used in gathering requirements from customers in software development. Yes, both identify users and user goals, but they serve for different purposes.

User stories are a short description of what your user will do when they come to your website or use your software. They use the natural language of the business and do not tell the whole story. The BA writes acceptance criteria which define the boundaries of a user story and can help the development team to know when a story is indeed complete.

A user story is usually written in the following format: As an [actor] I want [action] so that [achievement].

“A s a traveler I want to check in for a flight, so I can fly to my destination”.
“ As a small business owner, I want to create an invoice so that I can bill a customer”. Or “As a customer, I want to update my customer profile so that future purchases are billed to a new credit card number”.

In Scrum, the development of your product is split into a series of iterations called sprints, where each is usually between 2–4 weeks long. Usually, a user story is implemented all in a single iteration of an agile project, while it’s common to split a use case across multiple iterations. During a sprint, each story will go through a number of stages such as: not started, started, in testing, finished, delivered and accepted.

There is an acronym INVEST that is a checklist for a widely accepted set of criteria where BA and its team can assess the quality of user story. If User story fails to meet one of these criteria, the team might consider rewriting. Therefore a good User story should be:

· Independent (of all others),

· Negotiable (not a specific contract for futures),

· Valuable (It’s all about the end-user. If you can’t describe the value a customer is going to get out of your story, it’s not a good story),

· Estimatable (to a good approximation),

· Small (so as to fit within an iteration) and

· Testable (in principle even if there isn’t a test for it yet).

On the other hand, the Use case is a more detailed description of a set of interactions between the system and one or more actors, where an actor is either a user or another system. The use case is created as a document that includes:

· Short description with the goal,

· The trigger (event or sequence of events that initiate the use case),

· Specify the actors,

· Preconditions (the things that must happen in the system),

· Normal flow, alternative flow, exceptions (deviations from normal flow) and

· Post conditions (what system must have been achieved at the end of the normal or alternative flow steps).

In other words, use cases are more about behavior that the technical team will have to build into the software. As mentioned in the bullet points, it will contain a lot of details; clearly describing everything that a developer needs to build to meet user need’s need. And developers will get a good sense what the software needs to do!

There are a lot of story mapping agile tools that help BA to visualize the bigger picture while keeping all user stories, and use case elements in perspective. It helps stakeholders to stay updated about their project progress. Some of them are Jira Agile, Lucidchart, Team Foundation Server, BoardThing, Stories on board, FeatureMap and etc.

Based on my experience, Lucidchart (free trial) are pretty easy to use, have hundreds of templates and examples: Flowcharts, Mind map, ERD, Hundreds of shapes with easy drag and drop functionality — Export to PDF, PNG, JPG and Microsoft Visio. The wireframes made on Lucid Charts can be interactive to show pop-ups and different screen states. However, if you decide to upgrade your account there are integrations with Slack, JIRA, BitBucket, Ofice365, AWS, Excel, Quip, and etc. Real-time collaboration: there are multiple ways to share your diagrams with your clients and your viewer can easily add comments and edit the chart. The software has a revision history feature so that you can keep track of what’s been updated on your diagram.

At the end, we can sum up that User stories are centered on the result and the benefit of the thing customer is describing, while use cases are more detailed, and describe how your software will work. Both put the user at the centre of the development efforts making sure that your software project delivers an end product that users want and that satisfies their needs.

User stories vs use cases

Are use cases just multiple user stories??

What are the benefits of using user stories over use cases.. and vice-versa. When to use one over other. Does all agile methodologies uses user stories??

6 Answers 6

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Actually, the original use cases (see Jacobson’s OOSE) were pretty lightweight, much as user stories are now. Over time, they evolved until a common format for «use cases» now is a complicated document with inputs, outputs, inheritance, uses relationships, pseudocode, etc. Programmers, in general, try to convert everything into programming.

In any case, the attempt to defined what distinguishes a «use case» from a «user story» fro a «scenario» is pretty futile, as it’s hard to find two authorities who agree.\

Personally, I find the pattern «[Actor] [verbs] [noun] to get [business value]» helpful. If it gets over about a paragraph of text, it may be too big.

When it comes down to it «agile» is just a label, and people disagree over exactly what it means. Similarly people call very different things «use cases.»

Use cases aren’t compilations of user stories.

User stories are generally much simpler than use cases. I think use cases try to cover absolutely everything to do with the behaviour of some aspect of the system. That is, all behaviours, all error paths and all exception handling.

The recommended template for a user is:

As a (role) I want (something) so that (benefit)

(Thanks Mike Cohn for providing this simple template)

Descriptions of behaviour expressed like this are more agile.

This sort of template lets you describe behaviour using different levels of detail. For example:

IMHO Use cases are much more carved in stone! And hence can be a problem to update after the initial version.

User Story vs Use Case

«Is a User Story the same thing as a Use Case?» People often ask this question and the dispute on whether an agile team should practice Use Stories vs Use Cases has been around the field for years. Are User Story and Use Case the same thing? If not, which is better? Which one should you use? Or could use both?

Although there are some similarities between User Stories and Use Cases, User Stories and Use Cases are not interchangeable; both User Stories and Use Cases identify users and they both describe goal, but they serve different purposes.

User Stories are centered on the result and the benefit of the thing you’re describing, whereas Use Cases can be more granular, and describe how your system will act. Is there a place for Use Cases in Agile, or can they be used in conjunction with each other?

This article will tell you the difference between User Stories and Use Cases.

Agile Software for Scrum Teams

Need an agile software solution for product backlog management? Visual Paradigm supports a powerful agile toolset that covers user story mapping, affinity estimation, sprint management, etc. It’s powerful but yet easy-to-use, intuitive and, most important, AGILE.

User Stories vs Use Cases

If we consider the key component in both approaches:

What is a User Story?

A User Story is a note that captures what a user does or needs to do as part of her work. Each User Story consists of a short description written from user’s point of view, with natural language. Unlike the traditional requirement capturing, User Story focuses on what the user needs instead of what the system should deliver. This leaves room for further discussion of solutions and the result of a system that can really fit into the customers’ business workflow, solving their operational problems and most importantly adding value to the organization.

Concept of 3C’s

The 3C’s refer to the three critical aspects of good user stories. The concept was suggested by Ron Jeffries, the co-inventor of the user stories practice. Nowadays, when we talk about User Stories, we usually are referring to the kind of User Stories that are composed of these three aspects.

User Stories are written as cards. Each User Story card has a short sentence with just-enough text to remind everyone of what the story is about.

Conversation

Requirements are found and re-fined through a continuous conversations between customers and development team throughout the whole software project. Important ideas and decisions would be discovered and recorded during the stakeholder meetings.

Confirmation

Confirmation is also known as the acceptance criteria of the User Story. During the discussion of requirements, the customers tells the analyst not only what he/she wants, but also confirming under what conditions and criteria the working software would be accepted or rejected. The cases defined are written as confirmation. Note that confirmation focuses on verifying the correctness of work of the corresponding User Story. It is not an integration testing.

What is Use Cases?

Use Cases, introduced by Ivar Jacobson more than 20 years ago, are used to capture user (actor) point of view while describing functional requirements of the system. They describe the step by step process a user goes through to complete that goal using a software system.

A Use Case is a description of all the ways an end-user wants to «use» a system. Use Cases capture all the possible ways the user and system can interact that result in the user achieving the goal. They also capture all the things that can go wrong along the way that prevent the user from achieving the goal.

A Use-Case model consists of a number of model elements. The most important model elements are:

Detailed Use Case Specification

A Use Case Specification is a textual description of the functionality provided by the system. It captures actor-system interaction. That is, it specifies how a user interacts with a system and how the system responds to the user actions. It is often phrased in the form of a dialog between the actor and the system. The Use Case Specification is represented in the Use Case Diagram by an oval, and is what most people think of when they hear the term Use Case.

Why We Still Need Use Cases?

Alistair Cockburn explains that he sees (with companies he consults to) three main problems with User Stories:

Integrate Use Case, User Story and Story Mapping techniques

Visual Paradigm provides a complete agile environment that integrates Use Case, User Story, story mapping, affinity estimation, and Kanban into a completely seamless and automated end-to-end process. This process can address the shortcoming of what Alistair mentioned above with the User Story technique by supplementing Use Case and story mapping tools. The other useful agile tools are also incorporated for all the needs to manage your agile projects faster, better and smarter.

The concept map below gives an overview of the agile tools supported by Visual Paradigm.

Point 1 to 3 are tools for supplementing the short coming of user stories. The other user agile tools are listed in Point 4 to 7.

Ready for Agile?

Want an agile tool that can manage your scrum projects well? Visual Paradigm features a user story mapping tool, Affinity Estimation tool, sprint management tool, and task management.

Юзер-стори идеальная, а багов 100500? Как мы тестируем документацию

Зачем и как тестируют документацию? Представьте ту редкую ситуацию, когда в требованиях ошибка или документация составлена неверно. Что дальше? Требование уходит в разработку, программист неверно его истолкует и реализует фичу с искаженной функциональностью. Далее это заметит тестировщик, отправит баг-репорт, который пройдет весь life cycle (пофиксен, проверен, исправлен, закрыт). И это ещё хороший сценарий!

В реальной жизни не все баги исправляют с первого раза, а порой они попадают в прод с печальными последствиями. На вопрос «зачем» ответил. Ответ на вопрос «как» — ниже.

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

Меня зовут Михаил Тимофеев, это моя первая статья, занимаюсь по большей части нагрузочным тестированием в команде Test IT. Нашей компании 2 года, мы разрабатываем систему управления тестированием. Наша система помогает QA-командам работать с ручными и автотестами, привести в порядок тестовую модель, поддерживать и хранить ее в одном месте, упрощает коммуникацию внутри команды. Но это не значит, что мы боги тестирования. Мы тоже люди и совершаем ошибки. Главное — это вовремя их обнаружить и пофиксить =)

Flow тестирования документации

Для нас Agile не равно отсутствие документации. Мы фиксируем все обсуждения с помощью комментариев к уже созданной документации. Поэтому наши записи четко структурированы и отражают суть, что облегчает работу с документацией на регрессе. Мы приняли следующую иерархию документации:

Состав эпика в Test IT

PM, собравшись с мужеством, пишет «Epic» и «User Story»

Эти сущности в Test IT начинается со слова «Хочу», которое является вектором развития ПО. Например: «Хочу иметь возможность импортировать/экспортировать тест-планы», «Хочу переносить тест-кейсы с одного инстанса Test IT на другой» и т.д. Тут можно посмотреть пример нашей стори.

Эпики и стори содержат: требования, юзкейсы и критерии выполнения; задачи, подзадачи и дефекты.

Связка эпика и юзер-стори

Затем QA тестируют User Story на:

Завершенность: User story представляет собой полноценную, логично завершенную новую или усовершенствованную старую функциональность.

Последовательность: Данная User Story логично продолжает развитие «Epic», который она реализует, или закономерно продолжает общее развитие продукта в текущей версии.

Непротиворечивость: Реализуемый функционал не противоречит самому себе, и не противоречит логике работы интегрируемых с ним компонентов ПО.

Атомарность: Каждое требование, описанное в User Story, является целостным и неделимым на подзадачи. Оно само является подзадачей.

Отслеживаемость: Каждая User Story, Task, SubTask, Bug должны быть слинкованы между собой для возможности отслеживания работы по User Story.

Актуальность: Вся информация после обсуждений вносится либо в комментарии, либо правится непосредственно Product Owner.

Недвусмысленность: Перекликается с принципом «Атомарности», каждое требование должно иметь единственную трактовку во избежание двусмысленности и отсутствия понимания.

Обязательность: Каждое требование, описанное в User Story- является обязательным к выполнению.

Проверяемость: Наличие обоснованных и выполнимых критериев завершения задачи. У нас эту роль играет раздел «Definition of Done».

После тестирования юзер-стори пишем Test Cases в соответствии с пунктами Use Case и Definition of Done.

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

Пирамида тестирования

Unit у нас их пишут разработчики. И да, на это выделяется на планировании спринта как отдельная задача, и на них уже в самом начале закладывается время.

Components: здесь мы делим процесс тестирования между разработчиком и специалистом QA-отдела. Так мы обеспечиваем быструю обратную связь по разрабатываемой функциональности.

Integration: проводим с отделом разработки. Здесь важно отследить взаимодействие с ближайшими компонентами в системе или с компонентами, на которые влияет данная функциональность.

E2E: для них мы берем информацию из пользовательских сценариев.

Тест кейсы обеспечивают атомарную документацию по конкретной фиче в рамках User Story. На каждый вопрос от члена команды «А что если. » QA может составить минимум один тест. От количества заданных вопросов «А что если. », и уровня профессионализма тестировщика зависит качество выпускаемого продукта, стоимость найденных дефектов и их исправления.

User Story идеальная, ​а багов +100500

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

В Test IT мы сформировали свой подход к решению подобных проблем.

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

Feature tester

Специалист, который комплексно работает над задачей. В зоне его ответственности находится: тестирование документации, написание тестовых сценариев, тестирование frontend и backend компонентов. Тесная работа с командой разработчиков в рамках пользовательской истории, которую ему передали в работу в начале релиза.

Контроль качества по пользовательской истории сосредоточен на одном специалисте, как следствие:

Глубокое знание продукта;

Качественные сообщения о дефектах содержащие исчерпывающую информацию со стороны backend и frontend разработки;

Сокращение времени работ по исправлению дефектов;

Постоянное повышение квалификации;

Возможность влиять на юзер-стори на протяжении всего процесса разработки более оперативно и централизованно;

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

Стандартизация US

1. Description — общее описание к US, коротко передаем основную идею.

«Как пользователь, управляющий тестированием на проектах и использующий разные инстансы Test IT, я хочу переносить тест-планы с одного инстанса на другой».

«Администратор Test IT, координатор/руководитель проектов, Тест-менеджер».

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

Возможность импорта/экспорта тест-планов в собственном формате, возможность актуализации тест-планов и кейсов, находящихся в тест-плане с помощью импорта/экспорта.;

Реализовать возможность выполнения импорта и экспорта тест-планов в проекте.

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

Реализовать возможность актуализации тест-планов с помощью импорта, с отображением изменений в журнале изменения тестов, истории прохождения тестов и отображением актуальной версии тестов на момент их прохождения.

Test Case

Воспользоваться API для экспорта тест-планов на инстансе 1, указать проект целиком, или конкретные тест-планы,

Воспользоваться API для импорта тестов на инстансе 2, отправить полученную выгрузку,

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

Есть возможность экспортировать тест-планы с помощью API

При экспорте тест-планов есть возможность выбрать проект целиком, либо конкретные тест-планы

При экспорте планов, пользователь получает выгрузку в JSON формате в файле. Файл имеет следующее название: Test IT — <имя_проекта>— <имя_плана>— .

Стандартизация по пунктам дает полное понимание разрабатываемой функциональности. Прочитав этот документ, разработчик точно будет знать, кто пользователи и для какой цели им нужна данная фича. Для аналитика, владельца продукта и тестировщика будет сформирована единая сетка требований. Разработчики точно будут знать, куда смотреть во время технической экспертизы при постановке подзадач, а пункты Use Case и Definition of Done позволят лучше понять бизнес-задачи.

Применение паттернов из пирамиды тестирования к юзер-стори

1) юнит-тесты:

Удостовериться в наличии;

2) компонентное тестирование:

Не функциональные требования;

Проектные риски — зная своих коллег, можно заранее прикинуть реальное время на выполнение задачи. Позволит скорректировать время на reject US;

Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.

3) интеграционное тестирование:

Не функциональные требования;

Цели: для чего нужна фича, какие аспекты вашего ПО будут затронуты;

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

Технологии, использованные при создании продукта;

Цели качества (критерии — запрос должен выполняться за 1 секунду);

Тех. долг команды — позволит учесть в тестировании узкие места и ссылаться на существующую проблематику.

4) e2e:

Пользовательские сценарии (примени к каждому сценарию CRUD);

Различные окружения — железо, ОС, приложения, конфигурация, языки;

Процесс внедрения:

Разработать и принять форму написания юзер-стори;

Подход к тестированию: 1 юз.стори = 1 QA;

Разработка тестовых сценариев в соответствии с паттернами тестовых сценариев пирамиды тестирования;

Контроль за покрытием тестовыми сценариями каждой User Story.

Результат:

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

Глубокое понимание процессов взаимодействия конкретной фичи с остальным проектом;

Покрытие юзер-стори с учетом различных уровней тестирования. Специалист, только что пришедший на проект, сможет покрыть от 60% юзер-стори тестовой документацией;

Недвусмысленное понимание того, какие именно части юзер-стори покрыты тестовыми сценариями.

Дисклеймер: впервые тема была изложена в рамках доклада на конференции SQADays-28 в апреле 2021 года.

Библиография при подготовке:

37 Sources for Test Ideas, авторы Rikard Edgren, Martin Jansson and Henrik Emilsson

Тестовое покрытие по Бейзеру, автор видео Анастасия Асеева-Нгуен — эксперт по инженерным практикам в Tinkoff Group

User Story vs Use Case: Everything You Need to Know

A lot of people confuse user cases and stories, but actually they are different concepts. They might have some similar functions. For example, gathering information about user requirements and goals. But they are designed for different purposes. This article discusses in detail the two concepts and how they are different. The usage and practicality of the two concepts to businesses is also highlighted in the article. This article aims to serve as an aid for its readers and help them gain insight into this topic.

What is a use case?

Have you ever felt that the product you imagined and the product you developed were very different? Or the feature that you wanted is missing from the final version. Many product people can relate to these questions. This can help to understand why businesses need a use case in the first place.

In simple terms, a use case is an account of how a person who uses a certain process will achieve a goal. In technical terms, it is the description of the interaction between system and actors. The product of this process is a document containing all the steps followed by a user to achieve a goal.

For example, you are a carpenter planning to craft a door. The use case for this scenario would consist of all the steps taken by the carpenter to achieve the goal. This whole documentation would help study the flaws and errors of the process.

Product teams utilize use cases in a variety of situations. It is used in designing, testing and development. This process also helps to develop a rough outline of how a user help manual should be designed. Errors and other flaws are also minimized through this process.

The whole process of use cases has certain key terms. These terms are the basis of the entire process and provide the backbone.

The three basic terms don’t apply to every situation. Every project, model and circumstance are different in complexity. For complex products, many other terms are used in a use case. Some of the terms are:

From a technical point of view, use cases are a detailed description of guidelines for developers. It gives an idea of what the developers need to include in the system. This also gives the developer a sense of direction to work in.

It’s also important to note that when creating use cases you shouldn’t just cover the ideal scenario, you should also prepare alternative paths:

What is a user story?

After describing use cases, let’s move on to user stories.

User stories are a simple description of the desire of a user for a need. These stories are written from an end-user point of view. The language used for user stories is very informal and easy to understand.

In technical words, it is the description of a feature from an end-user’s point of view. This story is used in agile software development. It helps the product team in identifying their users and requirements. It also helps to break down all the complexity into simple easy to understand words.

The user story is also an easy method of recording user requirements. It helps to identify some important questions. Questions like the who, what and why of a feature. All this description is written to shift the focus from writing to discussing features. It can help simplify the whole process and increase effectiveness.

It is important for a user story to have an outline. An acronym INVEST is widely used for this purpose. It helps in checking that all the requirements have been fulfilled.

Now that both concepts have been described in detail it might feel that they are the same. The overlap between the two concepts is visible from far away but not near. Although what is same is their importance to the product team. They both are important components of the overall development process.

Why Create User Stories?

User stories are a simple way of defining what a user wants. Products can be explained clearly through it. A good user story will help all stakeholders in understanding the functionality of the product. It also helps in briefing the client on what the product is.

User stories can help to streamline the project

It means that a bigger goal can be divided into smaller achievable goals. This helps to achieve the project more efficiently and with less time waste. Smaller achievable goals mean little deviation from your goal.

Brings everyone on the same page

Their simple language means they are understandable by everyone. Both technical and non-technical members use this as a medium of communication. It also helps in engaging each stakeholder. The nature of user stories ignites product discussion among different stakeholders.

Provide a sense of purpose

By clearly defining the purpose of the product, user stories provide purpose to the whole mission. It also makes achieving the task easier for the development team. Due to user stories developers know why they are producing a product. This contributes to increased motivation.

Helps defining the whole product

It gives the development team the freedom to think out of the box. The team can then organize different ideas according to their priority. The criteria for priority might depend on factors like user value and complexity. This means that even the crazy ideas aren’t excluded from the process. They can be given a lower priority and handled accordingly.

Encourages a user focused approach

This method gives a lot of power to the end user. It means that everything is designed with the end users in mind, right from the beginning. Let it be a prototype, an MVP or a new feature, user stories help you keep the user in the middle of the focus. The stories align the product team with what users want. These stories serve as a constant reminder of serving user needs. Thus, user satisfaction is maximized due to user story.

Example of user story vs. use case

Let’s take an electric vehicle renting application as an example.

Imagine an application where you can list and rent all electric vehicle options in big cities.The users’ objective is to choose and successfully rent an electric vehicle.

Use case example

Use Case Name: Place Rent Order

Basic Use Case Description:

Alternative flow would be:

User story example

As a user, I want to link the credit card to my profile so that I can pay for a rent faster, easier and without cash.

As a service provider, I want to add photos of my vehicles in the application so that I can attract more users.

As a user, I want several available vehicles to be displayed so that I can choose the most suitable option for me.

The differences between a user story vs use case

User focus vs technical focus

User story is drafted to explain a user’s needs. It highlights a problem that a user faces in his day to day life. The language of this draft is very simple. It is developed to keep all the stakeholders on the same page. On the other hand, use cases are developed for the product team only. It gives the team an idea of what the software should achieve. It also highlights all the steps the developers need to follow in order to make the software. For this reason, use cases contain a lot more detail than user stories.

General vs in-depth

User story is a simplified form of many users interacting with a software. Use cases are very specific in relation to user stories. They describe specific user actions with any system.

Short vs Detailed

User stories miss out on a lot of details. This is because it gives room for discussion and improvement. This aspect of user stories is deliberate. This encourages stakeholders to initiate discussions and improve the product. Use cases on the other hand are specific. They describe in detail all the steps that a developer will follow. There is usually no room for discussion.

Use stories are developed before the user case. In most cases they are developed by user interaction. One user story can generate multiple use cases. The combination of all such use cases produces a detailed document. This document has a description of the interaction between all software and users.

The similarities of a user story and a use case

The biggest similarity between the two approaches is the key components. User stories have components like user role, goal etc. Use cases also have similar concepts. It includes actor, pre-conditions and other terms. So, both of these concepts become similar in how they approach a problem.

When to use a user story vs use case?

User stories have a lot of uses in product development. They are used before use cases to start customer focused conversations. This conversation means more room for improvement in the customer model. It helps in providing clarity to the whole concept. User stories ensure no useless detail gets into the whole process. This also ensures that goals are set from the beginning of the process. Thus, user stories increase efficiency.

There are several places when use cases can be used. They can be used to document the process of a current system. Often when existing systems are updated they can provide a lot of technical problems. Use cases help in understanding the bigger picture of the existing system. So, problems can be avoided before any changes are made.

Another use of the use case is in the development of new systems. It helps in providing a detailed description of all the steps developers need to follow. It also helps in defining user goals and easing the development process.

WRAP UP

By now you know what user stories and use cases are all about and what their use is. These concepts are instrumental to a successful product.

В чем разница между «сценарием использования», «историей пользователя» и «сценарием использования»?

Существует ли точное, но простое и понятное определение различия между «сценарием использования», «пользовательской историей» и «сценарием использования»?

(например, http://c2.com/cgi-bin/wiki?UserStoryAndUseCaseComparison очень длинный и трудный для получения, полный обсуждения)

Для меня самые большие различия между пользовательской историей и вариантом использования:

Честно говоря, различия с потоком прецедентов не совсем ясны, даже после прочтения этого параграфа (последнее предложение, возможно, самое важное):

Как вы можете себе представить, есть несколько различий между вариантами использования и сценариями. Во-первых, вариант использования обычно относится к общим субъектам, таким как Заказчик, тогда как сценарии обычно относятся к примерам таких субъектов, как Джон Смит и Салли Джонс. Ничто не мешает вам написать общий сценарий, но обычно лучше персонализировать сценарии, чтобы повысить их понятность. Во-вторых, сценарии использования описывают один путь логики, тогда как сценарии использования обычно описывают несколько путей (базовый курс плюс любые подходящие альтернативные пути). В-третьих, в процессах на основе UP случаи использования часто сохраняются в качестве официальной документации, тогда как сценарии часто отбрасываются после того, как они больше не нужны.

Возможно, я ошибаюсь, но сценарий использования действительно звучит как поток сценариев использования, но переименован в Agile Touch.

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

Лучше всего найти пример, уже существующий для вашего текущего проекта, и следовать ему.

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

Не зацикливайтесь на именах.

Пользовательская история всегда неофициальна и описывает потребности пользователя. Вариант использования может быть формальным или неформальным, и описывает поведение системы.

Можно иметь «технические» пользовательские истории, то же самое нельзя сказать о случаях использования.

После этого пользовательская история обычно отбрасывается. Варианты использования могут быть сохранены в течение жизненного цикла продукта.

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

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

Примеры пользовательских историй:

Поскольку детальность сценариев сценария использования определяется, они становятся больше о функции и процедуре.

Для более глубокого обсуждения этой темы я предлагаю прочитать http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison на сайте Алистера Кокберна. Поскольку он подписал Agile Manifesto, человека, который придумал User Stories и считался экспертом по Use Case в течение последних двух десятилетий, я думаю, что он является отличным источником для получения дополнительной информации.

_{Быстрое временное примечание : этот пост нуждается в улучшениях, чтобы лучше ответить на вопрос, например, 1) дополнительные ссылки должны быть включены в ссылки 2) некоторые цитаты, возможно, 3) общая правильность английского языка 4) общее качество повествования 5) и т. Д. Я буду вернемся к этому. Не стесняйтесь улучшать это самостоятельно.}

Взгляд на их шаблоны может дать ценную информацию о различиях между этими терминами.

Случай использования

Варианты использования были созданы и популяризированы Иваром Якобсоном в конце 80-х начале 90-х годов. Позже другие люди также внесли свой вклад в его работу (одним из таких людей является Алистер Кокберн, который является автором « Написание сценариев эффективного использования» ). Чтобы перефразировать Мартин Фаулер случаи использования могут использовать текст и диаграммы UML, но их наибольшее значение лежит в тексте этого. Они лучше, когда они не большие и легко читаемые.

Пользовательская история _{(aka. Feature)}

Билл Уэйк разработал мнемонику INVEST, чтобы описать, какими качествами должна обладать хорошая пользовательская история, и я позаимствую краткое изложение этого Мартина Фаулера со своего веб-сайта :

Независимо : истории могут быть доставлены в любом порядке. По
договоренности : детали того, что находится в истории, совместно создаются программистами и заказчиками в процессе разработки.
Ценно : функциональность рассматривается как ценная для клиентов или пользователей программного обеспечения.
Оценка : программисты могут придумать разумную оценку для построения истории.
Маленький : истории должны быть построены за небольшое время, обычно за несколько человеко-дней. Конечно, вы должны быть в состоянии построить несколько историй за одну итерацию.
Тестируемый : вы должны быть в состоянии написать тесты, чтобы убедиться, что программное обеспечение для этой истории работает правильно.

Сценарий использования

Сценарий использования следует шаблону GWT, который обозначает Given-When-Then, например:

Сценарий : название
Дано : конкретный факт
И : еще один конкретный факт (может быть необязательным)
Когда : происходит какое-то событие
Затем : происходит другое событие

Сценарии использования связаны с управляемой поведением разработкой. Звучит очень похоже на тест. Мартин Фаулер в своем блоге рассказывает историю и причины использования сценариев. Вот важная часть:

Сценарии использования могут быть использованы для написания теста для вашего приложения. Процитирую последний абзац поста Мартина:

Хотя стиль Given-When-Then является симптоматическим для BDD, основная идея довольно распространена при написании тестов или спецификации на примере. Месарош описывает модель как четырехфазный тест. Его четыре фазы: настройка (дано), упражнение (когда), проверка (затем) и разборка. Билл Уэйк придумал формулировку «Аранжировать, действовать, утверждать».

Поваренная книга разработчика: DDD-рецепты (5-я часть, Процессы)

В рамках предыдущих статей мы описали: область применения, методологические основы, пример архитектуры и структуры. В данной статье, я хотел бы рассказать как описывать процессы, о принципах сбора требований, чем отличаются бизнес требования от функциональных, как перейти от требований — к коду. Рассказать о принципах применения Вариантов Использования (Use Case) и как они нам могут помочь. Разобрать на примерах варианты реализации шаблонов проектирования Interactor и Service Layer.

Примеры приведенные в статье даны с использованием нашего решения LunaPark, оно поможет вам с первыми шагами в описанных подходах.

Отделяем функциональные требования от бизнес требований.

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

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

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

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

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

Тут можно выделить ряд характерных признаков, которые будут указывать, что это требования от бизнеса:

Функциональные требования — это Действия, которые система должна выполнить, для реализации бизнес-требований. Таким образом, функциональные требования связаны с разрабатываемым решением или программным обеспечением. Сформулируем функциональные требования для вышеуказанного примера:

Выделим следующие особенности:

Следует сказать пару слов о нефункциональных требованиях (также известных как «требования к качеству»), которые накладывают ограничения на дизайн или реализацию (например, требования к производительности, безопасности, доступности, надежности). Такие требования отвечают на вопрос «какой» должна быть система.

Разработка — это перевод бизнес требований в функциональные. Прикладное программирование — это реализация функциональных требований, а системное — нефункциональных.

Варианты использования (Use cases)

Реализация функциональных требований является, зачастую, самой сложной в коммерческих системах. В чистой архитектуре функциональные требования реализуются через слой Use Case.

Но для начала, я хочу обратится к первоисточнику. Ивар Якобсон — автор определения Use Case, один из авторов UML, и методологии RUP, в своей статье Use-Case 2.0 The Hub of Software Development выделяет 6 принципов применения Вариантов использования:

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

Простота через повествование

Повествование — часть нашей культуры; это самый простой и эффективный способ передачи знаний, информации одного человека — другому. Это лучший способ сообщить о том, что должна делать система, и помочь команде сосредоточиться на общих целях.

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

Данный принцип коррелирует с партерном Общий язык (Ubiques language) из DDD подхода.

Понимание картины в целом

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

Ивар Якобсон предлагает задействовать диаграмму вариантов использования, что очень удобно для сбора требований. Если требования собраны и ясны, то лучшим вариантом будет Контекстная карта (Context map) Эрика Эванса. Зачастую, Scrum подход интерпретируют так, что люди не тратят время на стратегический план, считая планирование, дальше чем на две недели, пережитком прошлого. Пропаганда Джеффа Сазерленда обрушилась на waterflow, а люди закончившие двухнедельные курсы подготовки скрам-мастеров, допущенные к управлению проектами, сделали свое дело. Но здравый смысл, осознает важность стратегического планирования. Не нужно делать детальный стратегический план, но он должен быть.

Фокус на значении

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

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

Далее автор приводит замечательную схему, на которую следует обратить самое пристальное внимание:

На схеме показан вариант использования, «Снятие наличных в банкомате». Самый простой способ достижения цели описывается в Основном Направлении (Basic flow). Другие случаи описываются как Альтернативные Направления (alternative flow). Эти направления помогают с повествованием, структурируют систему и помогают с написанием тестов.

Послойное построение

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

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

Эти идеи перекликаются с подходами гибкой разработки и с идеями Доменов (Domain).

Пошаговый вывод продукта на рынок

Большинство программных систем развиваются на протяжении многих поколений. Они не производятся за один раз; они построены в виде серии выпусков, каждое из которых построена на предыдущем выпуске. Даже сами релизы часто не выходят за раз, а развиваются через серию промежуточных версий. Каждый шаг предоставляет наглядную, пригодную для использования версию системы. Это тот способ, которым должны быть созданы все системы.

Удовлетворять потребности команды

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

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

Реализация

В чистой архитектуре Робертом Мартином дается следующее определение Вариантов использования :

These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their Critical Business Rules to achieve the goals of the use case.

Попробуем воплотить эти идеи в код. Давайте вспомним схему из третьего принципа применения Вариантов использования и возьмем ее за основу. Рассмотрим действительно сложный бизнес-процесс: «Приготовление пирога с капустой».

Давайте попробуем его декомпозировать:

Всю эту последовательность мы реализуем через Интерактор (Interactor), а каждый шаг будет реализован через функцию или Функциональный объект (Functional Object) на Сервисном слое (Service Layer).

Последовательность действий (Interactor)

Я очень рекомендую начинать разработку сложного бизнес-процесса именно с Последовательности действий. Точнее не так, вы должны определить Доменную область, к которой относится бизнес-процесс. Уточнить все требования бизнеса. Определить все Сущности, которые задействованы в процессе. Задокументировать требования и определения каждой Сущности в базе знаний.

Расписать все на бумаге по шагам. Иногда потребуется Диаграмма последовательности (sequence diagram). Ее автор тот же, кто придумал Варианты использования (Use Case) — Ивар Якобсон. Диаграмма была придумана им, когда он разрабатывал систему обслуживания телефонных сетей для компании Эриксон, взяв за основу схему реле. Мне очень нравится эта диаграмма, и термин Sequence, на мой взгляд более выразителен, чем термин Interactor. Но ввиду большей распространенности последнего, будем использовать привычный термин — Interactor.

Небольшая подсказка, когда вы описывайте бизнес-процесс хорошим подспорьем для вас, может стать, основное правило документооборота: «В результате любой хозяйственной деятельности, должен быть составлен документ». К примеру, мы разрабатываем систему скидок. Предоставляя скидку, мы по факту, с точки зрения бизнеса, заключаем договор между компанией и клиентом. В этом договоре должны быть прописаны все условия. То есть в домене DiscountSystem, у вас будет Entites::Contract. Не привязывайте скидку к клиенту, а создайте Сущность Контракт, где описываются правила ее предоставления.

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

Шаблон проектирования Последовательности действий отвечает за:

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

Вернемся к пирогу: попробуем описать процесс его приготовления через Interactor.

Реализация

Привожу пример реализации, с нашим решением LunaPark, которое мы представили в предыдущей статье.

Как мы видим, метод call! описывает всю бизнес-логику процесса выпечки пирога. И его удобно использовать для понимания логики приложения.

Договоренности

Пример использования

Процесс представлен через объект и мы имеем все необходимые методы для его вызова — прошел ли вызов успешно, возникла ли какая-то ошибка в процессе вызова, и если произошла, то какая?

Обработка ошибок

Если сейчас вспомнить третий принцип применения Use Case, обратим внимание на то, что кроме Основного направления, у нас были еще и Альтернативные направления. Это ошибки, которые мы должны обработать. Рассмотрим пример: мы конечно не хотим чтобы события пошли подобным образом, но ничего не можем с этим поделать, суровая реальность такова, что пироги периодически сгорают.

И во время выпечки, проверим, что наш пирог не сгорел:

Практика использования

1. Старайтесь описывать все вызовы в методе call!

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

Используйте вызов действий прямо в классе. Такой подход с точки зрения ruby может показаться непривычным, так он выглядит более читабельным:

2. По возможности используйте метод класса call

3. Не создавайте Функциональные объекты ради типизации кода, смотрите по ситуации

Сервисный слой (Service Layer)

Порядок действий (Interactor), как мы говорили, описывает бизнес-логику на самом верхнем уровне. Сервисный слой (Service layer) уже раскрывает детали реализации функциональных требований. Если мы говорим о приготовлении пирога, то на уровне Порядка действий (Interactor) мы говорим просто «замешиваем тесто», не вдаваясь в детали как его замесить. Процесс замеса описывается на Сервисном уровне. Вернемся к первоисточнику, большой синей книге:

В прикладной предметной области бывают такие операции, которым нельзя найти естественное место в объекте типа Сущности (Entity) или Объекта-Значения (Value object). Они по своей сути являются не предметами, а видами деятельности. Но поскольку в основе нашей парадигмы моделирования лежит объектный подход, мы попробуем превратить их в объекты.

В этом месте легко совершить распространенную ошибку: отказаться от попытки поместить операцию в подходящий для нее объект, и таким образом, прийти к процедурному программированию. Но если насильно поместить операцию в объект с чуждым ей определением, от этого сам объект утратит чистоту замысла, станет труднее для понимания и рефакторинга. Если в простом объекте реализовать много сложных операций, он может превратиться в непонятно что, занятое непонятно чем. В таких операциях часто участвуют другие объекты предметной области и между ними выполняется согласование для выполнения совместной задачи. Дополнительная ответственность создает цепочки зависимости между объектами, смешивая понятия, которые можно было бы рассматривать независимо.

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

Такой метод будет являться ошибкой. Дрова сами себя не нарубят, нам потребуется топор:

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

Как вы уже наверное догадались, это не самая удачная идея. Не все из нас занимаются рубкой дров, это не прямая обязанность человека. Мы часто видим насколько перегружены модели в Ruby on Rails, хранящие в себе подобную логику: получение скидки, добавление товара в корзину, снятие денег к балансу. Эта логика относится не к сущности, а к процессу в котором задействована эта сущность.

После того, как мы разобрались, какую логику мы храним в Службах попробуем реализовать один из них. Чаще всего службы реализуются через методы или функциональные объекты.

Функциональные объекты

Такие объекты имеют ряд преимуществ: они лаконичны, их очень просто тестировать. Есть и недостаток, таких объектов может получиться большое количество. Есть несколько способов сгруппировать подобные объекты, мы в части своих проектов делим их по типу:

Сервисный Объект (Service)

В нашей реализации Service — реализует функциональное требование и всегда возвращает значение.

Команда (Command)

В нашей реализации Command — выполняет одно Действие, изменяет объект, в случае успеха возвращает true. По факту, Команда не создает объект, а изменяет существующий.

Вахтер (Guard)

Вахтер, выполняет логическую проверку и в случае провала выдает ошибку обработки. Такой тип объекта никак не влияет на Основное направление, но переключает нас на Альтернативное направление, если что-то пошло не так.

При подаче молока важно убедится, что оно свежее:

Возможно вам покажется удобным разделять функциональные объекты по типу. Вы можете добавить свои, например, Builder — создает объект на основе параметров.

Договоренности

Обработка ошибок

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

Ошибки процесса выполнения

Такие ошибки могут возникать в результате нарушения логики обработки.

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

Такие ошибки должны наследоваться от LunaPark::Errors::Processing

Системный ошибки

Ошибки, которые произошли в результате сбоя системы.

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

Есть еще, ошибки валидации, которые мы рассмотрим подробнее в следующей статье.

Практика использования

1. Используйте переменные, чтобы повысить читаемость

2. Передавайте объекты, а не параметры

Старайтесь делать инициализатор простым, если обработка параметров не является его целью.
Передавайте объекты, а не параметры.

3. Используйте в название Действия — глагол действия и объект воздействия.

4. По возможности используйте метод класса call

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

5. Обработка ошибок не является задачей сервиса

Модули

До этого момента мы рассматривали имплементацию Сервисного слоя как набора функциональных объектов. Но мы легко можем разместить на этом слое методы:

Другая проблема, которая встает перед нами — большое количество сервисных объектов. Вместо, набивших оскомину «rails fat model», мы получим «services fat folder». Есть несколько способов организовать структуру, чтобы уменьшить масштаб трагедии. Эрик Эванс решает это за счет того, что объединяет ряд функций в один класс. Представим, что нам нужно смоделировать бизнес-процессы няни, Арины Родионовны, она может кормить Пушкина и укладывать его спать:

Такой подход более корректный с точки зрения ООП. Но мы предлагаем от него отказаться, по крайней мере, на начальных этапах. Не очень опытные программисты начинают писать много кода в таком классе, что в конечном счете приводит к увеличению связности. Вместо этого можно использовать модуль, представляя деятельность некоторой абстракцией:

При делении на модули должна соблюдаться низкая внешняя зависимость (low coupling) при высокой внутренней связности (high cohesion), мы же используем такие модули как Services, или Interactors, это также идет в разрез с идеями чистой архитектуры. Это осознанный выбор, который облегчает восприятие. По имени файла мы понимаем какой шаблон проектирования реализует тот или иной класс, если для опытного программиста это очевидно, то для новичка это не всегда так. После того как ваша команда будет готова, откажитесь от этого излишества.

Процитирую еще небольшой отрывок из большой синей книги:

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

Дайте модулям такие имена, которые войдут в ЕДИНЫЙ ЯЗЫК. Как сами МОДУЛИ, так и их имена должны отражать знание и понимание предметной области.

Тема модулей большая и интересная, но в полном объеме явно выходит за тему данной статьи. В следующий раз мы поговорим с вами о Репозиториях и Адаптерах. Мы открыли уютный телеграмм канал, где хотелось бы делиться материалами на тему DDD. Будем рады вашим вопросам и обратной связи.

User stories vs use cases: how they stack up

In this post, we’re looking at a close match up: user stories vs use cases. Discover the important differences and which one is right for you

Just what exactly are the differences between user stories and use cases? Aren’t they the same? Don’t they have the same goals? Why not just settle on one word for both of them? As it turns out, user stories and use cases, while they do have similar purposes, are not quite the same.

Start prototyping today. Enjoy unlimited projects.

In this post, we’ll have a look at the different formats these documents take and the type of content they contain. Hopefully, after reading this post, the differences will be clearer. You should also have a better idea of which one you should be including in your development cycle.

User stories vs use cases: documents galore

The agile world is dotted with a seemingly endless population of user-centric documents to use alongside your wireframe tool. The problem is, all of them are helpful.

However, the paradox is that agile is all about cutting through red tape and minimizing surplus documentation. And since many documents have similar functions, to remain truly agile, you may need to decide which documentation is relevant for your team and clients at any given moment. Too many documents and procedures in a small organization might be overkill.

Indeed, many agile documents have striking similarities and some may just be synonymous with others, such as user journeys, user journey boards and user journey maps which are essentially the same thing. Nonetheless, there are some documents that tend to get misinterpreted as synonymous when they are in fact different.

This is particularly true when we look at user stories vs use cases. People sometimes mix up these documents because they sound similar and have familiar goals. However, if you were to see both a user story and a use case side-by-side, you’d quickly notice the differences. Let’s look at what each document entails. If you already have a good idea of what each one is, feel free to skip down to user stories vs use cases for a battle finale!

What is a user story?

User stories define the who, the what and the why of a product feature. They’re usually aimed at developers but are intended to be easily understood by everyone on the team, including clients. They outline what a user needs to get done, from that user’s point of view.

User story structure

They often comprise just one sentence or a couple of lines written in the following structure:

An example of this could be:

“As a user, I want to have a barcode ticket for my train pass on my phone so that I don’t need to print it off and carry a paper around with me.”

That is then followed by acceptance criteria which usually contain the information that informs the developer or product manager when the user story can finally reach its conclusion, in other words, when the feature is ready. A product manager will normally hold a discussion with design and development teams to agree on what outcomes of the user story need to be satisfied. An acceptance criteria typically takes on the following format:

Using that format, an acceptance criteria generally tends to look a little like the following:

“Given there are sufficient funds in the user’s bank account, when they enter their details correctly and select a valid hour, the ticket should appear on the dashboard, then a confirmation email and purchase receipt should be sent to the email address the user registered with.”

Start prototyping today. Enjoy unlimited projects.

User story mediums

User stories are often simply written on index cards, something which owes to the pure simplicity of this important agile document. The acceptance criteria is often written overleaf.

However, this isn’t ’t the only medium that user stories can come in and they are often in fact digitalized and written up into excel or word documents or google docs or even PowerPoint presentation format.

They are often included in kanban or other agile software and assigned scrum points for each one There are actually many templates available to help teams to get started with creating user stories and these templates are also all digital.

Lots of information condensed

User stories may seem like a very simple document at first – and that’s exactly the point. However, the effort that goes into creating these simple one-to-two line sentences is not.

Like with everything in agile, plenty of user research will have gone into coming up with those few lines of a user story. And yes, we’re talking about identifying the user persona, creating it and gathering your product requirements.

The beauty of the user story is that it condenses a lot of crucial information and provides it in plain English or layman’s terms. This way, design and development teams don’t get bogged down in technical jargon and liberated to think more creatively about design solutions.

Start prototyping today. Enjoy unlimited projects.

What is a use case?

Before agile entered the tech scene to go on and replace the waterfall method as the most popular software development methodology, use cases were a thing. They were developed towards the end of the 1980s as a ULM (Unified Modelling Language) diagram.

In some respects, use cases are similar to user stories, in that they also use plain language and are focused on achieving a particular goal for the user. They are also useful for both technical and non-technical stakeholders. However, unlike user stories, user flows focus more on the functionalities of a feature or process being developed, that is, how a system plays out. It focuses on the various steps taken, both by the user and the system to achieve a goal.

Use case structure

While use cases are sometimes presented as a list of steps, it’s a lot more common to represent these steps in a diagram, like the one below. Some teams prefer to sketch them out their use case diagrams, whereas others prefer to create them using a tool like Lucidchart.

Use cases usually assume the following structure:

The use case takes the form of a diagram with the actor/s (users) to the left of a square and the product system or responsible departments of the company to the right.

Inside the square are oval shapes are the steps involved in a process. In each oval it might be “actor creates account”, “actor selects train schedule”…etc. in that sense, it’s true to say that use cases actually focus more on the functionality.

Various teams often add in additional items such as:

The exact items you add to supplement the use case will depend on your organization and the client’s requirements. Use cases, as with most documents in agile, follow a general pattern, but are not standardized.

Use cases: providing background

However, it can be useful to add in an overview to give some background and context to the diagram. It’s also helpful for the client and for your team to know exactly who’s involved in developing the product feature, especially if it’s a large team. This is because, as at some point, you’ll need to coordinate your efforts with theirs.

Including the pre-condition for the system before the user interacts with the feature is a great way to provide context about what the feature should change. It also sheds more light on what state the system should be in afterwards (post condition).

Post conditions

Some use cases will contain post conditions, that is, the state that the system should be in after the actor has used the feature and achieved their goal (and to tell the tale happily to other users!).

Let’s look at an example of the post condition. In the above case of the actor (user) who wanted to buy a train ticket and have the barcode available on their phone for easy access, you might want the system to remember that particular booking. In this way, if the actor subsequently wants to book a train ticket at the same hour and destination, the system might remember those details to shorten the process and to prevent possible data entry errors.

Another good example of a post condition might be a banking app that lets them repeat the exact same transfer more than once but without having to enter in all the same details again such as bank account numbers, they can instead just tap and send.

Как сделать удобный продукт: на примерах разбираем критерии хорошего Use case

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

Всем привет! Я Ната, UX/UI дизайнер в Red Collar. В этой статье я расскажу о методологии, которая улучшит коммуникацию внутри команды, а значит и работу над продуктом — Use Case или «юзкейсе», а также поделюсь шаблоном для тех, кто сталкивается с ней впервые.

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

Если в команде более 5 человек, а проект длится более 3 месяцев, то может возникнуть дискоммуникация. Например:

разработчики неправильно поняли сценарий взаимодействия и реализовали фичу не так, как планировалось;

в ходе долгих обсуждений внутри команды вы сильно отклонились от первоначальной идеи и точно воспроизвести её не можете;

дизайнеры спроектировали функциональность, которая изначально не планировалась;

один и тот же кейс в разных местах реализован по-разному, что увеличивает время разработки и усложняет UX;

при тестировании пропускаются значительные ошибки;

Use Case — это описание взаимодействия с системой в виде последовательности действий для достижения конкретного результата. По сути, это метамодель, которая иллюстрирует не саму систему, а набор функциональных требований к ней.

Методология была разработана в 80-х Иваром Якобсоном. Для всех желающих погрузиться в тему глубже есть бесплатная книга Use-Case 2.0, также другие ссылки по теме оставлю внизу статьи.

Юзкейсы существуют в двух равнозначных видах: UML-диаграмма или текстовый документ. По желанию их можно совмещать

Единого формата для написания юзкейсов не существует. Каждая компания сама определяет для себя формат и уровень детализации. Опишу основной принцип написания.

Основные элементы юзкейса:

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

2. Действующие лица или участники. Можно выделить такие варианты:

«Несколько пользователей и система». Например, если мы описываем общение в чате.

3. Описание последовательности действий в виде сценария.

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

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

Пример простого юзкейса

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

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

Рассмотрели вид основных сценариев юзкейсов, а что если возникла ошибка или пользователь столкнулся со сложностями? Для этого создается альтернативный юзкейс: когда результат основного не был достигнут. Например, пользователь не смог зарегистрироваться, так как имя уже занято или с указанной почты уже создана учетная запись.

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

Пример юзкейса с альтернативными сценариями внутри основного

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

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

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

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

Советы, которые ускорят написание юзкейсов:

Важно понимать, что юзкейс — это инструмент, а цель любого инструмента — упростить и улучшить работу. Если после внедрения юзкейсов в проект вы не видите изменений, а ресурсы расходуются все больше на ведение документации, то, вероятно, вам стоит пересмотреть процесс ведения документации и протестировать другие инструменты, например, User Story.

Всем крутых продуктов!

Шаблон юзкейса + дополнительные материалы

Подготовила для вас шаблон юзкейса, открыт всем в гуглдоке.

1. Статьи и бесплатные книги о юзкейсах от создателя методологии Ивара Якобсона — даст более полное представление об инструменте «из первых рук» (en)

2. Короткое видео с простым объяснением инструмента от бизнес-аналитика + ссылка в описании к видео на их шаблон юзкейсов (en)

3. Короткое видео о юзкейсах для новичков от UX/UI дизайнер в Siemens (ru)

4. Статья от Usability.gov с краткой информации о юзкейсах и примером их заполнения (en)

5. Статья от системного аналитика, где подробно рассказывается о методологии и опыте ее применения в QIWI (ru)

User Stories or Use Cases?

Last updated on «; the_modified_time(‘jS F Y’); /* echo » at «; the_modified_time(); */ echo «

User stories and use cases are both powerful techniques to capture requirements. But which one is right for you? This post shares my recommendations.

Use Cases and User Stories in a Nutshell

Use cases describe how a customer interacts with the product using one or more scenarios. It commonly consists of several structured scenarios including main success scenario, alternative scenarios and failure scenarios as well as the actor, a trigger, and pre- and postconditions. (Note that there are also so-called casual use cases that simply consist of a brief narrative but I find that these are not very common.)

User stories describe how a customer or user employs the product. Stories consist of a name, a brief narrative (the actual story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise. User stories are more informal than use cases, as they complement the text with a conversation: The person in charge of the product and the development team members must discuss each story. This creates a shared understanding and ensures that the story is feasible and testbale.

Both techniques put the customer or user at the center of the development effort. Use cases use actors to characterise the people interacting with the product; user stories use user roles or personas; and the functionality is described from the perspective of a customer or users. This encourages a user-centric and a void a solution centric mindset, that is, to focus first and foremost on the customers and users rather than being guided by technology.

Benefits and Drawbacks

User stories have become so popular since they appeared in the second half of 1990s for one main reason: they help you move fast. User stories encourage you to quickly sketch an idea or requirement, discuss it with the development team, expose the resulting software to the customers and users, analyse the feedback or data, and then decide what to do next. User stories move from documenting requirements to tacit knowledge: product owner and development team have a shared understanding of what the product needs to do, as they discuss and sometimes even co-write the stories. This saves time, but it does require close and effective collaboration.

Use cases are more structured and detail-rich, and they can embedded in models, such as, context diagrams. Creating a use case is usually much more work than capturing a user story, and this means that the development speed tends to be slower. But more detailed requirements are useful when a close collaboration between product owner and development team cannot be achieved, for example, when you work with a remote or offshore team.

Recommendation

My advice is: work with user stories whenever you can and write use cases if you must, that is, when you cannot enable close and regular collaboration between the person in charge of the product and the development team—be it in form of onsite or online workshops. This does not imply, however, that you shouldn’t learn more about use cases, including the modelling techniques they offer. The opposite is true: I’d like to encourage you to try out both approaches so you can determine which one works best for you. Alistair Cockburn’s book Writing Effective Use Cases and Mike Cohn’s book User Stories Applied are two classic reads, which will help learn more about the two techniques.

Learn More

You can learn more about this topic with the following:

What is the difference between use case, user requirements and user stories? [closed]

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

I’m wondering what the difference is, and at what stage these different terms are used within the Agile/Scrum methodology?

Trying to write a university report and haven’t been able to find anything defining all of these terms in the same place, which has made it difficult to understand the differences.

Are some of these terms even required within an Agile approach?

2 Answers 2

It makes less sense to compare User Requirements to User Stories or Use Cases, because requirements serve very different purpose. Use Cases and User Stories describe details of a function in the system, while User Requirements state functions and non-functional properties of the system (unambiguously but without any detail).

The user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, mainly by removing the need to write use cases.

Also there’s consensus that use cases and user stories are not interchangeable:

Meanwhile, use cases are more a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents

CJM словарь

Часто в команде мы применяем специальные термины для того, чтобы обозначить разные инструменты, которые помогают разобрать по полочкам, или наоборот обобщить пользовательский опыт. Один из самых популярных инструментов — это CJM или карта пути пользователя. У этой аббревиатуры много соседей, самым близким из которых мы решили дать определения. Надеемся, наш небольшой словарик будет полезен и другим проектировщикам.

User Experience

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

Persona

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

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

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

User story

Пользовательская история — простое и короткое описание жизненной или профессиональной ситуации, в которой человеку нужно воспользоваться той или иной функцией вашего решения. Часто истории могут быть взяты из интервью с пользователями (цитаты из историй), или же написаны ими самими.

Вот такая, например, пользовательская история: “После завершения приема у моего врача деньги по умолчанию списываются с моей карты и мне не нужно возвращаться в регистратуру или кассу, чтобы оплатить посещение. Это очень удобно!”

Часто для того, чтобы не упустить здравый смысл и ценные находки проектировщиков. Тогда сервисные истории звучат скорее как “сухие” блоки описания последовательности действий.

Когда наша команда Wonderfull делала прототип мобильного приложения для туристов в Москве, которые пребывают на чемпионат мира, описание пользовательской истории в Техническом задании для разработчиков было, например, таким:

Use Case

Случай использования того или иного решения / функции. Он имеет свою длительность и как правило связан с одним целевым действием. Например, юзкейсом или случаем использования банковского мобильного приложения может быть “удаленное пополнение счета мобильного телефона” или “блокирование потерянной банковской карточки”. Если продолжить нашу историю про прием в медицинской клинике, то юзкейсом сервисного сценария может быть “автоматическое списание денег с банковской карты пациента”.

CJM / Customer Journey Map

Карта пользовательского пути — описание истории, которая случилась с человеком в процессе взаимодействия с продуктом или сервисом. Карта CJM помогает не только зафиксировать последовательность шагов, но также отметить время, которое потратил пользователь на каждый шаг и создать эмоциональную кривую полученных впечатлений.

Service Blueprint

Сервисный сценарий. Он радикально отличается от CJM / карты пользовательского пути, так как создан не для фиксации текущего опыта пользователя, а для проектирования нового сервисного решения. Сервисный сценарий состоит из двух базовых частей — “надводной” и “подводной”, то есть видимого и невидимого для пользователя пространства сервисных процедур. На примере банковского офиса к видимой части сервисного сценария относится зона для посетителей, в которой у стоек обслуживания сотрудники банка общаются с посетителями. В невидимую часть попадают все процедуры банковского сервисного процесса, которые делают работники бэкофиса для того, чтобы обработать документы и совершить заказанные пользователем банковские процедуры.

Service Solution Blueprint

Сценарий сервисного решения. Если Service Blueprint / сервисный сценарий может быть создан для всего сценария обслуживания клиента от старта до завершения процесса обслуживания, то сценарий сервисного решения касается только лишь одного юзкейса или одной пользовательской истории. Например, service solution blueprint может быть составлен для “автоматического списания денег с банковской карты пациента” из нашей предыдущей истории про медицинскую клинику. В этом сценарии сервисного решения будут прописаны действия пациента, действия врача, ответная реакция и поведение цифровой системы, а также действия сотрудника сервисного центра в случае, если что-то пошло не так.

Проще говоря, сервисный сценарий — это про весь сервис (макроуровень сервисного проектирования), а сценарий сервисного решения только лишь про одно решение, а возможно даже, про один канал взаимодействия с пользователем (микроуровень сервисного проектирования).

Service сhannel

Канал обслуживания — это формат, в рамках которого происходит взаимодействие пользователя с сервисом, или, как говорят, “пользователю оказывают услугу”. Формат может быть как цифровым, так и нецифровым. Например, офис клиники или банка — это канал обслуживания. Канал обладает такой важной характеристикой, как пропускная способность в единицу времени (то есть, сколько клиентов мы можем обслужить в этом канале за определенное время). А вот мобильное приложение — это не только канал обслуживания, но и точка контакта пользователя с сервисом. В сервисном проектировании понятия “точка контакта” и “канал” часто используются как синонимы.

Service touchpoint

Точка контакта — это конкретное “место встречи” пользователя и сервиса. Единица или сервисный “атом” в канале обслуживания. “Встретиться” со своим пользователем сервис может в транспорте, дома, или на работе, в кафе, в самолете, или в процессе регистрации на авиарейс и во множестве других мест и ситуаций.

Точкой контакта с банковским сервисом может быть интернет-банк, мобильное приложение, банкомат, окно обслуживания в офисе, и даже сам сотрудник часто выступает в роли “живой точки контакта”.

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

Если в вашем сервисе для прохождения процедуры регистрации нужно открыть большой экран стационарного компьютера и потратить 30 минут сосредоточенного внимания, а ваш пользователь по умолчанию находится в постоянном режиме цейтнота, применяет только мобильные устройства и может потратить не больше 1 минуты на регистрацию, то ваша точка контакта, скорее всего, будет обладать очень неудовлетворительными пользовательскими характеристиками.

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

Двадцать лет с юзкейсами: выжимаем практический опыт

У нас в QIWI регулярно проводятся встречи аналитиков и проектных менеджеров, где мы рассказываем друг другу о своем опыте, делимся знаниями и полезными приемами. На одной из таких встреч я рассказал о методике Use Case и о своем опыте работы с ней. Рассказ был встречен на ура, и я решил поделиться им с хабрасообществом.

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

Юзкейсы стали широко известны по книге Алистера Коберна, одного из авторов Agile-манифеста. Русский перевод книги вышел в 2002 году. На самом деле автор методики — Ивар Якобсон. Он опубликовал ее в середине 80-х, а разрабатывать начал еще с конца 60-х. Впоследствии Ивар Якобсон, Гради Буч и Джеймс Рамбо объединили свои подходы к описанию информационных систем, и родился UML.

Мои отношения с юзкейсами начались в 1996 году и складывались поначалу не очень хорошо. Я тогда работал на предприятии связи, и у меня был халявный интернет. По дайлапу, через телефонный модем на 9600 бод я бороздил просторы тогдашнего интернета в поисках методики, которая помогла бы мне описать функциональность комплексной информационной системы предприятия.

Дело в том, что автоматизация бизнес-процессов там была реализована на изолированных десктопных приложениях с изолированными же базами данных. Вплоть до того, что учет абонентов-физлиц и расчетов с ними был в одной БД, а учет корпоративных абонентов — в другой. И нигде не было, например, пула свободных телефонных номеров. Стояла задача всё это объединить в единую учетную систему для всех услуг. То, что сейчас называют «биллинг».

Я не знал, как начать формулировать требования к такой большой системе, и стал искать подходящий способ. Наткнулся на спецификацию UML версии 0.9, которая тогда только что вышла. В полном восторге, с горящими глазами, прочитал ее от корки до корки. Мне всё дико понравилось, я понял все схемы UML и как ими пользоваться. Кроме одной: диаграммы Use Case. Было непонятно, что это, зачем она и как ее применять. Ниже объясню, почему так произошло.

Проблему биллинга в конце концов решили — купили у стороннего вендора, потом несколько лет внедряли. Но я к тому времени уже был далеко. Юзкейсы писать тогда так и не научился и, в общем, не ощущал особого дискомфорта.

В 2004 году я пришел работать системным аналитиком в одну из больших аутсорсинговых компаний, где состоялось мое настоящее знакомство с юзкейсами. Стандартом разработки там был Rational Unified Process, все функциональные требования во всех проектах полагалось формулировать только в виде юзкейсов. Это, конечно, радикальный подход, мне он и тогда казался странным, а теперь я точно знаю, что так нельзя. Но тем не менее, прослушав пару тренингов и прочитав Коберна, я разобрался в методике и стал ее применять. С тех пор юзкейсы — мой любимый инструмент анализа и разработки требований.

Что такое юзкейс?

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

А вот определение из глоссария UML (перевод мой).

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

Какое определение я сам стараюсь держать в голове, когда пишу юзкейс? Оно должно мне подсказывать, что я должен сделать, о чем мне надо не забыть написать:

Юзкейс — это текст,
описывающий сценарий
взаимодействия с системой,
приводящий к значимому результату.

Оно короткое, и это хорошо. Но в нем есть несколько неявных умолчаний. О которых я тоже помню, разрабатывая юзкейс. Вот полный вариант:

Юзкейс — это текст,
описывающий сценарий (возможно, не один)
взаимодействия (кого или чего?) с системой,
приводящий (возможно, не приводящий)
к значимому (для кого?) результату.

Такое определение говорит мне, что из описания юзкейса должны быть понятны:

Установка курсов для пользователей QIWI Кошелька

Что не нужно в юзкейсе

Коберн не скрывает, что его любимый формат юзкейса — Fully Dressed (как это по-русски, расфуфыренный?). Помимо основного и альтернативных сценариев в него включаются разделы:

Разрабатывая юзкейс, вы не должны накладывать преждевременных ограничений на дизайн. Взгляните на юзкейс выше. В нем нет деталей экранных форм и управляющих элементов интерфейса. Пользователь будет выбирать вариант из выпадающего списка, выбором опции или нажатием кнопки? Это сейчас не имеет значения, решения такого уровня следует отложить на потом. Не делайте работу дизайнера, он сделает ее лучше вас.

Вы скажете: ну как же, вот у тебя написано, что директор получает уведомление по электронной почте. А почему не по SMS или каким-то другим способом? Потому что мы с пользователями на тот момент уже согласовали вариант с e-mail-ом. Если бы я написал абстрактно, то у них возникло бы недоумение: как так, разве мы не решили, что это будет e-mail? Что-то изменилось? Описав пользовательский интерфейс чуть более детально, чем полагается по методике, я позаботился о читателе, чтобы он не споткнулся, читая юзкейс.

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

Что еще отсутствует в приведенном примере? В нем нет ничего о том, как курсы передаются из АБС в процессинговую систему QIWI Кошелька. Потому что это предмет другого взаимодействия и другого юзкейса. Если из-за какого-нибудь сбоя курсы не дойдут до процессинга — это не забота трейдера. Для него результат достигнут: курсы назначены и утверждены.

Не старайтесь запихнуть всё в один юзкейс. Разграничивайте их исходя из целей пользователей.

Условные конструкции

Одно из основных требований Коберна — отсутствие ветвлений в сценарии. Если есть альтернативный вариант развития событий, его полагается описать отдельно. Любую, сколь угодно сложную блок-схему с ветвлениями и циклами можно представить в виде набора линейных участков.

Я не всегда следую этому правилу. Признаюсь, я подправил свой юзкейс перед тем, как выложить его сюда в качестве примера. А в оригинале он выглядел вот так. Отличия начинаются с п.3.

Сценарий установки курсов

Бизнес-правила

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

Вот какие бизнес-правила были приложены к юзкейсу из примера.

Следует всегда внимательно оценивать, какие детали стоит включить в сценарии, а какие — вынести в список бизнес-правил.

Когда систем несколько

Одно из центральных понятий в теме юзкейсов — это «рассматриваемая система» (SuC, System under Consideration, или SuD, System under Development). Согласно классическому подходу, есть система, которую мы разрабатываем, и у нее есть граница. Всё во Вселенной делится на то, что внутри системы, и то, что вне ее. И мы рассматриваем исключительно такие взаимодействия, которые идут через границу системы. Зная, что на входе и на выходе мы можем решить, как оно должно работать внутри.

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

Но в реальности мы живем в многоклеточном организме. У компании много систем, они взаимодействуют между собой и совместно реализуют множество функций бизнеса. Почти в каждом проекте мы должны удовлетворить очередную потребность компании через внесение изменений, по возможности минимальных, в несколько систем.

У Коберна такое предусматривается, там есть вариант «организация — прозрачный ящик». Но у него об этом как-то вскользь. В основном рассказ идет о том, как описать единственную рассматриваемую систему в виде черного ящика.

Я предпочитаю в своих юзкейсах не делать различий между системами, к которым мы ставим требования, и внешними акторами. Каждая из систем, которые мы модифицируем, считается таким же участником взаимодействия, как и все остальные. С точки зрения классической методики так нельзя: система — то что внутри, акторы — то что снаружи.

Зато мой подход позволяет извлечь набор функциональных требований к каждой системе по отдельности. Берем все шаги юзкейсов, в которых участвует данная система. Смотрим, существующая ли это функциональность или новая, или существующая, но с какими-то изменениями. Шаги, в которых нет изменений, выкидываем. То, что остается — передаем команде разработчиков системы для детальной технической проработки. Повторяем для каждой из систем, участвующих в юзкейсах проекта.

Сказуемое без подлежащего

Время от времени в сценариях приходится встречать такие фразы: «данные сохраняются в БД», «пользователю отправляется СМС». Не бывает действий, которые выполняются сами по себе. Их всегда выполняет кто-то или что-то.

Я полностью согласен с рекомендацией Коберна о структуре предложений в сценарии. Каждый шаг юзкейса должен начинаться с подлежащего — кто или что выполняет действие. Затем сказуемое — какое действие. Дальше всё остальное. Сказуемое должно быть в настоящем времени и в действительном залоге. «Пользователь выбирает населенный пункт», «Приложение показывает список товаров».

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

Неуспешные сценарии

Иногда в проектах забывают предусмотреть случаи, когда что-то происходит не так. К примеру, клиент совершил покупку, а потом захотел ее вернуть. Если об этом не подумали заранее, то приходится срочно допиливать код после запуска. А в тяжелых случаях — выбросить всё и организовать взаимодействие систем в другом порядке.

Техника юзкейсов помогает (хотя и не гарантированно) избегать подобных осложнений. Написав основной сценарий, подумайте: что может пойти не так на каждом из шагов? Что может случиться в другом месте после того, как здесь всё уже закончилось? Каждый найденный вариант отклонений нужно выписать, для начала хотя бы одной фразой. Потом, если потребуется, проработать по шагам.

Если в проекте описаны только основные сценарии юзкейсов, то велик риск, что забыли что-то важное.

Модель предметной области

Юзкейсы должны опираться на модель предметной области, которую все участники проекта понимают одинаково. Вспомним первый шаг нашего примера: «Трейдер создает заявку на установку курсов. В заявке даются все исходные курсы покупки и продажи по списку котируемых валют, а также дата и время их вступления в силу (см. форму заявки)». В одном пункте употреблено пять понятий. Некоторые из них новые, возникли только в этом проекте.

Самый известный инструмент введения в предметную область — глоссарий. Следует включать в глоссарий только те слова, которые кому-то могут быть непонятны. Если начать объяснять всё, то после первых трех пунктов читателю станет скучно и он закроет глоссарий, не добравшись до важного.

Можно писать краткие статьи, объясняющие новые понятия. Вот пример — выдержка из документации всё того же проекта:

Имеется список поддерживаемых валют. Этот список делится на две части:

Для каждой валюты также известно, котируется ли она к рублю или к доллару США. «Котируется» в данном случае означает «курс задается Казначейством».

(Считаем, что доллар котируется к рублю, но не рубль к доллару, так как курс доллара задается в рублях, а не наоборот).

Еще один классический способ описания модели предметной области — диаграммы «cущность-связь» в формате IDEF1 или статических структурных диаграмм UML.

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

Перечень юзкейсов

Если требования описаны в форме юзкейсов, то их список становится полезным инструментом управления проектом. Например, в списке юзкейсов можно расставлять приоритеты реализации, можно измерять прогресс по количеству реализованных юзкейсов. Перечень юзкейсов может существовать в форме собственно перечня (Use Case Survey) или в виде диаграммы юзкейсов.

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

Здесь информации больше: мы видим участников взаимодействия и в каких юзкейсах они участвуют. Вопреки Коберну, в качестве участников показаны системы, к которым мы ставим требования (расчетная система, АБС), а также внешние неизменяемые системы (биржевой терминал, система бухучета) и пользователи.

Теперь я могу вам объяснить, почему юзкейс-диаграмма осталась для меня непонятной при первом знакомстве с UML. Дело в том, что все другие диаграммы UML моделируют систему, они показывают ее нам в разных «ракурсах». А юзкейс-диаграмма иллюстрирует не саму систему, а набор функциональных требований к ней. Юзкейс-диаграмма, следовательно, — модель модели. Не так просто было сразу это понять.

Заключение

Юзкейсы — уже довольно старая методология. За 20 лет появились новые подходы, которые потеснили методику юзкейсов в тех областях, в которых она когда-то была лучшей. Например, юзер стори позволяют более эффективно управлять требованиями в Agile-проектах. Методы дизайна пользовательского опыта помогают разрабатывать продукты, успешные на рынке. На мой взгляд, сегодня в сравнении с более современными методами юзкейсы находятся примерно в том же положении, какое в свое время занимали блок-схемы по сравнению с юзкейсами. Старые добрые блок-схемы — теперь диаграммы Activity в UML — используют до сих пор. Но когда-то они считались универсальным способом проектирования и описания программ, а потом их применение сузилось с появлением методик таких как Use Case, UML, BPMN.

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

User stories vs use cases: how they stack up

Just what exactly are the differences between user stories and use cases? Aren’t they the same? Don’t they have the same goals? Why not just settle on one word for both of them? As it turns out, user stories and use cases, while they do have similar purposes, are not quite the same.

In this post, we’re looking at a close match up: user stories vs use cases. Discover the important differences and which one is right for you

Just what exactly are the differences between user stories and use cases? Aren’t they the same? Don’t they have the same goals? Why not just settle on one word for both of them? As it turns out, user stories and use cases, while they do have similar purposes, are not quite the same.

In this post, we’ll have a look at the different formats these documents take and the type of content they contain. Hopefully, after reading this post, the differences will be clearer. You should also have a better idea of which one you should be including in your development cycle.

User stories vs use cases: documents galore

The agile world is dotted with a seemingly endless population of user-centric documents to use alongside your wireframe tool. The problem is, all of them are helpful.

However, the paradox is that agile is all about cutting through red tape and minimizing surplus documentation. And since many documents have similar functions, to remain truly agile, you may need to decide which documentation is relevant for your team and clients at any given moment. Too many documents and procedures in a small organization might be overkill.

Indeed, many agile documents have striking similarities and some may just be synonymous with others, such as user journeys, user journey boards and user journey maps which are essentially the same thing. Nonetheless, there are some documents that tend to get misinterpreted as synonymous when they are in fact different.

This is particularly true when we look at user stories vs use cases. People sometimes mix up these documents because they sound similar and have familiar goals. However, if you were to see both a user story and a use case side-by-side, you’d quickly notice the differences. Let’s look at what each document entails. If you already have a good idea of what each one is, feel free to skip down to user stories vs use cases for a battle finale!

What is a user story?

User stories define the who, the what and the why of a product feature. They’re usually aimed at developers but are intended to be easily understood by everyone on the team, including clients. They outline what a user needs to get done, from that user’s point of view.

User story structure

They often comprise just one sentence or a couple of lines written in the following structure:

An example of this could be:

“As a user, I want to have a barcode ticket for my train pass on my phone so that I don’t need to print it off and carry a paper around with me.”

That is then followed by acceptance criteria which usually contain the information that informs the developer or product manager when the user story can finally reach its conclusion, in other words, when the feature is ready. A product manager will normally hold a discussion with design and development teams to agree on what outcomes of the user story need to be satisfied. An acceptance criteria typically takes on the following format:

Using that format, an acceptance criteria generally tends to look a little like the following:

“Given there are sufficient funds in the user’s bank account, when they enter their details correctly and select a valid hour, the ticket should appear on the dashboard, then a confirmation email and purchase receipt should be sent to the email address the user registered with.”

User story mediums

User stories are often simply written on index cards, something which owes to the pure simplicity of this important agile document. The acceptance criteria is often written overleaf.

However, this isn’t ’t the only medium that user stories can come in and they are often in fact digitalized and written up into excel or word documents or google docs or even PowerPoint presentation format.

They are often included in kanban or other agile software and assigned scrum points for each one There are actually many templates available to help teams to get started with creating user stories and these templates are also all digital.

Lots of information condensed

User stories may seem like a very simple document at first – and that’s exactly the point. However, the effort that goes into creating these simple one-to-two line sentences is not.

Like with everything in agile, plenty of user research will have gone into coming up with those few lines of a user story. And yes, we’re talking about identifying the user persona, creating it and gathering your product requirements.

The beauty of the user story is that it condenses a lot of crucial information and provides it in plain English or layman’s terms. This way, design and development teams don’t get bogged down in technical jargon and liberated to think more creatively about design solutions.

What is a use case?

Before agile entered the tech scene to go on and replace the waterfall method as the most popular software development methodology, use cases were a thing. They were developed towards the end of the 1980s as a ULM (Unified Modelling Language) diagram.

In some respects, use cases are similar to user stories, in that they also use plain language and are focused on achieving a particular goal for the user. They are also useful for both technical and non-technical stakeholders. However, unlike user stories, user flows focus more on the functionalities of a feature or process being developed, that is, how a system plays out. It focuses on the various steps taken, both by the user and the system to achieve a goal.

Use case structure

While use cases are sometimes presented as a list of steps, it’s a lot more common to represent these steps in a diagram, like the one below. Some teams prefer to sketch them out their use case diagrams, whereas others prefer to create them using a tool like Lucidchart.

Use cases usually assume the following structure:

The use case takes the form of a diagram with the actor/s (users) to the left of a square and the product system or responsible departments of the company to the right.

Inside the square are oval shapes are the steps involved in a process. In each oval it might be “actor creates account”, “actor selects train schedule”…etc. in that sense, it’s true to say that use cases actually focus more on the functionality.

Various teams often add in additional items such as:

The exact items you add to supplement the use case will depend on your organization and the client’s requirements. Use cases, as with most documents in agile, follow a general pattern, but are not standardized.

Use cases: providing background

However, it can be useful to add in an overview to give some background and context to the diagram. It’s also helpful for the client and for your team to know exactly who’s involved in developing the product feature, especially if it’s a large team. This is because, as at some point, you’ll need to coordinate your efforts with theirs.

Including the pre-condition for the system before the user interacts with the feature is a great way to provide context about what the feature should change. It also sheds more light on what state the system should be in afterwards (post condition).

Post conditions

Some use cases will contain post conditions, that is, the state that the system should be in after the actor has used the feature and achieved their goal (and to tell the tale happily to other users!).

Let’s look at an example of the post condition. In the above case of the actor (user) who wanted to buy a train ticket and have the barcode available on their phone for easy access, you might want the system to remember that particular booking. In this way, if the actor subsequently wants to book a train ticket at the same hour and destination, the system might remember those details to shorten the process and to prevent possible data entry errors.

Another good example of a post condition might be a banking app that lets them repeat the exact same transfer more than once but without having to enter in all the same details again such as bank account numbers, they can instead just tap and send.

User stories vs use cases: differences

Now let’s pit user stories against use cases and see up front, apart from the structural format, how these two agile documents differ.

Degree of detail

User stories are normally, and purposely, more vague. The user story provides a simplified, abridged description in layman’s terms of what a feature should help the user do. This leaves it more open to interpretation and encourages more creativity and discussion on the part of the design and development teams.

Use cases cover more ground by showing how the user should interact with the system and how the system should reciprocate. They go into further detail about how the individual steps in a feature’s process.

Sprint length

The difference in detail is a big factor in user stories vs use cases. Perhaps one of the main differences between use cases and user stories is that the former are often completed over multiple sprints or iterations. On the other hand, user stories often contain features or details small enough to be completed over the course of one sprint. A team may even get through multiple user stories in one sprint.

User stories are much briefer, more succinct documents and generally tend to be used for smaller features. They can also be used to break larger features down into small steps or multiple user stories. Conversely, use cases tend to give more of an overview of a larger system functionality.

Use cases generally list out the system functionalities required for each step of a feature’s process. It shows you the input required from the user and the system.

Structure

There’s also a whopping big difference in the structure when it comes to user stories vs use cases. The user story is just a line or two of a statement about what exactly the user wants to achieve that can be written on a simple index card.

This makes them quick and easy to generate. On the other hand, use cases can take a bit more time to put together, as they detail out each step and are often represented in a diagram.

Because use cases list out the steps and demonstrate them in diagram form, this means they can be helpful in a practical sense for identifying friction points in the process a user undergoes to achieve a goal. However, this can also be done by using a combination of user stories and user flows, which are basically a map of the different screens a user goes through in a process.

When to use user stories or use cases

If you’re caught between using user stories or use cases, the only answer is that it depends on your team and how big it is. Furthermore, it depends on the type of product you’re working for, your organization and the client.

The best rule of thumb when deciding between the two is to have a discussion with all stakeholders involved in the product. Hash out the pros and cons of each and make a decision on which could be easier and faster for your team. Remember: to keep things agile, you should always try to avoid adding in too much detail.

Benefits of using user stories and use cases together

Nevertheless, you might reach a conclusion where you and your team decide to combine both user stories and use cases. Combining these two documents can also have its payoffs if done strategically.

Use cases make a great addition when combined with user stories because they still keep the plain language tone but go into extra detail about the system functionalities relevant to satisfy the user’s goal.

In fact, if you’re going to implement use cases in your development cycle, some experts recommend starting with use cases first, then moving on to user stories at later iterations. In this sense, you’d be using use cases to underpin the fundamental features of the product, then using user stories when adding the extra features at a later date.

Afterall, there’s something to be said for using use cases at the start of a large project or software development phase. It affords you a more detailed and structured approach.

Don’t replace user stories with use cases

In general, user stories are an incredibly powerful, simple and versatile tool in an agile environment. Providing your team has carried out adequate research into your user personas, generating user stories can be much faster than generating use cases.

Notwithstanding, if you happen to work for a large client, company, corporation or government body which requires copious amounts of documentation, you might have to use use cases for every feature. However, depending on the scale of your project and stakeholders, like clients, you may decide that user stories are enough to develop the features of your product.

The takeaway – User stories vs use cases

User stories and use cases share some similar concepts but are fundamentally different documents, each with their own unique benefits. User stories are faster to generate, spark conversation and offer a greater degree of creative flexibility. On the other hand, use cases offer up greater detail and a more structured approach to each step but take longer to generate.

The real answer when it comes to choosing between them is that it doesn’t really matter – it’s about whatever helps your team to be the most agile possible. If use cases help your team, there is no reason that they cannot also be implemented into your agile process and used alongside user stories.

Building Better Software

The official website of O’Reilly authors Jennifer Greene and Andrew Stellman

Requirements 101: User Stories vs. Use Cases

Here’s a question that I get over and over again:

What’s the difference between user stories and use cases?

Before I dive into an answer to that question, let’s rewind a little bit and talk about where user stories came from. I like them because they’re a great example of how the Agile movement changed the software world. Programmers used to just dive right into software projects and start coding. Whenever one of those pesky users started to tell us what they needed, we’d stop them and say something like, “Don’t worry, I totally get it. I know what you need.” The Agile folks figured out that “I know what you need” is a nasty little trap that programmers — especially good ones — fall into. We’d spend the whole project thinking that we understood our users’ needs, only to deliver software that they didn’t want. The Agile folks realized that if developers had to start working with users throughout the project to understand their needs if they wanted to avoid the code-and-fix trap.

Jenny and I teach you all about use cases and requirements in our first book, Applied Software Project Management (O’Reilly, 2005).

And that’s why I think the user story is one of the most useful tools to come out of the Agile movement. A user story — some people call it a scenario — expresses one very specific need that a user has. It’s usually written out as a couple of sentences. Most user stories are written in the language of the users, so any user should be able to read a user story and immediately understand what it means. A lot of time, user stories are written on index cards, although I’ve put them in Word documents, Excel spreadsheets and Wiki pages (depending on how the particular project is run).

A use case is similar to a user story, because it also describes one specific interaction between the user and the software. When I’m training people to improve the way they write down their project’s requirements, I often describe the use case as a “deceptively simple tool” that helps us find and write down all of the ways users interact with the software.

Looking at those definitions, I can definitely see why there’s confusion about the difference between user stories and use cases. If you look at the last two paragraphs, it might sound like I said the same thing twice! But while user stories and use cases are definitely similar, there are important differences between them. Each serves a distinct purpose, and I think they both have their place on a well-run software project.

I think the easiest way to understand the difference between use cases and user stories is to take a look at an example. Luckily, I’ve got one that I think helps make the difference clearer.

In our first book, Applied Software Project Management, Jenny and I spend a lot of time talking about how to develop use cases and use them to build better software. And as an example, we showed a use case for a software feature that everyone should be familiar with: a search and replace feature from a word processor. Comparing a user story for search and replace with a use case for the same feature helps highlight the differences.

It’s not hard to find lots of user story examples. There are lots of different ways you’ll see a user story formatted (although if you’re looking for a user story template, a 3×5 index card should be a good starting point!). So what would a user story for search and replace look like? I took a stab at writing one:

(One thing I like to do with user stories is to use “he” or “she”, rather than try to be gender-neutral. I think this makes the user in the story easier to connect with by personifying him a bit. It it also lets me write in a more conversational tone, which makes the user story friendlier and, I think, a bit easier to read and understand.)

Now, if you’re not familiar with user stories, you might think to yourself, “Wait a minute, my word processor’s search and replace feature does a lot more than that!” And that’s okay. A typical user story will have enough information to help the user understand what it is the software needs to accomplish, but it’s not meant to be a complete description of how the software works. I’m not going to try to give a long lesson in writing effective user stories here; I highly recommend reading Mike Cohn’s excellent articles and posts aboout user stories. (Mike, incidentally, is one of the software development veterans who contributed to our latest book, Beautiful Teams [O’Reilly, 2009]. He has some really fascinating things to say about Agile planning.)

So what would a use case sample look like for search and replace? Here’s the use case example Jenny and I built to demonstrate how use cases work:

Now, if I were a developer building a word processor or text editor, I’d actually be able to write a search and replace feature that implements that particular use case. (Just to be clear: there are many different use case formats; Jenny and I use this use case template in our book because it’s stripped down to the bare minimum sections that we think an effective use case should have.)

Here’s something about use cases that I think is interesting. While you were reading through our use case example, were you thinking of something that looks like the Replace dialog in Notepad or Microsoft Word, or the Find dialog in TextEdit? If so, take another look at the sample use case. It doesn’t have any words like “window,” “button,” “click,” “field” or “checkbox”. It’s all about what actions the user takes, and how the software responds. And there are many different ways that you could build software that implements the use case. Have you ever used the search and replace feature in vi? What about the search and replace feature in Emacs? They have very different user interfaces! Who knew there were so many ways you could implement search and replace? But if you compare each of them with this use case, they all follow the same basic course of events.

So now that we’ve gone through the use case and user story examples, what’s the difference between user stories and use cases? Here’s what I think are some of the key differences:

Once you get a sense of how user stories and use cases differ, you can start to see what purpose they can serve on your project. And if you only use user stories, or if you only use cases, then maybe on your next project you can try using them both.

Основы пользовательских историй. Часть 1. Введение

Перевод: Александр Якима (www.enter-agile.com)
Независимый консультант, agile-тренер. В IT-индустрии с 2002 года. Работал менеджером проектов, программ, а также присейл-менеджером в аутсорсинговых компаниях и директором по разработке в стартапах Силиконовой долины. В 2007-2008 сотрудничал с тренинг-центром Luxoft.

Аннотация:
В этой статье мы предлагаем обзор происхождения и приложений пользовательских историй, являющихся ключевым механизмом в гибких методах разработки и служащих проводником требований заказчика сквозь поток ценностей. В свою очередь, пользовательские истории являются критическим элементом в статьях «Бережливая и масштабируемая информационная модель требований для гибких компаний» и «Общая картина гибкости компании», обе статьи можно найти в блоге. Текущая же статья извлечена из будущей книги «Гибкие требования: бережливые практики управления требованиями для команд, программ и предприятий», издание которой запланировано на 2010 год. Отдельная благодарность Дженнифер Фосетт (Jennifer Fawcett) и Дону Видригу (Don Widrig) за их вклад в работу над книгой.

О терминологии (примечания автора перевода):
Центральным объектом статьи, как читатель уже мог догадаться, является пользовательская история, в оригинале звучащая как user story. Существует несколько различных, в том числе и довольно экстравагантных переводов этого термина (напр., «пожелание»). Однако при переводе я решил пользоваться исключительно практическими мотивами, именно поэтому мы используем термин «пользовательская история» в несколько официальном ключе и для непосредственных выкладок — «стори». Дело в том, что именно этот термин преобладает в быту большинства гибких команд при работе с англоязычными заказчиками и поэтому вполне оправдан.

Основы пользовательских историй

Они были на великом пиру языков, но довольствовались крохами.
— паж Моль к Костарду, «Напрасный труд любви», Уильям Шекспир

Введение

В гибкой разработке пользовательская история — это легковесная и более живая замена традиционным средствам описания требований: функциональных спецификаций, описаний сценариев использования (use cases) и т. д. На самом деле можно даже утверждать, что пользовательская история (стори) является наиболее весомым артифактом в гибкой разработке, поскольку представляет собой контейнер, служащий переносу потока ценностей к пользователю, а суть гибкой разработки как раз и состоит в быстрой доставке ценного результата.

Стори служит также метафорой всему нашему подходу, базирующемуся на инкрементальной доставке ценностей, а именно:

Определить полезную стори — реализовать и оттестировать в рамках короткой итерации — продемонстрировать и/или доставить ее пользователю — получить фидбек — усвоить информацию — повторить в цикле!

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

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

Пользовательские истории: обзор

В вышеупомянутых статьях и связанных с ними публикациях в блоге я подчеркивал существенность вклада Скрам-модели в гибкие практики для компаний, отмечая, к примеру, само определение роли продакт оунера (product owner), являющейся неотьемлимой по отношению к работе с требованиями. Но самим изобретением пользовательской истории мы обязаны XP и именно сторонники XP и разработали всю широту и глубину этого артефакта. Хотя это значительно менее значимое «методологическое распутье», чем это может показаться, так как пользовательские истории сейчас обычно входят в рамки Скрам-курсов как средство построения бэклога и определения состава Спринта. Наверняка мы должны благодарить Майка Кона (Mike Cohn) за большую часть этой интеграции, так как он обстоятельно проработал пользовательские истории в своей книге User Stories Applied [см. Cohn 2004], и был очень активным в сообществе Scrum Alliance.

Для наших целей мы определим пользовательскую историю так:

Пользовательская история — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.

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

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

Пользовательская история фиксирует короткую формулировку функции на карточке или, возможно, с помощью онлайн-средства.

Подробности поведения системы не фигурируют в этой короткой формулировке, а оставляются на потом и разрабатываются посредством диалога и критерия приемки командой и продакт оунером.

Пользовательские истории помогают преодолевать разрыв между разработчиками и пользователями

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

Билл Вейк (Bill Wake), один из создателей XP, описывает это следующим образом(2):
Пиджин (pidgin) — упрощенный язык, обычно используемый в торговле, позволяет людям, которые не могут общаться на своем родном языке, тем не менее работать вместе. Пользовательские истории действуют подобным образом. Мы не ждем от заказчика или пользователей точно такого же видения системы, как у разработчиков; стори действуют как пиджин, где обе стороны всегда могут договориться, чтобы эффективно вместе работать.

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

Пользовательские истории — это не требования

Несмотря на то, что стори играют в огромной степени роль, ранее принадлежавшую спецификациям требований (SRS), сценариям использования и т. п., они все же ощутимо отличаются рядом тонких, но критических нюансов:

Литература
Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Boston, MA: Addison-Wesley.

Use cases vs user stories in Agile development

By Courtney

18 January 2012

Tags: Agile

User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically (largely), removing the need to write use cases. Find out how.

Are user stories the same as use cases?

When running our workshops, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.

Looking around the web, there’s consensus that use cases and user stories are not interchangeable:

My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear with me – it will all be clear in soon”. But I thought it was time to dig further down into this.

Use cases and user stories

Let’s start with some definitions.

User stories

A user story is a short description of something that your customer will do when they come to your website or use your application/software, focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use.

A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.

Use cases

A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:

At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos? Won’t it take some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.

Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see this Breathingtech post, and the Use Case Blog). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making. By the end of this process, you’ve covered off everything a use case would have told you, but in an organic manner.

Clarifying user stories without use cases

Acceptance criteria

User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:

Writing the acceptance criteria is the first step of fleshing out the details of your user story.

Sprint planning meetings

In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (i.e. their highest priority features) and the team commits to the stories they will complete in the sprint.

As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. You’ll be able to quickly confirm or correct assumptions, and start to get rid of any ambiguity about the requirements.

The team further clarify assumptions and ambiguities as they estimate the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And this clarification process continues as they write the individual tasks for each story.

Standups

We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.

Wireframing

I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.

More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.

Design and development

Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.

No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met. You can learn more about the difference between the definition of done and acceptance criteria here.

Overall

This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.

And finally, in conclusion

There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.

Introduction to user stories — blog series

Further reading

Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.

Here are some other posts you might enjoy

Tina Fey’s Four Rules of Improv, as applied to Scrum

How the four rules of improv that Tina Fey describes in her book Bossypants translate to the spirit of Scrum projects.

Business Analysts and Scrum projects: A short case study

View a case study on business analysts and Scrum. See how BAs can contribute to Scrum projects and get additional resources on Scrum for BAs.

Make a bigger impact tomorrow

Level 5, 57-59 Courtenay Place,
Te Aro, Wellington, 6011,
New Zealand

© 2022 Boost.
All Rights Reserved

Level 5, 57-59 Courtenay Place,
Te Aro, Wellington, 6011,
New Zealand

What’s the difference between «use case», «User Story» and «Usage Scenario»?

Is there an exact, but simple and understandable defintion of the distinction between «use case», «User Story» and «Usage Scenario»?

there are quite a bunch of explanation, but right now, I see no one that explains the differences in a single sentence, or two.

10 Answers 10

A User Story is a more informal, friendlier and smaller version of a Use Case, minus the UML diagram; it is typically used in iterative scenarios.

A Usage Scenario is a Use Case drawn out into a step-by-step procedure, sometimes accompanied by a flowchart.

To me, the biggest differences between a User Story and a Use Case are:

According to Scott W. Ambler on Usage Scenarios, these artifacts look like a Use Case’s flow:

A usage scenario, or scenario for short, describes a real-world example of how one or more people or organizations interact with a system. They describe the steps, events, and/or actions which occur during the interaction. Usage scenarios can be very detailed, indicating exactly how someone works with the user interface, or reasonably high-level describing the critical business actions but not the indicating how they’re performed.

Honestly, the differences with a Use Case’s flow is not crystal clear, even after reading this paragraph (the last sentence being maybe the most important):

As you can imagine, there are several differences between use cases and scenarios. First, a use case typically refers to generic actors, such as Customer, whereas scenarios typically refer to examples of the actors such as John Smith and Sally Jones. There’s nothing stopping you from writing a generic scenario, but it’s usually better to personalize the scenarios to increase their understandability. Second, usage scenarios describe a single path of logic whereas use cases typically describe several paths (the basic course plus any appropriate alternate paths). Third, in UP-based processes use cases are often retained as official documentation whereas scenarios are often discarded after they’re no longer needed.

I may be wrong, but Usage Scenario really sounds like Use Case flow but rebranded with an Agile touch.

There isn’t an exact definition of any of this stuff. It all varies a little bit (or a lot) from company to company and from system to system.

Your best bet is to find an example already in place for your current project and follow it.

If you are creating a new system, you can find definitions of different types of use cases for whatever system you prefer—Just pick the pattern that seems to communicate your intentions best.

Don’t get hung up on names.

A user story is always informal and describe a user’s need. A use case can be either formal or informal, and describes system behavior.

It is possible to have «tech» user stories, the same is not true for use cases.

Once done, the user story is typically discarded. Use cases may be maintained during the product life cycle.

The scope is also different. User stories are typically smaller in scope, and consequently a use case comprises several user stories. A changed requirement for an existing system is described in a new user story, or an updated version of the use case.

The similarity between user stories and uses cases is that both of them are used for planning and scheduling.

Examples of User Stories are:

As the granularity of the Use Case scenarios are defined they become more about function and procedure.

For a discussionin depth on this topic I suggest reading http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison on Alistair Cockburn’s website. Since he’s a signatory of the Agile Manifesto, the person who coined User Stories and has been considered a Use Case expert for the last couple of decades I think he’s an excellent source for more info.

_{Quick temporary note: This post needs improvements to better answer the question, such as 1) additional details should be included from references 2) some citations maybe 3) overall correctness of English 4) overall quality of narrative 5) etc. I’ll be back to it. Feel free to improve it yourself.}

Taking a look at their templates can give valuable insight into the differences between these terms.

Use case

There are multiple templates for use cases. I found 3 after a quick search: 1, 2, 3. Some points they (sometimes vaguely) have in common are:

Some additional points that can be included are Level, Minimal Guarantees, Trigger, etc.

Above is what’s called fully dressed use case. You can simplify use case creation by using a casual use case by using only the most vital points, for example:

Use cases were created and popularized by Ivar Jacobson in late 80s early 90s. Later other people also contributed to his work (one of such people is Alistair Cockburn who is author of Writing Effective Use Cases). To paraphrase Martin Fowler use cases can make use of text and UML diagrams, but their greatest value lies in the text of it. They are best when they are not big and easy to read.

User story _{(aka. Feature)}

As a particular type of a user
I want to do something
so that some reason.

In addition, user story can have acceptance criterias.

Bill Wake developed INVEST mnemonic to describe what qualities a good user story should have, and I will borrow Martin Fowler’s short summary of that from his website:

Independent: the stories can be delivered in any order
Negotiable: the details of what’s in the story are co-created by the programmers and customer during development.
Valuable: the functionality is seen as valuable by the customers or users of the software.
Estimable: the programmers can come up with a reasonable estimate for building the story
Small: stories should be built in a small amount of time, usually a matter of person-days. Certainly you should be able to build several stories within one iteration.
Testable: you should be able to write tests to verify the software for this story works correctly.

Usage scenario

Usage scenario follow the GWT pattern which stands for Given-When-Then, like so:

Scenario: title
Given: a particular fact
And: another particular fact (may be optional)
When: some event happens
Then: some other event happens

Usage scenarios are associated with Behavior-Driven Development. It sounds very similar to a test. Martin Fowler in his blog post gives some history and reasoning behind usage scenarios. Here is the important part:

The given part describes the state of the world before you begin the behavior you’re specifying in this scenario. You can think of it as the pre-conditions to the test.
The when section is that behavior that you’re specifying.
Finally the then section describes the changes you expect due to the specified behavior.

Usage scenarios can be used for writing test for your application. To quote the last paragraph of Martin’s post:

Although Given-When-Then style is symptomatic to BDD, the basic idea is pretty common when writing tests or specification by example. Meszaros describes the pattern as Four-Phase Test. His four phases are Setup (Given), Exercise (When), Verify (Then) and Teardown. Bill Wake came up with the formulation as Arrange, Act, Assert.

Усиление методики UseCase данное в книге Алистера Кобёрна

В книге «Современные методы описания функциональных требований к системам» Алистер Кобёрн описал один метод написания части постановки задачи, а именно метод use case.

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

Пример use case

Как выглядит сценарий, на примере авторизации на сайте через email:

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

Контекст: Не авторизованный клиент авторизуется на сайте, чтобы сайт его узнал и показывал персональную для него информацию: историю просмотров, покупок, текущее количество бонусных баллов и пр, используя email как логин.
Уровень: цель пользователя
Основное действующее лицо: клиент (посетитель нашего интернет-магазина)
Область действия: Взаимодействие клиента с сайтом интернет-магазина
Заинтересованные лица и интересы:

Что здорово

Проверки на полноту и соответствие целям, то есть можно отдавать требования на проверку другому аналитику, допуская меньше ошибок на стадии постановки задачи.

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

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

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

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

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

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

Дополнение к методу из практики

Use case не является независимо приоритизируемой частью постановки, в отличии от user story.

В указанном сценарии, рассмотрим исключение “6.а. Аккаунта с данным email не обнаружено.” и следующий шаг “6.а.1 Система показывает сообщение о неуспешности и переходит к шагу 2”. Что из негативного осталось за кадром? Для клиента любой возврат равносильно тому, что весь труд который он проделал вводя данных выкидывается на свалку. (В сценарии этого просто так не видно!) Что можно сделать? Перестроить сценарий так, чтобы этого не возникало. Можно ли так сделать? Можно — как пример, посмотрите на сценарий авторизации в Google.

Оптимизация сценария

Книга рассказывает про формализацию, но мало рассказывает про методы оптимизации таких сценариев.

Но возможно усилить метод с помощью оптимизации сценариев и способ формализации use case позволяет это сделать. Конкретно, над каждым возникающим исключением нужно подумать, определить причину и перестроить сценарий так, чтобы избавиться от исключения или минимизировать путь клиента.

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

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

Первое что нужно сделать — нужно давать выбрать только тот город, куда мы можем сделать доставку. Когда это делать? Перед моментом выбора товара на сайте (автоопределение города через ip с уточнением).

Второе — нужно давать выбор только того товара, который мы можем доставить клиенту. Когда это делать? В момент выбора — на плитке товаров и карточке товара.

Эти два изменения значительно практически избавляют от этого исключения.

Требования на измерения и метрики

Рассматривая задачу минимизации обработки исключений можно поставить задачу на отчетность (не описывается use case). Как много было исключений, в каких случаях они возникали, плюс как много сценариев прошло успешно от входящих.

Но увы. Опыт показал, что требований на отчетность к сценариям в таким виде недостаточно, нужно рассматривать требования в отчетности на процессы, которые описываются в основном не в виде use case.

Выход на Usability

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

Для проектирования юзабилити мы добавили входной раздел — отображаемые данные.

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

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

В примере с авторизацией клиента, если выделить вводимую информацию на логин и пароль, то стоит изменить сценария авторизации с выделением этапов ввода отдельно логина и отдельно пароля (и это сделано в Yandex, Google, но не сделано в большинстве интернет-магазинов).

Выход на требуемые преобразования данных

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

Итого

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

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

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

Гайд по User Stories для Junior BA / PO / PM

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

Содержание:

Вводная информация о User Stories

Что такое User Stories

Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.

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

В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».

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

Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:

Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!

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

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

Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.

Так, истории пишутся в три строки:

Job Stories

В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.

Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.

«Тело» JS делится на три части:

Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.

Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.

Expected Outcome: описывает, что получит юзер после использования функции.

Job Stories могут писаться по двум форматам:

В одну строку:
When X I want to Y so I can Z» или «When X, actor is Y so that Z.

В три строки:
When X
I want to Y
So I can Z.

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.

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

Решает ли это настоящую проблему юзера?

Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?

Какие последствия от такого решения?

А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».

Пример работы техники «5 почему».

Три С в User Story

Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».

Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.

Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.

Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.

User Personas

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

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

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

Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:

Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.

Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?

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

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

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

Что же в сухой практике использования User Personas?

Отрицательный персонаж

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

Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.

Ключевой персонаж

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

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

INVEST

По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.

I — Independent — Независимый

Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).

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

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

N — Negotiable — Обсуждаемый

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

V — Valuable — Ценный

Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.

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

E — Estimable — Оцениваемый

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

история слишком большая;

в описании недостаточно данных;

разработчику нужно больше опыта.

Однако подробнее об оценках поговорим в отделе “Оценка историй”.

S — Small — Компактный

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

T — Testable — Тестируемый

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

Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.

Как добавить деталей к истории?

Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.

Acceptance Criteria

Что такое АС

Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.

АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.

Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.

Для чего нужны

Показывают фичу с точки зрения конечного юзера.

Для понимания задач бизнеса.

Достижения консенсуса с бизнесом относительно какой-то стори.

Служат базой для тестов.

Помогают эстимировать стори.

Правила написания

Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).

Должны быть измеримы.

Пишутся ДО работы над задачей.

Включают функциональные и нефункциональные критерии.

Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.

Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).

Не содержат технического арго.

Что делать, когда надо выбрать одно из нескольких решений?

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

Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:

1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.

Gherkin

Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see «Your article was published»

Базовый синтаксис Gherkin

1) Пишется сценарий-скелет.

Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see

2) Создается таблица с примерами.

В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например:

Пользователь и инструменты его исследования: CJM, Blueprint, JTBD, jobs story, Карта эмпатий, User story

Сегодня в статье попробуем привести в порядок то, зачем мы используем разные инструменты для исследования пользователей. Что такое магический JTBD и зачем он вообще нужен?

Кому не подходит вариант статьи, то есть стрим https://youtu.be/mcX-qt9pkMg

Начало начал. Разберемся с терминологией

Как в любой истории у нас есть главный герой, давайте называть его Актор, от слова Акт. В просторечье Пользователь. Методологии так или иначе пытаются проработать что-то вокруг этого самого Пользователя/актора.

Небольшое отступление, чтобы лучше понять суть терминов:

Пользователь от слова польза. (В словаре правда говорится про использование, то есть нахождение во владении, но этот утилитарный смысл мы опустим)

Актор – человек, который совершает акт в рамках какого-то сценария. Нам это понадобится позднее.

Первый шаг в создании продукта – это понять, кто, как решает сейчас проблему. Для этого идеально подходит карта действий, описывающая то, как задача решается Актором.

Начнем с путешествия пользователя к решению своих задач: CJM

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

Метод CJM появился в рамках классического маркетинга, ходят конечно слухи, что при проектировании первой мышки для apple был сформулирован термин представителями компании IDEO.
Основная задача метода показать как пользователь получает некий схематичный импульс и что он делает для утоления этого импульса. При этом еще желательно показать с какими проблемами он сталкивается, какие проблемы у него получается решать. Метод в целом подойдет как для существующего продукта, так и для продукта, над которым еще ведется работа.

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

Вопросы, которые можно задавать для проектирования CJM

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

Как пользователь использует наш продукт?

Как он решает свою задачу? Как он обходит бесячие штуки?

Как бы мы не старались схема получается весьма условной, есть только 1 стрим для движения нашего клиента. Но при добавлении разных вариантов, ветвлений схема перестает работать. В частности я с этим столкнулся, когда работал над оффлайн/онлайн проектом с омниканальным продвижением. То есть, когда нет единого пути, а у каждого свой путь, при чем 1 клиент может каждый раз отличным образом пользоваться нашим продуктом.

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

Сложные пути и множественные сценарии требуют других инструментов

Переход от CJM к Service BluePrint

Описание Service Blue print

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

Задачи пользователя? как и для чего?

Карта эмпатий. Простая

Окей, мы закончили с путями пользователей и думаю расположили объекты по ходу дела. Теперь пришло время поработать с тем как представить себе нашего пользователя, особенно, когда нам еще не понятен путь получения пользы. Для этого мы берем все, что мы написали в CJM и пытаемся дополнив это вписать в другую схему. Мы создаем так называемую карту эмпатий. Карта эмпатии (англ. empathy map) — инструмент визуализации идей, разработанный компанией XPLANE, позволяющий поставить себя на место пользователя, взглянуть на проблему, которую решает ваш продукт, его глазами. Может быть использован как в качестве альтернативы персонажам, так и как дополнение к ним.

В карте эмпатий можно выделить 4 блока:

Думаю и чувствую: что беспокоит пользователя? Какими словами он думает о проблеме? Насчет чего сомневается? Эту информацию лучше искать там, где пользователи жалуются: например, на форумах. Если у продукта есть служба поддержки – идем и слушаем, как нам делают мозги, собираем данные!

Говорю и делаю: как пользователь ведет себя публично? Что говорит? Какими способами решает проблему? Как ищет информацию по ней? Эту информацию стоит искать в социальных сетях. Особенно в этом плане полезен Linkedin – впн и в путь, ну или подойдет habr карьера: там можно относительно легко найти представителей самых разных профессий и изучить, какие события/конференции/обучающие мероприятия они посещают, в каких сообществах состоят, какие вопросы в них поднимают, какими навыками обладают и т.д. и т.п.

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

Слышу: как среда, в которой находится пользователь, воздействует на него? Что говорят ему коллеги, знакомые, авторитетные для него источники? Какие медиаканалы имеют влияние на пользователя? В отличие от блока «вижу», информация здесь не обязательно соответствует действительности. Но пользователь ей доверяет. Где искать информацию для этого блока: слухи и мнения на форумах (а собственно из соц. сетей можно узнать, что это за форумы), истории успеха, стереотипы и даже городские легенды.

Чего-то не хватает, а что если дополнить карту эмпатий болями и другими триггерами?

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

Ценности и достижения: что поможет пользователю избавиться от проблем и сомнений? За какие возможности продукта он готов платить? Какие ценности мы должны транслировать? Выводы из этого блока влияют на продукт с самых разных сторон: они могут повлечь как мелкие изменения в интерфейсе или в тексте, так и добавление/исключение определенных функциональных особенностей, и иногда – даже изменение в позиционировании продукта.

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

Цель персон – создать эмпатию у команды, особенно у тех, кто не общается с пользователями.

Окей, что-то много ресурсов для создания некой иконы нашего пользователя, как можно использовать карты эмпатий еще?

Что делать с Картой эмпатий? Как дальше адаптировать ее для бизнес задач?

Value proposition canvas – шаблон ценностного предложения.

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

Если будем делать еще один зум аут, то увидим, что подобная методология находит свою реализацию в том числе в моделях бизнеса, например lean canvas. Цифра 1 это про проблему и Потребителя, 2-3 – про то, как мы решаем проблему и какое у нас УТП (еще один способ сказать про ценностное предложение, но термин, конечно, не продуктовый). Про модель остервальдера, я когда-то писал статью, позже ее перепишу учитывая развитие мысли за почти 4 года.

Получается все эти инструменты, схемы – про уровень абстракции к задачам и болям пользователя и предположение про то, как мы можем эти проблемы решить или как пользователь их решает.

А что же с user srory, jobs story and JTBD?

User Story – краткое описание функции вашего продукта с точки зрения пользователя. Для этого вы проводите качественные исследования, анализируете данные и создаете несколько персон — собирательных образов пользователей — из ключевых сегментов вашей целевой аудитории. Формула:
— Как (тип пользователя)
— Я хочу (действие/цель)
— Чтобы (результат)
Пример:
Как модница Елена (образ пользователя), Я хочу купить на сайте новое платье в один клик (действие), Чтобы больше времени тратить на шопинг, а не оформление заказа (результат).

Но в других ситуациях это не работает:

Что если твоя аудитория слишком большая и сегментированная? У всех разные цели, разные профессии, разный бэкграунд. Еще интереснее, когда по персональным и социально-демографическим характеристикам аудитория примерно однородна. Тут обычно начинаются попытки все каким-то образом объединить в «Лену, юриста» или «Ваню, студента» — это значит, что вы начинаете делать предположения.
Что, если вы хотите привлечь новых пользователей? Ведь персоны основываются на данных текущих (а не потенциальных) пользователей.

User story (действующее лицо присутствует)

На примере Uber

кажется, что здесь точно есть две конкретные персоны: водитель и пассажир. На самом же деле, эта характеристика — лишь часть контекста: в зависимости от ситуации водитель может оказаться на месте пассажира, и наоборот. Мы думаем не о том, что разнит наших пользователей, а что их объединяет. Таким образом, то, что мы делаем, получает больший охват.

В Intercom как раз и изобрели job stories и используют их вместо user stories.

В Job Story фокус с персональных характеристик смещается на контекст.

Формула Job Story:

Когда (описание ситуации), Я хочу (мотивация), Чтобы (результат).

Пример:

Когда у меня есть всего 2 минуты, чтобы перекусить между встречами (описание ситуации),

Я хочу съесть что-то, чтобы это было просто, быстро и подняло мой уровень сахара в крови (мотивация),

Чтобы продержаться до обеда и сохранить рабочее настроение (результат).

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

Важно понимать, как выглядит ваша текущая аудитория — это приходит после регулярных исследований и интервью. Но конкретно перед разработкой нового сервиса и продуктовой стратегии нужна job story.

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

В Intercom провели исследование

чтобы понять «работу» карты, и обнаружили, что ей пользовались преимущественно на выставках, презентациях и в социальных сетях — чтобы впечатлить пользователей или инвесторов. Поэтому в компании решили сосредоточиться на внешнем виде карты (что сделало ее менее точной) и добавить возможность легко делиться ей в соцсетях. Ухудшив саму карту, они улучшили user experience – пользовательский опыт.

Когда «работа» продукта начинается и заканчивается

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

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

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

Understanding Use Cases, Use Case Scenarios, User Stories, Flow Charts

Table of Content

Often as designers, we encounter different methods to document our UI UX Designs. These methods could be as detailed or simple as needed. The difference between use case, use case scenarios, user stories, and user flows are precisely in the details.

As less detailed, first, we encounter the user stories. These stories break into use cases; the use cases can contain use case scenarios that translates into graphical flow charts.

But let’s start with the basics, definitions.

What is a user story?

The user story is a faster and less specific tool typically used in agile methodologies. The focus of the user story is on developing short descriptions of user-centered needs. User stories are simplified versions of requirements. A user story should also focus on being valuable to the end-user. A user story should be short, estimable, and testable. It is essential to mention that user stories do not replace requirement documentation since requirements deal with the product’s specifications and technical aspects.

What are a use case and a use case scenario?

A use case is a set of steps that are required to accomplish a specific task or goal. A use case can have multiple paths to reach the goal; each of them is considered a use case scenario. In simple words, a use case is a goal with various processes, and a case scenario represents a linear and straight path through one of the operations.

The use case it answers the questions like:

How many ways do we have to accomplish the task? (Basic paths and alternative paths)

Example 1: Let say that we encounter a mobile app sign-in; the user story will be: User A needs to SIGN IN to access the app. (Who, What, Why). Then, we developed the use case: first, we need to open the app, verify connectivity in the device, and then present the user the options that they have to accomplish the task. We see that we have multiple choices; we can sign-in using our Facebook account, Twitter account, or email. The use case is sign-in; each of the options to sign in is a use case scenario. All of the situations lead to the same outcome, but as users, we will encounter different interfaces depending on our choice of sign-in.

User story and a use case. What is the difference?

A user story will give us more information regarding the motive and needs of the user; it will also give us a high-level goal vs. the use case. It will provide us with the details of how to accomplish the target and all the scenarios that the user can encounter while performing the task. The use case is more detailed and focuses more on functionality. To learn more about user stories, please read our article entitled “Storyboards and How They Help in Product Definition”.

What is a Flow Chart?

A user flow is a more detailed and graphical representation of a use case or use case scenario. Flow Charts express navigation as a map; they use shapes and graphics to convey the screen’s content and navigation indicators to convey the interaction between screens. Complex cases should not use Flow Charts as documentation. When the use cases involve lots of screens/elements and navigation specifications, the diagram can become too big and too difficult to understand.

The user flows can be:

So what to do if the flow is too big to be represented in a single chart? We can accommodate the use of Wireflows and User flows into documents. These documents will contain the Low – Medium fidelity wireframes. Instead of the arrows, navigation works through unique screen IDs and indicators in the wireframes. Each action (buttons, menus, etc.) will point to other screen IDs. This type of documentation serves its purpose by user scenario, use case, feature, etc.

Our experience.

Use cases, user stories, and flow charts are essential parts of the mobile app design and development. We have encountered that user stories are usually provided by the product owner to communicate the user and business needs. Technical leads and UI/UX designers develop user flows based on the user stories and requirements. UI/UX designers then apply the use cases and transform them into graphical flow charts. All of these documentation becomes essential to current and future versions of the product.

The use cases and flow charts, in our experience, are documentation that goes through several parties involved in the process:

Use cases are time-consuming to create, but in our experience, they are certainly needed and useful as reference documentation and guidance for developers, designers, and testers. There are multiple ways to document a use case; there is no correct answer in which one to choose; It will depend on which one adapts better to your process and product. Choose the best deepening on the size of the case to document. If the feature or situation is not yet fully defined, it is best first to elaborate on the use case, and when the use case is approved, it translates into a flow chart or document.

What are the objectives of having case scenarios and flows documented?

Analyze and Document Requirements

It helps to identify not covered scenarios, errors, or side scenarios.

It validates User Stories.

It helps to understand the evolution of the features.

As a final thought, consider the needs of the business, the needs of the product, and the team’s needs (Development, SQA, etc.) Ensure you have all the elements required in your documentation to support the team and have documentation that can be expandable in a progressive way.

Что такое use case? Теория и примеры

💰 Какой была ваша первая зарплата в QA и как вы искали первую работу? Мега-обсуждение в нашем телеграм-канале.

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

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

В отличие от user story, которая излагается от имени какого-то конкретного пользователя, в use case может быть описано взаимодействие (с определенной целью) нескольких участников. Например:

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

Как написать use case?

Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:

Пример use case

В этом юзкейсе изложен сценарий входа пользователя в школьную систему.

Юзкейс-диаграммы

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

Пример диаграммы для юзкейсов входа в школьную систему:

Зачем нужны use case?

Давайте рассмотрим, в чем ценность юзкейсов для участников проекта разработки ПО.

В юзкейсе отражается конечная бизнес-ценность, понятная заказчику. Реализация сценария использования в системе очевидна даже для нетехнического специалиста. Наличие готового use case позволяет заказчику своевременно дать старт дальнейшей работе тестировщиков и разработчиков.

В сценарии использования указываются основной и альтернативные потоки событий. Вся информация в нем подается максимально структурированно и понятно, в привязке к конечному результату. Это удобно для понимания запутанных требований. Если сценарий поведения пользователя в системе сложный, use case просто необходим.

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки, которые сложно найти, например, при юнит-тестировании.

5 способов разработки Use Cases

Система управления требованиями 3SL Cradle предоставляет возможность выбора технологии разработки Use Cases удобной для конкретного коллектива. В данной статье кратко рассматриваются основные технологические подходы к организации разработки вариантов использования в 3SL Cradle.

Немного о Use Cases.

Алистер Коберн «Современные методы описания функциональных требований к системам»:

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

Структура описания варианта использования может быть адаптирована к задачам конкретного коллектива, но как правило фиксируются следующие разделы:

Технологии разработки Uses Cases в 3SL Cradle

Способ первый. Один элемент — один вариант использования — одно поле.

Основная единица управления в базе данных Cradle — элемент (item). Вы можете определить любой набор типов элементов, например, требования, тесты, функции, классы, оборудование… Также мы можем определить тип элемента Use Case и в поле TEXT данного элемента вводить полное описание варианта использования.

Данный способ отличается от предыдущего тем, что для элемента типа Use Case настраиваются поля в соответствии с выбранной структурой Use Case. Один раздел — одно поле. Таким образом, будут настроены поля: основное действующее лицо, область действия, участники и интересы и др.

Данный способ предполагает занесение каждого раздела Use Case в отдельный элемент (item), при этом можно ввести атрибут — тип раздела, что упростит анализ и выборки. Каждый вариант использования будет выглядеть как иерархия элементов, где элемент верхнего уровня соответствует данному варианту использования в целом, а подчиненные элементы — его разделам.

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

Как и зачем писать Use Cases

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

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

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

Мне нравится определение из книги Коберна (советую, ее, кстати, всем аналитикам): «Вариант использования фиксирует соглашение между участниками системы о ее поведении. Вариант использования описывает поведение системы при ее ответах на запрос одного из участников, называемого основным действующим лицом, в различных условиях».

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.

Кому и в каких случаях нужны сценарии

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

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс 🙂

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

А также другим участникам процесса.

В каких случаях они нужны:

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

— Для поддержки системы. Чтоб выявить ошибку, разобраться, на каком шаге что пошло не так.

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

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

Пример 2. Авторизация пользователя:

Успешный сценарий:

Важные моменты

— Очевидно, что если Пример 1 можно было безболезненно описать простым текстом, то Пример 2 намного лучше воспринимается в виде сценария. Но если у вас вся функциональность описана в виде юзкейсов, то лучше описывать юзкейсами даже очень простые сценарии, из пары шагов. Пусть ваша спецификация будет в едином стиле.

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

— Если в двух и более сценариях повторяется одинаковый набор шагов, есть смысл вынести эти шаги в отдельный сценарий, и ссылаться на них. Документ будет легче. А если что-то в этих шагах поменяется, то достаточно будет изменить в одном месте.

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

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

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Гайд по User Stories для Junior BA / PO / PM

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

Содержание:

Вводная информация о User Stories

Что такое User Stories

Сейчас User Stories являются одним из главных приемов работы бизнес-аналитиков и Product Owner. Бизнес-стейкхолдеры рассказывают эти истории, чтобы показать команде разработки суть и ценность задачи, которую надо реализовать. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта.

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

В качестве первого ответа приведем «официальное» определение из книги М. Кона «Пользовательские истории: гибкая методология разработки ПО».

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

Такое определение не помогает разобраться в сути приема и его распространенности среди пользователей. Неужели главное — это записи или то, что детали должны уточняться? Думаю, нет. Поэтому я не бросил копания и начал смотреть другие источники. Множество сайтов предлагает такое определение:

Этот ответ тоже не удовлетворил моё любопытство. Такое определение ставит во главу угла формат. Ведь User Story может существовать и без какой-то части (As a user, I want to save data) и быть написанной без обсуждения интровертным продакт-овнером. Но самое главное — об этом будет ниже — User Story может быть написана по совершенно иному формату!

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

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

Далее в статье я использую однострочные примеры пользовательских историй: «Как Х, я хочу Y, чтобы Z«. Тем не менее, многие аналитики использую другой подход, который считается даже более каноничным.

Так, истории пишутся в три строки:

Job Stories

В целом Job Stories — схожая с US техника. Можно назвать их приёмом-субститутом, ведь обычно они не используются вместе и выполняют максимально похожую функцию. Job Stories представляют требование в виде действия, которое выполняет пользователь. Они не описывают саму функцию, а лишь концентрируют внимание команды на потребности.

Job Stories концентрируются на психологической части фичи, на эмоциях, тревогах и прочем, что может возникнуть во время использования функции.

«Тело» JS делится на три части:

Situation: дает контекст обо всей JS, который помогает dev-команде придумать возможное решение.

Motivation: описывает невидимую руку, которая ведет юзера к использованию данной функции.

Expected Outcome: описывает, что получит юзер после использования функции.

Job Stories могут писаться по двум форматам:

В одну строку:
When X I want to Y so I can Z» или «When X, actor is Y so that Z.

В три строки:
When X
I want to Y
So I can Z.

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out to dinner with my friends.

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

Решает ли это настоящую проблему юзера?

Есть ли у такого решения какие-либо side effects? Влияет ли это на продукт в целом?

Какие последствия от такого решения?

А при работе с другими стейкхолдерами и выяснении первопричин нужды у них аналитик может использовать знаменитый приём «5 почему?».

Пример работы техники «5 почему».

Три С в User Story

Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют «the 3 C’s of User Stories».

Card — по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.

Conversation — каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.

Confirmation — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.

User Personas

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

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

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

Наиболее важными деталями персонажа являются его имя, место работы (роль в системе), место проживания. Причём имя и роль в будущем могут использоваться и при написании историй:

Как Георгий, я хочу печатать документы, чтобы я мог работать над ними вне компьютера.

Стоит также отразить маркетинговые характеристики персонажа такие как предпочитаемые бренды, блюда, увлечения и хобби. Эти характеристики важны не только, чтобы знать для кого мы создаем ПО, но и как его рекламировать и продавать. Описание должно также раскрывать и характер персонажа. Он веселый или чаще хмурится? Он делится информацией в соцсетях или вовсе не ведет их?

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

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

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

Что же в сухой практике использования User Personas?

Отрицательный персонаж

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

Создавая любое приложение для такси, мы вспомним, что в процессе заказа традиционно есть 3 участника: клиент, водитель, оператор. Скорее всего, задачей нашего приложения будет автоматизация работы оператора так, чтобы клиент мог связаться с водителем напрямую. В таком случае самому оператору в системе не будет места.

Ключевой персонаж

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

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

INVEST

По критериям INVEST мы можем судить, хорошо ли написана User Story и можно ли над ней работать.

I — Independent — Независимый

Следует избегать зависимости между историями, так как иногда это приводит к проблемам во время имплементации. (пример: задача А не может быть реализована без задачи Б, однако задача А — очень важна, а Б лишь желательно иметь в готовом продукте).

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

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

N — Negotiable — Обсуждаемый

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

V — Valuable — Ценный

Каждая User Story должна нести пользу как пользователю, так и продукту, а описание должно создаваться так, чтобы ценность была наиболее очевидна. Так команда разработки будет понимать, зачем это нужно реализовывать.

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

E — Estimable — Оцениваемый

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

история слишком большая;

в описании недостаточно данных;

разработчику нужно больше опыта.

Однако подробнее об оценках поговорим в отделе “Оценка историй”.

S — Small — Компактный

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

T — Testable — Тестируемый

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

Однако не стоит забывать, что стоит писать истории так, чтобы QA-команда могла понять, какие кейсы и сценарии ей тестировать. Для создания этого понимания аналитику требований следует пользоваться критериями приемки и описанием сценариев по Gherkin. Подробнее об этих приемах можно прочитать в разделе “Как добавить деталей к истории”.

Как добавить деталей к истории?

Очень важно понимать, что когда работа над «телом» стори закончена, начинается работа над деталями, которые и помогут команде понять, что надо реализовать. Среди способов добавить детали самыми знаменитыми являются Acceptance Criteria и сценарии по Gherkin.

Acceptance Criteria

Что такое АС

Элемент User Stories, который дополняет их так, что команда начинает видеть историю в деталях. Этот инструмент помогает понять, что должно быть сделано, чтобы удовлетворить потребность бизнеса.

АС помогают увидеть фичу с точки зрения конечного пользователя, установить границы фичи и создать понимание того, что должно быть сделано и что будет проверяться.

Их надо понимать максимально буквально, потому что это те критерии по которым мы понимаем, выполнена история или нет.

Для чего нужны

Показывают фичу с точки зрения конечного юзера.

Для понимания задач бизнеса.

Достижения консенсуса с бизнесом относительно какой-то стори.

Служат базой для тестов.

Помогают эстимировать стори.

Правила написания

Мы пишем их не в форме should, а в настоящем времени (суть в том, что человек читает и видит, какими «способностями» обладает юзер или система).

Должны быть измеримы.

Пишутся ДО работы над задачей.

Включают функциональные и нефункциональные критерии.

Пользователь может выбрать цвет. Пример: есть дропдаун с цветами.

Не слишком узкие (привязаны к одному юз-кейсу-примеру) и не слишком широкие (понятно где сделано и как работает).

Не содержат технического арго.

Что делать, когда надо выбрать одно из нескольких решений?

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

Компания хочет пообедать в итальянском веганском ресторане, где играет живая испанская гитара. Тогда ресторан, который подойдёт, должен соответствовать трем критериям:

1. Ресторан должен быть итальянским.
2. Ресторан должен быть должен подавать вегетарианские блюда.
3. В ресторане играет живая испанская гитара.

Gherkin

Scenario: Dr Bill posts to his own blog.
GIVEN I am logged in as Dr Bill
WHEN I try to post to my blog
THEN I should see «Your article was published»

Базовый синтаксис Gherkin

1) Пишется сценарий-скелет.

Scenario Outline: Dr Bill posts to his own blog.
Given I Have published
When I try to post a new blog
Then I should see

2) Создается таблица с примерами.

В данном примере мы должны показать связь между количеством постов в блоге и тем, какое сообщение увидит пользователь.Например:

Как описать программную систему в UML-диаграммах: от Use Case до состояний + краткий ликбез по ООП

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

Границы системы, акторы и варианты использования: что такое диаграмма Use Case

Проектируя программную систему, аналитик прежде всего отвечает на вопрос, что она должна делать, т.е. какие возможности представлять для разных пользователей. Для описания таких вариантов использования в UML есть одноименная диаграмма – Use Case. Она позволяет наглядно показать границы системы и ее функции, сгруппированные по контексту – прецеденты. При том, что каждый прецедент фактически отражает одно или сразу несколько функциональных требований, UML-диаграмма Use Case и одноименная форма представления требований – это разные вещи, хоть и связанные между собой. Подробнее об этом мы рассказывали в отдельной статье.

В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка. Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу). Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.

Пример UML-диаграммы вариантов использования (Use Case)

Далее следует детализировать, как именно выполняется процесс оплаты, раскрыв прецедент со схемы Use Case на UML-диаграмме последовательности. Однако, чтобы сделать это с привязкой к внутренним сущностям нашей программной системы, классам, следует сперва описать их на UML-диаграмме классов. Как это сделать, мы рассмотрим далее.

Ликбез по ООП или как построить UML-диаграмму классов

UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации. При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).

Ассоциация означает логическую связь между объектами разных классов. Например, договор на обучение связан с курсом. Поскольку в договоре нужно обязательно указать курс, эти классы будут связаны не простой ассоциацией, а ее более сложным вариантом – агрегацией. В этом случае у класса, который является целым, появится значок в виде незакрашенного ромбика. Если связь между объектами разных классов настолько сильная, что при уничтожении целого, уничтожаются и его части, ромбик будет закрашенным. Такая связь называется композицией и является самым сильным вариантом ассоциации. Можно также указать кратность связи, к примеру, в 1-м договоре на обучение могут быть указаны сразу несколько курсов. При этом над концами связи отобразятся мультипликаторы, обозначающие ее кратность.

• ← Usa area code
• User story mapping →