Что такое user story и use cases
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.
Одна персона представляет собой не группу пользователей, а так называемый архетип, то есть характерного представителя, и фактически моделирует при этом конкретную личность. Для этого и дают персонам имена и фотографии: для того, чтобы команда не просто использовала абстрактного мёртвого человечка, как часто называют картинки на диаграмме вариантов использования, а представляла себе конкретную личность, проникалась к ней эмпатией и сочувствием. И тогда появляется возможность оценивать с точки зрения этой личности те сценарии, которые мы для неё реализуем.
Как писать функциональные требования
Сегодня мы хотим рассказать о том, как наша продуктовая команда подходит к подготовке функциональных требований для разработчиков при создании новых продуктов и фич.
На этапе разработки может возникнуть много неожиданностей, особенно если не четко описать задачу. Разработку и функционирование одной и той же фичи разные участники команды могут понимать по-разному, поэтому продакт-менеджеры отвечают за создание продукта от разработки концепции до окончательного релиза. И важная часть этого процесса — подготовка функциональных требований.
Вопрос описания задач для разработчиков мы уже затрагивали в статье Как менеджерам научиться ставить задачи разработчикам, но в ней мы говорили больше про административные моменты, а сегодня речь пойдет скорее о технических. Это крайне важная составляющая любого бизнеса, продажи которого идут через интернет. Каждая компания, активно развивающаяся в интернет-среде, по сути превращается в бизнес по производству программного обеспечения. Но несмотря на это, компетенции в области управления требованиями, как правило, наращиваются очень медленно.
В результате мы часто видим одну и ту же картину: в отдел разработки постоянно падают задачи от разных отделов, требования в этих задачах описаны размыто, и как только что-то выпускается в бой – сразу же возвращается на доработку (ведь постановщик не до конца описал, что хотел, а разработчик сделал так, как посчитал нужным). Итог очевиден: непредсказуемые сроки выполнения задач, которые могут исчисляться месяцами, демотивированная команда, напряженные отношения внутри коллектива, недовольные клиенты, отставание от конкурентов и так далее.
Этой статьей мы хотим дать простой рецепт, который положит начало решению подобных проблем. Его можно смело рекомендовать к изучению (более того, к действию) всем, кто ставит задачи.
В разных компаниях существуют различные подходы к написанию функциональных требований, но в 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’ов:
Почему функциональные требования так важны
Используя такой формат функциональных требований, вы предоставляете команде разработки четкие инструкции. Кроме того, вы можете показать, как интерфейс выглядит со стороны клиента и как он решает его задачи. Такой подход помогает презентовать вашу идею и избежать недопониманий в команде.
Обычно постановка задачи разработчикам рождает у них множество вопросов, от ответов на которые зависит сложность и срок реализации. Для уточнения деталей им приходится тратить время на коммуникацию вместо своей прямой работы — создания классных фич и улучшения продукта. И даже в процессе коммуникации не всегда выясняются все тонкости, если постановщик задачи только отвечает на возникающие вопросы, но не проходит путь пользователя сам.
Возьмем наш пример про галерею. Если бы продакт-менеджер просто пришел с задачей создать галерею, только на одном пункте про удаление файлов разработчикам пришлось бы уточнять:
Функциональные требования помогают продакт-менеджеру продумать и четко сформулировать все сценарии взаимодействия пользователя с интерфейсов в рамках задачи.
Чем точнее поставлена задача и чем больше деталей есть у разработчиков до начала работы, тем эффективнее идет работа. Не тратится время на долгую и подчас бессмысленную коммуникацию. В этом случае все стороны в выигрыше: разработчики получают четкое понимание, что и как нужно сделать, а поставщик задачи получает выполненную работу именно в том виде, в каком он ее себе представлял.
А как вы подходите к постановке задач разработчикам?
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.
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.