Декомпозиция задач

Декомпозиция задач — разбивка большой, сложной или неопределённой задачи на маленькие, конкретные и выполнимые подзадачи, которые можно оценить и реализовать независимо.

Зачем нужно

Крупные задачи ("сделать авторизацию", "переписать компонент") парализуют: непонятно с чего начать, сложно оценить время, легко потеряться. Декомпозиция превращает слона в котлету: каждый шаг понятен, прогресс виден, оценки реалистичны. Это базовый навык, отделяющий Junior от Middle.

Где используется

Sprint Planning — декомпозиция User Stories в задачи
Личное планирование — разбивка учебных проектов
Оценка сроков — только после декомпозиции оценка реалистична
Code Review — маленький PR = маленькая задача

Методы декомпозиции

Метод "вертикальных срезов"

Плохо — горизонтальные слои (всё сразу):
  1. Весь backend
  2. Весь frontend
  3. Вся БД

Хорошо — вертикальные срезы (фича за фичей):
  1. Простейший вход (email + пароль, без UI)
  2. Базовый UI формы входа
  3. Валидация + сообщения об ошибках
  4. Сессия (помнит пользователя)
  5. Выход из аккаунта
  6. Регистрация нового пользователя

Шаги декомпозиции

Задача: "Добавить страницу профиля пользователя"

Шаг 1 — Вопросы:
  Что показывает страница? (имя, фото, email, посты?)
  Можно редактировать? Нужна авторизация?
  Откуда данные? API готов?

Шаг 2 — Составить список подзадач:
  -  Создать маршрут /profile/:id в роутере
  -  Описать тип ProfileData в TypeScript
  -  Написать хук useProfile(id) с запросом к API
  -  Создать компонент ProfileHeader (аватар, имя)
  -  Создать компонент ProfileStats (посты, подписчики)
  -  Обработать состояния: loading, error, not found
  -  Добавить ссылку "Профиль" в навигацию
  -  Написать тесты для хука useProfile

Шаг 3 — Оценить каждую подзадачу (SP или часы)
Шаг 4 — Определить зависимости (что от чего зависит)
Шаг 5 — Взять первую независимую задачу → выполнить

Правило MECE

Mutually Exclusive, Collectively Exhaustive:
- Подзадачи не пересекаются (Mutually Exclusive)
- Подзадачи покрывают всю задачу (Collectively Exhaustive)

Плохо:
  - Работа с формой
  - Работа с данными
  (пересекаются, неполные)

Хорошо:
  - UI компоненты формы (только вёрстка)
  - Логика валидации формы
  - API-интеграция (отправка, обработка ответа)
  - Состояние формы (loading, success, error)

Индикаторы плохой декомпозиции

✗ Задача занимает больше 2 дней → декомпозируй
✗ Задача "сделать всё" — непонятно когда готова
✗ Задачи сильно зависят друг от друга → параллельная работа невозможна
✗ Нельзя отдать задачу другому без объяснений на час

Частые ошибки

Ошибка	Проблема	Решение
Декомпозировать только первый уровень	Задачи всё ещё слишком большие	Декомпозировать до 4–8 часов максимум
Пропускать edge cases	Они всплывают в конце спринта	Явно добавить: "Обработать ошибки API"
Не учитывать тесты	Тесты "за кадром", не входят в оценку	Каждая задача включает написание тестов
Декомпозировать без понимания ТЗ	Делаешь не то	Сначала вопросы, потом декомпозиция