В чем разница между epic и story?

Epic vs Story: иерархия в управлении проектом

Эпики и истории — это элементы агайл-методологии, которые используются для разбиения работы на управляемые части. Они находятся на разных уровнях иерархии: epic это большой контейнер, а story это конкретная работа.

Аналогия: Epic как главное здание, а Stories как отдельные комнаты внутри здания.

EPIC — большая инициатива

Определение

Epic — это большая функция, инициатива или возможность, которая слишком обширна для одного спринта. Это стратегический элемент, который разбивается на несколько stories.

Характеристики Epic

✓ Объем: Очень большой, обычно работа на несколько месяцев ✓ Время: Может занять 3-6 спринтов (или даже больше) ✓ Зависимые: Один epic обычно состоит из 10-50 stories ✓ Уровень детализации: Высокий уровень абстракции (не очень детально) ✓ Владелец: Product Manager или Product Owner ✓ Статус: PLANNING → IN PROGRESS → DONE ✓ Цель: Описать БЕЗ ДЕТАЛЕЙ стратегическую цель

Примеры Epic

E-commerce:

• "Реализовать систему подписок"
• "Внедрить рекомендации товаров (AI)"
• "Переделать мобильное приложение на React Native"
• "Интегрировать с системой доставки"

SaaS приложение:

• "Добавить поддержку команд (teams) в систему"
• "Реализовать интеграцию с Slack и Teams"
• "Добавить аналитику и отчеты"
• "Реализовать синхронизацию данных в офлайн"

Банковское приложение:

• "Реализовать функцию переводов деньги"
• "Добавить возможность инвестиций"
• "Внедрить биометрическую аутентификацию"

Описание Epic

Обычно описание простое и недетальное:

ЕPIC: Система подписок

Описание:
Добавить в приложение возможность оформлять подписки
и платить по повторяющемуся расписанию (ежедневно,
еженедельно, ежемесячно).

Цель бизнеса:
Увеличить recurring revenue на 30% за счет подписок.

Ожидаемый результат:
Пользователи смогут выбрать тариф подписки и платить
автоматически каждый месяц.

STORY — конкретная единица работы

Определение

Story (User Story) — это конкретная, небольшая единица работы, которая может быть завершена в одном спринте (обычно за 2-5 дней). Это описание одного concrete requirements с точки зрения пользователя.

Характеристики Story

✓ Объем: Маленький, на 1-3 дня работы разработчика ✓ Время: Может быть завершена в одном спринте ✓ Зависимая: Одна story — это один feature ✓ Уровень детализации: Очень детальный (точные requirement'ы) ✓ Владелец: Business Analyst, Product Owner ✓ Статус: BACKLOG → IN PROGRESS → IN REVIEW → DONE ✓ Формат: Обычно написана в формате User Story

Стандартный формат User Story

As a [роль]
I want [действие]
So that [причина/бизнес-ценность]

Acceptance Criteria:
- Критерий 1
- Критерий 2
- Критерий 3

Примеры Story

Story 1 из Epic "Система подписок":

As a Customer
I want to see available subscription plans
So that I can choose the one that fits my needs

Acceptance Criteria:
- Отображается список из 3 планов (Basic, Pro, Premium)
- Каждый план показывает: цену, количество features, период биллинга
- Пользователь может прочитать описание каждого плана
- Кнопка "Subscribe" видна для каждого плана

Story 2 из Epic "Система подписок":

As a Customer
I want to select a subscription plan and enter payment details
So that I can subscribe to a plan

Acceptance Criteria:
- После клика на "Subscribe" открывается форма
- Форма требует: имя, email, способ оплаты
- Система валидирует данные перед отправкой
- При успехе показывается "Спасибо за подписку"
- При ошибке показывается детальное сообщение об ошибке

Story 3 из Epic "Система подписок":

As a Billing System
I want to automatically charge customers every month
So that we have recurring revenue

Acceptance Criteria:
- Система запускает крон-джоб каждый месяц
- Для каждой active подписки проверяется дата биллинга
- Если дата наступила, отправляется платеж через PaymentGateway
- Если платеж успешен, обновляется дата следующего платежа
- Если платеж失败, отправляется email пользователю с просьбой обновить карту

Таблица различий

Иерархия в проекте

ROADMAP (Стратегия)
        ↓
    EPIC 1: "Система подписок"
    │
    ├─→ Story 1.1: "Показать планы подписок"
    ├─→ Story 1.2: "Оформить подписку"
    ├─→ Story 1.3: "Автоматический биллинг"
    ├─→ Story 1.4: "Управление подписками в профиле"
    └─→ Story 1.5: "Отправлять напоминание перед биллингом"
    
    EPIC 2: "Реферальная программа"
    │
    ├─→ Story 2.1: "Генерировать реферальный код"
    ├─→ Story 2.2: "Показывать бонус за реферала"
    └─→ Story 2.3: "Отслеживать рефереров"

Практический пример: E-commerce

EPIC: "Добавить интеграцию с маркетплейсами"

Это большая инициатива, которая займет 4-5 месяцев разработки.

Этот epic разбивается на stories:

1. Story: "Синхронизировать товары с Яндекс.Маркет"

   • Acceptance: Товары из нашей БД передаются в Яндекс каждый день
   • Время: 5 дней

2. Story: "Получать заказы с Яндекс.Маркет"

   • Acceptance: Заказы автоматически создаются в нашей системе
   • Время: 4 дня

3. Story: "Синхронизировать товары с Ozon"

   • Acceptance: Товары передаются в Ozon по API
   • Время: 4 дня

4. Story: "Управлять ценами на всех маркетплейсах из админки"

   • Acceptance: BA может изменить цену в одном месте, и она обновится везде
   • Время: 3 дня

5. Story: "Отчет о продажах на маркетплейсах"

   • Acceptance: Админ видит дашборд с продажами по каждому маркетплейсу
   • Время: 3 дня

Когда использовать

Используй EPIC для

✓ Стратегического планирования (roadmap) ✓ Долгосрочных инициатив (6+ месяцев) ✓ Коммуникации с заказчиком на высоком уровне ✓ Планирования ресурсов (сколько людей нужно) ✓ Приоритизации крупных функций

Используй STORY для

✓ Планирования спринтов ✓ Детальной работы с требованиями ✓ Тестирования ✓ Code review ✓ Ежедневного управления работой

Вывод

✓ EPIC — это стратегический взгляд, "что мы хотим сделать?" ✓ STORY — это тактический взгляд, "как мы это сделаем, конкретно?" ✓ Один epic разбивается на несколько stories ✓ Каждая story может быть завершена за один спринт ✓ Stories имеют критерии приемки, epics — нет ✓ Вместе они создают полную картину проекта: от стратегии до реализации