Канбан на двадцать семь человек. История одного провала

Часть 1. С чего всего началось

Всем привет!

По ходу я налажал с канбаном в большой команде. Хочу рассказать эту историю и спросить вашего совета.

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

Сегодня это:

  • 8 человек в дискавери (бизнес-команда);
  • 17 человек в деливери;
    • 8 разработчиков;
    • 4 аналитика;
    • 3 тестировщика;
    • 2 девопсера;
  • 2 мастера потока.

В команду входят все необходимые люди для реализации полного процесса оказания услуги клиентам банка за исключением трех сервисных команд: 1) верстальщика, 2) бэкендеров и 3) поддержки 24х7.

Когда я пришёл в команду, расстановка сил была следующей:

  • 14 человек в команде разработки:
    • 8 разработчиков,
    • 1 тестировщик,
    • 3 аналитика,
    • 2 девопсера.
  • 7 человек в бизнес-команде.

Ребята использовали скрам-фреймворк. В скрам-команду входили разработчики и тестировщики. Аналитики были выше по течению и не участвовали в наполнении спринта и работе над задачами спринта. Девопс был ниже по течению и тоже не участвовал в работе над задачами спринта. В итоге было не ясно, что именно делают аналитики, как протекает регресс инкремента и его установка в прод. Из-за этого тестировщикам приходилось разрываться между тестированием задач в спринте и регрессом инкремента. А аналитики хотели себе отдельный спринт выше по течению, чтобы также набирать задачи на спринт и готовить фиксированный пул работ для разработчиков, а не переключаться по задачам, как штекер телефонистки времен Белла вечером в выходной день. Вдобавок увеличившийся размер команды ухудшил скорость коммуникаций. Каждая встреча большой толпой превращалась в пытку и скуку для половины участников.

До моего прихода у ребят было заготовлено решение. Они собирались разделиться на две скрам-команды и тем самым устранить проблемы с коммуникациями. Собственно, за этим отчасти нас со вторым скрам-мастером и наняли. Планировалось два скрам-мастера и две скрам-команды.

Когда я провел аудит процессов, то предположил, что использование канбан-метода больше подойдет для решения сложившихся проблем. Гипотеза заключалось в том, что:

  • с канбан-методом на 20+ человек у нас получится работать более слаженно, прозрачно, снизить нагрузку на команду (исключить переработки);
  • бизнес получит понимание, над чем работаем сейчас и на чем сфокусироваться дальше, сможет абсолютно легально наполнять очередь новыми задачами, не дожидаясь окончания спринта;
  • канбан-метод повысит гибкость и предсказуемость работы команды.
  • канбан-метод более экономичен с точки зрения встреч. Я подсчитал затраты на встречи в двух скрам-командах и в одной команде, использующей канбан-метод. Соотношение получилось примерно одиннадцать против четырех (речь о количестве уникальных встреч).

В итоге я принял решение перевести команду на канбан-метод, и постепенно мы это сделали.

Здесь произошел самый эпичный обсёр. Я принял решение за команду, даже не проконсультировавшись с ними.

UPD. В последствии, восстанавливая последовательность шагов, я точно вспомнил, что консультация была: и с руководителем, и с командой. Ошибка оказалась в другом.

Часть 2. Переход со Скрам-фреймворка к использованию Канбана

S.T.A.T.I.K. Сначала оффлайн-визуализация

Переход на канбан-метод начался с визуализации общего процесса работы. На большой доске я, начиная с конца, нарисовал последовательность действий по одной из фич. Что мы сделали, чтобы довести ее до прода? В решении этой задачи я использовал элементы воркшопа S.T.A.T.I.K. Нарисовав процесс, я позвал команду, чтобы она посмотрела на результат и накидала обратной связи. С учетом этих замечаний я двинулся дальше – в Jira.

Jira. Переходим к онлайн-визуализации

Парень, который был в команде скрам-мастером до меня и который с моим приходом вернулся в лоно разработки, уже запустил этот процесс, ранее создав доску в Jira. Там не хватало только стадии с регрессом и установкой в прод. Все это мы выявили на предыдущем шаге. Из-за этого было не видно, что происходит с задачами после закрытия. Дополнив процесс недостающей стадией, я понял, что ошибся, развивая текущий рабочий поток (workflow). Стадий стало слишком много. Мы пожили пару недель с этим, я увидел, сколько путаницы появилось в команде вместо желаемого облегчения, и создал новый рабочий поток с нуля.

Рис 1. Новый рабочий поток с нуля.

На доске это выглядело следующим образом:

Рис. 2. Доска с общим процессом.

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

Рис. 3. Доска аналитиков.
Рис. 4. Доска разработчиков.
Рис. 5. Доска тестировщиков.

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

Рис. 6. Доска эпиков.

