Блог
История (Story)

История (Story)

22 августа 2024

Что такое История?

История (Стори) — это краткое описание небольшого элемента желаемой функциональности, написанное от лица пользователя.

Agile команды реализуют истории в виде небольших вертикальных срезов функциональности системы, работа над которыми может быть завершена за несколько дней или меньше.

Истории — это основной артефакт, используемый для определения деталей и способов поведения системы в Agile. Они являются краткими, простыми описаниями функциональности, представленными c позиции пользователей и написанные на их языке. Каждая История реализует небольшой вертикальный срез поведения системы.

Истории предоставляют достаточно информации, чтобы бизнес- и технические специалисты могли понять намерение элемента функциональности. Детальные решения команды о способах разработки откладываются до тех пор, пока История не будет готова к переходу на стадию реализации. Благодаря критериям приёмки и приёмочным тестам Истории становятся более конкретными, что помогает обеспечить качество системы.

Пользовательские Истории доставляют функциональность непосредственно конечному пользователю. Истории-Энейблеры обеспечивают видимость для элементов работы, которые необходимы для поддержки исследований, архитектуры, инфраструктуры и соответствия требованиям.

В SAFe существует четырехуровневая иерархия артефактов, которые отражают функциональное поведение системы: Эпик, Капабилити (Возможность), Фича и История. В совокупности эти артефакты используются для описания предполагаемого поведения решения. Детали по реализации отражены в Историях, которые находятся в Беклоге Команды. Некоторые Истории возникают из Бизнес-Фич и Фич-Энейблеров в беклоге Релизного Поезда (Agile Release Train, ART), другие — из локального контекста команды.

Каждая История представляет собой небольшое, независимое поведение решения, которое может быть реализовано инкрементально и которое несет некоторую ценность для пользователя или решения. История является вертикальным срезом функциональности, таким образом каждая итерация гарантированно приносит новую ценность. Истории имеют небольшой размер и должны быть выполнены за одну итерацию (см. раздел Разделение историй).

Часто Истории сначала записываются на карточке или стикере. Наличие карточки создает осязаемую связь между командой, Историей и пользователем: она помогает вовлечь всю команду в написание Истории. Стикеры также имеют свои преимущества: они помогают визуализировать работу, их можно легко разместить на стене или столе или переставить, а при необходимости – удалить из рабочей области. Истории позволяют лучше понять объём и увидеть прогресс в выполнении работ:

«Посмотрите на все Истории, за выполнение которых мы собираемся взять на себя ответственность» (объем)
«Посмотрите на все Истории, которые мы сделали в эту итерацию» (прогресс)

Несмотря на то, что любой может написать Истории, ответственность за утверждение Историй в Беклоге Команды и взятие их в Итерации лежит на Владельце Продукта. Безусловно, стикеры плохо масштабируются на всё предприятие, поэтому Истории обычно обрабатываются в онлайн системах, которые называются «Agile инструменты управления жизненным циклом» (ALM).

В SAFe существует два типа историй: Пользовательские Истории и Истории-Энейблеры. Далее мы подробнее расскажем о каждом из них.

Источники Историй

Истории, как правило, возникают в результате декомпозиции Бизнес-Фич и Фич- Энейблеров, как показано на рисунке 1.

Рисунок 1. Пример Бизнес-Фичи, разделенной на Истории

Пользовательские Истории

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

Пользовательские Истории нацелены на удовлетворение потребностей клиента, поэтому основное внимание уделяется доставке ценности для него. Учитывая это, SAFe рекомендует писать Пользовательские Истории в формате «голоса пользователя»:

В качестве (роль пользователя) Я хочу (действие) таким образом (бизнес-ценность)
As a (user role), I want to (activity) so that (business value)

Используя этот формат, команды понимают, кто использует систему, что они с ней делают и почему они это делают. Таким образом, регулярное применение формата «голос пользователя» помогает повысить экспертность команды в предметной области. Члены команды начинают лучше понимать реальные бизнес-потребности своего пользователя. Пример показан на рисунке 2.

