Лекция
Привет, Вы узнаете о том , что такое пользовательские истории, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое пользовательские истории, user story, acceptance сriteria, ac , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.
пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приемочными испытаниями ruen). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — проходят проверку пользователем в роли «Владелец продукта» (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.
В разработке программного обеспечения и управлении продуктом пользовательская история (англ. User Story) — это неформальное описание функций программной системы на естественном языке. Они пишутся с точки зрения конечного пользователя или пользователя системы и могут быть записаны на карточках, стикерах или в цифровом виде в специальном программном обеспечении для управления. В зависимости от продукта пользовательские истории могут быть написаны различными заинтересованными сторонами, такими как клиент, пользователь, менеджер или команда разработчиков.
Истории пользователей — это тип граничного объекта . Они облегчают осмысление и коммуникацию; и могут помочь командам разработчиков программного обеспечения документировать свое понимание системы и ее контекста.
Пользовательские истории — быстрый способ документировать требования клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Цель пользовательских историй состоит в том, чтобы быть в состоянии оперативно и без накладных затрат реагировать на быстро изменяющиеся требования реального мира.
Пользовательская история остается неофициальным определением требований, пока отсутствует процедура приемочного тестирования. Прежде чем реализовывать пользовательскую историю, клиент должен определить соответствующую приемную процедуру, чтобы гарантировать, что цели пользовательской истории были достигнуты.
Пользовательские истории (User Stories) - это методология описания требований в разработке программного обеспечения, который был впервые предложен в рамках Agile-подхода к управлению проектами и разработке. Они представляют собой краткие, но информативные описания функциональных требований, сфокусированные на потребностях пользователей. Пользовательские истории обычно содержат следующие элементы:
Роль (Role): Кто будет использовать функцию или какую роль она затрагивает (например, "пользователь", "администратор", "гость" и т.д.).
Действие (Action): Что пользователь или роль планирует сделать с системой или функцией (например, "просматривать", "создавать", "редактировать" и т.д.).
Цель (Goal): Зачем пользователь или роль хочет выполнить это действие (например, "просмотреть список товаров", "создать новую задачу", "редактировать профиль пользователя" и т.д.).
Польза (Benefit): Какую пользу получит пользователь или роль от выполнения этой задачи или действия (например, "быстрый доступ к необходимой информации", "повышение производительности" и т.д.).
User Story (US) – это краткая формулировка того, что мы будем разрабатывать в системе, что привнесет ценность в пользовательский опыт (решит его проблему).
US формулируются по такому шаблону:
Я как персона/пользователь системы ХОЧУ желание/потребность/функциональность ЧТОБЫ получить ценность/решить проблему
Однако, не всегда одного текста US достаточно. Поэтому для того, чтобы разработчик понял, что нужно сделать, а тестировщик смог проверить результат, в дополнении к User Story пишутся критерии приемки. (см. ниже подробнее)
Истории пользователей пишутся пользователями или клиентами или для них, чтобы влиять на функциональность разрабатываемой системы. В некоторых командах менеджер продукта (или владелец продукта в Scrum ) в первую очередь отвечает за формулирование историй пользователей и организацию их в бэклог продукта . В других командах любой может написать историю пользователя. Истории пользователей могут разрабатываться путем обсуждения с заинтересованными сторонами, на основе персон или просто придумываться.
Пользовательские истории могут следовать одному из нескольких форматов или шаблонов.
Наиболее распространенным является шаблон Connextra , указанный ниже. Майк Кон предположил, что предложение «so that» является необязательным, хотя все равно часто полезным.
Как <роль> я могу <возможность>, чтобы <получить выгоду>
As a I can , so that
Крис Мэттс предположил, что «поиск ценности» является первым шагом на пути к успешной поставке программного обеспечения, и предложил следующую альтернативу:
Чтобы <получить выгоду> как <роль>, я могу <цель/желание>
In order to as a , I can
Другой шаблон, основанный на « Пяти W», определяет:
Как <кто> <когда> <где>, я хочу <что>, потому что <почему>
As , I want because
Шаблон, который обычно используется для улучшения безопасности, называется «История злого пользователя» или «История злоупотребления пользователем» и используется как способ думать как хакер, чтобы рассмотреть сценарии, которые могут возникнуть при кибератаке. Эти истории написаны с точки зрения злоумышленника, пытающегося скомпрометировать или повредить приложение, а не типичных персонажей, которые можно найти в истории пользователя:
Как недовольный сотрудник, я хочу уничтожить базу данных пользователей, чтобы навредить компании.
As a disgruntled employee, I want to wipe out the user database to hurt the company
В экстремальном программировании (XP) пользовательские истории создаются совместно разработчиками и представителем клиента. Клиент ответственен за формулировку истории. Разработчик может использовать серию вопросов, чтобы подтолкнуть клиента и выяснить необходимость некоторых специфических функциональных возможностей. Но при этом разработчик должен быть осторожен и не доминировать над процессом создания идеи.
Как только клиент создает историю, она записывается на небольшой карточке (например, 8x13 см) с названием и описанием, которое сформулировал клиент. Если разработчик и клиент видят, что история их не устраивает (слишком большая, сложная, неточная), она переписывается, пока это не удовлетворит обе стороны. Однако, Экстремальное программирование подчеркивает, что пользовательские истории не должны быть окончательно определенными на момент записи, так как требования имеют тенденцию изменяться со временем в процессе разработки.
Пример пользовательской истории:
Как пользователь, я хочу просматривать список товаров, чтобы мне было удобно выбирать и покупать необходимые товары онлайн.
Отборочный тест (эпическая история)
Как менеджер по персоналу, я хочу создать проверочный тест, чтобы понять, хочу ли я направлять потенциальных кандидатов функциональному менеджеру.
Викторина отзыв
Как менеджер, я хочу просмотреть свои существующие тесты, чтобы вспомнить, что у меня есть, и решить, могу ли я просто повторно использовать или обновить существующий тест для должности, которая мне нужна сейчас.
Ограниченное резервное копирование
Как пользователь, я могу указать папки, резервное копирование которых не требуется, чтобы мой резервный диск не заполнялся вещами, которые мне не нужно сохранять.
В методологии ХР пользовательские истории являются результатом планирования, и определяют то, что должно быть реализовано в программном проекте. Пользовательские истории приоритизируются клиентом по важности для системы, разбиваются на серию задач и оцениваются разработчиками.
Непосредственно перед реализацией разработчики могут обсудить историю с заказчиком. Истории могут быть сложными для понимания, могут требовать специфические знания, или требования, возможно, могли измениться со времени написания.
К каждой пользовательской истории в какой-то момент должно быть прикреплено одно или более приемочное тестирование. Это позволяет разработчику узнать, когда пользовательская история готова и как клиенту проверить это. Без точных формулировок требований в момент поставки продукта могут возникнуть длительные неконструктивные разногласия.
Майк Кон определяет критерии приемки как «заметки о том, что должна делать история, чтобы владелец продукта принял ее как завершенную». Они определяют границы пользовательской истории и используются для подтверждения того, что история завершена и работает так, как задумано.
Соответствующий объем информации, включаемой в критерии приемки, зависит от команды, программы и проекта. Некоторые могут включать «критерии предшественника», «Пользователь уже вошел в систему и уже редактировал свою информацию один раз». Некоторые могут записывать критерии приемки в типичном гибком формате, « Дано-Когда-Тогда » . Другие могут просто использовать пункты, взятые из исходных требований, полученных от клиентов или заинтересованных сторон. Для того, чтобы история считалась выполненной или завершенной, все критерии приемки должны быть выполнены.
Критерии приемки или Acceptance Сriteria (AC) – это структурированные, подробные пункты требований к создаваемой системе, которым должна соответствовать User Story, чтобы работа по ней считалась завершенной с точки зрения клиента / владельца продукта.
Идеальные критерии приемки:
А также все AC совместно с US должны удовлетворять критериям INVEST:
Теперь правила, которые мне помогают в написании критериев приемки. Для себя я их сформулировала так:
Используй опорный критерий
Структурируй
Пиши и сокращай
Помни о правилах INVEST и хороших AC
Перечитай сам и дай другу
Используй лайфхаки
Приступим к разбору каждого правила на рабочих примерах.
Приступим к разбору каждого правила на рабочих примерах.
Если абстрагироваться от теории, то US + AC – это та же самая статья, в начале которой описывается краткая суть, краткое содержание того, чем вы хотите поделиться с читателем. Любому потребителю вашего документа важно однозначно понимать краткое содержание описываемого функционала. Это и есть опорный критерий.
Давайте разберем важность применения этого правила на примере следующей
User Story, описывающей функциональность отображения списка доступных ресторанов и магазинов в мобильном приложении доставки еды:
Как выглядят критерии приемки без опорного критерия:
Теперь посмотрим на критерии приемки с опорным критерием:
Как мы видим, опорный критерий помогает нам достичь однозначности и определенности. Об этом говорит сайт https://intellect.icu . Мы сразу понимаем, что на главной странице есть функциональность отображения списка магазинов и ресторанов, а также у пользователя есть возможность поиска для сокращения времени на выбор позиций для покупки. Да, это другая User Story, но мы обозначаем, что она есть, т. к. эта функциональность напрямую помогает работать пользователю со списком ресторанов/магазинов.
Мы всегда должны понимать, кем и как используется наш документ. В нашей команде тестировщик использует US + AC для составления тест-кейсов, разработчик – для написания кода будущего функционала, а также в качестве критериев Definition Of Done после написания кода.
Если игнорировать структуры в написании, это может привести к ошибкам в написании тест-кейсов и багам в созданной функциональности.
Рассмотрим пример написания критериев приемки без структуры и с ней. User Story описывает функциональность онбординга (инструкции использования) пользователя в мобильном приложении «Профиль клиента».
User Story:
Как выглядят критерии приемки без структуры:
Пользователь авторизовался первый раз в мобильном приложении. После отображается «Онбординг». Онбординг состоит из нескольких страниц, каждая из которых состоит из: блока основной информации, кнопок навигации по онборингу.
Блок основной информации на странице 1 содержит информацию об управлении профиля, на странице 2 – информацию о возможности подключения сервисов, на странице 3 – информацию о способах оплаты, на странице 4 – об обращении в службу поддержки. Подробное описание основной информации всех страниц смотри на Макетах
кнопки навигации: на 1, 2, 3 страницах отображается кнопка «Вперед», нажимая на которую, открывается следующая страница. На 2, 3, 4 страницах отображается кнопка «Назад», нажимая на которую, открывается предыдущая страница. На странице 4 отображается кнопка «Готово», нажимая на которую» открывается Главная страница мобильного приложения. Если пользователь авторизуется в МП не в первый раз, то онбординг не открывается, открывается сразу главная страница мобильного приложения.
Как выглядят структурированные критерии приемки:
Согласитесь, что читать и понимать второй вариант гораздо приятнее. Структурировать критерии приемки в виде таблицы и писать текст критерия по пунктам помогает читателю не запутаться. Тестировщику, в свою очередь, будет легко связать первый критерий приемки с первым тест-кейсом, а разработчику – с текстом кода. Структура также помогает авторам не запутаться в своем документе, так как в нем четко видно, какие критерии уже успели описать, чего не хватает, не упущена ли какая-то логика.
Критерии желательно располагать в порядке основного сценария использования функциональности, т. е. не сначала написать про кнопки, а потом про первое отображение, иначе не понятно будет, к чему кнопки относятся. Кроме этого, можно каждый критерий сделать в виде гиперссылки и тогда будет удобно ссылаться на него в следующих документах.
Если вы еще не читали книгу «Пиши и сокращай» Максима Ильяхова, то советую вам это сделать.
Приведу пример, который мы разбирали с учениками в нашей Школе бизнес-анализа.
User Story:
Один из критериев выглядел так:
Согласитесь, есть неоднозначность и путаница при чтении этого критерия? А еще в нем много «воды». Например, что автор хотел сказать предложением «Сегментация пользователей будет осуществляться на уровне кода»? Могу только догадываться, что он имел в виду, что сегментация будет импортироваться из другой системы, о чем он говорит во втором предложении. То есть первое предложение бессмысленно.
А последующие предложения содержат в себе несколько критериев, которые достаточно трудно вычленить, если читаешь их в таком виде.
Как можно было бы переписать этот критерий:
Очевидно, что чем меньше слов, тем больше мы получаем нужной и понятной информации, которую удобно обрабатывать любому потребителю документа.
Здесь я не буду приводить примеры. Правило заключается лишь в том, что после написания всех критериев необходимо перечитать весь текст на предмет выполнения INVEST’а (о нем я говорила в начале статьи).
Да, часто бывает так, что какой-то из критериев не выполняется (как правило, это независимость от других US). Но важно это обсудить с командой и принять общее решение – разрабатывать задачу с учетом этих рисков или нет.
О критериях хороших AC я также говорила в самом начале статьи (бинарность, полнота, подтверждаемость, однозначность, непротиворечивость).
Что касается инструкций, я также, как и с критериями INVEST, прохожусь по всем критериям приемки и проверяю их на соблюдение каждого «критерия хороших AC».
Делитесь документом с коллегами. В моей команде, прежде чем отдать документ разработчикам, я прошу проверить его на адекватность владельца продукта, тестировщика и системного аналитика. Вы – часть команды. А ответственность за результат лежит на всех ее участниках. Поэтому не бойтесь делиться и принимать комментарии и замечания от коллег. Помните, что принятие обратной связи – это шаг вперед в развитии вашей компетенции, а также в развитии вашего проекта/продукта. Ну и элементарно: мнение со стороны помогает ничего не упустить и быть правильно понятым.
И последний пункт, которым я хотела поделиться – это лайфхаки. Для облегчения формирования критериев приемки вам могут помочь следующие шаблоны написания:
Если вам необходимо описать, ЧТО происходит в системе в результате какого-либо события, то используйте принцип: ЕСЛИ произошло событие (если пользователь нажал на кнопку), ТО получаем результат (ТО система сохраняет данные в системе).
Также можно вместо ЕСЛИ, ТО описать событие и выделить результат фразой «В РЕЗУЛЬТАТЕ». Эти конструкции помогут не наплодить несколько критериев в одном:
Общеизвестный формат описания Given When Then (по Геркину). Он похож на формат ЕСЛИ, ТО, только здесь еще прописывается состояние системы в начальный момент.
В блоке ДАНО пишем состояние системы в начальный момент, в блоке КОГДА – действия пользователя, событие, и в ТОГДА – результат:
Если вам необходимо описать атрибуты и перечислить из чего состоит, например, какое-то меню, то обозначаем, что на экране отображаются следующие правила и перечисляем каждое из них отдельным пунктом:
Если критерий большой, то используйте для описания вложенные таблицы и выделяйте примеры, характерные для критерия, чуть ниже основного текста критерия приемки:
Gherkin — это сценарно-ориентированный язык, который легко читается бизнесом и используется для описания функциональности программного обеспечения. Gherkin описывает конкретные сценарии использования продукта.
Он широко применяется в разработке программного обеспечения для:
Нет никаких убедительных доказательств того, что использование пользовательских историй повышает успешность программного обеспечения или производительность разработчиков. Однако пользовательские истории облегчают осмысление без ненужного структурирования проблем, что связано с успехом.
XP и другие гибкие методологии предпочитают общение лицом к лицу вместо всесторонней документации; быструю адаптацию к изменениям вместо фиксации на проблеме. Это достигается следующим:
Преимущества использования пользовательских историй:
Ориентированность на пользователей: Пользовательские истории акцентируют внимание на потребностях и ценностях пользователей, что способствует созданию более полезного и удовлетворительного продукта.
Простота и понятность: Они представляют собой простой и понятный способ описания требований, что упрощает коммуникацию между разработчиками, заказчиками и другими участниками проекта.
Итеративность: Пользовательские истории позволяют начать разработку с самых важных и ценных функций, постепенно добавляя дополнительные требования.
Приоритизация: Истории могут быть легко приоритизированы в зависимости от их значимости и важности для пользователей.
Тестирование: Они могут служить основой для создания тестовых случаев и проверки выполнения требований.
Ограничения пользовательских историй включают в себя:
Хотя пользовательские истории и сценарии использования служат единой цели документирования пользовательских требований с точки зрения взаимодействия между пользователем и системой, между ними есть различия.
Пользовательские истории — это небольшое и удобное в работе представление информации. Они сформулированы на повседневном языке пользователя и содержат небольшие детали, таким образом оставаясь открытыми для интерпретации. Они помогают читателю понимать, что должна делать система.
Сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно и могут быть сформулированы с точки зрения формальной модели. Сценарий самодостаточен. Он обеспечивает всю необходимую информацию и детали для понимания. Сценарий описывается как «обобщенное описание ряда взаимодействий между системой и одним или более агентами, где агент — пользователь или другая система».
Важно отметить, что пользовательские истории - это один из инструментов Agile-разработки, и их эффективное использование требует тесного взаимодействия между заказчиком и командой разработки, а также постоянного обновления и уточнения требований по мере развития проекта.
Во многих контекстах пользовательские истории используются и также суммируются в группы по онтологическим, семантическим и организационным причинам. Инициатива также упоминается как Программа в определенных масштабируемых гибких фреймворках. Различные варианты использования зависят от точки зрения, например, либо взгляд с точки зрения пользователя как владельца продукта в отношении функций, либо с точки зрения компании в отношении организации задач.
Карта историй в действии, с эпиками наверху для структурирования историй
В то время как некоторые предлагают использовать «эпик» и «тему» в качестве меток для любого мыслимого вида группировки пользовательских историй, руководство организации склонно использовать их для сильной структуризации и объединения рабочих нагрузок. Например, Jira , похоже, использует иерархически организованный список дел , в котором они назвали первый уровень задач «пользовательская история», второй уровень «эпики» (группировка пользовательских историй) и третий уровень «инициативы» (группировка эпиков). Однако инициативы не всегда присутствуют в разработке управления продуктом и просто добавляют еще один уровень детализации. В Jira существуют «темы» (для целей отслеживания), которые позволяют перекрестно связывать и группировать элементы разных частей фиксированной иерархии . [
В этом использовании Jira изменяет значение тем в организационной перспективе: например, сколько времени мы потратили на разработку темы «xyz». Но другое определение тем: набор историй, эпиков, функций и т. д. для пользователя, который формирует общую семантическую единицу или цель . Вероятно, нет общего определения, поскольку существуют разные подходы для разных стилей проектирования и разработки продукта. В этом смысле некоторые также предлагают не использовать какие-либо жесткие группы и иерархии.
Несколько эпиков или много очень больших историй, которые тесно связаны, суммируются как темы. Распространенное объяснение эпиков также: так много работы, которая требует много спринтов, или в масштабируемых фреймворках — Release Train или Solution Train.
Несколько тем, эпосов или историй, сгруппированных иерархически.
Несколько тем или историй, сгруппированных по онтологией и/или семантическим связям.
Картографирование пользовательской истории
Карта историй организует пользовательские истории в соответствии с повествовательным потоком, который представляет общую картину продукта. Метод был разработан Джеффом Паттоном с 2005 по 2014 год для устранения риска переполнения проектов очень подробными пользовательскими историями, которые отвлекают от реализации основных целей продукта.
Картографирование пользовательской истории использует семинары с пользователями для определения основных видов деятельности бизнеса. Каждый из этих основных видов деятельности может включать несколько видов пользователей или персон.
Затем проводится горизонтальная сквозная повествовательная линия путем определения основных задач отдельного пользователя, вовлеченного в эти бизнес-действия. Линия сохраняется на протяжении всего проекта. Более подробные пользовательские истории собираются и собираются, как обычно, с практикой пользовательских историй. Но каждая новая пользовательская история либо вставляется в повествовательный поток, либо вертикально связана с основными задачами.
Горизонтальная ось соответствует охвату целей продукта, а вертикальная ось — потребностям отдельных пользователей.
Таким образом, становится возможным описывать даже большие системы, не теряя общей картины.
Карты историй могут легко обеспечить двухмерную графическую визуализацию бэклога продукта : в верхней части карты находятся заголовки, под которыми сгруппированы истории, обычно называемые «эпиками» (большие крупнозернистые пользовательские истории), «темами» (коллекции связанных пользовательских историй ) или «активностями». Они идентифицируются по ориентации на рабочий процесс пользователя или «порядок, в котором вы бы объяснили поведение системы». Вертикально, под эпосами, фактические карты историй распределяются и упорядочиваются по приоритету. Первый горизонтальный ряд представляет собой «ходячий скелет» , а ниже — возрастающую сложность.
Карта пути пользователяпризвана показать общую картину, но для одной категории пользователей. Ее повествовательная линия фокусируется на хронологии фаз и действий, которые должен выполнить один пользователь для достижения своих целей.
Это позволяет отображать пользовательский опыт за пределами набора пользовательских историй. На основе отзывов пользователей можно определить положительные и отрицательные эмоции на протяжении всего пути. Точки трения или неудовлетворенные потребности можно определить на карте. Этот метод используется для улучшения дизайна продукта, позволяя вовлекать пользователей в подходы, предполагающие участие.
Вариант использования (User Cases) описывается как «обобщенное описание набора взаимодействий между системой и одним или несколькими субъектами, где субъектом является либо пользователь, либо другая система».Хотя пользовательские истории и варианты использования имеют некоторые сходства, между ними есть и несколько различий.
| Истории пользователей (User Stories ) | Варианты использования (Use Cases) | |
|---|---|---|
| Сходства |
|
|
| Различия |
|
|
| Шаблон | Как <тип пользователя>, я могу <какая-то цель>, чтобы <какая-то причина>. |
|
Кент Бек , Алистер Кокберн , Мартин Фаулер и другие обсуждали эту тему далее в теме экстремального программирования
Хотя и истории пользователя и прецеденты служат выявлению конкретных требований пользователя в терминах взаимодействия между ним и системой, между ними существует существенное отличие:
| Истории пользователя (User Stories ) | Прецеденты |
|---|---|
|
|
Исследование, описанное в статье про пользовательские истории, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое пользовательские истории, user story, acceptance сriteria, ac и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Разработка программного обеспечения и информационных систем
Комментарии
Оставить комментарий
Разработка программного обеспечения и информационных систем
Термины: Разработка программного обеспечения и информационных систем