Скорее всего, вы уже прекрасно знаете, что такое эпик. Вероятно, вы использовали их, и вы используете их для управления и организации вашего отставания. Итак, почему я пишу о том, что всем известно? Потому что многие думают, что знают, но на самом деле неправильно используют эпики.
Формальное определение
Почти все формальные определения, которые можно найти в Интернете, сходятся в том, что эпик описывается как большая пользовательская история, которую можно разделить на более мелкие части и представить в нескольких взаимодействиях. Например, определение Agile Alliance:
Эпопея — это большая пользовательская история, которая не может быть доставлена, как определено, в рамках одной итерации или достаточно велика, чтобы ее можно было разделить на более мелкие пользовательские истории.
Мне нравится и полностью согласен с этим определением. К сожалению, это не та реальность, которую я видел в последние годы.
Наиболее распространенное использование
Когда люди говорят об эпиках, я обычно вижу простую совокупность пользовательских историй. Удобный способ сгруппировать их. В некоторых случаях эпос определяет компонент, который будет длиться вечно. Мы могли бы назвать эту эпопею подпродуктом. В других случаях — этапы, на которых команда рассматривает возможность выполнения работы. Две пользовательские истории были бы в одной эпопее только потому, что они относятся к Фазе 2. Я также видел эпопеи, относящиеся к технологиям, с эпопеей для Front, еще одной для Back и еще одной для DevOps. Нередко можно увидеть эпики для групповых инцидентов. Или мой любимый из всех, эпопея для группы заинтересованных сторон, которые просят эту функциональность.
Как вы видите, все эти случаи — просто группы пользовательских историй, следующих по какой-то причине, но не той, которая описана формально. Почему это происходит?
Мы можем найти причину в том, как различные инструменты для управления нашим бэклогом реализовали эпики. Практически во всех случаях эпики предлагают пользователям мощный инструмент группировки. Это нормально, что пользователи заполняют свои потребности в группировке эпиками.
Давайте посмотрим на Jira, так как это самый распространенный инструмент для управления бэклогом. Некоторое время назад у них было следующее описание эпоса:
Истории, баги и задачи используются для описания одной отдельной работы. Эпики используются для описания группы связанных вопросов. Эпики также могут быть большой пользовательской историей, которую необходимо разбить на более мелкие, более управляемые фрагменты.
В тот момент они даже не скрывали, что эпики были просто для группировки вопросов. Конечно, вы также можете использовать их для больших пользовательских историй, но это было только одно из применений. В Jira очень легко создать панель мониторинга на основе эпиков или создать потоки, зависящие от эпиков. Теперь они изменили определение, сосредоточив внимание на формальном определении, но по-прежнему открывая возможность простой стратегии группировки:
Рассмотрите возможность создания эпика, если у вас есть большой объем работы, которую необходимо выполнить в течение нескольких спринтов или в течение длительного периода времени. Вы также можете создать эпик, когда заметите закономерность среди нескольких пользовательских историй и захотите объединить их в одну группу.
Я вижу ущерб, нанесенный этими инструментами. На основе определения эпиков создали функционал. Позднее эта функциональность использовалась для любой группы. Теперь исходное определение эпичности во многих командах было изменено с некоторыми важными побочными эффектами в культуре.
Что такое эпик?
Мы должны перестать использовать эпики как простые группы. Эпики — это способ планировать наше командное будущее. Они предоставляют контекст о больших целях, которые мы пытаемся достичь, о больших пользовательских историях, которые мы пытаемся реализовать.
Эпопея, как история, представляет потребность с точки зрения пользователя. Новая функциональность, цель, большое изменение — немногие кандидаты на звание эпика.
Эпопея не обязательно должна быть привязана к технологии или продукту. Эпиком может быть: «Интернационализировать платформу продаж». Это может включать переводы, новые валюты, новые налоги или юридические требования. Это может повлиять на ERP, точки продаж и многие другие продукты.
Эпопея рождается из очень большой потребности пользователя и, скорее всего, вначале немного абстрактна. Истории пользователей будут рождаться из эпоса, а не иначе. Пользовательские истории не должны создаваться независимо, а затем создавать эпопею, когда мы видим шаблон. Эпопея — это сущность, генерирующая пользовательские истории.
Эпос представляет собой цель, которая когда-нибудь будет достигнута. Из-за этого они конечны во времени. У нас нет эпиков с масштабом продукта или функционала, которыми можно будет управлять вечно. Эпопея не в функциональности, а в создании или изменении этой функциональности. Что-то, что в конечном итоге будет достигнуто, как пользовательская история, но больше.
Почему меня это так волнует?
Потому что одной из проблем некоторых команд является отсутствие видения будущего. Их волнует только текущий спринт. Эпики позволяют мыслить шире. Они представляют собой долгосрочную дорожную карту и стратегию. Они предоставляют контекст, почему мы работаем над определенной пользовательской историей.
Использование наших эпиков только для группировки проблем не позволяет нам иметь настоящие эпики, что затрудняет понимание командой их собственного контекста.
Мой совет: наверняка ваши инструменты предоставляют другие способы группировки заявок, которые вы можете использовать так же эффективно, как и эпики. Например, в Jira у вас есть компоненты и метки среди прочего. Не используйте эпики для вещей, которые не являются настоящими эпиками.
