Тимлиды и команды часто сталкиваются с перегрузкой, хаосом в спринтах и невозможностью нормально планировать. Все вокруг говорят о каком-то потоке или процессе, но откуда их взять и с чего начать строить?
Я покажу вам собственный, авторский метод декомпозиции, который я разработал в боевых условиях: без лишней теории, но с реальными результатами — сокращение времени на delivery, повышение предсказуемости, снижение переработок. Доклад подойдет тем, кто хочет навести порядок в команде, но уже устал от книжных рекомендаций. Будут реальные кейсы, примеры шаблонов и честные фейлы. Все можно применить сразу на следующем планировании.
Почему этот доклад важен именно сейчас.
Все устали от поверхностных гайдов. Я дам вам свою методику, отработанную на реальных проектах в двух крупнейших банках нашей страны. В первом метод родился, во втором стал локомотивом построения того, что называют управляемым потоком ценности.
Декомпозиция — на удивление больная тема для большинства команд, а ведь от нее зависит адекватность оценок, правильный порядок выпуска функционала, сама возможность выпуска MVP и запуска инкрементального производства. Распределение ролей, velocity, capacity, предсказуемость и прочее бинго.
Команды часто перегружаются из-за плохой структуры задач, особенно когда тимлид не участвует в формировании задач или делает это «на глазок», и как результат — страдает бизнес, получающий не то, не тогда и не в том качестве. И это не делает жизнь тимлида и команды счастливой.
Чего достигли наши команды благодаря «Трём карандашам»:
* сокращение ТТМ по бизнес-эпикам с 9 до 1,5 месяцев;
* точность оценки достигла требуемых 85-90% гарантии поставки;
* у команд появился ритм;
* удовлетворенность участников команд поднялась на 25% (по результатам исследования CSI);
* удовлетворенность бизнеса поднялась на 43% (по результатам исследования CSI).
Про метод.
Я его создавал, как инженер для инженеров — просто и наглядно. На самых минималках вам потребуется лист бумаги и три карандаша: синий, зеленый и красный. Конечно, со временем метод обрел структуру, ритуал и теорию, но под ними та же простая инженерная база, что и в день рождения метода.
Канвас груминга — лист бумаги, разделенный по вертикали на три области:
* чужой бэк (внешние зависимости),
* фронт или бизнес-логика;
* Наш бэк.
Три принципа груминга:
* трехзвенная архитектура;
* принцип работы пользовательского интерфейса;
* и, собственно, сами «Три карандаша».
Вы слушаете мой доклад и на следующий день вносите «Три карандаша» в свою команду как есть. Команда осваивает метод и затем адаптирует его под себя и особенности своего процесса: продуктовой, проектной, поддерживающей, платформенный и т. д.
Что мы с вами обсудим еще:
* почему «Три карандаша» занял свое место в разработке и стал основой для разработки на большом предприятии;
* как он решает проблемы разработчиков, согласования требований между командами, стримами, департаментами;
* как он помогает решать проблему онбординга новых разработчиков в команду;
* где в «Трёх карандашах» место старым добрым и хорошо проверенным User Story Mapping, Customer Journey Mapping, Gherkin, INVEST, story slicing.