Таким образом, у нас выстроилась иерархия канбан-досок:

  1. Доска с эпиками – крупные проекты с длительностью до трех месяцев.
  2. Общая доска со всеми задачами – детализация по эпикам в работе. Главная задача – понять, что мы держим в фокусе, над каким проектом работаем сейчас и что нам нужно сделать, чтобы выпустить следующий релиз в желаемый срок.
  3. Доска с задачами для стадий – рабочий инструмент для ежедневных задач.
Итоговый результат я показал Заказчику и команде. Заказчик остался доволен. У команды были вопросы, но по большей части нововведения она приняла молча.

Обучение команды и отказ от оценки

Одним из ключевых решений было обучение. Мы провели следующие воркшопы с командой:
  1. Карпаччо из слона. Цель: нарезка мелких пользовательских историй.
  2. Карта пользовательских историй. Цель: декомпозиция эпиков на завершенные пользовательские истории и элементы.
  3. getKanban. Цель: использование шести практик канбана в работе команды.
Все это в совокупности позволило нам уйти от такого ритуала, как грумминг или оценка задач. У команды уже давно было ощущение, что такие встречи – это время на ветер. Мы решили это проверить, убрав встречу, но договорившись (опять же в качестве эксперимента), что аналитики перед передачей задачи в очередь на разработку будут очно обсуждать задачу с разработчиком.

WIP-лимиты или ограничение незавершенной работы

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

Самая профитная вещь

Самым профитным, самым инсайтным решением для меня стало введение каденции по планированию поставки. Из-за того, что у нас нет явно выделенной роли релиз-менеджера, с релизами всё проходит очень больно. Ситуация очень сильно осложняется, если на наш релиз накладывается релиз обще-банковский или задача требует интеграционного тестирования с другими системами. Самым правильным решением на мой взгляд было бы введение в команде явной роли релиз-менеджера (в качестве эксперимента в течение месяца эту роль выполнял я), однако за неимением оного работаем с тем, что есть.

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

Для релизов мы пользуемся вкладкой Release в Jira. Создаем новую версию на этой вкладке, ставим номер инкремента и проставляем название версии с инкрементом в задачах, которые пойдут в релиз. Как правило, в ближайший релиз попадают задачи из стадий “Тестирование готово”, “Тестирование в работе”, “Разработка готова” или “Разработка в работе”. Мы договорились ограничить количество элементов в релизе. Сейчас это ограничение равняется десяти элементам. У нас есть гипотеза, что маленькое количество элементов в релизе позволит нам проводить регресс быстрее и с меньшей кровью.

Рис. 7. Доска релизов.

Таким образом, сейчас примерно раз в две недели мы планируем задачи на два релиза вперед и заранее прогнозируем сроки, когда бы нам хотелось выпустить следующий релиз в прод. Бизнес понимает, что и когда уйдет в поставку, планирует коммуникации и чувствует себя увереннее; ребята понимают, на чем им сфокусироваться, чтобы удовлетворить ожиданиям заказчика. Поставка релиза “точно в срок” – наш очередной эксперимент, ответ Jira на “скудные” метрики.

Роль Service Delivery Manager

Напоследок расскажу немного о роли Service Delivery Manager. В этой команде мне посчастливилось на практике опробовать эту роль на себе. Сказать, что я обосрался, это не сказать ничего. Изначально я заходил как скрам-мастер. Но по описанным выше причинам я решил перевести команду на канбан. Что сказать? Если с обязанностями скрам-мастера на сегодняшний день мне всё более менее ясно благодаря скрам-гайду, то с аналогичной ролью в Канбане вышли проблемы.

Во-первых, не понятно, что за что ты всё-таки отвечаешь. Формулировка “за поддержание потока” на практике звучит очень размыто. Тем не менее, в иерархической структуре очень выручает слово “менеджер”. Помню, как в самом начале работе у меня случился довольно напряженный разговор с владельцем продукта. Она – блестящий менеджер, великолепно разбирающийся в продукте, ожидала от меня выстраивания и поддержания процесса, руководства людьми и разработкой в команде. Когда же я объяснил ей, что вижу свои обязанности в другом, а именно в том, чтобы настроить процесс и передать его в команду, нам обоим поплохело. Я понял, разрыв между ожидания очень большой. И что я не могу сейчас ей дать того, что она хочет. Она просто не понимала, чем я буду управлять в команде, а слово “поток” ей ни о чем не говорило. Люда – да, задачи – да, поток – нет. В итоге сторговались на управлении задачами. Именно тогда я предложил ей опробовать себя в роли Service Delivery Manager, раз мы переходим на использование Канбана. И когда она услышала слово “менеджер”, ей сразу стало легче.

Во вторых, ты всё-таки менеджер. А это, извините за мою вольную трактовку Agile-манифеста, уже не самоуправляемая команда, если в ней есть менеджер. И как менеджер, отвечающий за поставку, я уже не мог себе просто сказать: они это сделают сами. Естественно, что я начал подключаться. И в этот самый момент обосрался во второй раз: я вдруг понял, что оперативное управление мне перестало быть интересным. Десять лет я исправно работал менеджером проектов и административным менедежером, с удовольствием общался с разными заказчиками и командами, с гордостью закрывал проекты и видел себя большим руководителем. А тут вдруг, как бабушка отшептала. Такие дела.

