Срочные задачи в Scrum: Как не дать пожарам сорвать Спринт
Scrum Guide говорит: Цель Спринта неизменна. Спринт — это защищенный кокон. Но в реальности случаются пожары: упал сервер, найден критический баг или пришел экстренный запрос от регулятора.
Вопрос не в том, можно ли брать такие задачи, а в том, как ими управлять, чтобы не выжечь команду и не превратить процесс в хаос.
Почему прерывания — это опасно?
- Потеря прозрачности: Ваши графики и метрики (Velocity) перестают отражать реальность.
- Смена контекста: Прыжки между задачами съедают до 40% продуктивности.
- Демотивация: Команда перестает верить, что она способна выполнить обещанное к концу спринта.
Что Говорит Scrum: Неизменность Цели Спринта
В идеальном мире Scrum, команда работает над задачами, выбранными во время Sprint Planning, чтобы достичь Цели Спринта. Если задача действительно критична и ставит под угрозу бизнес, только Product Owner имеет право попросить команду пересмотреть содержание Спринта. Но даже в этом случае, команда должна ответить: “Какую работу мы выкинем, чтобы взять новую?”.
Блок Список (Последствия Прерывания):
- Снижение Прозрачности: Метрики (скорость, предсказуемость) ломаются.
- Потеря Фокуса: Команда переключается, тратя время на смену контекста.
- Демотивация: Постоянные интеррапты подрывают способность команды выполнять обещанное.
Как работать с интерраптами на практике
Шаг 1. Фильтр Владельца Продукта (PO). PO должен решить: задача действительно горящая (бизнес теряет деньги прямо сейчас) или это просто чья-то хотелка? Всё, что не критично, отправляется в Бэклог Продукта до следующего планирования.
Шаг 2. Правило обмена Если задача критична — мы не просто докидываем её сверху. Мы спрашиваем: «Какую задачу из Спринта мы выкидываем, чтобы освободить место?». Ресурс команды ограничен, и нельзя впихнуть невпихуемое.
Шаг 3. Резервный буфер Зрелые команды, которые знают, что у них часто случаются баги, заранее оставляют в спринте 10–15% свободного времени (буфер). Если пожаров нет команда берет задачи из бэклога. Если есть они не срывают Цель Спринта.
Шаг 4. Фиксация в Бэклоге Даже самая срочная задача должна иметь карточку в Бэклоге Спринта. Без этого вы в конце недели не сможете объяснить, куда ушло время и почему Цель не достигнута.
| Шаг | Действие | Ответственный | Результат |
| Оценка Критичности | Определить, действительно ли задача угрожает бизнесу, или ее можно отложить. | Product Owner | Только критические задачи идут дальше. |
| Оценка Влияния | Команда оценивает, сколько времени займет задача и ставит ли она под угрозу Цель Спринта. | Разработчики | Определяется объем работы, который нужно удалить из текущего Спринта. |
| Использование Буфера | Если это мелкий баг, использовать заранее зарезервированный Буфер Интерраптов (до 15% ёмкости). | Разработчики | Спринт не прерывается, фокус сохраняется. |
| Прозрачность и Фиксация | Оценить интеррапт и включить его в Sprint Backlog для открытого отслеживания. | Scrum Master/Команда | Сохраняется прозрачность и возможность обсудить проблему на Ретроспективе. |
Эффективное управление срочными задачами требует постоянного партнерства между Product Owner (PO) и Scrum Master (CM). Однако, PO должен иметь смелость сказать нет некритичным запросам от влиятельных заинтересованных сторон, а CM — обеспечить, чтобы команда знала, какую работу нужно прекратить, чтобы избежать перегрузки.
Регулярные прерывания и срочные задачи свидетельствуют о проблемах на уровне организации — возможно, о недостаточной работе PO с заинтересованными сторонами или плохом качестве продукта (много продакшен-багов). Например, если команда стабильно тратит более 20% Спринта на интеррапты, ее предсказуемость падает, и она не может выполнить долгосрочные обязательства.
Анализ на Ретроспективе
Каждая срочная задача — это симптом. Если команда постоянно тратит 20% времени на пожары, значит, с продуктом или процессами что-то не так.
Может быть, код слишком сырой? Или Владелец Продукта не умеет говорить нет стейкхолдерам? Используйте эти данные на Ретроспективе, чтобы менять политику компании, а не просто привыкать к вечному стрессу.
Резюме: Гибкость — это не безотказность
В идеальном мире Scrum срочных задач нет. В реальном — они часть игры. Главное правило: новая работа заходит только в обмен на отмену старой.
Ключевой вывод: Не позволяйте интерраптам стать нормой. Если Цель Спринта под угрозой из-за новой задачи — честно признайте это и пересмотрите план. Лучше выполнить одну важную цель, чем бросить десять недоделанных дел.
Часто задаваемые вопросы (FAQ)
Это проблема прозрачности и управления заинтересованными сторонами. Scrum Master должен собрать данные о том, сколько времени тратится на интеррапты, и показать руководству, как это влияет на предсказуемость и выполнение долгосрочных целей. Эффективный способ — договориться о лимите на срочные задачи в Спринте (например, не более 10% времени).
Только Product Owner (PO) имеет право отменить Спринт, если Цель Спринта становится неактуальной или невозможной. Разработчики может попросить PO об отмене, если видит, что не сможет выполнить работу, но финальное решение остается за владельцем продукта.
Да. Любая работа, которую выполняет команда, должна быть оценена (пусть даже приблизительно — в Story Points или часах). Включение оценки в метрики команды обеспечивает прозрачность, позволяет измерить влияние интерраптов на скорость и предотвращает ситуации, когда “пятиминутная” задача на самом деле занимает полдня.
Буфер Интерраптов — это зарезервированная часть емкости Спринта (например, 15% общего времени команды), которая остается пустой на момент планирования. Она используется для неизбежных, мелких багов или поддержки, не прерывая главную Цель Спринта. Если буфер не используется, команда берет дополнительные задачи из Product Backlog.
Да, это критическое правило. Чтобы сохранить баланс, предсказуемость и избежать перегрузки, команда должна четко заявить: “Мы возьмем эту срочную задачу, взамен удаляем из Sprint Backlog задачу X”. Это делает стоимость интеррапта прозрачной для всех.