Все статьи
Что такое пользовательская история в SAFe®?
Дата: 14.12.2023
В этой статье вы узнаете, зачем использовать пользовательские истории в качестве элементов бэклога команды в Scaled Agile Framework® (SAFe®), рассмотрите несколько примеров хорошо написанных историй и поймете, что делает эти истории хорошими.
Истории — элемент модели требований
В SAFe принята следующая структура декомпозиции работ:
- Эпик.
- Фича.
- История.
Совместно они описывают работы для создания решения с ожидаемым поведением. Истории при этом являются самым распространённым типом описания, определяющим работу Agile-команды. История – это сокращенное название от «пользовательская история». Это подход описания ожидаемого результата работы от лица будущего пользователя разрабатываемой нами системы. Этот подход пришел из XP (Extreme Programming, экстремальное программирование) и замечательно изложен Майком Коном в книге «Пользовательские истории. Гибкая разработка программного обеспечения».
Каждая история описывает небольшой кусочек функциональности, который Agile-команда может сделать за одну итерацию.
В Agile истории обычно замещают собой более традиционные форматы спецификаций. Строго говоря, истории не являются жесткими требованиями к функционалу, а скорее общей идеей, намерением. Большинство историй появляются в процессе декомпозиции фич из Бэклога ART. Но некоторые истории могут быть не связаны с фичами, они появляются из понимания командой сути выполняемых ею работ. Независимо от своего происхождения, все истории отправляются в бэклог команды.
Любой член команды может написать историю, но только владелец продукта определяет, что попадёт в бэклог команды, а что нет, и оценивает получившийся результат, когда работы над историями закончены.
Эпик — существенная инициатива по разработке Решения.
Фича представляет собой функциональность решения, которая несет ценность для бизнеса, удовлетворяет потребности заинтересованных лиц и имеет такой размер, что она может быть реализована одним Agile Release Train в рамках одного Интервала Планирования (Planning Interval, PI).
Истории — это короткие описания небольшого компонента желаемой функциональности на понятном пользователю языке.
Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Итерации — это стандартный временной отрезок фиксированной длительности, в течение которого Agile-команды и ART по отдельности и совместно обеспечивают прирост потребительской ценности, работая над достижением PI-целей.
Бэклог ART — это Канбан-система, используемая для сбора и управления Фичами и Энейблерами, предназначенными для функционального улучшения Решения и расширения Архитектурной Полосы.
Бэклог Команды — это Канбан-система для хранения и управления пользовательскими Историями и Энейблерами для развития Решения.
Владелец Продукта — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, что он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.
Истории и энейблеры
В SAFe различают два типа историй:
- Пользовательские истории.
- 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., разработанная Биллом Вейком, описывает характеристики «хорошей» истории.
История — это заявлением о намерении, а не финальный контракт. Она содержит ровно столько информации, сколько необходимо бизнесу и разработке для общего понимания цели. Глубокая детализация истории откладывается до момента её реализации.
Каждая история описывает и определяет важный для пользователя кусочек функциональности системы. Чтобы гарантировать ценность истории для пользователя она описывается с его точки зрения. Например:
Как покупатель (роль пользователя), я хочу попадать в корзину с покупками с любой страницы сайта (действие), чтобы быстрее завершать покупку (цель/бизнес-ценность).
При планирования итерации команда производит оценку истории, в первую очередь, чтобы убедиться в общем одинаковом её понимании. История достаточно маленькая, чтобы её можно было оценить и команда имеет достаточно опыта для того, чтобы её оценить.
Тестируемость — это ключевая характеристика любой пользовательской истории. Если мы не знаем, как мы будем тестировать историю, значит, мы не понимаем её достаточно хорошо, чтобы приступать к разработке. Критерии приёмки истории в явном виде говорят о том, как история будет протестирована и могут быть использованы командой для разработки приёмочных тестов.
