Epics vs Features vs User stories vs SAFe Epics vs ?

Однажды, я написал отдельную заметку про разницу в терминах User stories, agile user stories, scenarios и use cases (о чем я вообще думал) и она стала чуть ли не самой популярной во всем блоге. Думаю, тому есть объективное объяснение. В сообществе разработки ПО процветает путаница среди множества популярных терминов. Только подумайте про UX, UI, CI/CD, DevOps, Product manager, North star etc

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

Сходу может показаться, что определение Эпика и так очевидно. На деле, вспоминая обсуждения с командами, становится понятно, что сформулировать определение далеко не так просто, как кажется.

С момента появления и за последние 16 лет термин «Эпик» приобрел множество различных значений. Посмотрим наиболее распространенные толкования.

Epic это большая User Story

Майк Кон так описал концепцию Эпика в своей книге 2004 года «User Stories Applied to Agile Software Development»: «Когда история слишком велика, ее иногда называют эпопеей».

Позже, Майк поделился дополнительными мыслями о предполагаемом использовании Эпиков в отдельном посте.

Мы называем большие истории эпопеями, когда хотим, сходу, дать понять собеседнику кое-что о них. Другими словами, мне нравится рассуждать об этом, как о фильмах. Если я скажу вам, что конкретный фильм был «приключенческим боевиком», то это сразу кое-что расскажет вам о фильме. Наверное, вы подумаете о погонях, перестрелках, какой-то истории, которую проживают герои и так далее. Точно так же, название истории «эпопеей» иногда может передать дополнительный смысл.

Предположим, вы спросите меня, было ли у меня вчера время, чтобы написать для команды пользовательские истории о системе ежемесячной отчетности. «Да, — отвечу я, — но сейчас это в основном Эпики». Это говорит о том, что, хотя я и писал их, у меня не было возможности разбить большинство из них на истории, которые, вероятно, были бы достаточно маленькими, чтобы их можно было сразу брать в разработку.

По сути, Майк предлагает использовать Эпики, скорее как прилагательное, чем как существительное, даже несмотря на то, что он структурирует свои предложения с использованием эпопеи, как существительного. То есть, это все те же пользовательские истории, только с более высоким уровнем неопределенности и охватывающие больший объем контекста. К тому же, вроде как, и сам термин Agile действительно должен быть прилагательным.

Epic это отдельный тип элементов в вашем Backlog

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

Возьмем, к примеру, описание Эпика от Atlassian (авторы Jira software). Эпики стали типом элементов невыполненной работы, которые отделены от пользовательских историй, но содержат их внутри себя:

Эпик — это большой объем работ объединенных по смыслу, который можно разбить на несколько более мелких историй. Например, вся работа из релиза, связанная с производительностью системы. Эпик может охватывать более одного проекта, если несколько проектов включены в доску, к которой принадлежит эпик.

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

По мере того, как команды стали внедрять новые структуры и правила, они также стали нести дополнительные накладные расходы на их обсуждение и поддержку.

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

Epic — это проект (но мы его так не называем)

Scaled Agile Framework (SAFe) отошел от обоих вышеупомянутых взглядов на эпопеи и привнес идею иерархических бэклогов на совершенно новый уровень, создав иерархию среди самих бэклогов.

В SAFe, вместо того, чтобы управлять единым бэклогом продукта включающего элементы разного размера, у вас есть отдельный бэклог команды с пользовательскими историями, бэклог программы с фичами, от англ. features (еще один термин, вызывающий путаницу) и портфолио бэклог с эпиками.

В данном случае эпики — это не большие пользовательские истории, а «контейнеры для инициатив»:

Эпик — это контейнер для инициатив по разработке решений, достаточно большой, чтобы потребовать анализа, определения минимально жизнеспособного продукта (MVP) и экономического согласования перед внедрением.

Такой взгляд добавил дополнительной путаницы, потому что теперь, когда люди говорят «Эпик», вы сначала должны прояснить, говорят ли они об эпопеях SAFe или каких-то других трактованиях.

Как мы можем устранить эту путаницу?

Самый простой способ добиться взаимопонимания внутри команды, а также между вашей командой и другими командами в вашей организации — это прийти к соглашению о том, что для вас означает термин «Эпик», а затем последовательно придерживаться именно такой трактовки в работе.

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

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

Посмотрите также выступление самого Джеффа «Requirements, Product Ownership, and Other Misunderstood Concepts in Agile Development» на Agile2014.

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

Кстати, знали ли вы, что существует целый глоссарий популярных в Agile терминов?

Заметка является моим вольным переводом мыслей Кента МакДональда из его Epic Confusion.