В блоге Майка Кона, наткнулась на полезную статью о декомпозиции историй и решила пересказать основные идеи. Вот как видит автор пять самых распространённых ошибок и способы их исправить. Если тема актуальна, то стоит заглянуть и в оригинал.
Ошибка №1: Разделение историй — задача только Product Owner’а
🚨PO без технического бэкграунда может разделить историю так, что:
- Из нескольких подзадач, 99% работы окажется в одной подзадаче.
- Появятся зависимости между подзадачами, мешающие завершению любой из них в рамках одной итерации.
⚙️Решение:
- Разделение историй — командная работа. PO + команда. Это не означает, что вся команда должна делить каждую историю в полном составе, но деление истории не должно производиться только одним или парой человек для каждой истории. PO и несколько представителей команды делят сначала одну или несколько историй, затем PO и несколько других участников делят следующую и т.д.
- Обсуждение на Daily Scrum. Например, на Daily Scrum PO объявляет: «Нужно разбить 3 истории в следующие пару дней для подготовки к следующему спринту». Несколько человек из команды выражают готовность помочь и определяются с подходящим временем.
Ошибка №2: Разделение по техническим границам
🚨Истории делятся не по функциональным, а по техническим границам, т.е. только с точки зрения команды, а не пользователя или стейкхолдера. Истории типа:
- «Как пользователь, я хочу бэкенд который делает X».
- «Как пользователь, я хочу фронтенд который делает тот же Х».
Таким образом получаются истории, не имеющие для пользователя никакой ценности сами по себе. (Фронтэнд, например, веб-интерфейс, не несет пользы без бэкэнда и\или базы данных)
⚙️Решение:
• Делите по «путям» через историю.
• По путям с точки зрения команды: обычно есть путь, определяющий что происходит, когда все идет правильно, и пути для возможных ошибок.
• По путям с точки зрения пользователя: например, при заказе товаров из корзины пользователь может выбрать варианты доставки. В первой версии можно предположить, что все пользователи получают только один из вариантов, а остальные добавить позднее. Это упростит интерфейс и потребует меньше тестирования.
Ошибка №3: Указание решения истории в самой истории
🚨В самой истории описано как решать эту историю (Если нужно повесить картину на стену, сразу прописывается какой крепеж использовать, вместо простого «Нужно повесить картину на стену»).
⚙️Решение:
- Фокусируйтесь на «что», а не «как».
- Если команда включает в истории слишком много конкретики, то возможно вы делите истории на слишком маленькие под-истории.
Ошибка №4: Спайки для каждой истории
🚨Команды создают спайки (исследовательские задачи) даже для простых историй, чтобы «убрать все риски».
⚙️Решение: Спайки нужны только при высокой неопределённости. Некоторая неопределенность присуща каждой истории, и спайки должны быть использованы лишь в особых случаях с действительно высокой неопределенностью.
Ошибка №5: сразу внедрять все бизнес-правила
🚨Команда пытается реализовать все правила сразу, даже если это значительно усложняет разработку.
Пример, мобильное приложение для банка. Правило: «Не выдавать кредиты общей суммой > $10 млн».
Вместо полной проверки в первой версии можно:
- Сделать базовую заявку без проверки существующих кредитов.
- Добавить проверку в последующих итерациях.
⚙️Решение:
- Постепенное усложнение. Сначала разрабатывается более простой вариант, потом внедряются бизнес-правила, если это упрощает работу.
- Важно: Не выпускать в эксплуатацию версию без критичных правил!
Моя "любимая ошибка" здесь под номером 3 🌱
