Как мы применили Скрамбан и остались довольны: Кейс Инферит Клаудмастер
Привет, с вами команда “Инферит Клаудмастер”. Сегодня мы хотим рассказать вам о нашем опыте практического применения Канбан-метода в разработке. Для этого мы пообщались с Лилей Ермаковой, Service Delivery Manager, которая своими руками лидировала внедрение нового процесса. Несколько дисклеймеров: Мы все еще продолжаем наш путь в Скрамбан и не претендуем на завершенный и идеальный результат. Мой рассказ в основном прикладной, поэтому Закон Литла, формулы и большую науку я затрагивать не буду. В конце статьи размещу ссылки, на ресурсы, наполненные хардкор статистикой и аналитикой. Канбан, как замечают коллеги, — очень перегруженное слово. Задам координаты теории, на которую я ориентируюсь, — это материалы Канбан Университета и ProKanban.org . Исходная ситуация Мы одновременно тестировали две продуктовые гипотезы. Как иллюстрация к закону Конвея, у нас выросли две кросс-функциональные команды с разными культурами и практиками. В каждую команду включены бэкендеры, фронты, дизайнеры и тестировщики. Отдельно команды сопровождали системные инженеры, а также команды развития бизнеса и маркетинга. Модули продукта завязаны на общие компоненты, при этом имеют собственную специфику и область применения: один модуль для аналитики, другой для автоматизации инфраструктуры. Из этого вытекало два следствия: взаимозависимость работ в командах и специализация команд на задачах с разной спецификой. Как был организован процесс? У каждой команды своя культура, правила, длина спринта и свой продакт. Посередине — человек, который все объединяет в одно — Technical Product Owner. Если вы скажете, agile солянка, то будете правы. Релизы получалось делать раз в месяц (в лучшем случае). Помимо разработки, необходимо было объединить результат обеих команд и провести общее регрессионное тестирование.
https://habr.com/ru/companies/inferit/articles/839202/
#kanban #agile #scrum #процессы #построение_процесса #практические_советы #кейс #как_это_работает