Пост про Jira и работу с канбан досками, как проходила эволюция от маленькой борды на одну команду, до 5 досок и 6 команд.

Сейчас конфигурация джира проекта выглядит следующим образом:

– Используем стори, баги, энейблеры
– Каждая доска представляет собой 30% шагов из основного воркфлоу
– Эпики и фичеры у нас в отдельном программ\портфолио канбане
– Используем Канбан настройки, вместо скрама, но придерживаемся скрам каденций
– Сделали свои, кастомные приоритеты
– Воркфлоу на 25 шагов- 3 основных доски, которые показывают элементы из 3 проектов в сумме
– На каждой доске в среднем по 5 свимлейнов

Если интересно, как мы к этому пришли, то тогда найдите подходящую секцию ниже.

Начало и внедрение Канбан метода

Все началось с маленькой команды разработки в 8 человек. У нас были сжатые сроки, отсутствие четких требований и много энтузиазма. Была дефолтная джира, с воркфлоу на 5 шагов (open->to-do->in progress->done) и базовой структурой беклога (epic->feature->story->task/bug). Мы начали нашу разработку, которая с первого часа не соответствовала джировскому флоу. И с самого начала у меня было несколько базовых идей по изменению: 

1) Выделить upstream и downstream потоки. Суть в том, что поток любой работы условно можно разделить на 2 части: Upstream и Downstream, формирование объема работ и реализация работы. (наперед скажу апологетам КМП, у меня сертификата нет, могу ошибиться в терминах, не стесняйтесь поправлять)

Я бы выделил 2 причины зачем разделять: у них разные “владельцы” и разные метрики здоровья. Upstream – кол-во декомпозированных задач достигших уговоренного Definition of Ready. Downstream –  кол-во задач достигших оговоренного Definition of Done состояния. В рамках (open->to-do->in progress->done) выделить upstream/downstream нельзя. 

2) Вместе с разделением потока на составные части, я также хотел зашейпить каждый конкретный шаг в воркфлоу. Банально, если мы кодим, то статус так и должен называться – coding. А если тестируем, то это должно быть testing, а не просто in review.

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

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

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

Для тех кто вдруг пропустил, есть официальный Канбан Гайд, в котором собрано сверх-много полезной информации.

Что делать, если доска становится длинной?

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

Можно конечно пойти по пути уменьшения кол-ва статусов или какой-то группировки их в группы. Например подготовка технического задания + кодинг + тестирование = разработка. Но есть решение лучше, просто разделить 1 доску на несколько. Создайте канбан доску (а не скрам), зайдите в настройки и сделайте маппинг “статус-колонка”. Если у вас 30 статусов, то можно сделать 1 доску только на первые 10 статусов и вторую на оставшиеся 20. Или 3 по 10, ну вы поняли логику. Я разделил флоу на 3 части-доски.

1) Первая доска – работа аналитиков, тот самый upstream. Это прям отдельная доска, но каждая задача переходит с одной доски на другую, потому что идет через один и тот же workflow. 

2) Вторая доска – разработка внутри итерации. Тут больше всего движняка происходит, именно ее мы обсуждаем на синках и именно она дает наилучшее понимание, как хорошо идет работа по итерации. 

3) Третья доска – реализация работы на продакшене. Конкретно нам нужна реже всего, раз в 3 месяца на пред-релиз митингах, когда происходит продакшн релиз.

По итогу, каждая доска показывает определенный, обособленный кусочек контекста, с фокусом на рабочую группу и со своими метриками эффективности. Но все проходит через один workflow, просто он нарезан на кусочки.

Swimlanes

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

И вот для четкого разделения мы выбрали swimlane. Доска делится на горизонтальные секции, и в каждую секцию можно вывести задачи определенного рода, использую JQL. Если вы начинаете работать с джирой, то настоятельно рекомендую посмотреть обучалки про jql, даст вам неимоверный буст. И мы начали разделять задачи сначала по стримам и ПО, а затем добавили и еще ряд критериев. 

Затем, мы решили использовать свимлейн на третьей доске, посвященной релизам. И там у нас критерий для каждой дорожки – свой релиз. 

А когда у нас стало больше 2х команд, то мы дали каждой свой свимлейн на 2й доске, посвященной разработке. 

Приоритеты

Чтобы выделить важность одних задач над другими, мы решили отредактировать дефолтные приоритеты в джире, и создали свои. Почти во всех трекерах, есть приоритеты вроде P1 <-> P6. Где 1 это важно, а 6 почти совсем не важно. Вроде и хорошо, но тебе всегда нужно ломать голову, это 3 или 4 или может 5? С виду простой функционал усложняет общий процесс. И вместо него, был предложен понятный подход приоритетности: Critical (бросать все и делать только эту задачу), Committed (пообещали бизнесу сделать), Stretch (сделаем если будет время), Minor (делать только если совсем других задач нет). 

Таким образом, на каждой доске есть четкое определение, что происходит в горизонтальной секции (swimlane) и обозначены приоритеты по задачам внутри нее.

Можно ли делать итерации без функционала Sprint? А если очень хочется? 

Большинство джира проектов использует функционал спринтов, когда у тебя есть кнопки “Начать спринт” и “Закончить спринт”, плюс есть репортинг по спринтам. Это всегда дихотомия, если хочешь использовать спринты, то обязан выбрать в настройках Scrum. Если хочешь работать по канбану, то нужно выбирать Kanban.

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

Скрам настройки явно не подходили, и решением я придумал “костыль” с Release versions. 

Джира дает возможность отмечать задачи специальным тегом – Fix Version. Как правило, его используют для определения релиза. Но никто ведь не мешает приравнять итерацию с релизом, верно? 🙂 Как итог, вы получаете контейнер двойного назначения, куда можно складывать задачи. 

Какие удобства? 

– Все плюшки канбана, плюс эмуляция нужных вещей от скрама

Какие неудобства? 

– Нет встроенного спринт-репорта, все метрики надо считать вручную
– Back-dated data quality issues, как-то “задвоения” тега итерации, отсутствие тега итерации и проч. Нужно больше внимания уделять гигиене беклога

Зачем вообще нужны какие-то итерации, если канбан так хорошо деливерит? Да все просто, канбан не даст вам долгосрочного планирования, и чтобы определять направление работы на недели\месяцы вперед нужно создавать контейнеры по типу итераций a.k.a спринтов (маленькие 2-3-4 недельные отрезки), а затем больших контейнеров на квартал. 

Как подружить разные проекты в рамках одной доски?

Вот вы собрали себе доску, отстроили процесс, а тут вдруг нужно работать с соседней командой(ами), которая используют другой проект, с другим воркфлоу. Хочется показывать всю работу в одном месте. В моей ситуации задействовано целых 3 проекта с разными настройками.

Оказалось, что сделать это достаточно просто! В настройках доски расширьте значение Filter Query по-умолчанию с текущего на проекта на еще один. Затем в настройках доски можно назначить новые статусы в нужные колонки.

Т.е. у вас раньше в колонке Тестирование показывались задачи со статусом “Testing”. Вы добавили новый проект, у них нет статуса “Testing”, но есть похожий “In Review”. Добавьте его в колонку и теперь на доске вы увидите задачи с этими статусами, с двух проектов. 

Это не будет 1:1, но общей снепшот\контекст можно создать. А общий контекст нужен критичен, когда сразу несколько команд работают вместе.

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