Вольный перевод статьи 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.
ПОДЕЛИТЬСЯ: