> Как оцениваются задачи в Agile (Python)

Короткий ответ

В Agile оценка задач - это коллективная экспертная оценка относительной сложности, а не точный прогноз времени. Основные методы: story points, planning poker, T-shirt sizing. Оценки нужны для планирования спринта и измерения velocity команды, а не для внешних KPI. Для backend-задач важно учитывать скрытую сложность: интеграции, миграции данных, инфраструктуру, тестирование и риски деградации производительности.

Подробное объяснение

Оценка в Agile решает три задачи: декомпозиция работы, приоритизация бэклога и прогнозирование delivery. Story points - это относительная мера сложности, объёма и неопределённости. Команда калибрует шкалу на исторических данных: если задача на 5 points заняла 3 дня, а на 8 - 5 дней, значит шкала работает.

Для backend-разработки оценка включает несколько измерений:

• Сложность реализации - алгоритмы, архитектурные изменения, рефакторинг.
• Объём работы - количество эндпоинтов, моделей, миграций.
• Неопределённость - неизвестные зависимости, отсутствие спецификаций, legacy-код.
• Риски - интеграции с внешними сервисами, нагрузочное тестирование, безопасность.

Planning poker снижает эффект якорения: каждый участник независимо оценивает, затем обсуждаются расхождения. Если backend-разработчик оценивает в 5, а тестировщик в 13 - это сигнал о скрытых рисках, которые нужно вскрыть до спринта.

Важный принцип: оценка не является обязательством. Это прогноз с доверительным интервалом. Для backend-задач часто используют Fibonacci-шкалу (1, 2, 3, 5, 8, 13), потому что точность падает с ростом сложности.

На практике

В backend-команде оценка начинается с декомпозиции user story до технических задач. Например, "добавить endpoint для экспорта отчётов" разбивается на: модель данных, генерация CSV, фоновая обработка, кэширование, API-контракт, тесты.

На практике используют velocity - среднее количество story points за спринт. Если команда закрывает 30 points за две недели, то новый спринт планируется на 25-30 points с учётом отпусков и support-задач.

Для backend важно учитывать non-functional requirements: если задача затрагивает горячий путь запроса, добавляются points на профилирование и оптимизацию. Если нужна миграция данных - это отдельная задача с собственными рисками.

Оценки пересматриваются после спринта: если задача оценена в 8, а заняла 2 дня, значит шкала сбита или задача была переоценена. Команда корректирует калибровку, а не наказывает разработчика.

Пример кода

Оценка не связана с кодом напрямую, но можно показать, как техническая сложность влияет на оценку:

PYTHON
# Задача на 2 points - простой CRUD endpoint
@app.get("/users/{user_id}")
def get_user(user_id: int):
    return db.query(User).filter(User.id == user_id).first()

# Задача на 8 points - тот же endpoint, но с пагинацией,
# фильтрацией, кэшированием и обработкой ошибок
@app.get("/users")
def list_users(
    page: int = 1,
    per_page: int = 20,
    role: str | None = None,
    cache: Cache = Depends(get_cache)
):
    cache_key = f"users:{page}:{per_page}:{role}"
    if cached := cache.get(cache_key):
        return cached
    
    query = db.query(User)
    if role:
        query = query.filter(User.role == role)
    
    users = query.offset((page - 1) * per_page).limit(per_page).all()
    result = {"items": users, "total": query.count()}
    cache.set(cache_key, result, ttl=60)
    return result

Разница в оценке объясняется не объёмом кода, а количеством решений: кэширование требует инвалидации, пагинация - тестов на граничные случаи, фильтрация - индексов в БД.

Как отвечать на собеседовании

Начните с главного: оценка - это относительная мера сложности, а не время. Затем перечислите методы и объясните, почему для backend важна декомпозиция. Приведите пример из практики: как вы оценивали задачу с миграцией данных и почему она оказалась дороже, чем казалась.

Подчеркните, что вы учитываете скрытые затраты: тестирование, документацию, code review, деплой. Упомяните, что velocity - это инструмент планирования, а не метрика эффективности разработчика.

Если спросят про конкретные числа - скажите, что шкала калибруется на истории команды, и приведите пример: "задача на 5 points у нас обычно занимает 2-3 дня, но если она затрагивает legacy-модуль, я добавляю 2 points на риски".

Что проверяет интервьюер

Интервьюер оценивает:

• Понимаете ли вы разницу между оценкой и обязательством.
• Умеете ли декомпозировать backend-задачи на технические составляющие.
• Знаете ли вы, как работать с неопределённостью и рисками.
• Понимаете ли роль velocity и как она связана с планированием.
• Умеете ли аргументировать свою оценку и слушать аргументы других.

Для senior-позиции важно показать, что вы не просто называете числа, а видите систему: как оценка влияет на бэклог, приоритизацию и ожидания стейкхолдеров.

Типичные ошибки

• Оценка в часах вместо story points - возврат к waterfall-мышлению.
• Оценка в одиночку без обсуждения с командой - теряются скрытые риски.
• Учёт только времени на написание кода, без тестов, ревью и деплоя.
• Использование velocity как KPI для давления на команду.
• Непересмотр калибровки шкалы после нескольких спринтов.
• Оценка задач, которые не декомпозированы - невозможно дать адекватную оценку.
• Игнорирование non-functional requirements: производительность, безопасность, observability.