Рисунок 2. Пример Пользовательской Истории в формате «голос пользователя»

Персоны (personas) описывают характерные особенности клиентов решения, которые помогают командам лучше понять своего конечного пользователя. Например, для автомобильной компании персонами могут быть: Боб – любитель быстрой езды и Джейн – осторожный и законопослушный водитель. Описания историй могут ссылаться на этих персонажей (Как Джейн, я хочу…).

Несмотря на то, что формат «голос пользователя» является единым для всех Пользовательских Историй, не каждая система взаимодействует с конечным пользователем. Иногда «пользователем» является устройство (например, принтер) или система (например, сервер транзакций). В этих случаях История может быть написана в формате, показанном на рисунке 3.

Рисунок 3. Пример Пользовательской Истории, в которой роль пользователя выполняет «система»

Истории-Энейблеры

Команды также разрабатывают новую архитектуру и инфраструктуру, необходимые для реализации новых Пользовательских Историй. В этом случае История может напрямую не затрагивать конечного пользователя. Команды используют Истории-Энейблеры для проведения исследований, поддержки необходимой архитектуры или инфраструктуры. Истории-Энейблеры могут быть выражены техническим, а не ориентированным на пользователя, языком, как показано на рисунке 4.

Рисунок 4. Пример Истории-Энейблера

Существуют разные типы Историй-Энейблеров, в том числе:

Рефакторинг и Спайки
Создание или улучшение инфраструктуры разработки/развертывания
Выполнение технологических задач (Например, индексация 1 миллиона веб-страниц)
Создание необходимых конфигураций продуктов или компонентов для различных целей
Проверка качеств системы (например, тестирование производительности и уязвимостей)

Истории-Энейблеры демонстрируются так же, как и Пользовательские Истории: демонстрация полученных знаний, созданных артефактов или пользовательского интерфейса, модуля-заглушки (stub) или макета (mock-up).

Как написать хорошие Истории?

Для создания хороших Историй необходимо рассмотреть несколько точек зрения. В Agile все члены команды договариваются о том, что именно они будут создавать, чтобы сократить количество доработок и повысить производительность. Команды взаимодействуют друг с другом, используя разработку на основе поведения (BDD) для определения деталей приёмочных тестов, которые конкретно и точно описывают, что из себя должна представлять каждая завершённая история с точки зрения поведения системы.

Совместное написание историй помогает учесть все точки зрения и договориться о едином понимании вариантов поведения Истории, включая результаты, представленные в описании Истории, критериях приёмки. Ожидаемое поведение Истории в итоге фиксируется в приёмочных тестах, которые пишутся на языке домена системы с использованием BDD. Затем тесты BDD автоматизируются и начинают непрерывно выполняться, что в дальнейшем поддерживает встроенное качество. Тесты BDD должны отвечать требованиям (Историям) системы и, следовательно, могут использоваться в качестве окончательного утвержденного описания поведения системы, заменяя классические спецификации, основанные на документах.

3Cs: Card, Conversation, Confirmation

Рон Джеффрис, один из изобретателей XP, считается автором подхода 3Cs для написания Историй:

Карточка (Card) – Заявление Истории о намерении фиксируется на бумажной карточке, стикере или с помощью какого-то другого инструмента. Карточки обеспечивают физическую связь между командой и Историей. Размер карточки физически ограничивает масштаб описания Истории и преждевременные предположения о требуемой специфике поведения системы. Физические карточки также помогают команде «прочувствовать» объем предстоящей работы. Так как есть большая разница между «держать десять карточек в руке» или «смотреть на десять строчек в электронной таблице».
Обсуждение (Conversation) – Обязательное обсуждение Истории между командой, клиентом (или доверенным лицом клиента), Владельцем Продукта (который может представлять клиента) и другими заинтересованными лицами. Обсуждение позволяет определить детали поведения, необходимые для реализации намерения. В результате дискуссии могут появиться дополнительные требования и конкретика в виде критериев приёмки или уточнений формулировки самой Пользовательской Истории.

