Что такое Spike?

Spike (спайк) — это термин из [Extreme Programming (XP)](/ru/extreme programming - xp), обозначающий ограниченную по времени задачу исследования или экспериментирования, целью которой является уменьшение неопределённости, получение знаний или ответ на технический или функциональный вопрос, необходимый для реализации [пользовательской истории](/ru/historia de usuario).

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

Spike получил своё название по аналогии с «пиком» — он представляет собой короткий, сфокусированный выброс усилий для изучения конкретного вопроса, после чего команда возвращается к обычному рабочему потоку.

Spike используется в ситуациях, когда команда сталкивается с неопределённостью, которая мешает планированию или реализации работы:

Технологическая неопределённость

Команда не знает, возможно ли техническое решение, или не может оценить его сложность:

• «Поддерживает ли этот API нужную нам функциональность?»
• «Какова производительность библиотеки X при нашей нагрузке?»
• «Совместима ли новая версия фреймворка с нашей кодовой базой?»

Архитектурная неопределённость

Команде нужно принять архитектурное решение, и для этого требуется проверка гипотез:

• «Какой подход к хранению данных лучше подходит для нашего сценария?»
• «Как интегрировать микросервис X с существующей системой?»
• «Какой паттерн использовать для обработки событий?»

Неопределённость требований

Команда не до конца понимает, что именно нужно пользователю:

• «Как пользователи взаимодействуют с аналогичными функциями в конкурирующих продуктах?»
• «Какой формат отчёта будет наиболее полезен для целевой аудитории?»
• «Как пользователи реагируют на предложенный прототип интерфейса?»

Неопределённость оценки

Команда не может дать разумную оценку задаче из-за недостатка знаний:

• «Мы не можем оценить эту историю, потому что не понимаем объём работы по интеграции»
• «Нам нужно разобраться с legacy-кодом, прежде чем мы сможем оценить сложность изменений»

Технический Spike (Technical Spike)

Технический spike направлен на исследование технических аспектов решения. Его проводит один или несколько разработчиков, и результатом обычно является техническое решение или доказательство концепции (proof of concept).

Примеры:

• Создание прототипа интеграции с платёжной системой для оценки сложности
• Тестирование производительности различных баз данных для выбора оптимальной
• Исследование возможностей нового API для определения, подходит ли он
• Оценка технического долга в модуле, который предстоит изменить

Формат результата: код прототипа, результаты бенчмарков, техническое описание решения, список ограничений.

Функциональный Spike (Functional Spike)

Функциональный spike направлен на исследование пользовательских аспектов — поведения пользователей, удобства интерфейса, бизнес-процессов.

Примеры:

• Создание кликабельного прототипа для тестирования с пользователями
• Исследование конкурентных продуктов для определения лучших практик
• Проведение интервью с пользователями для уточнения требований
• Анализ данных поведения пользователей для обоснования дизайнерских решений

Формат результата: прототип интерфейса, результаты пользовательского тестирования, описание сценариев использования, рекомендации по дизайну.

Ограниченность по времени (Timebox)

Spike всегда имеет фиксированный таймбокс — максимальное время, которое команда готова потратить на исследование. Типичный таймбокс spike:

• Маленький spike: 2-4 часа (быстрый вопрос, который можно решить за полдня)
• Средний spike: 1-2 дня (требует прототипирования или тестирования)
• Большой spike: 3-5 дней (сложное исследование, не более одного спринта)

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

Определённый результат

Spike должен иметь чёткое определение того, какой результат ожидается:

• Ответ на конкретный вопрос (да/нет, вариант A или B)
• Оценка трудоёмкости задачи в story points или часах
• Прототип или доказательство концепции
• Техническое описание выбранного подхода
• Список рисков и ограничений

Отсутствие функционального инкремента

Spike не является задачей по разработке. Код, написанный в рамках spike, как правило, является одноразовым прототипом и не попадает в production. Результат spike — знание, а не функциональность.

Планирование Spike

В Scrum spike планируется как элемент [Sprint Backlog](/ru/sprint backlog) во время [Sprint Planning](/ru/sprint planning). Существуют два подхода к планированию:

Подход 1: Spike в текущем спринте, реализация — в следующем. Команда выделяет spike в текущий спринт, получает результаты, и на основе этих результатов создаёт пользовательские истории для следующего спринта. Это более безопасный подход, так как он даёт время на осмысление результатов.

Подход 2: Spike и реализация в одном спринте. Если spike небольшой (2-4 часа), команда может запланировать его в начале спринта, а оставшееся время использовать для реализации на основе результатов. Это более агрессивный подход, требующий уверенности в том, что spike не затянется.

Оценка Spike

Вопрос оценки spike является дискуссионным в Scrum-сообществе:

• Не оценивать в story points: spike не доставляет ценность пользователю, поэтому не должен влиять на velocity. Вместо этого spike получает фиксированный таймбокс
• Оценивать в story points: spike потребляет ёмкость команды, и его следует учитывать при планировании спринта
• Оценивать в часах: spike имеет фиксированное время исполнения, которое удобнее выражать в часах

Наиболее распространённый подход — задавать таймбокс без оценки в story points.

Spike на Sprint Review

Результаты spike могут быть представлены на [Sprint Review](/ru/sprint review) в формате:

• «Мы исследовали вопрос X и выяснили, что...»
• «Мы создали прототип Y, который показал...»
• «На основе результатов spike мы рекомендуем подход Z»

