Квартальное планирование подразделения из 10 команд

Чтобы не было споров в ключе “А где же здесь Agile?”, задаю контекст:

1. Команды фиксированные, постоянные, кросс-функциональные, ~по 10 человек.
2. Подразделение ~10–20 команд.
3. Подразделения почти продуктовые — ещё есть каналы, и с их разработчиками нужно договариваться.
4. Для реализации чего-то ценного нужно заранее договориться со многим смежными подразделениями (читайте о том, как договориться уже во время реализации).
5. Есть вводные с уровня выше (портфельного), но основная часть задач генерируется командами.

Хотим получить

План задач на квартал или год, упорядоченных на основе их ценности и сложности.

Эпики, фичи, истории @ портфель, программа, команда

Чтобы не изобретать велик, возьмём картинки из SAFe, однако описанный далее процесс планирования ≠ SAFe PI Planning.

Из первой картинки нам важно, что эпики могут прийти с уровня портфеля. Эпики разделят на фичи, а фичи попадут в бэклоги программ (программа — команда команд). Синие – бизнесовые, бордовые – технические.

Далее фичи будут разделены на истории, а истории попадут в бэклоги команд.

Сколько эпик, фич, историй получится на год?

Чёткого правила нет, однако давайте выведем чисто из головы число для примерного представления.

Для подразделения из 10 команд и релизного цикла 1,5 месяца на квартал:

• эпики 2–5 на квартал,
• фичи по 2–5 для каждого эпика,
• истории по 2–5 для каждой фичи.

Далее планирование будет проводиться на уровне фич.

Участники планирования на уровне подразделения

1. Руководители и эксперты подразделения: бизнес, ИТ, архитектура
2. Руководители команд: бизнес, ИТ
3. Любые другие участники, представители команд, заказчиков

Процедура планирования квартала

1. Разместить в общем доступе в одном хранилище существующую инфо, полезную для планирования: предварительные планы команд; цели подразделения и с уровня +1; стандарты, регламенты, требования к качеству; обязательства перед заказчиками и смежниками, обещания; архитектурные задачи.
2. Ознакомиться с методикой оценки фич WSJF. Самостоятельно подумать и предложить, по каким критериям будут оцениваться фичи, каким будет формат бэклога. (Примеры критериев см. в следующем §.)
3. Выбрать, в каком инструменте будет “бэклог для планирования на год”, например, Google.Spreadsheets.
4. Организовать встречу для обсуждения п.2–3. Итог: согласованные критерии оценки и формат бэклога.
5. Затем одна желающая команда уходит с ДЗ: “Заполнить только что созданный шаблон годового плана своими задачами”. Если времени на проверку шаблона нет, то goto п.7.
6. Организовать встречу с представителями первой команды, чтобы посмотреть, что получилось, и обсудить, насколько полезны выбранные в п.4 критерии и удобен формат. И доработать их, если нужно.
7. Если п.5 выполнила только одна команда, то теперь ДЗ выполняют остальные команды до установленного срока.
8. При наступлении срока команды самостоятельно изучают годовой план всего подразделения – соседних команд, особое внимание уделяя взаимосвязям и зависимостям.
9. Организовать встречу представителей всех команд для обсуждения получившегося плана подразделения.
10. При необходимости заочно доработать план и встретиться ещё раз.

Примеры критериев

Ниже перечислены возможные примеры для понимания формата. Пунктов слишком много, некоторые пересекаются. Вы можете предложить любые другие критерии и единицы измерения. Желательно выбрать или сформулировать ≤5 критериев оценки, а иначе просто будет слишком трудно для выскоуровневого планирования.

1. Бизнес-ценность, вес 1..10 или Фибоначчи (можно разделить на несколько)
2. Уверенность в бизнес-ценности, коэффициент 0..1
3. Риски бизнес, вес 1..10 или Фибоначчи
4. Риски ИТ, вес 1..10
5. Риски политическтие, вес 1..10
6. Сложность реализации, вес 1..10 или Фибоначчи
7. Сложность интеграции, вес 1..10
8. Длительность наша, спринтов, Min (для упрощения считаем, что максимально фокусируемся на одной бизнес-задаче/истории в спринте и делаем всё возможное для её реализации и доведения до Definition of Done)
9. Длительность наша, спринтов, Max
10. Длительность смежников, спринтов, Min (наша оценка того, сколько спринтов займёт задача до DoD)
11. Длительность смежников, спринтов, Max
12. Жёсткие даты: праздники, запланированные кампании, deadlines
13. Зависимости

Другие статьи о встречах Agile-команды

1. Safety check — проверка безопасности перед встречей
2. Как оживить ретроспективу?
3. Когда какую ретро проводить?
4. Ретро: Онлайн-доски для ретроспективы
5. Ретро: Формат сбора мнений Mad-Sad-Glad
6. Ретро: Что такое ретроспектива, зачем нужна и как проводить
7. Ретро: Как провести ретроспективу (видео)
8. Ретро: На каких темах фокусироваться
9. Игра: Rory cubes — Кубики Рори
10. Почему 3-й вопрос Daily/StandUp такой важный или видео
11. Daily Scrum / Stand-up meeting vs Status meeting — what’s the difference?