> Что происходит, если фича не успела быть сделана в спринт и как переносится задача (Go)

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

Если фича не успела быть сделана в спринт, это называется carry-over. Задача не "сгорает" - она переносится в следующий спринт с полным сохранением контекста, оценки и статуса. Перенос - это не провал, а нормальная практика в Scrum, если команда честно оценивает объём работы. Главное - не переносить задачи молча: нужно зафиксировать факт на ретроспективе, обсудить причины и скорректировать планирование следующего спринта с учётом незавершённой работы.

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

В Scrum незавершённая задача не удаляется и не "переоткрывается" с нуля. Она остаётся в бэклоге спринта как незавершённая, и команда принимает одно из решений:

• Перенести в следующий спринт - если задача всё ещё актуальна и её можно завершить в ближайшее время.
• Вернуть в бэклог продукта - если приоритет изменился или задача потеряла ценность.
• Разбить на подзадачи - если задача слишком большая и её часть уже готова.

Перенос задачи в следующий спринт - это не просто "перетащить карточку". Нужно:

1. Зафиксировать статус - что уже сделано, что осталось, какие блокеры были.
2. Пересмотреть оценку - оставшаяся часть может быть меньше или больше исходной.
3. Обновить описание - добавить комментарии о текущем состоянии, чтобы следующий спринт начал с полным контекстом.
4. Обсудить на ретроспективе - почему не успели: переоценка, внешние зависимости, неожиданные сложности, переключение контекста.

Важно понимать: перенос задачи - это не нарушение Scrum. Нарушение - это когда команда систематически не успевает и не анализирует причины. Если переносы случаются регулярно, это сигнал к пересмотру процесса планирования: возможно, команда берёт слишком много работы или оценки систематически занижены.

Технически в трекере (Jira, YouTrack, Linear) перенос - это просто смена спринта у задачи. Но с точки зрения процесса - это управленческое решение, которое должно быть явным и задокументированным.

На практике

На практике перенос задачи выглядит так:

1. В конце спринта на daily-митинге или перед планированием команда просматривает незавершённые задачи.
2. Для каждой задачи принимается решение: перенести, вернуть в бэклог или разбить.
3. Задача переносится в следующий спринт с обновлённым описанием и комментарием о текущем прогрессе.
4. Оценка пересматривается - если осталось 20% работы, оценка уменьшается.
5. На ретроспективе команда обсуждает причины и вырабатывает меры: например, уменьшить velocity на следующий спринт или добавить буфер на непредвиденные сложности.

Важный нюанс: если задача переносится, она не должна занимать место новой задачи в следующем спринте "бесплатно". Команда должна явно включить её в commitment следующего спринта и учесть при планировании. Иначе получится, что команда планирует новый объём, а старый "висит" - и в итоге переносов становится только больше.

Ещё один момент: если задача переносится несколько раз подряд, это красный флаг. Стоит разобраться, почему задача не завершается: возможно, она слишком большая, зависит от внешних факторов или потеряла актуальность.

Пример кода

Пример не требуется - это процессный вопрос, не связанный с написанием кода. Но можно привести пример комментария в трекере при переносе:

Перенос из спринта 12 в спринт 13.
Статус: реализована основная логика, осталось:
- покрыть тестами edge cases
- добавить метрики
- провести code review
Блокеров нет, оценка оставшейся работы: 3 story points (из 8 исходных).
Причина переноса: неожиданная зависимость от внешнего API, ушло 2 дня на согласование.

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

Начни с прямого ответа: задача переносится в следующий спринт, это нормальная практика. Затем покажи понимание процесса: зафиксировать статус, пересмотреть оценку, обсудить на ретроспективе. Подчеркни, что перенос - это не провал, а сигнал для анализа. Если спросят про velocity - скажи, что перенос не должен "съедать" capacity следующего спринта без пересмотра планирования. Хорошо добавить, что систематические переносы - это проблема процесса, а не отдельной задачи. Не углубляйся в детали конкретного трекера, если не спрашивают - это не главное.

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

Интервьюер проверяет:

• Понимание Scrum-процесса и того, что перенос задач - это штатная ситуация, а не авария.
• Умение анализировать причины: почему задача не успелась, что можно сделать, чтобы это не повторялось.
• Понимание, что перенос требует явного действия: обновление статуса, пересмотр оценки, коммуникация с командой.
• Отношение к процессу: кандидат не должен паниковать или винить кого-то, а должен предлагать конструктивные меры.
• Понимание разницы между переносом задачи и изменением scope - это разные вещи.

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

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