Tales user story что это

Обновлено: 02.07.2024

Самая интересная штука в Scrum, это Пользовательские истории или User Story. Никаких Вам технических заданий, распоряжений или, ужас какой, приказов.

Это небольшая карточка с одним предложением:

Как … я хочу ….чтобы…

Ну вернее много карточек, конечно.

3 правила написания User Story:

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

2. Обычный язык. Знаете или не знаете сложные термины — в пользовательских историях пишите языком пользователя или заказчика.

3. Компактность требований. В идеале, одна User Story формулирует одно конкретное и небольшое требование. Дробить задачи стоит аккуратно . Уменьшать требования до функции выбора цвета кнопки в итоге обойдется себе дороже.

Рекомендуется ориентироваться на объем работа, которые укладываются в период одного спринта.

Карточки с User Story оформляются и в электронном и в бумажном форматах.

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

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

Все зависит от направления работ и тематики проектов. Главное, потом придерживаться этих форматов внутри одного проекта.

Формула: >>> Как … я хочу … чтобы … <<<

состоит из трех частей:

КАК — это заказчик или конечный пользователь результатов проекта.

Я ХОЧУ — примечание, чтобы увидеть глазами пользователя конечный результат задачи

ЧТОБЫ — итоговая цель для чего задача исполняется.

КАК подписчик Я ХОЧУ видеть название каждой строки при вводе личной информации ЧТОБЫ знать какую именно информацию мне нужно вводить.

Формулу можно дополнять, но убирать из нее элементы не рекомендуется.

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

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

Я, как покупатель интернет-магазина, хочу оплатить покупку онлайн.

И вот несколько пользовательских историй, которые могут быть частью эпика выше:

Я, как покупатель, хочу оплатить покупку через банковскую карту Visa (MasterCard, МИР и т. д.)
Я, как покупатель, хочу оплатить покупку через банковский перевод

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

У оформленной истории также появляется порядковый номер, приоритет и оценка работы. Последний показатель присваивается истории на планировании работ, каждая команда может использовать свою систему оценок. Число показывает, сколько сил уйдет на выполнение User Story.

Для порядка в бэклоге может добавляться тема истории (если разработка идет по нескольким направлениям).

Детализироваться истории могут двумя способами:

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

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

Такие требования нужно переосмыслять. Что значит масштабируемость для этой системы? — Чтобы платежная сеть обрабатывала минимум 2 млн транзакций в секунду. Это уже можно оценить, реализовать и проверить.

Кто и когда пишет истории?

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

В разработке по Agile важно не кто написал историю, а кто ее обсуждал.

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

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

Contents

Talse Uzer Story

A Talse Uzer Story (TUS) is the story set in Talse Uzer, the universe and overarching story that Tower of God is set in. The TUS is a universe under the premise that “The world comprises of several tales as its centre, and these tales persist as unchangeable records”.

Once written, a tale from the Talse Uzer universe cannot be set back or restored to a previous state. Hence the past becomes permanently fixed, which in turn restricts future events. It's a universe that rejects the existing hypothesis that the world holds infinite possibilities.

Up to this point, Tower of God is the only 'official' TUS in Talse Uzer since SIU is yet to publish any other Talse Uzer Stories. However, this detail may change in the future.

Talse Uzer Story

A Talse Uzer Story (TUS) is the story set in Talse Uzer, the universe and overarching story that Tower of God is set in.

About

Once written, a tale from the Talse Uzer universe cannot be set back or restored to a previous state. Hence, the past becomes permanently fixed, which in turn restricts future events. It's a universe that rejects the existing hypothesis that the world holds infinite possibilities.

Up to this point, Tower of God is the only 'official' TUS in Talse Uzer since SIU is yet to publish any other Talse Uzer Stories. However, this detail may change in the future.

Чем еще хороши истории?

Нам нравится работать через истории, потому что:

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

Что такое пользовательская история и как она помогает в разработке программ?

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

Как «кто-то», я хочу «выполнить что-то», чтобы «прийти к такой-то цели».

Анализируя историю, команда отвечает на вопросы:

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

Как и все в Agile, такая структура не жесткое правило. Целевую часть иногда могут опускать, хотя именно она описывает ценность.

Где будут записаны истории, не так важно. Это могут быть стикеры, бумага или цифровой документе. Место User Story — в бэклоге продукта.

Подход к описанию задачи с точки зрения пользователя смещает фокус на него. Это соответствует принципам Agile: с историями команда лучше понимает, как поставить ценное ПО.

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

10 приемов, чтобы написать хорошую историю

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

Читайте также: