Spike: как бороться с неопределенностью задач в Agile

Вольный перевод статьи Spikes — Scaled Agile Framework.

“Если бы мы знали, что мы делаем, это бы не называлось исследованием” — Альберт Эйнштейн

Spike (Спайк) — тип исследовательской Enabler-истории в SAFe®. Изначально описан в Экстремальном Программировании (eXtreme Programming, XP) как работа по исследованию, проектированию или прототипированию. Эта работа позволяет получить необходимые данные для снижения риска в ходе реализации Фичи, лучше изучить требования и/или повысить точность оценки работ.

Как и для других Историй, трудозатраты на Спайки оцениваются, а результаты демонстрируются в конце Итерации. Спайки также являются частью процесса работы Agile Release Train (ART) над Эпиками, для определения их состоятельности и ценности.

Agile и Lean ценят факты выше экспертизы. Столкнувшись с неопределенностью, вопросами или рисками, Agile-команды проводят небольшие эксперименты, вместо того чтобы строить предположения о возможном результате и переходить к Решению. Команды могут использовать Спайки в самых разных ситуациях:

• Оцените новые Фичи и Возможности путем разделения их на более мелкие части, поддающиеся количественной оценке.
• Выполните технико-экономический анализ, который поможет оценить целесообразность реализации Эпика.
• Проводите крупное исследование, чтобы ознакомиться с новой технологией или предметной областью.
• Исследуйте подход к технической реализации и функционал, снижая риски и неопределенность.

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

Технические и функциональные спайки

Спайки в основном бывают двух видов: технические и функциональные.

Функциональные Спайки используются для исследования общего поведения системы и определяют:

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

Технические Спайки используются для исследования различных подходов в области разработки решения. Например:

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

Для некоторых Фич и Историй могут потребоваться оба типа Спайков. Например:

“Как потребитель, я хочу видеть свое ежедневное потребление энергии в виде гистограммы, чтобы я мог быстро определить свое прошлое, текущее и прогнозируемое потребление энергии”.

В этом случае, команде может потребоваться реализация обоих типов Спайков:

• Технический Спайк для исследования того, сколько нужно времени, чтобы обновить интерфейс для клиента, определения требований к пропускной способности каналов связи и какие дополнительные данные нужно отправлять и получать.
• В рамках Функционального Спайка можно создать прототип гистограммы на веб-портале и собрать обратную связь от пользователей о размерах гистограммы, стиле и визуализации графика.

Руководство по работе со спайками

Поскольку сами Спайки не несут ценность для пользователя, не тратьте на них много усилий. Следуйте рекомендациям ниже.

Оценка, демонстрация и приемка

Как и остальные Истории, спайки оценены, декомпозированы и помещены в Бэклог Команды. Но результат Спайка отличается от результата Истории и чаще всего содержит информацию, а не рабочий код. Они должны собирать исключительно только те данные, которые необходимы для идентификации и оценки Истории.

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

Сроки реализации cпайков

Поскольку Спайки несут в себе высокую неопределенность, планирование в одной  Итерации как Спайка, так и зависимой от него Истории достаточно рискованно. Однако, если Спайк небольшой и с большой долей вероятности будет найдено быстрое решение, то планирование в одной Итерации и Спайка, и Истории может быть достаточно эффективно.

Исключение, не правило

Каждая История несет в себе неопределенность и риски — это природа Agile-подхода. Команда находит верное решение путем обсуждений, экспериментов и сотрудничества. В какой-то мере, каждая История содержит в себе Спайк-подобные активности, вскрывающие функциональные и технические риски. Цель Agile-команды научиться справляться с неопределенностью в каждой итерации. Спайки помогают в ситуациях, когда есть высокая неопределенность или много неизвестных.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.