Оценка задач в IT: как считать стори поинты и идеальные часы без ошибок

Знаете это чувство? Вы уверенно говорите менеджеру: «Эту задачу я сделаю за два дня». А через неделю вы всё ещё копаетесь в коде, потому что выяснилось, что API работает не так, как в документации, а тестировщик ушёл на больничный. Оценка задач - это не магия хрустального шара, а навык управления рисками. В IT-среде часто спорят, что лучше: story points или идеальные часы. На самом деле, оба метода работают, если понимать их природу. Сегодня разберёмся, как перестать занижать сроки и начать планировать спринты так, чтобы команда не выгорала.

Почему время - плохой метрика для разработки

Давайте честно: ни один разработчик не может точно сказать, сколько времени займёт создание нового модуля аутентификации. Почему? Потому что мы оцениваем сложность, а не длительность. Если вы скажете «5 часов», вы имеете в виду чистое время работы над кодом. Но в реальности эти 5 часов растянутся на два рабочих дня из-за совещаний, перекусов, ожидания ответа от бэкенда и багов, которые всплывают только при деплое.

Ideal Hours (идеальные часы) - это гипотетическое время, которое потребовалось бы эксперту, работающему в вакууме, без прерываний, с идеальным интернетом и полной документацией под рукой. Это абстракция. Реальная жизнь вносит свои коррективы. Именно поэтому Agile-команды массово переходят на относительные оценки. Суть проста: нам не важно, сколько минут вы будете писать этот код. Важно, насколько эта задача сложнее других задач в вашем бэклоге.

Что такое Story Points и как они работают

Если story points (очки истории) звучат как абстрактная ерунда, представьте себе шкалу сложности видеоигр. Задача уровня «убить первого врага» - это 1 очко. Задача «пройти финального босса без смертей» - это 8 очков. Мы сравниваем задачи между собой, а не привязываем их к секундомеру.

Для оценки чаще всего используют последовательность Фибоначчи: 1, 2, 3, 5, 8, 13, 21. Почему именно она? Потому что чем больше задача, тем выше неопределённость. Разница между задачей на 1 час и на 2 часа очевидна. А вот разница между задачей на 10 часов и на 11 часов уже несущественна для планирования. Последовательность Фибоначчи искусственно создаёт «разрывы», заставляя команду думать крупными мазками, если задача становится слишком большой.

Как правильно проводить Planning Poker

Самый популярный инструмент для присвоения очков - это Planning Poker. Звучит азартно, но процесс серьёзный. Каждый участник получает колоду карт с числами Фибоначчи. Тимлид читает описание задачи, и все одновременно показывают карту со своей оценкой.

Главная фишка здесь - расхождения. Если один разработчик показал «3», а другой «13», дискуссия неизбежна. Тот, кто поставил 13, объясняет риски: «Я знаю, что этот легаси-код ломается при каждом чихе, там нужно рефакторить базу данных». Тот, кто поставил 3, говорит: «Но мы же просто добавляем поле в форму!». В итоге команда приходит к консенсусу, обычно выбирая большее число, потому что оптимизм новичков часто обманчив.

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

Идеальные часы: когда они всё-таки нужны

Не стоит выбрасывать часы в мусор. Они полезны в двух случаях. Первый - когда вы работаете по модели Fixed Price (фиксированная цена). Клиенту нужны конкретные цифры в договоре, и ему сложно объяснить, почему «8 очков» стоят дороже, чем «5 очков». Второй случай - когда команда только формируется. Новичкам проще мыслить категориями времени, пока они не привыкли к относительной оценке.

Но есть ловушка. Идеальные часы часто путают с рабочими часами. Предположим, вы оценили задачу в 4 идеальных часа. В реальности вы работаете 8 часов в день, но продуктивных из них, по данным исследований Microsoft, около 2-3 часов. Остальное уходит на почту, чаты и переключения контекста. Поэтому коэффициент пересчёта идеальных часов в рабочие дни обычно составляет 1:2 или даже 1:3. Если вы забыли про этот коэффициент, ваш проект сорвётся раньше, чем начнётся.

Факторы, которые ломают любую оценку

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

• Непонятные требования. Если в тикете написано «Сделать красиво», вы не можете оценить эту задачу. Пока нет чётких критериев приёмки (Definition of Done), любая оценка - гадание на кофейной гуще.
• Зависимости от внешних команд. Вы идеально оценили фронтенд, но ждёте API от смежного отдела две недели. Ваша оценка верна, но дата сдачи - ложь.
• Контекстные переключения. Если разработчик параллельно ведёт три проекта, его эффективность падает экспоненциально. Для него задача на 5 очков может стать задачей на 10, просто потому что он постоянно теряет нить повествования.

Чтобы минимизировать ущерб, вводите буфер. Опытные лиды добавляют 20-30% к итоговой оценке спринта на непредвиденные обстоятельства. Это не запас ленивых, это страховка от хаоса.

Velocity: главный индикатор здоровья команды

Когда вы научились ставить очки, появляется возможность считать Velocity (скорость выполнения). Это сумма очков, закрытых командой за предыдущие спринты. Допустим, ваша команда стабильно закрывает 40 очков за двухнедельный спринт. Теперь, когда заказчик спрашивает: «Когда будет готов функционал на 200 очков?», вы можете ответить: «Через пять спринтов, то есть примерно через 10 недель».

Но не используйте Velocity для сравнения разных команд! Команда А может считать задачу в 5 очков, а команда Б ту же задачу в 13. Их скорости несопоставимы напрямую. Velocity работает только внутри одной конкретной команды как инструмент самоорганизации и предсказания сроков.

Частые ошибки при оценке

Многие компании внедряют Agile формально, сохраняя старые привычки. Вот типичные грабли:

1. Перевод очков обратно в часы. Менеджер видит, что задача на 8 очков была сделана за 2 дня, и начинает требовать, чтобы следующая задача на 8 очков тоже делалась ровно за 2 дня. Это убивает суть относительной оценки.
2. Оценка до анализа требований. Ставить очки «на глазок» перед грумингом бэклога бессмысленно. Сначала уточняем детали, потом оцениваем.
3. Игнорирование тестирования. Разработчики часто оценивают только написание кода, забывая, что на тесты, исправление багов и деплой уходит столько же времени, сколько на саму разработку.

Практические советы для старта

Если вы решили перейти на стори поинты или улучшить текущий процесс, начните с малого. Не пытайтесь сразу внедрить сложную систему весовых коэффициентов. Выберите одну эталонную задачу, которую все знают и понимают, и примите её за единицу измерения (например, 1 или 2 очка). Все остальные задачи оценивайте относительно неё.

Ведите журнал оценок. После каждого спринта анализируйте: где мы ошиблись? Почему задача, которую мы считали простой, заняла столько времени? Возможно, мы недооценили сложность интеграции со старым сервером. Эти ретроспективы ценнее любой методики.

И помните: цель оценки - не наказать тех, кто не успел, а дать бизнесу предсказуемость. Если вы будете использовать оценки как оружие контроля, команда начнёт завышать числа, чтобы чувствовать себя комфортно. Доверие важнее точности цифр.