«Три карандаша» — авторский метод груминга и декомпозиции, который спас мою команду от хаоса и провала сроков

TechLead

Доклад принят в программу конференции

Мнение Программного комитета о докладе

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

Целевая аудитория

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

Тезисы

Тимлиды и команды часто сталкиваются с перегрузкой, хаосом в спринтах и невозможностью нормально планировать. Все вокруг говорят о каком-то потоке или процессе, но откуда их взять и с чего начать строить?

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

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

Декомпозиция — на удивление больная тема для большинства команд, а ведь от нее зависит адекватность оценок, правильный порядок выпуска функционала, сама возможность выпуска MVP и запуска инкрементального производства. Распределение ролей, velocity, capacity, предсказуемость и прочее бинго.

Команды часто перегружаются из-за плохой структуры задач, особенно когда тимлид не участвует в формировании задач или делает это «на глазок», и как результат — страдает бизнес, получающий не то, не тогда и не в том качестве. И это не делает жизнь тимлида и команды счастливой.

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

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

Канвас груминга — лист бумаги, разделенный по вертикали на три области:
* чужой бэк (внешние зависимости),
* фронт или бизнес-логика;
* Наш бэк.

Три принципа груминга:
* трехзвенная архитектура;
* принцип работы пользовательского интерфейса;
* и, собственно, сами «Три карандаша».

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

Что мы с вами обсудим еще:
* почему «Три карандаша» занял свое место в разработке и стал основой для разработки на большом предприятии;
* как он решает проблемы разработчиков, согласования требований между командами, стримами, департаментами;
* как он помогает решать проблему онбординга новых разработчиков в команду;
* где в «Трёх карандашах» место старым добрым и хорошо проверенным User Story Mapping, Customer Journey Mapping, Gherkin, INVEST, story slicing.

Рустем Файзуллин

Газпромбанк

26 лет в IT. 16 лет занимался разработкой системного программного обеспечения для Z/OS IBM Mainframe. 10 лет разрабатывал системы поддержки принятия решений и предикативного анализа на базе SAS Systems. Проработал во всех ролях от джуна до техлида, менеджера проектов до Agile-коуча. Сейчас работает Agile-коучем в Газпромбанке.

Видео

Другие доклады секции

TechLead