Как действуешь, если необходимо добавить задачу в середине спринта?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Добавление задач в середине спринта: управление изменениями
Это очень частая ситуация в реальных проектах. Заказчик звонит и говорит: "Ну и еще надо добавить...". Как реагировать? Просто добавить в спринт? Отказать? Отложить? Правильный ответ зависит от ситуации.
Мой подход: Классификация задач
К новой задаче в середине спринта я отношусь по-разному в зависимости от ее типа.
Тип 1: КРИТИЧНЫЙ БАГ (Severity = Critical)
Определение: Система не работает, пользователи не могут работать, данные теряются.
Примеры:
- Платежная система упала
- Данные не сохраняются
- Безопасность нарушена
Мой ответ: Добавляем немедленно, прерываем текущую работу
Действие:
- Уведомляю Scrum Master и Product Owner
- Очищаю место в спринте: одна из текущих историй откладывается в next sprit
- Критичный баг становится приоритетом #1
- Разработчик начинает работать (даже если это середина текущей истории)
Пример: "В системе обнаружили vulnerability в аутентификации. Добавляю в спринт. Игорь, перейди на эту задачу, пожалуйста."
Тип 2: ВАЖНАЯ ФИЧА (Priority = High, но не критична)
Определение: Нужна срочно для конкурентоспособности, но система работает без неё.
Примеры:
- Конкурент запустил фичу, нам нужна срочно
- Большой клиент попросил фичу для контракта
- Маркетинг просит фичу для кампании
Мой ответ: Спрашиваю, что убрать
Процесс:
- Встреча с Product Owner и Scrum Master
- Я говорю: "Эта фича в спринте займет 21 story points. У нас осталось 10 points capacity до конца спринта. Что из текущих историй убираем?"
- PO выбирает историю для отложения
- Новая фича добавляется в спринт
Пример: "Маркетинг просит интеграцию с Facebook pixel до конца недели. Это важно для кампании. Сейчас спринт на 85% заполнен. Либо отлаживаем историю "Экспорт в CSV" (которая не критична), либо просим еще неделю для Facebook."
Это честный разговор: вы не можете сделать все, нужно выбирать.
Тип 3: УТОЧНЕНИЕ ТЕКУЩЕЙ ЗАДАЧИ (Scope change)
Определение: Требование уже в спринте, но нужно добавить или изменить.
Примеры:
- История "Форма оплаты" требует еще одного поля
- Дизайнер попросил изменить интерфейс
- Мы забыли про одно условие
Мой ответ: Оцениваю, включаю в текущую историю
Процесс:
- Встреча с разработчиком, которые работает над этой историей
- Я говорю: "Нам нужно добавить валидацию на поле email. Это добавит еще 2-3 часа работы. Есть ли место в текущей истории?"
- Если есть место: добавляем в AC текущей истории
- Если нет места: разговор о перепланировании
Пример: "В истории "Форма регистрации" нам нужно еще проверить уникальность email. Это займет ~3 часа. У истории было оценено 13 points, это плюс 3 часа. Можешь включить в текущую работу?"
Тип 4: НОВАЯ ИДЕЯ ИЛИ ПРЕДЛОЖЕНИЕ (Priority = Low)
Определение: Идея, которая звучит хорошо, но не срочная.
Примеры:
- "Может быть сделать экспорт в Excel?" (когда уже есть PDF)
- "А может быть добавить темную тему?" (когда основной функционал готов)
- "Интересная фича бы была..."
Мой ответ: В backlog, не в спринт
Действие:
- Создаю историю в Jira в Product Backlog (не в спринт)
- Говорю: "Отличная идея. Я создал историю в бэклоге. На следующем Planning рассмотрим приоритет."
- Если это очень популярная идея, может стать приоритетной на следующем спринте
Пример: "Темная тема звучит здорово. Добавил в бэклог. Давайте оценим это на Planning и посмотрим, есть ли место в следующем спринте."
Правило: Всегда есть трейдофф
Ключевой принцип:
Вы не можете добавить задачу без того, чтобы что-то убрать.
Если спринт 100% спланирован, и вы добавляете что-то новое, вы разрушаете спринт. Знаю это по опыту: попытки "втиснуть все" приводят к:
- Срыву спринта
- Техническому долгу
- Выгоранию команды
- Потере доверия ("Вы обещали готово в пятницу, но это не готово")
Когда ты видишь, что новая задача входит в спринт
Шаг 1: Классифицируй
Вопросы себе:
- Это критично? (0 баллов - добавляем, прерываем текущее)
- Это срочно? (1-2 дня - важная фича, спрашиваем что убрать)
- Это уточнение текущей работы? (включаем в текущую историю)
- Это идея? (в бэклог)
Шаг 2: Обсуди с stakeholders
Не принимай решение в одиночку. Встреча с:
- Product Owner (кто определяет приоритет)
- Scrum Master (кто следит за спринтом)
- Лидом разработчиков (кто оценивает effort)
Шаг 3: Документируй
В Jira:
- Создаю историю
- Ставлю priority
- Добавляю в спринт (если нужно)
- Добавляю комментарий: "Запрос от [источник], добавлено в спринт вместо истории [какая убрана]"
В Slack/Email:
- Отправляю короткое сообщение: "Добавили историю X в спринт, убрали историю Y в next sprint"
Шаг 4: Следи за спринтом
В Daily standup проверяю:
- На ли мы все еще на трек?
- Есть ли новые блокеры?
- Есть ли еще предложения добавить задачи? (Обычно если одна добавляется, идут еще)
Конкретный пример из практики
Ситуация: Понедельник 14:00. Я на стенде истории спринта:
Вторник до конца: 40 points
Оставилось в спринте: 50 points
Capacity: 90 points
Оставалось: 0 points (спринт полный)
Позвонил Product Owner: "Прошла встреча с крупным клиентом. Они просят интеграцию с 1С до конца спринта (пятница). Это может стоить нам контракта на 500к."
Интеграция с 1С - это 34 story points (на основе похожего проекта).
Мой ответ:
"Вижу, это важно. Давайте посчитаем. 1С это 34 points, у нас есть 0 points свободной capacity.
Я предлагаю два варианта:
Вариант 1 (рискованный): Убираем историю "Отчеты по продажам" (21 points) и историю "Интеграция Slack" (13 points) из спринта. Добавляем 1С. Сегодня к вечеру начинаем разработку.
Риск: Отчеты и Slack переносим на следующий спринт. Они были нужны для кампании маркетинга.
Вариант 2 (экономный): Делаем MVP интеграции с 1С за эту неделю (13 points). Убираем историю "Экспорт в Excel" (13 points). Полную версию 1С делаем на следующем спринте.
Удовлетворит ли клиента MVP версия?"
PO: "Клиент хочет полную версию, но может быть MVP сойдет... Дай мне часа два уточнить."
Я: "ОК. Уточни и перезвони к 17:00. Я подготовлю список того, что входит в MVP для 1С, чтобы клиент понял."
(Готовлю список функций MVP: синхронизация контрагентов, документов, проводок)
17:30 PO перезвонил: "Клиент согласен с MVP. Спринт меняется, убираем Excel, добавляем 1С MVP."
В Jira я:
- Удалил историю "Экспорт в Excel" из спринта (в next sprint)
- Добавил историю "1С интеграция - MVP"
- Переоценил с 34 points на 13 points
- Написал comment: "Запрос от клиента через PO, добавлено вместо Excel"
- На Daily standup (вторник утро) объявил: "Изменение спринта. Добавляем 1С MVP, убираем Excel. Лучше?"
Результат: Пятница: 1С MVP готов, клиент доволен. Экспорт в Excel делаем на следующем спринте. Спринт завершен, хотя план изменился.
Как избежать частых изменений спринта
1. Хороший Planning Если требования ясны до Planning, меньше неожиданностей.
2. Контактный лист для бэклога Проводи Weekly Backlog Refinement, чтобы потенциальные задачи обсудили до спринта.
3. Жесткие границы спринта "Спринт это договор. Мы обещаем сделать X за Y времени. Если хотите добавить, нужно что-то убрать."
4. Distinction между типами задач Критичные баги могут прерывать спринт. Идеи нет. Это должно быть явно.
Заключение
Добавление задач в спринт это нормально в Agile, но это должно быть сознательное решение, а не просто "да, добавим, всё сделаем".
Ключевой навык BA это:
- Быстро классифицировать задачу (критично ли?)
- Оценить impact на спринт
- Предложить варианты (добавить и убрать, отложить, сделать MVP)
- Принять решение вместе с Product Owner
- Документировать и коммуницировать изменение
Этот подход сохраняет спринт управляемым, а команду - мотивированной.