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

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

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

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

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

2. Валидация – за счет встреч по планированию в явном виде фиксируются цели на ближайший квартал, что дает уверенность, что время разработки инвестируется наилучшим образом

3. Визуализация – для всех заинтересованных лиц и стейкхолдеров в явном виде и в одном месте представлена бизнес-ценность, которая находится в работе

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

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

2. Стейкхолдеры – являются заказчиками Эпиков, участвуют во встречах по планированию и убеждаются, что их ожидания совпадают с заявленными целями и визуализацией работы

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

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

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

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

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

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

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

3. Планирование – итоговый этап определения состава работ в следующем квартале.

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

   • Эпик находится в статусе Планирование

   • Карточка Эпика заполнена по шаблону

   • Эпик обсуждался с представителями команды разработки, команда подтвердила, что это технически реализуемо

   • К эпику с типом связи Подзадача привязана минимум одна Стори / Рефакторинг

   • Декомпозиция на Стори была проведена совместно с командой разработки или с СТО

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

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

   2. Планирование – повторная встреча, на которой фиксируется итоговый состав работ и проставляется итерация выполнения (квартал). Итерация может не быть ближайшей, если работы займут продолжительное время. Таким образом формируются ожидания стейкхолдеров.

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

      • Эпики переведены в статус Готово к разработке

      • У каждого Эпика проставлена итерация, в которую он будет готов (то есть будет соответствовать критериям приемки)

4. Готово к разработке – очередь Эпиков, по которым определены договоренности → запланированы в определенную итерацию

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

6. Выпущено – Эпики, работы по которым завершены, выпущены в продакшн и приняты со стороны владельца Эпика.

7. Отменено – Эпики, которые по тем или иным причинам было решено не делать.

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

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

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

Примеры:

• Найдена более логичная декомпозиция без изменения объема работы

• Что-то не было учтено, и состав работ меняется с потенциальным влиянием на Итерацию

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