Обсуждение охватывает все этапы жизненного цикла Истории:

- Уточнение беклога
- Планирование
- Реализация
- Демонстрация

Своевременное обсуждение создает единое понимание объема работ, что не может обеспечить формальная документация. Спецификация в виде примера может заменить подробную документацию. Обсуждение также помогает выявить пробелы в пользовательских сценариях и нефункциональных требованиях (НФТ / NFR).

Подтверждение (Confirmation) – Критерии приёмки содержат информацию, которая позволяет убедиться в том, что История реализована правильно и охватывает соответствующий функционал и НФТ (NFR). Пример приведен на рисунке 5. Некоторые команды часто используют раздел подтверждения в карточке Истории, в том числе чтобы записать то, что они будут демонстрировать.

Рисунок 5. Критерии приёмки Истории с помощью BDD

Agile команды формулируют приёмочные тесты везде, где это возможно, как правило, на понятном для бизнеса языке, специфичном для предметной области. Формулировка в виде BDD позволяет создать исполняемую спецификацию для валидации и верификации решения. Подобная автоматизация также обеспечивает возможность быстрого регрессионного тестирования системы, улучшая Непрерывную Интеграцию, рефакторинг и обслуживание.

Инвестируем в хорошие Истории — INVEST

Agile команды тратят много времени на поиск и выявление, проработку и понимание Пользовательских Историй, а также на написание приёмочных тестов. Так и должно быть, потому что:

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

На самом деле сложнее всего — понять реальную цель, для чего пишется код. Поэтому инвестиции в создание хороших Пользовательских Историй оправдывают усилия команды. Билл Уэйк (Bill Wake) придумал аббревиатуру INVEST для описания свойств хорошо подготовленной Пользовательской Истории.

I – Independent (Независимая) – Пишите Истории, которые могут разрабатываться отдельно, независимо от других Историй
N – Negotiable (Обсуждаемая) – Пишите Истории, объём работ по которым может обсуждаться
V – Valuable (Ценная) – Пишите Истории, которые предоставляют ценность клиенту
E – Estimable (Оцениваемая) – Пишите Истории, которые могут быть оценены
S – Small (Маленькая) – Пишите Истории, которые помещается в Итерацию
T – Testable (Проверяемая) – Пишите Истории, которые можно проверить

Декомпозиция хороших Историй

Небольшие Истории будут разработаны быстрее, и их оценка будет содержать меньше неопределённости. Небольшие элементы проходят через любую систему быстрее, с меньшей вариативностью и меньшим риском. Поэтому декомпозиция больших Историй на более мелкие — обязательный навык для каждой Agile команды. Это одновременно и искусство, и наука инкрементальной разработки. Известный подход разделения большой Истории на более мелкие включает в себя десять различных вариантов:

Шаги рабочего процесса
Варианты бизнес-правил
Значительные усилия
Просто/сложно
Различия в данных
Методы ввода данных
Ожидаемые качества системы
Эксплуатация (например, Create (Создание), Read (Чтение), Update (Обновление), Delete (Удаление) [CRUD])
Сценарии использования
Создание спайка

На рисунке 6 показан пример разделения Истории по сценариям использования.

Рисунок 6. Пример декомпозиции большой Истории на более мелкие Истории

Как оценить Истории?

Agile команды используют сторипоинты и «покер оценки», чтобы оценить объём предстоящей работы. Сторипоинт (story point) — это одно число, которое одновременно включает в себя комбинацию качеств:

Объём – Сколько там?
Сложность/комплексность – насколько сложно?
Знание – Что мы знаем?
Неопределённость – Что неизвестно?

