Кейс применения Канбана в интернет-банке Альфа-Клик

0
(0)

Друзья, всем привет!

Сегодня я расскажу историю, как я использовал Канбан-метод, когда работал Скрам-мастером в Альфа-Лаборатории Альфа-банка. Это был мой второй опыт применения Канбана в работе.

Дело было в далеком 2016-м. Я тогда только-только познакомился с Agile, Скрамом и Канбаном и активно экспериментировал, где только можно.

В Альфа-Лабораторию я пришел в команду Альфа-Клика – интернет-банк Альфа-Банка. У нас в команде было 10 человек: 2 аналитика, 3 разработчика, 4 тестировщика и 1 релиз-менеджер. Это не считая владельца продукта. Команда была сложившаяся и на мою удачу уже использовала Канбан-метод для управления разработкой.

Изначально, когда я только пришел, Канбан-доска и карточки выглядела следующим образом:

Не смотря на всё это «несовершенство» (по моему мнению) Канбана, разработка велась, релизы катились, стейкхолдеры были довольны. То есть Канбан работал и приносил пользу бизнесу, но мне тогда всё казалось несовершенным.

Засучив рукава, я взялся за работу, но тут же столкнулся с первой «трудностью» – у команды всё было хорошо. Как внедрять изменения, если тебе говорят: «У нас всё нормально!»?

Я тогда совсем ничего не знал о кейсах применения Канбана, потому что их на английском-то было мало, не говоря уже о русско-язычном сообществе.

Поэтому пришлось действовать наугад. Не смотря на то, что мы использовали Канбан, мы также пользовались скрамовскими практиками. В частности я ввел регулярные ретроспективы. И именно благодаря им команда получила возможность рассказать, что на самом деле «не всё так хорошо».

Вскоре выяснилось, что у команды были следующие боли:

  1. Коммуникационные внутри команды.
  2. “Старое” наследие.
  3. Отсутствие обратной связи.
  4. Проблемы с бэклогом.
  5. Отсутствие предсказуемости.

Боли плохой коммуникации

  1. Отсутствие качественной связи с удаленным членами команды.
  2. Потеря информации при передаче.
  3. На этапе регресс. тестов задачи возвращаются с “псевдо-багами”.
  4. Отсутствие чувства единства в команде.

Как лечили:

  1. Создали группу для e-mail рассылки.
  2. Создали группу в мессенджере.
  3. Создали шаблон заведения дефектов.
  4. Договорились описывать задачи в Jira.
  5. Договорились о процессе передачи информации.

Боли “старого” наследия

  1. Неаккуратная канбан-система.
  2. Много лишней и неактуальной информации.
  3. Неактуальные статусы.
  4. Хаос и неразбериха.
  5. Единый воркфлоу для канбан-систем всех команд.
  6. Отсутствие синхронизации между живой и электронной досками.

Как лечили:

  1. Договорились с командой убрать все лишние карточки с доски.
  2. Договорились убрать неактуальные статусы.
  3. Договорились обновить физическую доску.
  4. Договорились разделиться с другими канбан-командами.
  5. Один человек синхронизирует обе доски.

Боли обратной связи

  1. Задачи попадают в систему в случайном порядке.
  2. Откат из продакшн из-за несогласованности действий с другими подразделениями.
  3. Отсутствие вектора развития.

Как лечили:

  1. Договорились о регулярной встречи с владельцем продукта по наполнению канбан-системы.
  2. Стали заранее уведомлять команды и Заказчиков о планировании внедрений.
  3. Стали регулярно проводить ретроспективы команды.

Боли бэклога

  1. Задачи не доходят до бэклога.
  2. Владелец продукта не знает, как приоретизировать задачи в бэклоге.
  3. Владелец продукта подключает одного аналитика для оценки задач в бэклоге.
  4. У команды нет простого понимания, что делать дальше.

Как лечили:

  1. Договорились с владельцем продукта представить бэклог в удобном для всех формате.
  2. Договорились с командой прорабатывать задачи в бэклоге (PBR).

Боли непредсказуемости

  1. Очень старые задач в системе.
  2. Экспертная оценка задач одним аналитиком.
  3. Не можем ответить P.O., когда задача будет готова.
  4. Многозадачность у членов команды. Стрессы и напряжение.
  5. Большое количество багов на регрессах.
  6. Множественные перепоставки.

Как лечили:

  1. Синхронизировали информацию на досках.
  2. Изменили дизайн карточек.
  3. Выгрузили статистику.
  4. Дали SLA владельцу продукта по готовности задачи.
  5. Стали использовать WIP лимиты.
  6. Стали смотреть на метрики, принимать осознанные решения по наполнению системы.

Результат

Время производства сократилось с 40 дней до 18 дней с вероятностью 95%.

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

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

Stay tuned!

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Сожалеем, что вы поставили низкую оценку!

Позвольте нам стать лучше!

Расскажите, как нам стать лучше?

1 thought on “Кейс применения Канбана в интернет-банке Альфа-Клик

Comments are closed.

Индекс лояльности клиентов

Пожалуйста, оцените по шкале от 0 до 10 вероятность, что вы порекомендуете нас другу или коллеге?

Baши пpeдлoжeния пo улучшeнию кaчecтвa нaшeй paбoтыЧто нам нужно улучшить в нашей работе, чтобы вы могли оценить нас 10?
Извините! Вы уже проходили голосование. Если вы забыли дополнить свой отзыв, напишите нам через обратную связь.

Задайте мне вопрос

Спросите меня, если не нашли ответ на сайте

Мы используем cookie-файлы. Оставаясь на сайте, вы соглашаетесь с политикой конфиденциальности.
Хорошо