Привет, с вами команда “Инферит Клаудмастер”. Сегодня мы хотим рассказать вам о нашем опыте практического применения Канбан-метода в разработке. Для этого мы пообщались с Лилей Ермаковой, Service Delivery Manager, которая своими руками лидировала внедрение нового процесса.
Несколько дисклеймеров:
Мы все еще продолжаем наш путь в Скрамбан и не претендуем на завершенный и идеальный результат.
Мой рассказ в основном прикладной, поэтому Закон Литла, формулы и большую науку я затрагивать не буду. В конце статьи размещу ссылки, на ресурсы, наполненные хардкор статистикой и аналитикой.
Канбан, как замечают коллеги, — очень перегруженное слово. Задам координаты теории, на которую я ориентируюсь, — это материалы Канбан Университета и ProKanban.org.
Исходная ситуация
Мы одновременно тестировали две продуктовые гипотезы. Как иллюстрация к закону Конвея, у нас выросли две кросс-функциональные команды с разными культурами и практиками. В каждую команду включены бэкендеры, фронты, дизайнеры и тестировщики. Отдельно команды сопровождали системные инженеры, а также команды развития бизнеса и маркетинга.
Модули продукта завязаны на общие компоненты, при этом имеют собственную специфику и область применения: один модуль для аналитики, другой для автоматизации инфраструктуры.
Из этого вытекало два следствия: взаимозависимость работ в командах и специализация команд на задачах с разной спецификой.
Как был организован процесс?
У каждой команды своя культура, правила, длина спринта и свой продакт. Посередине — человек, который все объединяет в одно — Technical Product Owner. Если вы скажете, agile солянка, то будете правы. Релизы получалось делать раз в месяц (в лучшем случае). Помимо разработки, необходимо было объединить результат обеих команд и провести общее регрессионное тестирование.
Какую проблему мы решали?
Наша главная боль была в сложности предсказать дату выхода наших релизов. Даты постоянно “плавали” на +/- 5 дней и более. Релизы в какой-то момент занимали около 35 календарных дней. Значительную часть этого времени мы тратили на ожидание готовности задач и устранение регресса.
Как мы искали решение?
С миру по нитке каждый член нашей команды привносил свой опыт работы с фреймворками и подходами. Много времени мы провели в обсуждениях, как правильно и как неправильно. Каждый реализовывал agile принципы в меру своего понимания и владения инструментами, но общей картинки у нас не было.
Итак, мы выбрали Канбан
В ходе обсуждений мы пришли к идее, что с решением проблемы нам сможет помочь Kanban-метод по следующим причинам:
Прогноз длительности выполнения работ на основе статистики, а не субъективных ощущений
Первые шаги не требуют новых ролей или инструментов
В метод не требуется верить, он просто работает
Принципы Канбан просты и лаконичны (меньше усилий на обучение)
И последнее, но не по значимости - ориентированность на создание ценности и результата.
Дальше пришлось ломать мифы в своей голове:
Всем все видно vs доски в Jira
“Не знаю сколько это займет, это задача на несколько спринтов, я в фоне поделаю”. Основной принцип, который моментально приносит результат: всю работу в направлении доставки ценности клиенту должно быть видно.
Всю — значит совсем всю ?. У себя мы обнаружили много “фоновых” задач и “влетов” с разных сторон, которые жили в разных проектах в Jira или просто в личной переписке.
Предсказуемость vs работать быстрее
“Вы медленно разрабатываете”. Разработчики не станут разрабатывать быстрее, но будут меньше переключаться и быстрее доделывать каждый отдельный элемент работы. Сначала объем работы, реально выполняемый в спринт, обескураживает, если сравнивать сколько задач брали в спринт раньше, и сколько стали брать сейчас. Но уверенность в том, что команда сделает объем, на который закоммитилась в заданное время, с лихвой окупает себя.
Делать больше vs поставлять ценность клиенту
“Нам нужно тестировать гипотезы, давайте больше фич”. Скажу честно, сложно отказаться от идеи постоянно “быть в мыле” и иметь 10 подброшенных вверх мячей, которые нужно успевать передавать другому, в пользу того, чтобы последовательно доводить каждую задачу до конца и получать по ней обратную связь. Обратная связь — не менее важная часть, так как одна из ценностей Канбан — ориентированность на клиента. Приоритизация результата (outcome) против объемов производства (output).
Игра командой vs перебрасывание через забор
“Пусть QA проверяют, дизайнеры рисуют, аналитики анализируют”. Неявный механизм, заложенный в Канбан — это командная работа. Когда на одном из участков блокируется работа, у команды есть стимул объединить усилия, чтобы вытягивать работу вправо и разблокировать работу.
Канбан в IT — это не то же самое, что в Toyota
Оказалось, все сложно и запутано. Если есть желание разобраться и стать душнилой экспертом, могу поделиться ссылками, с которых можно начать:
Канбан Университет https://kanban.university/kanban-guide/#kanban-method
Видео на русском: https://www.youtube.com/watch?v=xJl5pdL5gFU
Видео, как все начиналось, на английском: https://www.youtube.com/watch?v=vPSlK2ibenA
Начали со STATIK
Применение Kanban-метода начинается с упражнения с аббревиатурой STATIK, под которой скрывается Systems Thinking Approach to Implementing Kanban. Цель метода “зарисовать” текущую модель поставки ценности и ее проблематику.
Мы взяли шаблон STATIK в Miro и выполнили все шаги, как написано в инструкции. Было полезно, что нами руководил опытный коллега, который применял Канбан в другой компании.
В нашем случае это заняло 2 встречи по 1 часу. На выходе мы получили реальную карту процесса нашей работы. В нем оказалось всего-то 12 статусов (хе-хе) и около 7 типов задач.
Подробнее о STATIK: https://www.youtube.com/watch?v=uI5D00zav58
Одна доска
Упростить управление зависимостями нам помог переезд в единый Jira-проект. Мы накатили на него всю эту махину из 12 статусов и 7 типов задач. Правда, не стали делать переходы между статусами обязательными, чтобы любой статус можно было пропустить.
Наши истории проводят в работе от 5 до 7 дней, поэтому для целей ежедневной синхронизации нам не информативно смотреть на доску в разрезе историй. Наша основная доска настроена по дорожкам типа “История” и мы смотрим за движением карточек на уровне сабтасков, задач и багов.
Позже у нас появились другие доски, с другими представлениями, но они за рамками данной статьи. По мере сбора статистики использования, мы сократили число статусов и типов задач вдвое.
Фильтры для Канбан доски
Доски в Jira — это просто отображение данных. Можно создавать столько угодно досок и совершенно при этом не мешать работе коллег на других досках даже в одном проекте. Вы даже можете создать доску только ради представления бэклога или только ради использования отчета.
Типы фильтров, которые помогут обуздать хаос:
Основной фильтр определяет данные, которые могут появиться на вашей доске. Hint! Такой фильтр можно переипользовать на других досках.
Подфильтр дополнительно отсекает задачи поверх предыдущего запроса.
Быстрые фильтры фильтры, которые появляются вверху доски, в отчетах (Control Сhart, Cumulative Flow Diagram) и в бэклоге и позволяют фильтровать поверх фильтров 1 и 2.
Hint! Если выборка по быстрым фильтрам не пересекается, вы получите пустую доску.
Фильтр для дорожки. Правила, по которым задача попадает на дорожку.
Фильтр для цвета. Правило, на основе которого карточка окрашивается в разные цвета.
Как мы настроили основную доску
Основной фильтр
Основной фильтр мы перестраиваем каждый спринт по условию, что статус не в удаленных, не в бэклоге и номер релиза старше последнего. Таким образом на доску попадают задачи, начиная со статуса “В очереди”.
Hint! Сортировка в основном фильтре определяет порядок карточек на доске.
Подфильтр
Мне не удобно работать с доской, где много сабтасков в колонке “Готово”, дорожка от этого становится на весь экран. Штатный фильтр “Скрывать завершенные старше 1 недели” не сильно упрощает жизнь. Поэтому я использую подфильтр — показывать завершенные задачи только за 1 день. На представление в отчетах это влияния не оказывает.
Быстрые фильтры
Мы настроили быстрые фильтры по командам, по багам и по историям. Фильтр по командам — основной на дейликах. Фильтр работает на основе пользовательского поля “Команда”, который мы добавили в форму задачи. Поле заполняется автоматически по исполнителю.
Фильтр для дорожки
Наша основная доска построена на дорожках по задачам типа “История”, то есть каждая дорожка — это история и по ней двигаются подзадачи этой истории. Автоматически формируется дорожка “Все остальное”. Туда попадают задачи, баги, а также история без подзадач.
Основной нюанс в том, как сделать, чтобы ваши истории располагались в нужном вам порядке. Порядок карточек на доске определяется сортировкой в основном фильтре. При этом если вы пользуетесь функцией перетаскивания карточек в бэклоге (ranking), то другие сортировки работать не будут. То есть либо карточки в бэклоге двигать, либо сортировка по приоритету.
Окрашивание карточек
На дейликах наглядно видно состояние задачи по ее цвету. У нас, если задача задержалась в колонке, она начинает краснеть. Делается это в меню “Доска” -> Настроить.
Задаете при помощи JQL, как окрашивать карточку.
Hint! Имейте в виду, условие проверяется сверху вниз. Если настроить фильтры, как это сделала я, то если карточка была в колонке больше 3-х дней, то фильтр проверит: больше 5? - нет, больше 3? - да, цвет желтый. Если поставите фильтры в другом порядке может быть зеленым постоянно :)
Усилить эффект “пригорания” тасок можно, добавив перфорацию на карточках. Это делается флажком “Дней в колонке”.
Вот такой эффект у карточки, которая дольше 5 дней в колонке.
WIP-лимиты
Мы продолжали учиться, в чем нам немало помогли материалы Kanban Russia и команды Банка Т. Один из главных, можно сказать, волшебных компонентов Канбан — это лимиты на незаконченную работу, так называемые WIP-лимиты, где WIP — аббревиатура для “work in progress”.
Перед установкой первых лимитов мы провели игру Фичабан в каждой команде и для менеджеров отдельно. Всего 3 игры до 1,5 часов каждая. Игра позволяет в легком формате прочувствовать, как работает Канбан. Большое спасибо авторам, что все это доступно и идеально работает.
Ссылка на игру: https://tools.flowfast.io/featureban
Отличный инструктаж от Игоря Филипьева, как проводить игру: https://www.youtube.com/watch?v=0xLc54EBvXc
Hint! В игре заблокированные задачи отмечаются красным. В Jira это тоже можно сделать при помощи функции “Поставить флаг”. Карточка окрашивается в другой цвет.
Важной темой для обсуждения была подготовка к тому, что часть времени у некоторых членов команды не будет задач и ни в коем случае не стоит это время использовать для того, чтобы начать какую-нибудь новую задачу. Почему? По той же причине, по которой запрещено обгонять по обочине, — задачи, которые уже находятся в работе, затормозятся.
Встречи
Мы переназвали все свои встречи на Канбан-манер. Были ретроспективы, стали service delivery review, было планирование - стали встречи по пополнению очереди. Основное изменение, которые коснулось этих встреч — это то, что мы проговорили фокус на процессах, а не на людях, которые в них участвуют.
Наибольшие изменения претерпели “дейлики”. Снова спасибо коллегам из Банка Т за совет. Наша рутина теперь такая: мы идем по доске Jira справа налево, сверху вниз. Сверху у нас наиболее приоритетные истории, справа у нас подзадачи, которые ближе всего к завершению.
Основной вопрос — что мы можем сделать, чтобы сдвинуть карточку вправо. Таким образом мы обсуждаем только задачи в работе или готовые к работе, а не операционку, которую сделали “за вчера”.
Первое время к нам продолжали “залетать” задачи, которые кто-то решил поделать в свободное время или которые пролезли вне встречи по пополнению очереди. Такие задачи оставляли на доске, и они краснели с молчаливым укором, пока команда не вытягивала их вправо.
Метрики
Первое, что влюбляет менеджеров в Канбан — это научный подход и метрики, много разных метрик и графиков.
Основные метрики, которые нужно трекать в Канбан:
Cycle time — время от начала работы до конца работы.
Item Aging — старение элемента работы.
WIP-лимиты на одновременную работу.
Throughput — сколько элементов можно завершить на 100% за период времени.
Метрики встроены в Jira и их можно получить из отчетов:
Control Chart
Cumulative Flow Diagram
Control Chart хорошо описан в документации самой Jira. Важно понимать, как он устроен, чтобы делать корректные заключения на его основе. Кто первый раз видит этот график, обратите внимание на нижнюю секцию с настройками — там все самое интересное.
Ссылка на документацию для детального ознакомления: https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-control-chart/
В магазине приложений Google Chrome есть пара бесплатных плагинов, которая позволит получить все метрики из вашей Jira, а также даст возможность делать симуляции методом Монте-Карло:
Hint! Напомню, что вы можете создавать сколько угодно досок Jira с такими настройками фильтров и приоритетов, которые вам удобны. Отчеты и приложения подхватывают ваши быстрые фильтры с доски Jira и позволяют показывать данные в нужных срезах.
Волшебство сработало
Но не совсем.
Мы определили WIP-лимиты по командам эмпирически, на основе данных, накопленных в Jira. Изначально лимиты поставили также на колонку “В работе” по числу историй в работе. Позже работа с WIP несколько изменилась, о чем упомяну ниже.
Время разработки и выхода релиза сократилось. Задач на доске стало объективно меньше и это позволило их более пристально и сознательно трекать. Но даты релиза пролежали колебаться, хотя отклонение сводилось к пределу 2–3 дней.
Нас это не устроило.
Секретный компонент
Под названием time-box.
После долгих споров мы пришли к конструкции, похожей на Scumban. Канбан со Scrum. В огромной степени этому способствовала управленческая воля и поддержка на всех уровнях лидерства нашей команды. Было много встреч, много разъяснительной работы, отработки возражений. Мне потребовалось значительно подтянуть свое знание Scrum и потратить на это много времени, но это было не напрасно!
Провели еще одну игру — “Видео Scrum”. Которая, как вы догадались, в легком формате позволяет полностью прочувствовать, как работает Scrum.
Общая информация об игре: https://agilemasters.ru/2021/04/29/igra-video-skram/ .
Для проведения требуется опыт и знание Scrum. Очень рекомендую пригласить опытного ведущего.
Важный момент — дальнейшее последовательное применение Scrum сопровождалось поддержкой на всех уровнях управления и лидерства. У ряда наших разработчиков предыдущий опыт работы был связан с проектной разработкой, которая предполагала работу по ТЗ и квартальным планам. Потребовалось на разный лад и разными голосами доносить суть и принципы Scrum.
Что изменилось, когда добавили Scrum
Наши встречи соответствуют фреймворку Scrum и по терминологии, и по целям проведения. У нас есть фиксированная длительность спринта, по завершению спринта мы выкатываем релиз.
Time-box создает необходимое ограничение на то, чтобы не допускать “распухания” задачи в пути, а также требует изобретательности и командной работы, чтобы выполнить задачу с заданными ограничениями со стороны времени, требований к задаче и definition of done.
Самым сложным для понимания было, что и во фреймворке Scrum, и в Канбан-методе все события, принципы и ограничения направлены на стимулирование командной работы. Командная работа — это, когда все готовы собраться и пинать одну историю вместе вне зависимости от своей специализации.
Что стало с Канбан
Метрики делятся на опережающие и запаздывающие. Первые показывают в моменте, что есть отклонение, другие позволяют говорить о характеристиках процесса, когда работа над элементом поставки завершена.
Очень полезной оказалась табличка, где указано на каком событии какую метрику стоит обсуждать.
Скриншот из видео Ильи Павличенко, Scrum.ru. В конце даю ссылку на статью, как использовать метрики Канбан в Scrum.
Как именно мы обсуждаем каждую метрику?
Cycle time обсуждаем на ретроспективе, что можно было сделать иначе, чтобы сократить время элемента до готовности. В первое время мы обнаруживали такие вещи: “Троянский конь” — история, в которой решили реализовать нечто большее, чем сама история, “баг-бумеранг”, который был про одно место в коде, но оказалось имеет множество зависимостей. После того как мы перешли к жестким временным рамкам на спринты, основное обсуждение на встречах — успели ли мы сделать все, что брали в scope спринта. И если не успели, то что нам помешало.
Throughput мы обсуждаем на планировании и ориентируемся на предыдущие достижения. Бэклог спринта — предмет договоренностей владельца продукта и команд. Объем на спринт определяется на основе обсуждения story points. Слово “обсуждение” в этой фразе ключевое.
На WIP смотрим ежедневно на доске. В целом, подход такой, что на человека не должно быть более 1 сабтаска или бага одновременно. Если такой появляется — это сигнал к тому, что часть работы заблокирована и нужна помощь. Также смотрим по времени выхода в регресс, когда мы должны перестать брать задачи в работу, чтобы успеть к релизу. Ожидаемый расклад, конечно, что к этому моменту очередь уже полностью выбрана и ничего не осталось. На ретроспективе обсуждаем, если у нас обнаружилось неожиданное “бутылочное горлышко” или накопитель.
Item Aging. Сейчас отслеживаем по наглядной раскраске карточек на доске, флагами отмечаем заблокированные элементы. Сам график Item Aging пока не используем. Думаем, как применить.
Могу сказать, что эволюционное путешествие нашей команды в agile продолжается. Мы масштабируем подход на базе фреймворка Flight Levels. Я рассказывала об одной доске, но на самом деле у нас их значительно больше. Мы стремимся полностью визуализировать поток создания ценности и доставки ее клиенту, а также “навести мосты” там, где раньше были функциональные или административные размежевания.
В итоге, если бы меня спросили, что бы я сделала иначе, чтобы достичь такого эффекта быстрее и проще, я бы сказала, что заручилась бы поддержкой и пониманием agile и scrum на всех уровнях команды или компании. Имеется в виду осознанная и информированная поддержка, основанная на личном опыте и желании применить фреймворк. Взрослых самостоятельных людей сложно заставить что-то делать, если они в это не верят. Поэтому — продавать, продавать и еще раз продавать идеи. Чем больше у идеи спонсоров и евангелистов, тем быстрее это получится.
Полезные ссылки:
Закон Литла 50 лет спустя: https://projectproduction.org/journal/reprint-littles-law-as-viewed-on-its-50th-anniversary/
Еще исследования и статистика: https://www.focusedobjective.com/
Харизматично, ультимативно про метрики:
Здесь видео о том, как настроить пользовательские поля и автоматизацию по подсчету Cycle Time в Jira. Полезно даже, если вам нужно собственное поле с другой целью: https://www.youtube.com/watch?v=9QosVez8Dac
Статья, как использовать метрики Kanban в Scrum: https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events
kleevahew
Отличная статья, спасибо. Многое из перечисленного откликнулось. А как относятся программисты к получившемуся фреймворку? Находят ли его полезным? Злятся ли от ограничений work in progress?