Все статьи
Что такое пользовательская история в 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 новой версии).
Поскольку эти работы не задевают напрямую пользователя мы описываем энейблеры на более техническом языке.
Энейблеры — это элементы бэклога, которые расширяют Архитектурную Полосу разрабатываемого решения или улучшают производительность потока разработки ценности.
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, вступайте в сообщество SAFe® Russia.
Критерии приёмки
Каждая история должна иметь чётко сформулированные критерии приёмки (acceptance criteria), содержащие необходимую информацию для команды для правильной реализации истории.
Как покупатель книг, я хочу попадать в корзину с любой страницы приложения, чтобы быстро оформить покупку.
- Пользователю необязательно входить в систему, чтобы воспользоваться функционалом.
- Кнопка корзины с покупками должна содержать счётчик выбранных товаров.
- Кнопка корзины с покупками может быть как иконкой, так и текстом.
- Когда пользователь перейдёт в список покупок, у него должна быть возможность вернуться на страницу, с которой он пришел.
Agile-команда использует критерии приёмки для создания приёмочных тестов, проверяющих ожидаемое поведение разрабатываемого решения. По возможности, команда автоматизирует эти тесты для быстрых регрессионных прогонов решения. Это ключевой момент в достижении встроенного качества (Built-In Quality).
Хорошая история требует множественных точек зрения (multiple perspectives). Создавая истории совместно, Agile-команда сможет учесть точки зрения всех своих участников, достичь согласия в ожидаемом поведении истории (Story Behaviour) и представить результаты в описании истории, критериях приёмки и приёмочных тестах.
Написание эффективных пользовательских историй является одним из ключевых навыков Agile-команды.
Встроенное Качество — это практики, которые на протяжении всего процесса создания ценности для клиента обеспечивают соответствие результатов работы Agile-команд действующим стандартам качества в технической части и бизнес-домене.
Критерии эффективных историй
Давайте теперь погрузимся в вопросы важности совместного написания историй и характеристики эффективных историй. В Agile в написание историй вовлечена вся команда полностью для создания общего понимания того, что надо разработать и прояснить для всех смысл и назначение истории. Этот подход сокращает число переделок, увеличивает пропускную способность и гарантирует поставку ценности в каждую итерацию.
Представьте себе совместное написание пользовательских историй в команде Agile-разработчиков.
- Владелец продукта представляет точку зрения пользователя.
- Разработчики обсуждают техническую возможность и варианты реализации.
- Тестировщики делятся идеями по исключительным ситуациям, граничным значениям и прочим неожиданным способам, которыми пользователь может взаимодействовать с системой.
Совместное написание истории гарантирует, что будут обсуждены все эти аспекты. Затем команда представляет результаты своего взаимодействия в виде описания истории и критериев приёмки. Критерии приёмки содержат информацию, необходимую для гарантии корректности реализации истории, и покрывают как функциональные, так и не функциональные требования к системе.
Характеристики эффективной истории
Модель I.N.V.E.S.T., разработанная Биллом Вейком, описывает характеристики «хорошей» истории.
История — это заявлением о намерении, а не финальный контракт. Она содержит ровно столько информации, сколько необходимо бизнесу и разработке для общего понимания цели. Глубокая детализация истории откладывается до момента её реализации.
Каждая история описывает и определяет важный для пользователя кусочек функциональности системы. Чтобы гарантировать ценность истории для пользователя она описывается с его точки зрения. Например:
Как покупатель (роль пользователя), я хочу попадать в корзину с покупками с любой страницы сайта (действие), чтобы быстрее завершать покупку (цель/бизнес-ценность).
При планирования итерации команда производит оценку истории, в первую очередь, чтобы убедиться в общем одинаковом её понимании. История достаточно маленькая, чтобы её можно было оценить и команда имеет достаточно опыта для того, чтобы её оценить.
Тестируемость — это ключевая характеристика любой пользовательской истории. Если мы не знаем, как мы будем тестировать историю, значит, мы не понимаем её достаточно хорошо, чтобы приступать к разработке. Критерии приёмки истории в явном виде говорят о том, как история будет протестирована и могут быть использованы командой для разработки приёмочных тестов.
