Spike
Spike (термин из XP, прижился в Scrum) — задача-исследование, которую команда берёт в спринт, когда не может оценить или начать большую историю из-за неопределённости.
Свойства Spike:
- Time-box — фиксированное время (1–3 дня), не SP
- Конкретная цель — «понять, можно ли использовать библиотеку X», «оценить трудоёмкость интеграции с API Y»
- Результат — отчёт, прототип, обновлённая оценка истории
Spike не доставляет ценности пользователю напрямую — он подготавливает работу над «настоящими» историями.
Типы Spike:
- Architectural — выбор технологии или архитектурного решения
- Functional — прояснение требований к фиче
- Technical — оценка сложности интеграции, нагрузочного теста и т.п.
Когда применять и когда нет
Применять
- История слишком неопределённа для оценки в SP
- Нужна предварительная архитектурная проработка
- Не понятна интеграция с внешними системами
Не применять
- Каждая вторая история превращается в Spike — это симптом плохого Refinement
- Spike растягивается на весь спринт — нарушено правило time-box
Примеры применения
Команда видит большую историю «Интеграция с Telegram Bot API». Никто из команды раньше не работал с этим API. Берут Spike на 2 дня: разработчик пробует базовый вариант, читает доку, делает прототип. По итогам — оценка для основной истории и техническое решение.
Часто задаваемые вопросы
Нет. Spike имеет time-box (фиксированное время, например 2 дня), не SP. Это намеренно: SP — оценка для истории, дающей ценность; Spike даёт информацию, а не ценность.
Нет. Если за выделенное время не разобрались — это сама по себе важная информация: задача сложнее, чем казалось. Берёте новый Spike или эскалируете.