Как мы применили Скрамбан и остались довольны: Кейс Инферит Клаудмастер

Привет, с вами команда “Инферит Клаудмастер”. Сегодня мы хотим рассказать вам о нашем опыте практического применения Канбан-метода в разработке. Для этого мы пообщались с Лилей Ермаковой, Service Delivery Manager, которая своими руками лидировала внедрение нового процесса.  

Несколько дисклеймеров:  

Мы все еще продолжаем наш путь в Скрамбан и не претендуем на завершенный и идеальный результат. 

Мой рассказ в основном прикладной, поэтому Закон Литла, формулы и большую науку я затрагивать не буду. В конце статьи размещу ссылки, на ресурсы, наполненные хардкор статистикой и аналитикой. 

Канбан, как замечают коллеги, — очень перегруженное слово. Задам координаты теории, на которую я ориентируюсь, — это материалы Канбан Университета и ProKanban.org. 

Исходная ситуация 

Мы одновременно тестировали две продуктовые гипотезы. Как иллюстрация к закону Конвея, у нас выросли две кросс-функциональные команды с разными культурами и практиками. В каждую команду включены бэкендеры, фронты, дизайнеры и тестировщики. Отдельно команды сопровождали системные инженеры, а также команды развития бизнеса и маркетинга.  

Модули продукта завязаны на общие компоненты, при этом имеют собственную специфику и область применения: один модуль для аналитики, другой для автоматизации инфраструктуры.  

Из этого вытекало два следствия: взаимозависимость работ в командах и специализация команд на задачах с разной спецификой.  

Как был организован процесс? 

У каждой команды своя культура, правила, длина спринта и свой продакт. Посередине — человек, который все объединяет в одно — Technical Product Owner. Если вы скажете, agile солянка, то будете правы.  Релизы получалось делать раз в месяц (в лучшем случае). Помимо разработки, необходимо было объединить результат обеих команд и провести общее регрессионное тестирование.  

Какую проблему мы решали? 

Наша главная боль была в сложности предсказать дату выхода наших релизов. Даты постоянно “плавали” на +/- 5 дней и более. Релизы в какой-то момент занимали около 35 календарных дней. Значительную часть этого времени мы тратили на ожидание готовности задач и устранение регресса. 

Как мы искали решение? 

С миру по нитке каждый член нашей команды привносил свой опыт работы с фреймворками и подходами. Много времени мы провели в обсуждениях, как правильно и как неправильно. Каждый реализовывал agile принципы в меру своего понимания и владения инструментами, но общей картинки у нас не было. 

Итак, мы выбрали Канбан 

В ходе обсуждений мы пришли к идее, что с решением проблемы нам сможет помочь Kanban-метод по следующим причинам:  

1. Прогноз длительности выполнения работ на основе статистики, а не субъективных ощущений 

2. Первые шаги не требуют новых ролей или инструментов 

3. В метод не требуется верить, он просто работает 

4. Принципы Канбан просты и лаконичны (меньше усилий на обучение) 

5. И последнее, но не по значимости - ориентированность на создание ценности и результата. 

Дальше пришлось ломать мифы в своей голове: 

1. Всем все видно vs доски в Jira 

“Не знаю сколько это займет, это задача на несколько спринтов, я в фоне поделаю”. Основной принцип, который моментально приносит результат: всю работу в направлении доставки ценности клиенту должно быть видно.  

Всю — значит совсем всю