Спикер: Евгений Степченко — Delivery Manager в Т-банке.
Введение
В докладе рассматривается практический опыт масштабирования Kanban-системы на реальном проекте, а также то, как использование различных уровней масштабирования влияет на прозрачность процессов, взаимодействие между командами и получение ценности.
Спикер делится собственным опытом, накопленным как в Т-банке, так и на предыдущей работе, где внедрение Kanban происходило в условиях роста, усложнения разработки и увеличения количества участников процесса.
Контекст проекта
В 2016 году команда спикера работала в аутсорсинговой компании. Новый клиент пришёл с минимальными требованиями и задачей создать сервис доставки в
Афганистане, включающий доставку такси, еды, покупок и передачу заказов.
Контекст проекта:
- отсутствовал опыт взаимодействия с заказчиком;
- требования не были полноценно сформулированы;
- клиент хотел быстрый прототип.
Было принято решение работать совместно три месяца, чтобы получить прототип будущего продукта.
Проектная структура включала:
- заказчика.
- backend, web UI и инфраструктуру в одной команде;
- отдельную мобильную команду;
- отдельную команду приёмочного тестирования.
Спикер отвечал лишь за одну часть цепочки, используя элементы Kanban: доску, дневные встречи, ограничение незавершённой работы.
Первый этап и первые изменения
Команда успешно создала рабочий прототип, после чего проект продолжился с целью вывести продукт на реальных пользователей.
Клиент начал активно расширять функциональность и увеличивать состав команд. В этот момент управление стало сложнее, и было принято решение разделить команду на две.
Ошибочным шагом оказалось разделение по компонентам — фронтенд и бэкенд, что привело к отсутствию сквозных поставок и типичным проблемам:
- функциональность нельзя пощупать целиком;
- появляются зависимости;
- сроки непонятны.
Переход к кросс-функциональным командам
После неудовлетворенного заказчика команда была переформирована в две кросс-функциональные, при этом сохранен общий бэклог. Это дало:
- прозрачность поставок;
- взаимозаменяемость;
- повышение ответственности;
- единый взгляд на продукт.
Одним из важных эффектов стало то, что Kanban начал распространяться на соседние команды сам по себе. Спикер отмечает, что многие команды внедряли Kanban не под давлением, а вследствие наблюдения пользы в работе других.
Хочешь разобраться, что тебе даст Канбан?
Выбери, что ближе твоему запросу — и получи 🎁 подарок
Этот шаг стал примером масштабирования в глубину — когда практики распространяются на сервисы и команды, связанные с основной областью разработки.
Появление новых ограничений и масштабирование в ширину
Следующим этапом стало столкновение с новой проблемой — отсутствием прозрачности после передачи задачи в приёмочное тестирование, которое выполняла сторонняя компания.
Команда не понимала:
-
когда будет проверена задача;
- какие задачи в очереди;
- что блокирует релиз.
Чтобы повысить прозрачность, на Kanban-доску были добавлены статусы, относящиеся к тестированию, и стала видна реальная динамика.
Со временем тестировщики также начали работать по Kanban, что стало примером масштабирования в ширину — на соседние этапы потока разработки.
Усложнение коммуникаций и инженерные практики
По мере увеличения количества команд возникла сложность координации. Появилась инициатива регулярных инженерных встреч, где команды договаривались о технологических подходах, лучших решениях и общих правилах разработки.
Результат:
- инженерные практики стали едиными;
- появился backlog инженерных улучшений;
- снизилось количество разрозненных решений.
Масштабирование в высоту
Следующий шаг — создание общей продуктовой Kanban-системы, охватывающей весь поток: от формулировки требований до вывода в продакшн.
Новая ролевая структура, появление сервис-delivery менеджера и регулярная координация позволили сделать весь процесс прозрачным на уровне продукта, а не отдельных команд.
Ключевые результаты внедрения
Использование трёх уровней масштабирования позволило достичь:
- прозрачности поставки.
- ускорения выхода функциональности;
- гибкости при изменениях;
- сквозной координации;
- улучшения взаимодействия команд;
- роста продукта и команды.
Проект продолжил существовать, приобрёл реальную аудиторию и стал коммерчески успешным.
Выводы спикера
Евгений Степченко выделяет несколько ключевых уроков:
- масштабирование Kanban — эволюционное развитие, а не заранее спроектированная конструкция;
- начинать нужно с локальной области, не масштабируя всё сразу;
- распространение происходит естественно, когда появляется ценность;
- наличие управленческого владельца — критически важный фактор;
- инженерные практики и DevOps необходимы для быстрой поставки;
- кризисы и сложности — повод для улучшений.