Рад приветствовать Юрия Кудына, Юрия Лапина и Филипа Томашевского в нашем разговоре сегодня. Они — блестящие умы, стоящие за Advanced Kanban Boards (AKB), инструментом, который фундаментально меняет подход команд к работе с Jira.
Их работа особенно ценна, поскольку решает проблему, с которой сталкиваются почти все практики канбана: Jira незаменима, но ей не хватает функций, необходимых для полноценной реализации канбана. Сочетание AKB и Nave’s Kanban Analytics Suite создаёт комплексное решение для Jira, позволяя командам применять политики и практики, не вынуждая их отказываться от существующего инструментария.
Я рад изучить, как AKB помогает командам визуализировать сквозной поток, эффективно применять ограничения на объём работы в процессе (WIP limits) и поддерживать человеко-ориентированный подход, который делает канбан мощным инструментом.
Визуализация полной картины
«В канбане очень важно видеть всё от идеи до завершения», — объяснил Юрий Кудын. «Только так мы можем увидеть, как создаётся ценность, выявить узкие места и построить действительно эффективный поток».
Проблема в том, что большинство команд разбивают свой поток на части. Управление продуктом получает одну доску. Инженерия — другую. Маркетинг — третью. Каждая доска выглядит управляемой, но общая картина исчезает.
Юрий Лапин привёл показательный пример: «У нас был клиент с отдельными досками для каждой функции. Всё выглядело нормально внутри каждой доски, но бэклоги продолжали расти, а время в бэклоге увеличивалось. Они этого не видели, потому что у них не было единого представления о создании ценности».
Создание одной огромной доски Jira звучит как решение, но любой, кто пробовал, знает, что она становится непригодной для использования. Столбцы бесконечно растягиваются по экрану.
AKB решает эту проблему. Команды могут увеличивать и уменьшать масштаб, сворачивать или разворачивать любой столбец и сохранять пользовательские представления для разных ролей. Инженеры DevOps видят только столбцы развёртывания. Тестировщики видят этапы тестирования. Руководители продуктов видят подготовку требований. Все работают на одной доске, но фокусируются на том, что важно для них.
«Мы можем предварительно определять представления и экономить много времени», — пояснил Юрий. «Больше не нужно постоянно щёлкать мышью».
Группы столбцов выводят это на новый уровень. Команды могут группировать столбцы по функциям (например, все инженерные шаги) и применять политики ко всей группе, а не только к отдельным столбцам. Доска остаётся читаемой, показывая полный поток от идеи до производства.
WIP limits, соответствующие уровню зрелости
Здесь AKB действительно выполняет обещание канбана. На мой взгляд, доску канбана нельзя назвать доской канбана, если на ней нет ограничений WIP.
AKB предоставляет ограничения WIP на нескольких уровнях, что идеально подходит для команд, находящихся на разных этапах своего пути.
Для команд, только начинающих работу с управлением потоками, личные ограничения WIP помогают избежать перегрузки. «Мы можем назначить ограничение на количество работ для каждого члена команды», — отметил Юрий, — «чтобы мы могли определить, кто перегружен, а кто нет».
По мере развития команд ограничения на уровне столбцов поддерживают движение работы. Но настоящая сила приходит с группами столбцов, особенно в сочетании с разделением на этапы выполнения и завершения.
«Мы можем применять ограничения на объём работ не только к определённой работе, например, к рассмотрению архитектуры или кода, но и ко всей инженерной функции», — объяснил Юрий. «И мы можем видеть, чем заняты наши сотрудники».
Это важно, потому что столбцы завершения — это парковки. Работа там просто ждёт. Без ограничений на эти очереди они становятся чёрными дырами. AKB позволяет командам отмечать столбцы как активные или ожидающие, а затем автоматически рассчитывает показатели эффективности на основе того, где работа фактически проводит своё время.
Поддержание движения и видимости работы
Блокеры убивают поток. AKB делает их невозможно игнорировать.
Помимо базовой возможности маркировки в Jira, AKB позволяет командам указывать причины возникновения препятствий, используя пользовательские поля. Наведение курсора на флаг сразу показывает причину, без необходимости нажимать. Со временем команды могут анализировать, какие препятствия возникают чаще всего, и устранять первопричины.
Зависимости получают такую же обработку. Визуальные ссылки на доске показывают связи между рабочими элементами, причём разные цвета обозначают разные типы ссылок. Критические блокеры отображаются красным цветом. Специальное окно отслеживает зависимости вне команды, разделяя внутренние и внешние потребности координации.
Но что действительно впечатлило меня: индикаторы состояния.
Команды устанавливают пороговые значения для приемлемого времени в каждом столбце. Вместо того чтобы мысленно отслеживать десятки переменных, простой индикатор с цветовой кодировкой показывает зелёный (всё хорошо), жёлтый (предупреждение) или красный (проблема).
«Мы видим, что предел старения для всего потока превышен», — продемонстрировал Юрий. «Также по группам столбцов мы развиваемся больше, чем ожидалось. У нас больше возвратов, чем ожидалось. Эффективность низкая. Такие индикаторы показывают элементы, на которые нужно обратить внимание».
Возвраты между столбцами особенно коварны. Работа может не нарушать ограничения WIP и не задерживаться слишком долго ни в одном столбце, но пинг-понг разрушает эффективность. AKB отслеживает, сколько раз каждый элемент возвращается, и отмечает чрезмерное движение.
Наконец, AKB делает политики процессов доступными там, где команды фактически работают. Вместо того чтобы скрывать определения выполнения в страницах Confluence, которые никто не читает, команды добавляют их непосредственно в столбцы, группы столбцов или всю доску. Наведите курсор на любой столбец, чтобы увидеть критерии выхода и соглашения.
«Информация должна быть легкодоступна», — подчеркнул Юрий. «Мы верим в информационные радиаторы, а не в информационные холодильники. Вам не нужно открывать его и заглядывать внутрь».
Если вы хотите изучить Advanced Kanban Boards, вы можете найти его на Atlassian Marketplace.
Для более глубоких обсуждений или чтобы записаться на демонстрацию, посетите их веб-сайт и используйте опцию «Запланировать демонстрацию». Упомяните «NAVE» в описании, чтобы получить специальное предложение и получить индивидуальные рекомендации по вашему конкретному случаю использования. Команда обсудит, как решить ваши проблемы, основываясь на своём опыте работы с другими клиентами и их опыте в области Agile и канбан-консалтинга.
AKB заставляет Jira работать так, как это нужно командам. В сочетании с аналитикой Nave команды наконец получают полную картину: как работает работа, где она застревает и что с этим делать.
1. Какие проблемы решает инструмент Advanced Kanban Boards (AKB) при работе с Jira?
Инструмент Advanced Kanban Boards (AKB) решает проблему отсутствия необходимых функций в Jira для полноценной реализации канбана. Он позволяет командам визуализировать сквозной поток, эффективно применять ограничения на объём работы в процессе (WIP limits) и поддерживать человеко-ориентированный подход.
2. Как AKB помогает командам управлять потоком работы?
AKB позволяет командам увеличивать и уменьшать масштаб, сворачивать или разворачивать любой столбец и сохранять пользовательские представления для разных ролей. Это помогает командам видеть полную картину потока работы от идеи до завершения.
3. Какие уровни ограничений WIP предоставляет AKB?
AKB предоставляет ограничения WIP на нескольких уровнях: личные ограничения для каждого члена команды, ограничения на уровне столбцов и ограничения на уровне групп столбцов. Это позволяет командам адаптировать подход к управлению потоком работы в зависимости от их уровня зрелости.
4. Как AKB помогает отслеживать возвраты между столбцами?
AKB отслеживает, сколько раз каждый элемент возвращается между столбцами, и отмечает чрезмерное движение. Это помогает командам выявлять неэффективные процессы и оптимизировать поток работы.
5. Как AKB делает политики процессов доступными для команд?
AKB делает политики процессов доступными, добавляя их непосредственно в столбцы, группы столбцов или всю доску. Это позволяет командам легко получать доступ к необходимой информации и следовать установленным процессам.