Сторипоинты относительны, не привязаны к какой-либо конкретной единице измерения. Размер каждой Истории (сложность и риски) оценивается относительно наименьшей Истории, которой присваивается «один сторипоинт». Во время оценки применяется модифицированная последовательность Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100) [2], позволяющая учесть неопределённость в оценке сложности, особенно когда это относится к высоким оценкам сложности (например, 20, 40, 100).

Покер оценки (Estimating Poker)

«Покер оценки» сочетает в себе экспертное мнение участников, аналогию и дезагрегацию, то есть разделение Историй или Фич на более мелкие, более простые для оценки элементы. Agile команды часто используют этот инструмент для проведения быстрой и надежной оценки Истории. (При этом следует отметить, что существуют и другие методы.)

Правила покера оценки:

Участвуют все члены команды.
Каждый участник получает колоду карт, содержащую модифицированную последовательность Фибоначчи.
Владелец Продукта участвует в мероприятии, но не принимает участие в самой оценке.
Скрам Мастер/Коуч Команды участвует в мероприятии, но не оценивает, если только он не выполняет какую-то работу по разработке.
Для каждого элемента беклога, который необходимо оценить, Владелец Продукта зачитывает описание Истории.
Обсуждение, ответы на вопросы.
Каждый участник «в закрытую» выбирает карту со своей оценкой.
Все участники одновременно переворачивают карты, чтобы избежать предвзятости и сделать все оценки видимыми.
Участники, которые поставили высокие и низкие оценки, комментируют свои оценки. Участники обсуждают разницу.
После обсуждения каждый участник проводит повторную оценку и повторно выбирает свою карту с оценкой.
Оценки, скорее всего, сойдутся; Если нет, процесс повторяется.

До проведения покера оценки рекомендуется предварительно провести небольшое обсуждение дизайна Истории. При этом слишком длительное обсуждение дизайна часто превращается в потерю времени. Реальная ценность покера оценки заключается в том, чтобы договориться о сложности и деталях выполнения Истории. Кроме этого, это еще и весёлое упражнение!

Пропускная способность (Velocity)

Пропускная способность (скорость) команды на Итерацию равна среднему значению количества сторипоинтов за несколько предыдущих Итераций, которые были приняты в соответствии с Определением Выполненности (Definition of Done, DoD). Если члены команды в течение долгого времени работают вместе, то средняя скорость такой команды (количество выполненных сторипоинтов за итерацию) становится устойчивой и предсказуемой. Предсказуемая скорость помогает в планировании и ограничении количества незавершённой работы, так как команды не берут на себя больше Историй, чем позволяет их историческая скорость. Этот показатель также оценивает, сколько времени требуется команде для доставки Эпиков, Фич, Возможностей (Капабилити) и Энейблеров, которые также прогнозируются с помощью сторипоинтов.

Ёмкость (Capacity)

Ёмкость — это пропускная способность команды, которая рассчитана для конкретной Итерации. Из-за отпуска, отсутствия на рабочем месте или каких-то других событий некоторые члены команды не смогут вносить свой вклад в разработку и достижение целей Итерации в течение определенного времени в рамках Итерации. Таким образом, максимальная потенциальная скорость для этой команды на эту Итерацию уменьшается. Например, команда, которая в среднем доставляет 40 сторипоинтов за Итерацию, скорректирует свою максимальную скорость до 36, если член команды находится в отпуске в течение одной недели. Зная об этом заранее, во время Планирования Итерации команда берет на себя обязательство выполнить Истории на максимум 36 сторипоинтов в предстоящую Итерацию. Во время PI-Планирования такой подход также помогает прогнозировать фактическую ёмкость, доступную для каждой Итерации в Интервал Планирования (Planning Interval, PI). Таким образом, при разработке своих целей на Интервал Планирования команда не берет на себя больше обязательств, чем может выполнить.

Устанавливаем базовый уровень для оценки

