что такое user story и use case
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.
Одна персона представляет собой не группу пользователей, а так называемый архетип, то есть характерного представителя, и фактически моделирует при этом конкретную личность. Для этого и дают персонам имена и фотографии: для того, чтобы команда не просто использовала абстрактного мёртвого человечка, как часто называют картинки на диаграмме вариантов использования, а представляла себе конкретную личность, проникалась к ней эмпатией и сочувствием. И тогда появляется возможность оценивать с точки зрения этой личности те сценарии, которые мы для неё реализуем.
Разница между 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% сценариев, с которыми пользователи будут работать мало и редко, а внимание дизайнера будет размазано по всем возможным сценариям, что снизит их качество.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в 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’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
Как мы делаем аналитику IT-проектов: прояснение требований
В этой статье мы расскажем о том, какие инструменты мы используем для решения задач аналитики — их особенности и назначение. После прочтения вам будет проще построить коммуникацию с аналитиками.
Аналитик — своего рода посредник между бизнесом, проектированием и разработкой, который периодически смещается в ту или иную сторону, но при этом удерживает процесс создания продукта в поле здравого смысла. Он обеспечивает коммуникацию между всеми участниками процесса, собирает, проясняет и приоритезирует требования и помогает принять обоснованные решения.
Для того чтобы взаимодействие между клиентом, аналитиком и разработчиками проходило эффективно, мы используем определённый набор артефактов. Важно понимать, что для каждого проекта мы подбираем свой набор, который необходим для исчерпывающего описания данного программного обеспечения. Типы и содержание документов зависит от желаемых результатов, стейкхолдеров и команды. Мы познакомим вас с основными артефактами, чтобы вы понимали, что представляет собой и зачем нужен каждый из них.
Это первый артефакт, который возникает в проекте. Представляет собой текстовый документ, который кратко описывает основную идею проекта. Он на верхнем уровне определяет продукт, который требуется разработать с учётом потребностей заинтересованных сторон.
Проще говоря, в Vision формулируется:
В Vision зафиксированы наиболее существенные требования, ограничения и приемлемые уровни качества.
На основе данного артефакта определяется подходящий набор артефактов и, следовательно, формируется решение для задач проекта. С помощью него детализируют и декомпозируют требования.
Это короткие формулировки намерений, описывающие, что система должна делать для пользователя. Обычно мы готовим их вместе с Vision.
Текст каждой формулировки — User Story — должен объяснять роль или действия юзера в системе, его потребность и профит, который он получит после того, как история случится.
Особенности User Stories:
Именно на основании User Stories проводится дальнейший анализ.
Так же как и User Stories описывают, как пользователь должен взаимодействовать с системой, чтобы достичь конкретной цели. В чём же тогда отличие? User Story помогает определить задачу и намерение. А Use Cases не сообщают о задачах и намерениях, они более подробно фиксируют функциональные возможности.
Посмотрим на эти различия на примере гипотетической разработки обычного калькулятора.
Формулировка User Story может быть такой: «Я как пользователь хочу иметь возможность совершать математические операции, чтобы упростить механические расчеты».
А кейсы, соответствующие данной User Story, могут быть такими:
Когда готово верхнеуровневое описание, аналитики переходят к более детальному описанию системы. Здесь выбор инструментов также основывается на особенностях конкретного проекта. Представим, что предполагается сложная система, где много документов, часть системы встраивается в более крупную или множество интеграций. В таком случае мы можем столкнуться с реальными функциональными ограничениями на то, что мы можем сделать за адекватный срок. Например, API, которую нам предоставляет внешняя система, накладывает обязательства на реализацию функционала регистрации пользователя. Это могут быть определённые поля, параметры или условия, которые мы должны включить в запрос. Иногда технические ограничения накладываются и на пользовательский интерфейс. Чтобы разобраться в существующих ограничениях и с их учётом создать удобный функционал, нужно разобраться, какие существуют и какие должны быть реализованы интеграционные сценарии, нарисовать диаграмму компонентов или развертывания.
Теперь давайте познакомимся с этими инструментами ближе. Напомним, что для каждого проекта мы определяем свой набор артефактов и их наполнение.
Прежде чем приступать к разработке, мы должны сформулировать понятия о предметах, фактах и событиях, которыми будет оперировать система. Для этого требуется привести эти понятия к той или иной модели данных. А именно — заменить их информационными представлениями. Здесь мы как раз используем описание сущностей.
Инструменты, которые мы рассмотрели выше, отражают концептуальные и логические аспекты построения модели системы. Логическое представление включает понятия, которые не имеют материального воплощения. Иными словами, элементы логического представления, такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически. С их помощью мы можем понять статическую структуру или динамические аспекты поведения системы.
Чтобы создать физическую систему, необходимо реализовать все элементы логического представления в конкретные материальные сущности. Для описания таких сущностей мы используем физическое представление модели, в том числе диаграмму компонентов.
Таким образом, диаграмма компонентов помогает:
В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты.
Показывает инфраструктуру системы графически. Диаграмма отображает, как располагаются и соединяются сетевые устройства. С её помощью определяются сведения о компьютерах, обрабатывающих информацию, как они связаны друг с другом и какие дополнительные ресурсы (принтеры, модемы, маршрутизаторы и т. д.) должны быть задействованы.
Элементами диаграммы развертывания являются узлы, компоненты и связи между ними. Узел — это некоторый физически существующий элемент системы. В качестве узла могут рассматриваться компьютеры, датчики, принтеры, модемы, цифровые камеры, сканеры и т.д.
Диаграмма развертывания помогает более рационально распределить компоненты системы по узлам сети, от чего зависит в том числе и производительность системы. С её помощью можно решить вспомогательные задачи, например, связанные, с обеспечением безопасности.
Карта экранов схематично отображает экраны проекта и связи между ними. Она помогает сохранить целостность интерфейса, структурирует работу, делает её более прозрачной и прогнозируемой.
Также карта экранов нужна для разработки системы навигации по приложению. Если в будущем планируются новые элементы системы, то с помощью карты экранов можно определить, куда и как их добавлять.
Когда нет интерактивных прототипов, карта экранов позволяет продемонстрировать логику бизнес-процесса.
Мы обычно используем блок-схемы, чтобы описывать процессы. Они полезны, когда требуется:
Ещё с помощью блок-схемы можно показать карту экранов или любую другую диаграмму — например, Use Cases. По сути блок-схема — это диаграмма с уникальной легендой. Она помогает визуально представить систему с определённой точки зрения.