Точная оценка — одна из ключевых частей планирования в Agile. Она помогает командам прогнозировать сроки, заранее выявлять риски и управлять ожиданиями стейкхолдеров. В Agile цель оценки — не предсказать точное количество часов, а понять сложность, неопределённость и объём работ.

Существует несколько популярных техник оценки. Ниже я опишу наиболее распространённые: T-Shirt оценка, Story Points, и оценка в часах, а также объясню, что должно входить в полноценную оценку как со стороны разработки, так и со стороны тестирования.

1. Оценка в T-Shirt размерах

T-Shirt оценка — это высокоуровневый, быстрый и приблизительный способ оценки. Он особенно полезен на ранних этапах (discovery, первичный рефайнмент, планирование дорожной карты), когда подробное разбиение задач ещё невозможно.

Как это работает
Задачи классифицируются по «размерам»:

• XS – очень маленькая
• S – маленькая
• M – средняя
• L – большая
• XL – очень большая
• XXL – слишком большая → требует разделения

Этот подход оценивает относительный размер, а не точные трудозатраты.

Примеры
User Story:
«Как пользователь, я хочу изменить язык приложения, чтобы пользоваться им на своём языке».
T-Shirt оценка: S
Почему:

• кнопка выбора языка уже есть
• нужно просто обновить текст/переводы
• тестирование простое (проверить перевод экранов)

Минимальная сложность – поэтому S.

Другой пример:
User Story:
«Как пользователь, я хочу видеть историю своих последних 5 операций на главном экране».
T-Shirt оценка: M
Почему:

• нужно добавить новый блок на главную страницу
• backend должен передавать список операций
• тестирование включает проверку сортировки, отображения, пустого списка

Сложнее, чем обычная правка текста, но не суперсложно — M.

User Story:
«Как пользователь, я хочу загружать фотографию профиля».
T-Shirt оценка: L
Почему:

• нужна кнопка загрузки
• backend должен хранить файл
• проверка размера картинки, формата
• тестируем ошибки: слишком большой файл, неподдерживаемый формат
• проверка отображения на разных экранах

Много шагов, интеграций и тестов — L.

User Story:
«Как пользователь, я хочу иметь личный кабинет с графиками, настройками, подписками и уведомлениями».
T-Shirt оценка: XXL (слишком большой)
Почему:

• много разных функций в одной истории
• разные экраны
• разная логика
• много тестирования

Такую историю нужно разбивать на маленькие.

Позже T-Shirt размеры могут быть конвертированы в Story Points.

2. Оценка в Story Points

Story Points отражают усилие + сложность + неопределённость.

Команды часто используют последовательность Фибоначчи:
1, 2, 3, 5, 8, 13, 21 …

Что отражают Story Points

• Сложность — насколько трудна задача
• Объём усилий — сколько работы нужно выполнить
• Неопределённость — риски, нечёткие требования

Почему Story Points удобны

• команда формирует предсказуемую производительность (velocity)
• SP избегают иллюзии точности
• разработка и QA оценивают задачу совместно

Примеры
User Story:
«Как пользователь, я хочу изменить своё имя в профиле, чтобы обновить личную информацию».
Почему это просто:

• UI уже есть, нужно только добавить поле.
• Проверить пару простых валидаций (не пустое, не слишком длинное).
• Проверить, что имя обновляется в профиле.

Оценка: 2 SP
Минимальный риск, минимальная сложность.

User Story:
«Как пользователь, я хочу видеть сообщение об ошибке, если ввожу неправильный пароль при входе».
Разбиение:

• Проверить, что сообщение выводится.
• Проверить корректность текста.
• Проверить, что оно исчезает при вводе нового пароля.
• Проверить лог с backend (опционально).

Оценка: 3 SP
Немного больше тест-кейсов, но всё ещё очень просто.

User Story:
«Как пользователь, я хочу иметь возможность удалять товары из корзины».
Разбиение:

• Проверить кнопку «Удалить».
• Проверить обновление суммы заказа.
• Проверить, что товар действительно пропал после обновления страницы.
• Проверить удаление нескольких товаров подряд.
• Легкая API проверка (GET/DELETE запросы).

Оценка: 5 SP
Нужно больше проверок, есть логика, есть риск найти баги.

User Story:
«Как пользователь, я хочу оплачивать заказ картой».
Почему это сложно:

