Тимлиды и команды часто сталкиваются с перегрузкой, хаосом в спринтах и невозможностью нормально планировать. Все вокруг говорят о каком-то потоке или процессе, но откуда их взять и с чего начать строить? Я покажу вам собственный, авторский метод декомпозиции, который я разработал в боевых условиях: без лишней теории, но с реальными результатами — сокращение времени на delivery, повышение предсказуемости, снижение переработок. Доклад подойдёт тем, кто хочет навести порядок в команде, но уже устал от книжных рекомендаций.
Будут реальные кейсы, примеры шаблонов и честные фейлы. Всё можно применить сразу на следующем планировании.

Почему этот доклад важен именно сейчас:
Все устали от поверхностных гайдов. Я дам вам свою методику, отработанную на реальных проектах в двух крупнейших банках нашей страны. В первом метод родился, во втором стал локомотивом построения того, что называют управляемый поток ценности.
Декомпозиция — на удивление, больная тема для большинства команд, а ведь от нее зависит адекватность оценок, правильный порядок выпуска функционала, сама возможность выпуска MVP и запуска инкрементального производства. Распределение ролей, velocity, capacity, предсказуемость и прочее бинго.
Команды часто перегружаются из-за плохой структуры задач, особенно когда тимлид не участвует в формировании задач или делает это «на глазок», а как результат страдает бизнес, получающий не то, не тогда и не в том качестве. И это не делает жизнь Тимлида и команды счастливой.

Для кого:
Тимлиды, которые отвечают за результат и страдают от невозможности добиться от команды нормального прогноза по поставке. Для команд, тонущих в интеграционных релизах, постоянных переделках функционала по замечаниям бизнеса.
Скрам-мастера и техлиды, которые ищут структуру и примеры для выстраивания производственного процесса.

Чего достигли наши команды благодаря "Трём карандашам":
Сокращение ТТМ по бизнес эпикам с 9 до 1,5 месяцев
Точность оценки достигла требуемых 85-90% гарантии поставки.
У команд появился ритм.
Удовлетворённость участников команд поднялась на 25% (по результатам исследования CSI)
Удовлетворённость бизнеса поднялась на 43% (по результатам исследования CSI)

Про метод.
Я его создавал, как инженер для инженеров - просто и наглядно. На самых минималках вам потребуется лист бумаги и три карандаша: синий, зелёный и красный. Конечно, со временем метод обрел структуру, ритуал и теорию, но под ними таже простая инженерная база, что и в день рождения метода:
Канвас груминга - лист бумаги, разделенный по вертикали на три области:
- Чужой бэк (внешние зависимости)
- Фронт или бизнес-логика
- Наш бэк
Три принципа груминга:
- Трёхзвенная архитектура
- Принцип работы пользовательского интерфейса
- и собственно, сами "Три карандаша"

Вы слушаете мой доклад и на следующий день вносите “Три карандаша” в свою команду как есть. Команда осваивает метод,и затем адаптирует его под себя и особенности своего процесса: продуктовой, проектной, поддерживающей, платформенный и т.д.

Что мы с вами обсудим ещё:
- Почему “Три карандаша” занял своё место в разработке и стал основой для разработки на большом предприятии?
- Как он решает проблемы кроссфункциональности разработчиков, согласования требований между командами, стримами, департаментами?
Как он помогает решать проблему онбординга новых разработчиков в команду?
- Где в “Трёх карандашах” место старым добрым и хорошо проверенным User Story Mapping, Customer Journey Mapping, Gherkin, INVEST, story slicing?