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

Различия между Epic и User Story

Epic и User Story — это иерархические единицы работы в Agile. Эпик — это большой фрагмент функционала, который разбивается на несколько User Stories для реализации. Разберу подробно:

1. Epic (Эпик)

Определение: Большой, стратегический фрагмент функционала, который нельзя выполнить за один спринт. Обычно охватывает несколько недель или месяцев работы.

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

• Огромный масштаб (не оценивается в story points)
• Соответствует стратегическому направлению продукта
• Требует разбиения на несколько User Stories
• Может охватывать работу нескольких teams
• Может быть растянут на несколько спринтов
• В JIRA обычно помечается как Epic

Примеры эпиков:

• "Интеграция платежных систем"
• "Миграция на микросервисы"
• "Новая система рекомендаций контента"
• "Реализация двухфакторной аутентификации"
• "Переделка личного кабинета"

Структура эпика:

Nазвание: Интеграция платежных систем

Описание: Добавить поддержку Stripe, PayPal и Yandex.Kassa
для упрощения способов оплаты для пользователей

Зачем: Увеличить conversion rate и среднюю сумму заказа

Диапазон работ: Q1-Q2 2026

Teams: Backend (2 инженера), Frontend (1), DevOps (1)

2. User Story (История)

Определение: Небольшой, конкретный фрагмент функционала, который можно реализовать за 1-2 спринта. Формат: "Как [роль], я хочу [действие], чтобы [выгода]".

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

• Малый масштаб (оценивается в story points: 1-8 обычно)
• Выполняется за 1-2 спринта
• Вызывает конкретную ценность для пользователя
• Выполняется одним инженером или парой
• Легко тестируется
• Имеет четкие критерии приемки (Acceptance Criteria)

Примеры историй (вложены в эпик "Интеграция платежей"):

• "Как клиент, я хочу платить через Stripe, чтобы использовать свою кредитку"
• "Как администратор, я хочу видеть статус платежей в личном кабинете"
• "Как разработчик, я хочу документацию по API платежей, чтобы интегрировать их"

Структура User Story:

Название: Интеграция Stripe - базовая функциональность

Как клиент
Я хочу платить через Stripe
Чтобы использовать мою кредитку без дополнительных сервисов

Acceptance Criteria:
- Форма оплаты отображает Stripe как вариант
- После ввода реквизитов платеж обрабатывается за 1-2 сек
- При успехе пользователь видит подтверждение
- При ошибке показывается понятное сообщение
- Платежи записываются в БД с тремя статусами:
  (pending, completed, failed)

Story Points: 5 (может быть сделано за 1 спринт)

3. Иерархия: Как все это связано

┌──────────────────────────────────────────────┐
│ EPIC: Интеграция платежных систем (Q1-Q2)  │
├──────────────────────────────────────────────┤
│                                              │
│ ┌─────────────────────────────────────────┐ │
│ │ Story 1: Stripe базовая интеграция (5) │ │
│ │ Acceptance Criteria: ... (Done)         │ │
│ └─────────────────────────────────────────┘ │
│                                              │
│ ┌─────────────────────────────────────────┐ │
│ │ Story 2: Stripe вебхуки и IPN (8)       │ │
│ │ Acceptance Criteria: ... (In Progress)  │ │
│ └─────────────────────────────────────────┘ │
│                                              │
│ ┌─────────────────────────────────────────┐ │
│ │ Story 3: PayPal интеграция (5)          │ │
│ │ Acceptance Criteria: ... (To Do)        │ │
│ └─────────────────────────────────────────┘ │
│                                              │
│ ┌─────────────────────────────────────────┐ │
│ │ Story 4: Dashboard с статистикой (8)    │ │
│ │ Acceptance Criteria: ... (To Do)        │ │
│ └─────────────────────────────────────────┘ │
│                                              │
└──────────────────────────────────────────────┘

4. Сравнительная таблица

5. Практический workflow

Планирование:

1. PM/PO видит стратегическую потребность → создает Epic
2. Epic уточняется на refinement встречах
3. Epic разбивается на User Stories (от 3 до 20)
4. Stories приоритизируются и планируются в спринты
5. Team вытягивает Stories на спринт planning
6. Инженер берет Story и реализует
7. QA тестирует по Acceptance Criteria
8. После завершения Stories → Demo → Feedback
9. Когда все Stories готовы → Epic закрывается

Пример планирования:

Epic: "Новый рекомендательный движок" (3 месяца)
├─ Sprint 1: Stories про API ML модели
├─ Sprint 2: Stories про хранение данных
├─ Sprint 3: Stories про UI и персонализацию
└─ Sprint 4: Stories про аналитику и оптимизацию

6. Зачем нужна такая структура

Epic помогает:

• Видеть стратегическое направление
• Коммуницировать с stakeholders
• Планировать ресурсы на квартал
• Отслеживать прогресс по большим инициативам

User Story помогает:

• Конкретизировать работу для инженера
• Оценить сложность (story points)
• Сделать работу выполнимой за спринт
• Четко определить "done"
• Делать регулярные demo

Вывод

Epic — это стратегическое видение, User Story — это тактическая реализация. Хороший PM разбивает стратегию (Epic) на конкретные, выполнимые задачи (Stories), которые инженеры могут реализовать, получить feedback и итерировать. Оба инструмента критичны для Agile разработки.