• Работа с платёжным сервисом.
• Много негативных сценариев (недостаточно средств, неверная карта, отказ банка).
• Redirect на сторонний сайт.
• SQL проверки (опционально).
• Большая регрессия после внедрения.

Оценка: 13 SP
Высокий риск, много интеграций, много тестов.

3. Алгоритм перевода T-Shirt размеров в Story Points

1. Определяем T-Shirt размер
Сначала команда оценивает задачу на раннем этапе (Product Discovery, Refinement) с помощью T-Shirt Sizes.
На этом этапе оценивается относительная сложность, а не точное время.

2. Определяем базовую шкалу Story Points
Идея в том, что чем больше задача, тем больше неопределённости, поэтому больше оценка.

3. Назначаем Story Points каждому T-Shirt размеру

Пример типовой таблицы перевода:

4. Корректируем SP с учётом факторов
После первоначального перевода учитываем:

• QA effort: ручное тестирование, API, UI, регрессия
• Риски: неопределённые требования, зависимости от других команд
• Разработка: backend, frontend, интеграции
• Дополнительно: нестандартные задачи (например, миграции данных, performance тесты)

Например, M задача с необычным API может быть оценена 8 SP вместо 5 SP.

5. Итоговая Story Points оценка

• Команда обсуждает и согласует SP на Planning/Refinement
• Это становится официальной оценкой истории для спринта

✅ Пример перевода:
User Story: «Как пользователь, я хочу видеть историю своих последних 5 операций на главном экране».

• T-Shirt Size: M → Story Points: 5 SP

Причины:

• Средняя задача: требуется backend (получение истории операций), frontend (отображение на главном экране), тестирование UI и проверка данных.
• Нет высокой неопределённости или сложных интеграций, поэтому 5 SP подходит.

User Story: «Как пользователь, я хочу изменить язык приложения, чтобы пользоваться им на своём языке».

• T-Shirt Size: S → Story Points: 2-3 SP

Причины:

• Нужно изменить текстовые ресурсы / локализацию.
• Возможно немного работы на фронтенде для переключателя языка.
• Тестирование: проверить переключение языка, корректное отображение текста.

4. Оценка в часах

Иногда команды конвертируют оценки в часы — особенно в корпоративных проектах, регулируемых индустриях или для отчётности перед внешними командами.

Используется:

• при Sprint Planning
• при согласовании сроков с другими командами
• при работе с подрядчиками или аудиторами

Пример
Story: «Реализовать двухфакторную аутентификацию (2FA)».

• Разработка: 12 часов
• QA-тестирование: 6 часов
• Регрессия: 4 часа
• Документация: 1 час

Итого: 23 часа

Такой подход более детализирован, но подходит для команд, работающих под требованиями compliance.

5. Что должно входить в оценку

Независимо от того, SP это или часы, оценка должна учитывать все типы работ.

✔ Разработка

• имплементация
• рефакторинг
• unit-тесты
• интеграции
• код-ревью
• исправление багов

✔ QA

• написание тест-кейсов
• подготовка тестовых данных
• функциональное тестирование
• API-тестирование
• UI-тестирование (разные браузеры/устройства)
• регрессия
• проверки локализации
• анализ логов
• автоматизация тестов
• запуск пайплайнов
• баг-репорты и ретест

Многие команды недооценивают QA-вклад, что приводит к срывам и падению качества.


✔ Дополнительно. Риски

• неясные требования
• зависимость от других команд
• работа с третьими системами
• крупный рефакторинг
• изменения в архитектуре

Риски увеличивают Story Points, так как добавляют неопределённость.

2. Нефункциональная работа

• производительность
• нагрузка
• безопасность
• доступность (accessibility)

3. Митинги и взаимодействие

• grooming
• refinement
• согласования с другими командами
• сессии дизайна

Эти активности тоже требуют времени.

6. Пример полной оценки

Story:
«Как пользователь, я хочу подписаться на рассылку и получить подтверждающее письмо».

Разработка

• backend endpoint: 5ч
• изменения в БД: 3ч
• UI: 4ч
• unit-тесты: 2ч
• code review + фиксы: 2ч

Итого Dev: 16 часов

QA

• тест-кейсы: 2ч
• функциональные тесты: 3ч
• проверка писем: 1ч
• кросс-браузерные проверки: 2ч
• API тесты: 2ч
• регрессия: 2ч

Итого QA: 12 часов

Общий итог: 28 часов или 8 Story Points.