Пожалуй, самый важный вывод, который я для себя сделал после этого, это то, что Канбан – очень крутой инструмент для руководителя с выделенной командой (как и для менеджмента 3.0).  Мне было тяжело переступить через себя и взять руководство процессом разработки, и не хватило сил, энергии, знаний и опыта, чтобы передать процесс управления релизами в команду, но я отчетливо понял, что если в тебе горит желание управлять, такой инструмент, как канбан будет сегодня лучшим подспорьем. Тем более, что два года назад я начинал путь в канбане с книжки Эрика Бречнера “Agile Project Management with Kanban”.

Часть 3. Заключительная. Итоги и вопросы

Напомню о текущей расстановке сил. Нас двадцать семь человек.

Сегодня мы пользуемся общей канбан-доской, визуализируя все работы. Работы разделены на эпики. Эпики представлены в виде свимлайнов. По каждому эпику виден прогресс и понятен объём работ. Раз в две недели мы наполняем очередь и планируем очередную поставку. На доске мы фильтруем задачи по релизам, что помогает нам фокусироваться на главном и вроде бы удовлетворять пожелания заказчика.

И вот спустя два с половиной месяца бизнес пришел и предложил нам разредиться на три мини-команды в соответствии с направлениями:

  1. новые фичи;
  2. конверсия;
  3. подключение новых партнеров.

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

Еще одной из причин такого разделения есть желание решить проблему с релизами и интеграционным тестированием. Бизнес согласился взять на себя эту функцию, назначив ее на владельца направления. Но взамен попросил разделения на три команды, чтобы каждый владелец направления занимался своими задачами и видимо своими релизами (здесь я додумываю).

Мне эта идея показалась мягко говоря странной, и всё внутри меня стало против такого разделения. Мне кажется, что мы слишком рано решили провести этот очередной эксперимент, еще не до конца обкатав схему с планированием поставки. Однако, по-скольку в команде разработки мы так и не нашли желающего постоянно управлять релизами (я от этой роли после эксперимента отказался), а бизнес не может сейчас пустить релизы “на самотек”, они решили, что так будет лучше. Моё замечание о том, что мы занимаемся тем, чем они нам говорят (что, мол то, что мы делаем 100% одного направления – это ваше же решение), пока не было услышано. Бизнесу кажется, что если он явно разделит потоки и явно назначит аналитика, разработчиков и тестировщика на каждое направление, он защитится сам от себя – от пере-усиления одного направления за счет другого. Один последний аргумент от бизнеса, с которыми мне сложно поспорить – в маленьких командах быстрее коммуникация. А также бизнес считает, что в маленьких командах выше уровень ответственности за результат.

Друзья, скажите, что я сделал не так? Почему у нас не зашло? Я проверил четыре гипотезы, о которых писал в первой части, качественно и количественно могу точно сказать, что три из четырех подтвердились:

  • бизнес получил понимание, над чем работаем сейчас и на чем сфокусироваться дальше, сможет абсолютно легально наполнять очередь новыми задачами, не дожидаясь окончания спринта;
  • канбан-метод повысил гибкость и предсказуемость работы команды.
  • канбан-метод оказался экономичнее с точки зрения встреч.

К сожалению, мы пока не устранили переработки. Но я связываю это с двумя вещами:

  1. был ранее накопленный пул задач в системе, который мы сейчас старательно перевариваем.
  2. у нас сохраняется “пропушивание” задач в систему вместо вытягивания.

Где я накосячил? Я не хочу, чтобы команда делилась на три команды, и ребята явно закреплялись за отдельным направлением. Я вижу здесь следующие проблемы и вопросы, которые меня пугают:

  1. Что делать, когда кто-то заболел или ушел в отпуск? У нас по одному тестировщику и аналитику на направление. Придется как-то перебрасывать людей.
  2. Что делать, когда в команде нет задач? Когда нагрузка ниже пропускной способности?
  3. Не произойдет ли закукливания в направлении? Это задачи не из нашего направления, мы не хотим это делать?
  4. Что делать, когда в одном из направлений нужно резко ускориться? Мы же всё равно будет перебрасывать людей.
  5. Что делать с коммуникациями между командами? Всех на один митинг и делить? Ребята уже поговаривают о разделении на дейли, так как им неинтересно знать, что происходит у других. А по общей доске делать встречу еженедельно.

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

Я понимаю, что сейчас самым верным решением будет довериться команде, как ранее они доверились мне. Поэтому конечно же я помогу им всем, чем смогу. Как избежать факапа в следующий раз?

Facebook Comments

1 thought on “Канбан на двадцать семь человек. История одного провала

Leave a Reply

Your email address will not be published. Required fields are marked *