Команда планирует новую функцию, но неясно, справится ли существующая архитектура с нагрузкой. Разработчики предлагают три варианта решения, но ни один не проверен на практике. Владелец продукта хочет начать разработку прямо сейчас, а технический лид говорит: «Сначала нужен Spike».
В статье разберём, что такое исследовательские задачи в Agile, когда они нужны и как с ними работать, чтобы снижать риски до начала полноценной разработки.
Что такое Spike
Spike (спайк) — это исследовательская задача с фиксированным временем, цель которой — получить информацию для снижения неопределённости. Spike не создаёт рабочий функционал для пользователя, а помогает команде разобраться в технических или функциональных вопросах до начала основной разработки.
Термин появился в Extreme Programming (XP) и описывал работу по исследованию, проектированию или прототипированию. Сейчас Spike активно используется в Scrum, Kanban Методе и SAFe для управления рисками в условиях высокой неопределённости.
Spike отвечает на конкретные вопросы:
- Реализуемо ли это технически?
- Какой подход выбрать?
- Насколько сложна интеграция?
- Что именно нужно пользователям?
Зачем нужны Spike: 4 ситуации применения
Agile-команды проводят небольшие эксперименты вместо того, чтобы строить предположения и сразу переходить к разработке.
Spike используются в конкретных ситуациях:
- Оценить новую функцию или возможность. Когда функция слишком крупная или неясная для оценки, Spike помогает разделить её на измеримые части и понять реальный объём работы.
- Проверить техническую реализуемость. Перед внедрением новой технологии или архитектурного решения команда тестирует подход на небольшом прототипе. Это выявляет ограничения и технические риски до полноценной разработки.
- Изучить новую предметную область или технологию. Команда может не иметь опыта работы с конкретной технологией или бизнес-процессом. Spike даёт время разобраться в деталях и принять обоснованное решение.
- Снизить риск при разработке эпика. В SAFe Spike часто используется на уровне портфолио для определения ценности и состоятельности крупного эпика. Небольшое исследование помогает понять, стоит ли вкладывать ресурсы в полноценную реализацию.
Технические и функциональные Spike
Существует два основных типа исследовательских задач, которые решают разные проблемы.
Технические Spike
Исследуют подходы к технической реализации решения. Команда изучает архитектурные варианты, производительность, интеграции, технологические ограничения.
Примеры технических Spike:
- Определить, стоит ли разрабатывать решение самостоятельно или купить готовое.
- Оценить влияние новой функции на производительность системы.
- Проверить совместимость с внешним API или сервисом.
- Сравнить несколько технологических подходов к решению задачи.
Так, команда планирует обновлять данные на интерфейсе клиента в режиме реального времени. Технический Spike помогает оценить, сколько времени займёт обновление интерфейса, какие требования к пропускной способности каналов связи, какие дополнительные данные нужно передавать.
Функциональные Spike
Исследуют поведение системы с точки зрения пользователя. Команда изучает требования, собирает обратную связь, определяет границы функциональности.
Примеры функциональных Spike:
- Понять, как пользователи хотят взаимодействовать с новой функцией.
- Определить варианты декомпозиции крупной фичи.
- Выявить риски и ключевые сложности с точки зрения бизнеса.
- Собрать инсайты для принятия решения о целесообразности разработки.
Например, компания планирует добавить дашборд с энергопотреблением для пользователей. Функциональный Spike — это создание простого прототипа интерфейса и сбор обратной связи: понятна ли визуализация, какие данные важны, удобен ли формат представления.
Комбинированные Spike
Некоторые задачи требуют обоих типов исследования. Для истории «Как потребитель, я хочу видеть своё ежедневное потребление энергии в виде гистограммы» команде нужно:
- Технический Spike: Оценить время обновления данных, требования к пропускной способности, объём передаваемой информации.
- Функциональный Spike: Создать прототип гистограммы и собрать обратную связь о размерах, стиле, визуализации.
Как работать со Spike: практическое руководство
Чтобы Spike приносили пользу, а не превращались в бесконечные исследования, следуйте чётким правилам.
- Фиксируйте временные рамки. Spike имеет жёсткий time-box. Обычно это от нескольких часов до нескольких дней, редко — целый спринт. Если за отведённое время не удалось получить ответ, команда останавливается и решает: продолжить исследование, изменить подход или отказаться от фичи.
- Формулируйте чёткие вопросы. Spike должен отвечать на конкретные вопросы, а не быть размытым «изучить технологию». Хорошие формулировки: «Поддерживает ли API нужную нам функцию?», «Справится ли текущая база данных с 10 000 запросов в секунду?», «Понимают ли пользователи новый интерфейс?».
- Определяйте критерии приёмки. Как и для обычных историй, для Spike нужны критерии завершения. Результат Spike — это информация, а не рабочий код. Критерии могут быть такими: «Документ с описанием трёх вариантов решения и рекомендацией», «Прототип интерфейса и результаты тестирования с 5 пользователями», «Отчёт о нагрузочном тестировании».
- Не тратьте много усилий. Spike не должен создавать production-ready решение. Цель — получить достаточно данных для принятия решения. Прототип может быть «на коленке», архитектура — упрощённой, код — некрасивым. Важен результат исследования, а не качество кода.
- Демонстрируйте результаты. Как и другие истории, Spike демонстрируются на ревью итерации. Команда показывает владельцу продукта и стейкхолдерам, что узнала, какие выводы сделала, какие решения рекомендует. Это создаёт прозрачность и коллективную ответственность.
Оценка и планирование Spike
Spike оцениваются так же, как обычные истории, и включаются в бэклог команды.
Оценка трудозатрат. Команда оценивает Spike в story points или часах. Оценка отражает сложность исследования, а не объём кода. Сложный технический Spike может занять больше времени, чем простая пользовательская история.
Планирование в спринте. Планировать Spike и зависимую от него историю в одном спринте рискованно — Spike может не дать однозначного ответа. Обычно Spike выполняется в одном спринте, а основная разработка — в следующем.
Исключение: если Spike небольшой (несколько часов) и команда уверена в быстром результате, можно запланировать обе задачи в одной итерации.
Приоритизация. Spike приоритизируется по уровню риска и неопределённости. Чем выше риск провала или чем больше неизвестных, тем раньше нужно провести исследование.
Типичные ошибки при работе со Spike
Даже опытные команды допускают ошибки, которые превращают Spike в потерю времени.
Spike без чётких критериев завершения
Команда начинает исследование без определения, что именно считается результатом. Spike затягивается, потому что непонятно, когда останавливаться.
Определяйте критерии приёмки для Spike так же, как для обычных историй. Результат Spike — это конкретная информация: документ с выводами, прототип с результатами тестирования, отчёт о производительности. Владелец продукта принимает Spike на основе этих критериев.
Слишком много усилий на исследование
Команда создаёт слишком детальный прототип или проводит исчерпывающее исследование. Spike растягивается и поглощает ресурсы, хотя для принятия решения достаточно базовой информации.
Помните: Spike не несёт ценность для пользователя напрямую. Собирайте только те данные, которые необходимы для оценки и принятия решения о дальнейшей разработке.
Spike как норма, а не исключение
Команда использует Spike для каждой неясной истории. Spike становится обязательным этапом вместо инструмента для критических ситуаций с высокой неопределённостью.
Цель Agile-команды — научиться справляться с неопределённостью в каждой итерации через обсуждения и эксперименты. Spike помогает только в ситуациях с действительно высокой неопределённостью или серьёзными рисками.
Что в итоге
Spike — это исследовательская задача, которая помогает командам снижать неопределённость и риски до начала разработки. Технические Spike изучают подходы к реализации, функциональные — поведение системы и потребности пользователей.
Эффективные Spike имеют чёткие вопросы, фиксированное время и конкретные критерии завершения. Они не создают production-ready решения, а дают информацию для принятия обоснованных решений.
Внедрить практику работы со Spike и обучить команду управлению рисками при разработке непросто — нужно учитывать уровень зрелости команды, специфику проектов и организационный контекст. Компания Neogenda помогает командам внедрять Agile и SAFe практики, обучает работе с техническим долгом и исследовательскими задачами. Мы работаем с крупными брендами: Сбер, Ростелеком, банки и IT-компании.
Начните трансформацию с бесплатной консультации от практиков Neogenda — это первый шаг к тому, чтобы создавать продукты, которые решают реальные задачи пользователей.