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

Всем привет!

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

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

Сегодня это:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Карпаччо из слона. Цель: нарезка мелких пользовательских историй.
2. Карта пользовательских историй. Цель: декомпозиция эпиков на завершенные пользовательские истории и элементы.
3. getKanban. Цель: использование шести практик канбана в работе команды.

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

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

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

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

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

Таким образом, сейчас примерно раз в две недели мы планируем задачи на два релиза вперед и заранее прогнозируем сроки, когда бы нам хотелось выпустить следующий релиз в прод. Бизнес понимает, что и когда уйдет в поставку, планирует коммуникации и чувствует себя увереннее; ребята понимают, на чем им сфокусироваться, чтобы удовлетворить ожиданиям заказчика. Поставка релиза «точно в срок» — наш очередной эксперимент, ответ 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. Что делать с коммуникациями между командами? Всех на один митинг и делить? Ребята уже поговаривают о разделении на дейли, так как им неинтересно знать, что происходит у других. А по общей доске делать встречу еженедельно.

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

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