> For the complete documentation index, see [llms.txt](https://akrisanov.gitbook.io/team-playbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://akrisanov.gitbook.io/team-playbook/delivery/process-planirovaniya-epikov.md).

# Процесс планирования Эпиков

Планирование осуществляется поквартально.

Для визуализации Эпиков, проведения планирования и контроля текущего состояния работ по ним используется доска **Цели (Эпики)**.

### Зачем это нужно

1. **Петли обратной связи** – за счет относительно небольших отрезков (3 месяца) есть возможность давать и получать корректирующую обратную связь, повышая предсказуемость поставки
2. **Валидация** – за счет встреч по планированию в явном виде фиксируются цели на ближайший квартал, что дает уверенность, что время разработки инвестируется наилучшим образом
3. **Визуализация** – для всех заинтересованных лиц и стейкхолдеров в явном виде и в одном месте представлена бизнес-ценность, которая находится в работе

### Участники и роли

1. **СРО (РО) и СТО** являются владельцами Эпиков в Бэклоге. СРО или Продакты отдельных команд формируют Эпики, несущие прямую бизнес-ценность, СТО формирует Эпики, являющиеся критичными для технологического здоровья продукта
2. **Стейкхолдеры** – являются заказчиками Эпиков, участвуют во встречах по планированию и убеждаются, что их ожидания совпадают с заявленными целями и визуализацией работы
3. **Менеджеры и эксперты из команд разработки** валидируют и подтверждают, что ознакомлены с верхнеуровневыми требованиями, понимают ожидаемый результат по каждому Эпику и готовы подтвердить выполнимость целей ближайшего квартала

\* эксперты от команд: члены команд с наибольшей экспертизой, участвующие в обсуждении и декомпозиции Эпиков в процессе подготовки к планированию

### Процесс планирования и разработки

Для каждого рабочего элемента (Эпика) предусмотрены следующие статусы:

1. **Бэклог** – очередь работы на будущее. На данном этапе Эпик может состоять из заголовка карточки и представляет собой некую идею, которую возможно нужно будет сделать в будущем.
2. **Анализ** – этап подготовки наиболее ценных Эпиков к планированию. На данном этапе продуктовая командам детализирует описание эпика по шаблону, обсуждает идею со стейкхолдерами, привлекает экспертов от разработки. В случае необходимости на данном этапе стартует написание драфта бизнес-требований (если он поможет в понимании Эпика и его декомпозиции).\
   По итогу должен появится образ результата (критерии приемки) и декомпозиция на отдельные `Стори`/`Рефакторинг`. Они заводятся в очереди соответствующей команды (например, для веб это очередь `Веб-приложение` ) в статусе `Бэклог` и обязательно должны быть привязаны к Эпику с типом `Подзадача`.

   `Рефакторинг` – тип задачи, аналогичный `Стори` по шаблону, но являющийся подзадачей для технических эпиков. Это удобно для дальнейшей аналитики соотношения технического долга и продуктовым задачам.
3. **Планирование** – итоговый этап определения состава работ в следующем квартале.

   Критерии готовности Эпика к обсуждению на предпланировании / планировании:

   * Эпик находится в статусе `Планирование`
   * Карточка Эпика заполнена по шаблону
   * Эпик обсуждался с представителями команды разработки, команда подтвердила, что это технически реализуемо
   * К эпику с типом связи `Подзадача` привязана минимум одна `Стори` / `Рефакторинг`
   * Декомпозиция на `Стори` была проведена совместно с командой разработки или с СТО

   Планирование состоит из двух встреч:

   1. ***Предпланирование*** – встреча, на которой владельцы Эпиков (РО и/или СТО) рассказывают стейкхолдерам (Заказчикам) и представителям команд разработки о том, что они ожидают реализовать в предстоящем квартале.\
      В ходе предпланирования Эпики обсуждаются, фиксируются уточняющие вопросы и комментарии для проработки (например зависимости / недостаточная декомпозиция и т.д.). Участники расходятся на неделю для финализации состава работ следующего квартала.
   2. ***Планирование*** – повторная встреча, на которой фиксируется итоговый состав работ и проставляется итерация выполнения (квартал). Итерация может не быть ближайшей, если работы займут продолжительное время. Таким образом формируются ожидания стейкхолдеров.

      Результат встречи по планированию:

      * Эпики переведены в статус `Готово к разработке`
      * У каждого Эпика проставлена итерация, в которую он будет готов (то есть будет соответствовать критериям приемки)
4. **Готово к разработке** – очередь Эпиков, по которым определены договоренности → запланированы в определенную итерацию
5. **В работе** – как только первые подзадачи от Эпика попадают в работу у команды, Эпик переходит в статус `В работе` и находится в нем до момента выпуска в продакшн всех его `Стори`. `Стори` прорабатываются и поступают в разработку по мере готовности бизнес-требований и макетов (где это требуется в явном виде) через встречи по пополнению .
6. **Выпущено** – Эпики, работы по которым завершены, выпущены в продакшн и приняты со стороны владельца Эпика.
7. **Отменено** – Эпики, которые по тем или иным причинам было решено не делать.

#### Еженедельная синхронизация

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

В процессе работы над Эпиком состав его подзадач (`Стори` / `Рефакторинг`) может поменяться.

Примеры:

* Найдена более логичная декомпозиция без изменения объема работы
* Что-то не было учтено, и состав работ меняется с потенциальным влиянием на Итерацию

*Эти изменения также важно подсвечивать на регулярных встречах.*