Все статьи

Рустем Файзуллин

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

Сергей Рогачев

Генеральный директор «Лидеры изменений», Agile-коуч, эксперт в Agile-трансформации крупных компаний.

Развивает SAFe® и OKR в России, продюсер исследования «Agile в России», конференций Enterprise Agile Russia и OKR Russia. Публичные кейсы: Монитор Электрик, РТЛабс, Газпром нефть, ХМАО, HeadHunter, Главстрой, Xsolla, Администрация города Саратов, Билайн, DSSL и Сбербанк.

Подробнее

Что такое пользовательская история в SAFe®?

Дата: 14.12.2023

В этой статье вы узнаете, зачем использовать пользовательские истории в качестве элементов бэклога команды в Scaled Agile Framework® (SAFe®), рассмотрите несколько примеров хорошо написанных историй и поймете, что делает эти истории хорошими.

Истории — элемент модели требований

В SAFe принята следующая структура декомпозиции работ:

  • Эпик.
  • Фича.
  • История.

Совместно они описывают работы для создания решения с ожидаемым поведением. Истории при этом являются самым распространённым типом описания, определяющим работу Agile-команды. История – это сокращенное название от «пользовательская история». Это подход описания ожидаемого результата работы от лица будущего пользователя разрабатываемой нами системы. Этот подход пришел из XP (Extreme Programming, экстремальное программирование) и замечательно изложен Майком Коном в книге «Пользовательские истории. Гибкая разработка программного обеспечения».

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

В Agile истории обычно замещают собой более традиционные форматы спецификаций. Строго говоря, истории не являются жесткими требованиями к функционалу, а скорее общей идеей, намерением. Большинство историй появляются в процессе декомпозиции фич из Бэклога ART. Но некоторые истории могут быть не связаны с фичами, они появляются из понимания командой сути выполняемых ею работ. Независимо от своего происхождения, все истории отправляются в бэклог команды.

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

Модель требований SAFe

Эпик — существенная инициатива по разработке Решения.

Фича представляет собой функциональность решения, которая несет ценность для бизнеса, удовлетворяет потребности заинтересованных лиц и имеет такой размер, что она может быть реализована одним Agile Release Train в рамках одного Интервала Планирования (Planning Interval, PI).

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

Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.

Итерации — это стандартный временной отрезок фиксированной длительности, в течение которого Agile-команды и ART по отдельности и совместно обеспечивают прирост потребительской ценности, работая над достижением PI-целей.

Бэклог ART — это Канбан-система, используемая для сбора и управления Фичами и Энейблерами, предназначенными для функционального улучшения Решения и расширения Архитектурной Полосы.

Бэклог Команды — это Канбан-система для хранения и управления пользовательскими Историями и Энейблерами для развития Решения.

Владелец Продукта — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, что он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.

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

В SAFe различают два типа историй:

  1. Пользовательские истории.
  2. Enabler-истории (энейблеры).

Пользовательские истории описывают ценность для конечного пользователя. Поскольку истории пользователе-центричны, они описываются от лица пользователя.

Хорошо написанная история должна описывать требуемый функционал, быть сосредоточенной на пользователе, а не на системе и содержать достаточный минимум информации для бизнеса и разработчиков, чтобы понимать цель истории.

Помимо пользовательских историй в SAFe выделяют второй тип работ – это Enabler-истории (энейблеры).

Энейблеры нужны для описания работ, необходимых команде для продолжения разработки:

  • архитектура (например, переход 8 на 11 версию Java);
  • соблюдение требований регуляторов (например, требование к алгоритмам и длина ключа шифрования);
  • исследованиям (Spike, небольшое исследование в рамках истории);
  • инфраструктура (переход в OpenShift новой версии).

Поскольку эти работы не задевают напрямую пользователя мы описываем энейблеры на более техническом языке.

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

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

Критерии приёмки

Каждая история должна иметь чётко сформулированные критерии приёмки (acceptance criteria), содержащие необходимую информацию для команды для правильной реализации истории.

Agile-команда использует критерии приёмки для создания приёмочных тестов, проверяющих ожидаемое поведение разрабатываемого решения. По возможности, команда автоматизирует эти тесты для быстрых регрессионных прогонов решения. Это ключевой момент в достижении встроенного качества (Built-In Quality).

Хорошая история требует множественных точек зрения (multiple perspectives). Создавая истории совместно, Agile-команда сможет учесть точки зрения всех своих участников, достичь согласия в ожидаемом поведении истории (Story Behaviour) и представить результаты в описании истории, критериях приёмки и приёмочных тестах.

Написание эффективных пользовательских историй является одним из ключевых навыков Agile-команды.

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

Критерии эффективных историй

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

Представьте себе совместное написание пользовательских историй в команде Agile-разработчиков.

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

Совместное написание истории гарантирует, что будут обсуждены все эти аспекты. Затем команда представляет результаты своего взаимодействия в виде описания истории и критериев приёмки. Критерии приёмки содержат информацию, необходимую для гарантии корректности реализации истории, и покрывают как функциональные, так и не функциональные требования к системе.

Характеристики эффективной истории

Модель I.N.V.E.S.T., разработанная Биллом Вейком, описывает характеристики «хорошей» истории.

SAFe® для команд
Тренинг SAFe® for Teams дает навыки работы в Agile-команде, которая в рамках Agile Release Train (ART) совместно с другими Agile-командами и заинтересованными лицами разрабатывает единое решение. По окончании тренинга и сдачи выходного экзамена участники получают международный сертификат Certified SAFe® Practitioner (SP).

Авторы:

Поделиться

VK
Telegram