5 ошибок декомпозиции User Story и как их избежать

В блоге Майка Кона, наткнулась на полезную статью о декомпозиции историй и решила пересказать основные идеи. Вот как видит автор пять самых распространённых ошибок и способы их исправить. Если тема актуальна, то стоит заглянуть и в оригинал.

Ошибка №1: Разделение историй — задача только Product Owner’а
🚨PO без технического бэкграунда может разделить историю так, что:
• Из нескольких подзадач, 99% работы окажется в одной подзадаче.
• Появятся зависимости между подзадачами, мешающие завершению любой из них в рамках одной итерации.
⚙️Решение:
• Разделение историй — командная работа. PO + команда. Это не означает, что вся команда должна делить каждую историю в полном составе, но деление истории не должно производиться только одним или парой человек для каждой истории. PO и несколько представителей команды делят сначала одну или несколько историй, затем PO и несколько других участников делят следующую и т.д.
• Обсуждение на Daily Scrum. Например, на Daily Scrum PO объявляет: «Нужно разбить 3 истории в следующие пару дней для подготовки к следующему спринту». Несколько человек из команды выражают готовность помочь и определяются с подходящим временем.

Ошибка №2: Разделение по техническим границам
🚨Истории делятся не по функциональным, а по техническим границам, т.е. только с точки зрения команды, а не пользователя или стейкхолдера. Истории типа:
• «Как пользователь, я хочу бэкенд который делает X».
• «Как пользователь, я хочу фронтенд который делает тот же Х».
Таким образом получаются истории, не имеющие для пользователя никакой ценности сами по себе. (Фронтэнд, например, веб-интерфейс, не несет пользы без бэкэнда и\или базы данных)
⚙️Решение:
• Делите по «путям» через историю.
• По путям с точки зрения команды: обычно есть путь, определяющий что происходит, когда все идет правильно, и пути для возможных ошибок.
• По путям с точки зрения пользователя: например, при заказе товаров из корзины пользователь может выбрать варианты доставки. В первой версии можно предположить, что все пользователи получают только один из вариантов, а остальные добавить позднее. Это упростит интерфейс и потребует меньше тестирования.

Ошибка №3: Указание решения истории в самой истории
🚨В самой истории описано как решать эту историю (Если нужно повесить картину на стену, сразу прописывается какой крепеж использовать, вместо простого «Нужно повесить картину на стену»).
⚙️Решение:
• Фокусируйтесь на «что», а не «как».
• Если команда включает в истории слишком много конкретики, то возможно вы делите истории на слишком маленькие под-истории.

Ошибка №4: Спайки для каждой истории
🚨Команды создают спайки (исследовательские задачи) даже для простых историй, чтобы «убрать все риски».
Решение:
• Спайки нужны только при высокой неопределённости. Некоторая неопределенность присуща каждой истории, и спайки должны быть использованы лишь в особых случаях с действительно высокой неопределенностью.

Ошибка №5: сразу внедрять все бизнес-правила
🚨Команда пытается реализовать все правила сразу, даже если это значительно усложняет разработку.
Пример, мобильное приложение для банка:
• Правило: «Не выдавать кредиты общей суммой > $10 млн».
• Вместо полной проверки в первой версии можно:
1. Сделать базовую заявку без проверки существующих кредитов.
2. Добавить проверку в последующих итерациях.
⚙️Решение:
• Постепенное усложнение. Сначала разрабатывается более простой вариант, потом внедряются бизнес-правила, если это упрощает работу.
• Важно: Не выпускать в эксплуатацию версию без критичных правил!

Моя "любимая ошибка" здесь под номером 3 🌱

#инструменты #agile