В стандартном Скраме оценка в сторипоинтах для каждой команды — и результирующая пропускная способность (скорость) — является локальной и независимой, что также означает возможную крайне высокую разницу в оценках от команды к команде. При большом масштабе это делает крайне трудным предсказание размера в сторипоинтах для более крупных Эпиков и Фич, когда пропускная способность команд сильно отличается друг от друга. Чтобы решить эту проблему, команды в SAFe изначально «калибруют» стартовое значение для сторипоинта, где один сторипоинт определяется примерно одинаково для всех команд. При этом отсутствует необходимость регулярно перекалибровывать оценку команды или пропускную способность. Нормальной является ситуация, когда калибровка (определение Историй на 1 сторипоинт) выполняется один раз при запуске новых Релизных Поездов (Agile Release Train, ART).

Нормализованные сторипоинты – метод, который помогает определить стартовое значение пропускной способности для новых команд. Это позволяет сформировать перечень Историй, которые команда потенциально может выполнить в Итерацию:

Определите 8 сторипоинтов на каждого членка команды за исключением Владельца Продукта и Скрам Мастера для двухнедельной Итерации.
Вычтите один сторипоинт за каждый день отсутствия для каждого члена команды.
Найдите небольшую Историю, полная разработка которой (включая обсуждение, написание кода, тестирование и проверку) займёт примерно 1 день. Обозначьте ее как «История на один сторипоинт». Это не означает 100% загрузку всех участвующих в разработке этой Истории в течение дня. Иными словами, речь идёт об астрономическом рабочем дне, а не сумме рабочих часов каждого участника.
Оцените сложность каждой следующей Истории относительно той, которую вы приняли за «1».

Пример: Команда состоит из шести человек, включая трех разработчиков, двух тестировщиков, Скрам Мастера и Владельца Продукта, без отпусков и праздников. В этом сценарии предполагаемая изначальная скорость = 5 × 8 сторипоинтов = 40 сторипоинтов на Итерацию.

Таким образом, мы достигаем, что сторипоинты между командами не равны, но в некоторой степени сопоставимы. Это помогает менеджменту лучше понять стоимость одного сторипоинта и более точно определить стоимость ближайшей Фичи или Эпика. Несмотря на то, что команды со временем увеличивают свою пропускную способность (и это хорошо), в реальности пропускная способность может оставаться стабильной. На практике на пропускную способность сильно влияет изменение размера команды и технический контекст выполняемых Историй, а не вариации производительности.

Примечание: В SAFe организациях Kanban команды обычно тратят меньше времени на оценку Историй, чем Scrum команды. В Канбан модели, основанной на потоке, элементы работы или Истории обычно разделяются и «калибруются» таким образом, чтобы команда могла доставить одну Историю в рамках одного «слота», который обычно составляет несколько дней. В контексте SAFe, где командам необходимо участвовать в Планировании Итераций и распределять Истории для разработки в будущих Итерациях, Канбан командах также необходимо иметь некоторое представление о размерах этих Историй.

Канбан команды в SAFe могут изначально использовать покер оценки или аналогичный механизм для определения размера своих Историй. Однако более вероятно, что со временем у них появляется понимание, как разделять работу на Истории, близкие по сложности. Такой подход помогает потоку в целом и гарантирует, что ни одна большая История не блокирует другие Истории, которые также должны пройти через систему Канбан. По мере того, как команды понимают свою скорость, они могут предвидеть, сколько Историй они могут доставить за единицу времени. Это позволяет им размещать Истории по Итерациях во время PI Планирования и иметь возможность брать на себя обязательства перед другими командами относительно того, когда будут выполнены конкретные Истории.

Для команд, отвечающих за регулярное обслуживание и поддержку, проведение оценки своих типичных элементов работы часто не даёт какой-то дополнительной ценности. В большинстве случаях эти команды не оценивают такой тип работы как «обработка запросов». Тем не менее, все команды должны проводить Ретроспективы, формулировать элементы улучшений в своих беклогах, а также обсуждать внедрение новых практик и другие важные вопросы, требующие внимания, планирования и оценки.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Story».