В гибкой разработке основной целью является постепенная доставка ценности. Однако функции часто начинаются как огромные эпики, которые слишком велики, чтобы поместиться в один спринт. Когда требование слишком велико, оно становится риском. Оно останавливает прогресс, задерживает обратную связь и вызывает путаницу относительно того, что на самом деле завершено. Именно здесь становится необходимым разделение пользовательских историй.
Разделение крупного требования на более мелкие, управляемые части позволяет команде регулярно доставлять рабочее программное обеспечение. Это снижает риски и гарантирует, что каждый этап приносит ценность конечному пользователю. Данное руководство рассматривает практические стратегии по разбиению сложных функций на выполнимые пользовательские истории.
🧩 Почему разделение имеет значение
Большая пользовательская история часто не соответствует критериям INVESTкритериев. Она может быть слишком большой для точной оценки, непроверяемой или не имеющей ценности в отдельности. Когда история слишком большая, команда может потратить недели на её выполнение, не показав ничего заинтересованным сторонам. Разделение решает эти проблемы, фокусируясь на:
- Скорость доставки:Меньшие истории означают более быстрое завершение и более раннюю доставку.
- Циклы обратной связи:Заинтересованные стороны могут быстрее оценить рабочее программное обеспечение и дать направление.
- Снижение рисков: Если обнаружена ошибка, её легче изолировать в небольшой истории, чем в огромном эпике.
- Фокус: Команды могут сосредоточиться на одной конкретной цели, не переключаясь между задачами.
📐 Критерии INVEST
Прежде чем разделять, полезно понять, что делает историю хорошей. Модель INVEST предоставляет чек-лист:
- IНезависимость: история не должна сильно зависеть от других историй.
- NОбсуждаемость: детали можно обсуждать и корректировать.
- VЦенность: она должна приносить ценность пользователю.
- EОцениваемость: команда должна уметь оценить объём усилий.
- SМалость: она должна умещаться в рамках одного спринта.
- TПроверяемость: должны существовать чёткие критерии принятия.
Если история не соответствует хотя бы одному из этих критериев, её необходимо разделить. Цель — создать последовательность историй, которые можно доставлять независимо, но при этом вносить вклад в общую цель.
🔨 Распространенные методы разделения
Существует не один способ разделения истории. Правильный подход зависит от функции. Ниже приведено сравнение распространенных стратегий, используемых при сложной разработке.
| Метод | Фокус | Лучше всего подходит для |
|---|---|---|
| Вертикальная нарезка | Функциональность от начала до конца | Функции, требующие немедленной ценности |
| Горизонтальная нарезка | Технические уровни | Инфраструктура или общие компоненты |
| Сценарий-ориентированный | Рабочие процессы пользователей | Сложные процессы с вариациями |
| Ориентированный на данные | Объем и типы | Отчетность или пакетные операции |
| Ориентированный на интерфейс | Сложность интерфейса | Формы или панели мониторинга |
1. Вертикальная нарезка
Это наиболее распространенная и рекомендуемая стратегия доставки функций. Вертикальная нарезка означает прорезание всех технических уровней для предоставления конкретного функционального элемента от базы данных до пользовательского интерфейса.
- Как это работает: Сначала вы создаете небольшую, полностью функциональную функцию, а затем расширяете ее.
- Пример: Вместо того чтобы сначала строить всю схему базы данных, вы сначала создаете функцию «Сохранить пользователя», затем «Обновить пользователя», затем «Удалить пользователя».
- Преимущество: Каждая история приводит к созданию рабочего фрагмента программного обеспечения, который можно развернуть.
2. Горизонтальная нарезка
Горизонтальная нарезка предполагает построение одного уровня системы за раз для всех функций. Это часто используется для технической инфраструктуры.
- Как это работает: Вы строите слой базы данных, затем слой API, затем слой пользовательского интерфейса.
- Пример: Создание универсального механизма ведения журнала до его применения к конкретным функциям.
- Преимущество: Обеспечивает согласованность и повторное использование по всей системе.
- Осторожно: Это часто замедляет предоставление ценности пользователю. Используйте это только при необходимости для технической устойчивости.
3. Разделение по сценариям
Сложные функции часто имеют разные пути, которые может пройти пользователь. Разделение по сценариям разбивает функцию на конкретные случаи использования.
- Как это работает: Определите основной путь и исключительные пути.
- Пример: Функция оплаты может быть разделена на «Оплатить кредитной картой», «Оплатить через PayPal» и «Вернуть транзакцию».
- Основной путь: Успешная оплата.
- Исключительный путь: Оплата отклонена или истекло время ожидания.
4. Разделение, управляемое данными
Когда функция включает обработку различных объемов или типов данных, разделяйте по объему или сложности данных.
- Как это работает: Начните с простых данных, затем добавьте сложность.
- Пример: Функция импорта может начаться с «Импорт CSV», затем «Импорт Excel», затем «Импорт JSON». Альтернативно, разделите по объему: «Импорт 10 записей», затем «Импорт 10 000 записей».
5. Разделение, управляемое пользовательским интерфейсом
Если сложность заключается в интерфейсе, разделяйте по экранам или компонентам, участвующим в процессе.
- Как это работает: Разбейте интерфейс на логические разделы.
- Пример: Панель мониторинга может быть разделена на «Заголовок», «Боковая панель» и «Основная область диаграммы». Или: «Создать форму» против «Просмотр формы».
📝 Пример пошагового руководства: Оформление заказа в электронной коммерции
Чтобы проиллюстрировать эти стратегии, рассмотрим сложную функцию оформления заказа для интернет-магазина. Эпик — «Полный процесс оформления заказа». Это слишком много для одного спринта.
Шаг 1: Определите цель
Цель — позволить клиенту приобрести товары. Минимальная ценность — получение оплаты и подтверждение заказа.
Шаг 2: Примените вертикальное разделение
Вместо того чтобы строить логику доставки, налогов и оплаты отдельно, мы проводим вертикальное разделение.
- История 1:Я как покупатель хочу добавить товары в корзину, чтобы купить их позже.
- История 2:Я как покупатель хочу просмотреть содержимое своей корзины, чтобы проверить свой заказ.
- История 3:Я как покупатель хочу ввести свой адрес доставки, чтобы мой заказ прибыл.
- История 4:Я как покупатель хочу выбрать способ оплаты, чтобы оплатить безопасно.
- История 5:Я как покупатель хочу подтвердить свой заказ, чтобы получить чек.
Шаг 3: Уточнение с использованием разделения по сценариям
Внутри истории 4 (Оплата) есть сложности. Мы делим её дальше.
- Под-история А:Поддержка оплаты только кредитными картами.
- Под-история Б:Поддержка интеграции с PayPal.
- Под-история В:Грамотно обрабатывать ошибки отказа в оплате.
Шаг 4: Определите критерии приемки
Каждая история должна иметь четкие критерии, чтобы обеспечить её тестирование. Для истории 3 (Адрес доставки):
- Учитывая, что пользователь находится на странице оформления заказа
- Когда пользователь вводит действительный адрес
- Тогда система проверяет формат
- И пользователь может перейти к оплате
⚠️ Распространенные ошибки при разделении
Даже опытные команды допускают ошибки при разделении функций. Будьте внимательны к этим распространенным проблемам.
- Чрезмерное разделение:Разделение истории на мелкие фрагменты, которые занимают всего 2 часа. Это создает чрезмерную административную нагрузку.
- Недостаточное разделение:Истории, которые все еще занимают две недели. Это нарушает вместимость спринта.
- Техническое vs. Функциональное:Разделение по «Базе данных», «API» и «Фронтенду» часто скрывает ценность. Заинтересованные стороны хотят знать, что пользователь может сделать, а не только то, что обрабатывает сервер.
- Пренебрежение зависимостями:Создание истории, которую невозможно доставить, потому что она зависит от другой истории, еще не включенной в бэклог.
🤝 Сотрудничество и уточнение
Разделение — это совместная деятельность. Ее не следует выполнять в одиночку. Продуктовый владелец, разработчики и тестировщики должны все участвовать.
1. Роль владельца продукта
Владелец продукта определяет что и ценность. Они обеспечивают, что самая маленькая часть все еще приносит ценность. Они определяют приоритеты, какая часть наиболее важна для следующего релиза.
2. Роль команды разработчиков
Разработчики предоставляют оценки и оценивают техническую осуществимость. Они могут предложить разделить историю иначе, чтобы снизить технические риски или обеспечить параллельную работу.
3. Роль команды тестирования
Тестировщики обеспечивают, что разделенные истории можно протестировать. Они задают вопросы, например: «Можно ли автоматизировать тест для этой конкретной части?» или «Разделение позволяет ли нам безопасно выпустить в продакшн?»
📊 Управление зависимостями
При разделении часто возникают зависимости. Их необходимо тщательно управлять.
- Внутренние зависимости:История B требует, чтобы сначала была выполнена история A. Отметьте их в своем бэклоге.
- Внешние зависимости:Может потребоваться API сторонней компании. Это фактор риска.
- Разъединение:Где возможно, проектируйте систему так, чтобы истории не зависели друг от друга. Используйте флаги функций для скрытия незавершённой работы.
Таблица: Типы зависимостей
| Тип | Определение | Стратегия управления |
|---|---|---|
| Жёсткая зависимость | История B не может начаться без истории A | |
| Мягкая зависимость | История B проще, если история A выполнена | |
| Опциональная зависимость | История B работает лучше с историей A |
🔍 Измерение успеха
Как вы узнаете, работает ли ваша стратегия разделения? Посмотрите на эти метрики.
- Стабильность скорости:Если истории имеют правильный размер, скорость должна оставаться стабильной.
- Процент завершения:Вы завершаете истории в каждом спринте?
- Уровень дефектов:Вы находите меньше ошибок в продакшене? Меньшие истории проще протестировать.
- Удовлетворённость заинтересованных сторон:Удовлетворены ли заинтересованные стороны прогрессом, который они видят?
🔄 Итерации и улучшения
Разделение — это не разовая задача. По мере того как вы узнаёте больше о функции, вы можете обнаружить, что ваши первоначальные разделения были неверны. Будьте готовы перегруппироваться.
- Во время доработки:Если история всё ещё слишком большая, разделите её ещё раз. Не заставляйте её в спринт.
- Во время спринта: Если история слишком маленькая, объедините ее с другой. Не позволяйте работе оставаться незавершенной.
- После спринта: Оцените точность оценок. Соответствовал ли разрыв усилиям? Настройте будущие разрывы на основе этих данных.
🧠 Дополнительные соображения
Для очень сложных систем применяются дополнительные соображения.
1. Соответствие нормативным требованиям
Некоторые функции необходимо разделять для соблюдения законодательных требований. Например, защита персональных данных может потребовать специального журнала аудита до выпуска основной функции. Разделяйте на основе потребностей соответствия.
2. Пороги производительности
Если функция требует высокой производительности, разделите реализацию, чтобы включить тестирование производительности на ранних этапах. Не ждите конца, чтобы проверить скорость.
3. Доступность
Убедитесь, что каждый разрыв соответствует стандартам доступности. Не создавайте историю «Просмотр страницы», а затем добавляйте доступность в последующей истории «Исправление доступности». Включите это в первоначальный разрыв.
📝 Краткий чек-лист для разделения
Перед перемещением истории в активный бэклог пройдитесь по этому чек-листу.
- История сама по себе приносит ценность? ✅
- История может быть протестирована независимо? ✅
- История достаточно мала для спринта? ✅
- Есть ли четкие критерии приемки? ✅
- Зависимости минимальны или управляются? ✅
- История соответствует цели пользователя? ✅
Следуя этим стратегиям, команды могут превратить непреодолимые функции в поток управляемой работы. Результат — предсказуемый поток ценности, программное обеспечение высокого качества и команда, которая чувствует себя успешной в конце каждого спринта.
Помните, цель — не просто разделять истории, а понимать ценность, которую они приносят. Держите пользователя в центре каждого решения о разделении.