Это помогает стейкхолдерам понять, на что была потрачена часть ёмкости команды, и участвовать в принятии решений.

В Kanban spike визуализируется как элемент работы на [канбан-доске](/ru/kanban board), часто с отдельным типом карточки или меткой. Ключевые особенности:

• Spike подчиняется [WIP-лимитам](/ru/wip limit - work in progress limit) наравне с другими элементами
• [Cycle time](/ru/cycle time) spike отслеживается и анализируется
• Spike имеет таймбокс, визуально обозначаемый на доске (например, красной меткой с датой окончания)

Формулируйте чёткий вопрос

Плохо: «Исследовать интеграцию с платёжной системой». Хорошо: «Определить, поддерживает ли API Stripe рекуррентные платежи с переменной суммой, и оценить трудоёмкость интеграции».

Определяйте формат результата заранее

До начала spike команда должна договориться, какой формат будет иметь результат: документ, прототип, презентация на [ретроспективе](/ru/sprint retrospective), запись в wiki. Это предотвращает ситуацию, когда знания остаются только в голове одного разработчика.

Соблюдайте таймбокс строго

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

Не превращайте Spike в разработку

Spike — это исследование. Если в процессе spike команда начинает разрабатывать production-код, это уже не spike, а задача разработки. Код из spike может быть использован как референс, но не должен напрямую попадать в production без прохождения стандартного процесса (code review, тестирование, CI).

Делитесь результатами

Результаты spike должны быть доступны всей команде и сохранены для будущего использования. Запись в confluence, короткое демо на daily, или комментарий к задаче в Jira — выберите формат, который работает для вашей команды.

Контекст: Команда разрабатывает платформу электронной коммерции. [Product Owner](/ru/product owner) хочет добавить функцию «Купить сейчас — заплатить позже» (BNPL). Команда никогда не работала с BNPL-провайдерами и не может оценить сложность интеграции.

Spike: «Оценить сложность интеграции с BNPL-провайдерами Klarna и Afterpay. Определить, какой провайдер лучше подходит по функциональности, цене и простоте интеграции. Таймбокс: 2 дня.»

Действия:

1. Изучение документации API обоих провайдеров (4 часа)
2. Создание sandbox-аккаунтов и тестовых интеграций (8 часов)
3. Сравнение по критериям: функциональность, цена, качество документации, поддержка (2 часа)
4. Документирование результатов и рекомендация (2 часа)

Результат: «Рекомендуем Klarna. API хорошо документирован, поддерживает все нужные сценарии. Оценка интеграции: 8 story points (3-5 дней). Основные риски: необходимость верификации мерчанта (до 2 недель), ограничения по валютам для российского рынка.»

Далее: На основе результатов spike Product Owner создаёт [пользовательские истории](/ru/historia de usuario) для интеграции с Klarna, и команда может уверенно оценить и спланировать работу.

• «Вечный spike»: spike без чёткого таймбокса, который затягивается на недели. Решение: всегда устанавливать жёсткий таймбокс
• «Spike ради spike»: использование spike для оттягивания решений. Решение: спросить, действительно ли недостаток знаний мешает работе
• «Spike без результата»: знания остаются в голове одного разработчика. Решение: определять формат результата заранее
• «Spike как задача разработки»: написание production-кода под видом spike. Решение: чётко разделять исследование и реализацию
• «Слишком много spike»: значительная часть спринта уходит на spike. Решение: обычно spike не должны занимать более 10-15% ёмкости спринта

Spike и Proof of Concept (PoC) — это одно и то же?

Не совсем. Spike — это ограниченная по времени задача исследования, результатом которой может быть PoC, но не обязательно. Spike может ограничиться изучением документации, анализом кода или проведением интервью. PoC — это один из возможных результатов spike, когда для ответа на вопрос нужно создать работающий прототип.

Может ли spike длиться больше одного спринта?

В теории нет. Spike по определению ограничен по времени и не должен превышать один спринт. Если исследование требует больше времени, его следует разбить на несколько последовательных spike с чёткими промежуточными результатами. Каждый spike должен давать ценную информацию, даже если общее исследование не завершено.

Кто выполняет spike?

Это зависит от типа spike. Технический spike обычно выполняет один или два разработчика. Функциональный spike может выполнять дизайнер, [Product Owner](/ru/product owner) или пара «разработчик + дизайнер». В сложных случаях spike может быть командной задачей для [mob programming](/ru/mob programming).

Нужно ли spike проходить через Definition of Done?

[Definition of Done](/ru/dod definition of done) обычно не применяется к spike напрямую, так как spike не производит функциональный инкремент. Вместо этого рекомендуется создать отдельный «Definition of Done для spike»: результат задокументирован, знания переданы команде, следующие шаги определены.

Что делать, если spike показал, что задача невозможна?

Это ценный результат! Spike сэкономил команде недели или месяцы работы, которая привела бы к тупику. Команда должна обсудить результат с [Product Owner](/ru/product owner) и рассмотреть альтернативные подходы к решению бизнес-задачи.

Как отслеживать spike на канбан-доске?

На [канбан-доске](/ru/kanban board) spike отображается как карточка с отличительным признаком (другой цвет, метка «Spike», иконка). Рекомендуется добавить на карточку дату окончания таймбокса, чтобы команда видела, если spike затягивается. Spike проходит по стандартному потоку (To Do -> In Progress -> Done), где «Done» означает «результат получен и задокументирован».