Это общее описание функций программы, написанное как бы от имени пользователя. В user-story формулируется, чем функционал приложения ценен для заказчика. Добавить дополнительную информацию, если это необходимо. Иногда User story нуждаются в дополнительной информации, чтобы разработчики могли лучше понимать задачу. Добавление примеров использования, требований к дизайну или примеров данных может помочь лучше сформулировать историю и избежать недопонимания.
На переговорах мы стараемся вытянуть из него максимальную информацию о том, чего хочет пользователь. Полезность юзер стори прежде всего в том, что они помогают разработчику лучше понять область, продукт, аудиторию заказчика. Востребованность юзер стори оценивается обнаружением и проработкой пользовательских потребностей, на выходе продукт их должен удовлетворять. Обязательно формулируйте персоны вашего продукта до начала работы над user story.
Расширяем user stories
При необходимости определитесь с промежуточными проверками. Мы работаем в распределенных командах, где все работают удаленно, а карта пользовательских историй — это инструмент для постоянной работы, поэтому для USM мы используем Miro. Все примеры, которые я приведу ниже, взяты из реальной жизни, с доски одной из наших команд. Во многих контекстах используются пользовательские истории, которые также объединяются в группы по смысловым и организационным причинам. Мы часто сталкиваемся с ситуацией, когда сами разработчики начинают описывать пользовательские сценарии, думая от лица пользователя. Дизайнеры стараются использовать самые трендовые «фишки», надеясь, что именно этот проект дополнит их портфолио ещё одной качественной работой.
Архитекторы, разработчики, тестировщики и прочие мастера своего дела, опираясь на «хотелки» пользователей и сценарии того, как эти хотелки будут совершаться, видят для себя конкретный вектор работы. Обратите внимание, что итоговый приоритет определяется сценарием пользователя. Мы идем слева направо, и только затем по версиям – ведь мы хотим принести больше ценности пользователю.
Что такое пользовательские истории в agile?
Пользовательские истории — быстрый способ документировать требования клиента, без необходимости разрабатывать обширные формализованные документы и впоследствии тратить ресурсы на их поддержание. Цель пользовательских историй состоит в том, чтобы быть в состоянии оперативно и без накладных затрат реагировать на быстро изменяющиеся требования реального мира. Я использовал оба термина « пользовательская история » и « задача » годами в своих тренингах, и мне казалось, что они имеют вполне конкретные отличия. Пользовательские истории составляли беклог продукта, а задачи выявляли во время планирования спринта и записывали в беклог спринта.
Пользовательские истории – это тип пограничного объекта. Они способствуют выработке смысла и общению, то есть помогают командам разработчиков систематизировать свое понимание системы и ее контекста. Если вовлечь команду разработки нельзя, подумайте над использованием другой техники для определения функциональности продукта — Use Cases (кейсы использования продукта). Если вы не знаете, кто ваши пользователи и покупатели, и как она хотят использовать ваш продукт, не следует писать истории вообще. Вы рискуете создать теоретические истории, основанные на ваших убеждениях и идеях, а не на данных и эмпирических доказательствах. Я уверен, вы неоднократно будете пользоваться этими простыми но мощными средствами управления требованиями, когда начнете использовать истории в своих проектах.
МОЩНЫЕ ИНСТРУМЕНТЫ РАБОТЫ С ИСТОРИЯМИ: УПОРЯДОЧИВАНИЕ, РАЗБИЕНИЕ И ГРУППИРОВКА
В таком подходе написание ТЗ — это отдельный этап разработки, на выходе из которого появляется подробный, максимально детальный документ, в идеале, написанный по ГОСТ. И без такого документа к команде разработчиков даже подходить нельзя. Даже среди команд, работающих по Scrum, нередко встречаются такие, где задачи на разработку приходят только после подготовки аналитиком ЧТЗ — частного технического задания. Часто лучше рассматривать письменную часть как указатель на реальное требование. Пользовательские истории редко включают в себя сведения о производительности или нефункциональных требованиях, поэтому нефункциональные тесты (например, время отклика) могут быть пропущены. Без точной формулировки требований могут возникнуть длительные неконструктивные аргументы, когда продукт должен быть доставлен.
Это позволяет разработчику узнать, когда пользовательская история готова и как клиенту проверить это. Без точных формулировок требований в момент поставки продукта могут возникнуть длительные неконструктивные разногласия. Эпики — это по сути те же истории пользователей, но они включают несколько и содержат описание функционала приложения и его задач. Обычно эпики используют, чтобы не перегружать список с общими задачами. Когда приходит время создания юзер стори, то эпики дробят на эти истории.
Формула User Story
Если рассказывать о нём историю (как он живет, что делает) это хорошо запомнится всем участникам диалога, и в дальнейшем будет достаточно назвать типаж клиента, и всем будет понятно, о ком идёт речь. В результате такого мышления, направленного на желаемый исход (то что будет после создания продукта), мы фокусируемся на продуктовые ценности, которые лягут в основу создаваемой карты. Для подтверждения задачи agile-команда проводит демонстрацию новой функциональности заказчику, собирает замечания, получая оперативную обратную связь. User Stories Applied – самая лучшая и полная книга о том, как писать, оценивать, тестировать и принимать пользовательские истории. Процесс разработки мобильного приложения состоит из нескольких последовательных этапов.
- Есть определенные правила составления User Story, а также критерии оценки получившегося в итоге материала.
- Сформулировав пользовательские истории, позаботьтесь о том, чтобы они были доступны всей команде.
- 5 Как гость я могу войти в систему под ранее созданной учетной записью, для последующей работы.
- В ходе собрания по планированию спринта или итерации команда решает, какие истории она выполнит в ходе этого спринта.
- Пользовательские истории — это номинальное требование от пользователя с описанием его конечной цели.
User story — это эффективный инструмент для организации работы внутри IT-отдела. Но система может подойти для команд из любых сфер, в которых требуется решать много сложных задач быстро. Впоследствии эпики разделяют на несколько карточек, чтобы работать над ними. Если бы это делали сразу, список задач бы увеличивался из-за большого количества актуальных историй. Чтобы написать хорошую историю, важно руководствоваться принципами и использовать основные шаги, которые чаще применяют в большинстве компаний. При написании пользовательских историй держите в уме следующее.
Критерии INVEST для User Story
Думайте не только о должности, но о самой личности человека. Наша команда должна иметь общее представление о том, кто такой Макс. Мы понимаем, как «работает» этот человек, как он думает и что он чувствует. Пользользовательская история называется историей потому что она создается через рассказ, как история. Подробный пример с описанием всех шагов был выше — надеемся, что логика ясна. Проще всего визуализировать через такие инструменты, где предусмотрено создание досок и карточек.
Это означает, что для того чтобы чтобы сделать нашу user story проверяемой, мы можем переписать ее в формате gherkin. И хотя разные части могут быть
интересными разным категориям читателей,
важно, user story это чтобы каждый разобрался в этом
подходе в целом. Госзаказчики (и не только они!) и сейчас очень любят писать задания на разработку по ГОСТ — кажется, что это гарантирует качество.