Привет всем. Это продолжение истории про переход команды PVS-Studio на работу по методике kanban. На этот раз речь пойдет про YouTrack, как мы выбирали и внедряли этот трекер задач и с какими вызовами столкнулись в процессе. Статья не имеет цели рекламировать или ругать YouTrack. Тем не менее замечу, что по мнению нашей команды ребята из JetBrains проделали (и продолжают делать) отличную работу.

0853_Kanban_YouTrack_ru/image1.png

Про историю перехода на kanban и о предпосылках смены трекера задач я рассказывал в предыдущей статье "Kanban команды PVS-Studio. Часть 1: agile". Рекомендую ознакомиться с ней для лучшего понимания некоторых аспектов текущей статьи. Также хочу заметить, что здесь я не планирую подробно рассказывать обо всех особенностях YouTrack, так как их очень много. При желании вы можете заглянуть в документацию и убедиться в этом сами. Думаю, статья будет интересна в первую очередь тем, кто планирует или уже использует этот трекер.

Предыстория

Если вам не хочется читать первую часть статьи, то вот краткая предыстория. После внедрения методики kanban нам очень понравилась идея использования kanban-доски для проведения ежедневных митингов. Однако в связи с переходом на удаленный режим работы наша первоначальная физическая доска оказалась не у дел. Немного помучавшись, мы решили форсировать работы по выбору и внедрению альтернативного трекера задач на замену Bitbucket. При выборе отдавалось предпочтение инструментам с электронной доской. На самом деле, выбор изначально был между YouTrack и чем-то другим, так как YouTrack активно лоббировался тимлидом нашей С++ команды (Филипп, привет). В качестве основного конкурента YouTrack рассматривали Jira, но в итоге остановились всё же на YouTrack.

Bitbucket в команде PVS-Studio мы использовали с середины 2014 года. Долгое время он нас вполне устраивал. Но с ростом размера компании мы столкнулись с рядом неудобств, вызванных отсутствием или сложностью реализации некоторых возможностей:

расширенная настройка оповещений;
настраиваемые рабочие процессы;
связи между задачами;
учёт времени;
отчёты;
agile-доски.

Даже при поверхностном изучении YouTrack оказалось, что все эти возможности там доступны уже "из коробки". Воодушевленные, мы приступили к процессу перехода на новый инструмент.

Подготовка

Как я уже упоминал в первой части статьи, за время работы с Bitbucket там было создано более 5500 задач. Конечно, было бы неплохо перенести их в YouTrack, но сделать это оказалось не так-то просто.

Со стороны Bitbucket относительно безболезненный экспорт задач возможен только в Jira. Альтернативный вариант – выгрузка задач при помощи Bitbucket API в промежуточный json определенного формата. При этом процесс сохранения всего репозитория в zip-архив через меню экспорта Bitbucket в любом браузере намертво зависает через какое-то время. На тематических форумах говорят, что это старая проблема, связанная с новой версией API Bitbucket. Таким образом, единственным рабочим вариантом является выгрузка задач по одной при помощи скрипта в тот же json (в сети можно найти несколько подобных скриптов). Но это только половина дела. С другой стороны, в YouTrack предлагается импорт задач из Jira, а также некоторых других систем, среди которых нет Bitbucket. Остается аналогичный вариант с импортом через json. Для этого источник данных нужно подготовить, преобразовав json от Bitbucket с учётом всех различий в форматах данных.

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

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

Поначалу обилие возможностей YouTrack немного сбивало с толку. Также чувствовался иной по сравнению с Bitbucket подход к организации работы с трекером. Если Bitbucket практически закрыт с точки зрения настройки пользователем, то в YouTrack ситуация прямо противоположна. Уведомления, сохраненные поиски, отчёты, agile-доски, статьи для внутреннего портала "Knowledge Base" — всё это можно при необходимости настроить самостоятельно.

Хочу отметить, что в процессе перехода на YouTrack мы не столкнулись с какими-то серьёзными техническими трудностями или неразрешимыми проблемами. В итоге удалось реализовать все наши "хотелки". Более того, начав плотно работать с YouTrack, мы открыли для себя много дополнительных возможностей. Точнее, смогли оценить их реальную пользу. Например, отчёты о затраченном времени. Такие отчёты позволяют посмотреть, какие сотрудники в принципе принимали участие в работе над определенной задачей, а не просто создали или закрыли ее. Про фишки учёта времени в YouTrack я расскажу далее.

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

Если говорить о технической части, то немного повозиться пришлось с доработкой рабочих процессов (Workflows), которые в YouTrack реализованы на JavaScript. Но основная работа носила административный характер:

определение очередности перехода: вся команда сразу или по отделам;
выбор архитектуры: один проект для всех или разные проекты для разработки и маркетинга, например;
создание пользователей, настройка ролей и групп;
базовая настройка проекта, определение прав доступа;
настройка структуры полей;
создание и настройка kanban-досок;
выбор стратегии учёта времени;
настройка рабочих процессов;
отчёты;
обучение сотрудников.

Далее в ходе изложения я буду придерживаться этого плана работ.

Очерёдность перехода, организация проектов

Основной вопрос перехода на YouTrack для нас состоял в том, какую часть команды мигрировать вначале. Переводить сразу всех мы опасались. Слишком много доработок пришлось бы делать с участием большого количества пользователей. Выбор пал на отдел маркетинга. Во-первых, это отдел, который наравне с разработчиками уже давно привык использовать kanban в повседневной работе. Во-вторых, там около десяти сотрудников, а этого вполне достаточно чтобы опробовать все основные сценарии работы с новым трекером. Наконец, ~~их было просто не так жалко~~ наш отдел маркетинга очень креативен и весьма гибок по части нововведений. Хочу выразить отдельное спасибо руководителю отдела Екатерине за бесконечное терпение и поддержку на этапе экспериментов с YouTrack. :)

Другой вопрос заключался в том, делать ли нам один проект на всю команду или разделить проекты по направлениям работы (отделам). YouTrack предлагает удобные средства для работы с несколькими проектами одновременно, и поначалу нам показалась разумной идея отделить разработку от маркетинга. Можно было бы разделить сущности и таким образом уменьшить общий объём значений в полях, количество тэгов и т. п., что в итоге упростило бы работу с трекером для пользователей. Но был очень важный аргумент против: наши задачи постоянно переназначаются между сотрудниками маркетинга и разработкой. Пример – задача про написание статьи. Первоначально статья пишется, допустим, разработчиком отдела С++. Далее она попадает на сотрудников отдела маркетинга для вычитывания и перевода. Затем снова возвращается автору для публикации. Наконец, после публикации задача вновь назначается на отдел маркетинга для дальнейшего продвижения в соцсетях и на тематических сайтах. Таким образом, наличие двух проектов осложнило бы процесс совместной работы. YouTrack умеет перемещать задачи между проектами, но при этом рекомендуется соблюдать соответствие между полями проектов. А ещё есть рабочие процессы, которые привязаны к проекту и также зависят от полей.

В итоге мы решили создать один общий проект и сразу настраивать его с учётом возможности одновременной работы всех команд. А переход начать с отдела маркетинга. Так третьего декабря 2020 года был создан проект "Marketing", впоследствии переименованный в "PVS-Studio".

0853_Kanban_YouTrack_ru/image3.png

Пользователи, группы, роли

Идеология работы с пользователями, группами и правами доступа (ролями) в YouTrack довольно проста, но имеет особенности. Поэтому я остановлюсь на этом вопросе подробнее. Начнём с иерархии.

Облачная реализация YouTrack является одним из сервисов в инфраструктуре JetBrains для командных продуктов. Все такие сервисы объединены в единое целое, могут управляться и обмениваться данными через связующий сервис верхнего уровня JetBrains Hub. Там же содержатся все общие настройки, такие как глобальные права доступа, пользователи, группы. Они называются ресурсами.

Родительским для всех проектов является проект c именем "Global". Все создаваемые группы по умолчанию предлагается добавлять как ресурсы к этому проекту. Это позволит использовать их во всех дочерних проектах. Вы можете ограничить видимость группы, добавив ее в конкретный проект.

0853_Kanban_YouTrack_ru/image4.png

Иерархия групп по умолчанию представлена родительской группой "All Users", куда включены вообще все пользователи. Также есть подгруппа "Registered Users" с признаком автоматического добавления в нее новых пользователей после регистрации. Группы пользователей YouTrack можно использовать для разграничения доступа, в запросах на выборку задач, в рабочих процессах.

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

0853_Kanban_YouTrack_ru/image6.png

Эти группы мы используем главным образом при рассылке уведомлений из рабочих процессов, чтобы уведомление, например, о просроченной задаче получал не только сотрудник, но и его непосредственный руководитель. Реализовали это просто. В группу "Managers" включены все тимлиды. Группа каждого отдела, помимо сотрудников, также содержит одного или нескольких тимлидов. При отправке уведомления пользователю проверяем, в какой группе тот состоит. Если в группе "Managers", то сообщение получит только он. Иначе, производится поиск рабочей группы пользователя. Уведомление получит как пользователь, так и все тимлиды, состоящие в его рабочей группе. Более подробно про наши рабочие процессы я расскажу далее.

Вернёмся к списку групп. Обратите внимание, все группы относятся к проекту "Global" (являются его ресурсами), а группе "Registered Users" назначена роль "Global Observer". Роль в YouTrack – это именованный набор (контейнер) разрешений двух типов: "Hub" и "YouTrack". Тип "Hub" содержит доступы для работы с глобальными сущностями: группы, проекты, роли, пользователи и т.п. Тип "YouTrack" предназначен для настройки доступа к возможностям трекера: работа с задачами (создание, комментирование, добавление вложений и т.п.), отчёты, сохраненные списки и т.п. Мы не стали создавать дополнительных ролей. Имеющихся по умолчанию вполне хватает для работы.

0853_Kanban_YouTrack_ru/image8.png

Каждый новый пользователь будет автоматически добавлен в группу "Registered Users" и в соответствии с ролью "Global Observer" получит минимальный набор из трёх разрешений.

0853_Kanban_YouTrack_ru/image9.png

Это разрешения уровня "Hub". Нам хотелось максимально автоматизировать процесс добавления новых пользователей, чтобы они сразу получали нужный набор разрешений для работы с проектом "PVS-Studio" (уровень разрешений "YouTrack"). Давайте посмотрим, как это было реализовано. Откроем свойства группы "Registered Users".

0853_Kanban_YouTrack_ru/image11.png

Видите, помимо роли "Observer" группе также назначена роль "Developer" в проекте "PVS-Studio". В YouTrack эта роль предлагается по умолчанию для работы с проектом. Она унаследована от родительской группы "All Users", для которой мы её назначили явно.

0853_Kanban_YouTrack_ru/image13.png

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

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

0853_Kanban_YouTrack_ru/image15.png

Ничего неожиданного. Видим ту же группу "All Users" и командную роль "Developer". Уровень доступа для участников команды можно настроить (ссылка "Edit"), задав одну или несколько ролей.

0853_Kanban_YouTrack_ru/image16.png

Наконец, чтобы увидеть, кто имеет доступ к проекту, необходимо перейти на соседнюю вкладку "Access" в свойствах проекта.

0853_Kanban_YouTrack_ru/image18.png

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

Роли могут быть дополнительно настроены. Так как у нас одна роль "Developer" для всех пользователей проекта, меняли только её настройки. Внесли незначительные правки для уровня разрешений "Hub", а именно: добавили возможность чтения групп. Это позволило пользователям при желании использовать группы в произвольных фильтрах задач. Обратите внимание, если настройка отличается от дефолтной (была изменена), это будет указано справа от чек-бокса.

0853_Kanban_YouTrack_ru/image20.png

Помимо этого, мы внесли изменения и для уровня доступа "YouTrack" роли "Developer". Разрешили вносить правки в чужие статьи внутреннего портала "Knowledge Base", а также удалять и обновлять комментарии к статьям. Запретили удалять задачи, такая возможность у нас доступна только администраторам. Также отключили видимость приватных полей. Пример такого поля у нас – сохраняемое значение таймера задачи (дата и время), которое используется при учёте затраченного времени.

0853_Kanban_YouTrack_ru/image21.png

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

Переходим к настройке ключевого компонента любого трекера – полям задачи.

Поля, теги

Изначально в YouTrack предполагалось создать такую же структуру полей, как в Bitbucket. А затем уже вносить изменения в соответствии с возникающими потребностями. Но просто так сделать это не удалось. Дело в том, что наша старая физическая kanban-доска была своего рода виртуальной надстройкой над Bitbucket. Поэтому многое из того, что мы использовали на физической доске (дополнительные состояния задачи, цвета карточек), просто отсутствовало в Bitbucket.

В свою очередь, электронная agile-доска в YouTrack базируется на сущностях, которые должны быть настроены в трекере. И доску мы хотели начать использовать сразу. Таким образом, стояла задача доработки привычной нам структуры полей с учётом отображения их на электронной доске, то есть некая компиляция полей Bitbucket и сущностей физической доски.

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

0853_Kanban_YouTrack_ru/image23.png

Project. Этого поля нет в списке, но оно всегда присутствует в карточке любой задачи и содержит имя проекта, к которому задача прикреплена. Мы работаем с единственным проектом "PVS-Studio".

Assignee. Исполнитель задачи, текущий ответственный. В перечисление типа "user" должны быть явным образом добавлены все пользователи, которые могут быть назначены исполнителями. Значения данного поля используются для наименования строк на электронной kanban-доске (отображение задач по ответственным).

State. Текущее состояние задачи. Может иметь значения:

Buffer — задача запланирована, но работы по ней ещё не проводились. Если для задачи в статусе Buffer не задан исполнитель, она считается находящейся в бэклоге;
In progress — задача в работе;
Review — задача открыта, находится на приёмке (проверке);
On hold — задача открыта, но работа над ней временно (на короткий период) приостановлена;
Resolved — задача решена и закрыта (проблема устранена, достигнут ожидаемый результат);
Suspend — над задачей работали, а затем отложили на длительный период. Далее к задаче планируют вернуться;
Wontfix — задача не решена, закрыта (не удалось решить по каким-то причинам, завели по ошибке и т.п.);
Duplicate — задача не решена, закрыта, так как имеется задача-дубликат.

Значения данного поля используются для наименования столбцов на электронной kanban-доске (отображение задач по ответственным).

Component. Направление работ по задаче, принадлежность задачи какому-либо отделу или подотделу разработки. Например, "Marketing", "Office", "C++ (Rules)", "C# (Core)" и т.п.

Type. Тип задачи: произвольная задача (Task), правка бага (Bug), подготовка мероприятия или доклада (Event), написание статьи (Article) и т.п.

Priority. Важность задачи, приоритет. Может иметь следующие значения (по росту приоритета): Minor, Normal, Major, Critical, Blocker.

Scope. "Скоуп" — диапазон рабочего времени (продолжительность в часах, днях или неделях), которое планируется затратить на выполнение задачи. Поле заполняется на этапе постановки. Если в ходе работ или при завершении задачи окажется, что на работу было затрачено значительно больше времени, чем планировалось, это будет поводом провести обсуждение. Учёт времени работы система ведёт автоматически, когда задача находится в статусе "In progress" или "Review" (поле "State"). Для этого необходимо включить ведение учёта времени в настройках проекта, а также настроить соответствующий рабочий процесс.

Spent time. Содержит диапазон рабочего времени, которое было фактически (суммарно) затрачено на выполнение задачи. Это второе поле, которое потребуется настроить при включении режима учёта времени в настройках проекта. Поле доступно в режиме только чтения. Затраченное на задачу время (единица работы) может быть добавлено двумя способами:

вручную при помощи комментария особого вида "Добавить затраченное время";
автоматически (комментарий о затраченном времени будет добавлен также автоматически). В этом режиме время учитывается только когда задача находится в работе (установлено значение "In progress" или "Review" в поле "State"). При переводе задачи в "не рабочее" состояние, например в "On hold" или "Resolved", время, которое задача находилась в работе, будет прибавлено к значению в поле "Spent time". Также время будет учтено при смене ответственного. Наконец, информация о затраченном времени для каждой задачи обновляется автоматически в 9:00 утра каждого рабочего дня. Момент (дата и время) последнего перехода фиксируется в служебном поле "TimerTime". Все это настроено в соответствующем рабочем процессе, о котором я расскажу далее.

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

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

0853_Kanban_YouTrack_ru/image24.png

TimerTime. Служебное поле, которое скрыто от пользователей. Хранит дату и время одного из последних событий: смена статуса задачи, смена ответственного. Применяется в рабочем процессе для учёта затраченного времени.

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

Для полей с типом перечисления (state или enum) есть дополнительная настройка – выбор цвета значения в поле. Цвета отображаются в списках задач и на досках. Пример такой настройки для поля "State":

0853_Kanban_YouTrack_ru/image25.png

Помимо полей, YouTrack предлагает возможность указания специальных меток для задач, называемых тегами. Могут быть задачи как без тегов, так и с несколькими тегами. Это весьма удобно и позволяет увеличить число различных комбинаций возможных состояний задачи. Замечу, что у полей с типом перечисления (enum) тоже есть возможность установки более одного значения, но работа именно с комбинациями полей и тегов кажется более эффективной. На данный момент мы используем около 18 тегов.

Вот так выглядит заголовок карточки задачи с тэгами.

0853_Kanban_YouTrack_ru/image26.png

Также обратите внимание на выделение цветом перечислимых полей в легенде этой же задачи.

0853_Kanban_YouTrack_ru/image27.png

По комбинации полей и тэгов данной задачи можно понять, что она назначена на Филиппа и временно отложена. Работы ведутся по направлению диагностик для языка C++ (причем идет работа над новой диагностикой по запросу клиента, так как установлены теги "New Rule" и "Client", а сама диагностика относится к классу "General Analysis"). Это обычная задача со средним приоритетом. Трудоемкость (скоуп) задачи на момент создания оценили в четыре рабочих дня (32 часа при восьмичасовом рабочем дне). При этом на работу с задачей уже потратили более 16 рабочих дней и это повод задуматься. :) Отсутствие значения в поле "TimerTime" говорит о том, что в данном состоянии (On hold) учёт времени не ведётся. Дедлайн задаче не задан.

А вот как выглядит список задач.

0853_Kanban_YouTrack_ru/image29.png

Кстати, список отфильтрован по задачам компонента С++ (для всех подотделов) при помощи запроса:

Component: {C++ *}

Запрос получает все задачи, значения компонента которых начинаются со строки "C++". Вообще, поисковые запросы YouTrack – одна из мощнейших возможностей. К тому же, это удобно и интуитивно понятно. Теги и поисковые запросы можно сохранять, настраивать для них оповещения, делиться ими с коллегами или использовать приватно. Мы ещё немного поговорим про запросы, когда доберёмся до рабочих процессов.

Все поля и теги задачи можно использовать в поисковых запросах, а также отчётах.

Kanban

Я столько говорил про электронные доски, что просто не могу не показать хотя бы одну. :) Вот фрагмент kanban-доски для команды C++ (отображение задач по ответственным).

0853_Kanban_YouTrack_ru/image31.png

Столбец "Resolved" свернут. Доска генерируется на базе запроса, который можно задать в ее настройках:

0853_Kanban_YouTrack_ru/image32.png

Таким образом, будут отображены все нерешённые задачи, а также задачи, закрытые после 11 марта 2021 года. Это дата одного из последних релизов. Мы решили ограничить период показа закрытых задач одним релизным циклом, чтобы не захламлять доску.

Также список задач будет дополнительно отфильтрован по пользователям, явно заданным для отображения в строках доски. Конечно, это не единственно возможный вариант. Не так давно мы начали использовать другое представление доски, при котором в строках указаны не сотрудники, а направления работы (отделы). Это позволяет больше сосредоточиться на задачах и их движении. Представление доски может быть настроено в соответствии с вашими потребностями.

Расскажу про одну важную особенность работы досок YouTrack. Первоначально мы настроили kanban в режиме "Automatically add new issues", который был предложен по умолчанию. Как и режим "Manually assign issues", он предполагает добавление задачи на доску, при котором между ними образуется связь. То есть задача будет буквально принадлежать доске. Но в этом режиме нет возможности, например, отфильтровать задачи в столбце "Resolved" по дате, как сделано у нас сейчас. Доска отображает все когда-либо добавленные на неё задачи. Это одна из причин, по которой мы не стали использовать первые два режима, а остановились на третьем. Также в режиме "Automatically add new issues" любая новая задача попадала сразу на все доски, что тоже не всегда удобно. Хотя для классического варианта работы с множеством проектов, ограниченных по времени, и одной доской на проект вариант "по умолчанию", наверное, удобнее. Он требует меньше дополнительных настроек.

Другие настройки доски тривиальны, так что больше рассказывать здесь нечего. Kanban — это одна из тех возможностей YouTrack "из коробки", которую можно начать использовать практически сразу. Чего нельзя сказать об учёте времени и настройке рабочих процессов. Переходим к наиболее интересной, на мой взгляд, части повествования.

Учёт времени и рабочие процессы

Наверное, учёт времени и рабочие процессы – это то, чего нам больше всего не хватало в Bitbucket после kanban-доски. Я объединил эти пункты, так как без настройки рабочих процессов учёт времени возможен только в ручном режиме.

Про рабочие процессы YouTrack подробно рассказано в документации. Если в двух словах, то это скрипты на JavaScript, которые позволяют автоматизировать различные виды деятельности в трекере. Предлагается набор рабочих процессов по умолчанию (на данный момент их более 35). Можно менять стандартные рабочие процессы, настраивая их для своих нужд. Любой стандартный рабочий процесс, если он был неудачно модифицирован, легко вернуть в исходное состояние. Можно создавать свои рабочие процессы, а также разделяемые рабочие процессы (для совместного использования из разных скриптов). В общем, есть определенный простор для творчества.

Мы использовали несколько рабочих процессов по умолчанию, которые показались нам необходимыми. Некоторые процессы модифицировали, а также добавили пару своих.

Учёт времени

Про учёт времени мы начали думать давно. Хотелось иметь хотя бы приблизительное понимание, сколько занимает работа над той или иной задачей. Почему иногда работа затягивается. И как-то анализировать всё это. В Bitbucket мы пытались указывать скоуп задачи прямо в заголовке, в квадратных скобках. Кстати, туда же мы добавляли и другую информацию, которую нельзя было указать в полях Bitbucket. Например, метку, что задача делается по запросу клиента. Заголовок задачи мог иметь вид: "[client][5 дней] Краткое описание задачи". Понятно, что Bitbucket никак не помогал в анализе этих псевдотегов. Поэтому у нас была разработана утилита, которая через API доставала из Bitbucket информацию и генерировала разные отчёты. Также при помощи этой утилиты мы оповещали пользователей о забытых задачах (по которым не было комментариев за последние три-четыре дня, например). В общем, пытались как-то настроить свои рабочие процессы.

Что касается учёта времени, то нам был доступен только ручной анализ задач по требованию. Нужно было смотреть дату создания задачи, искать псевдотег скоупа в описании (а его туда могли забыть добавить) и делать какие-то выводы. Очевидно нерабочая схема. Представьте себе нашу радость, когда мы увидели возможность настройки учёта времени в YouTrack практически за три клика. Всего-то и нужно было включить этот режим в настройках проекта, добавив пару полей.

0853_Kanban_YouTrack_ru/image34.png

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

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

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

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

Рабочие процессы

Список рабочих процессов, прикрепленных к проекту, можно увидеть в его свойствах. Вот наш текущий набор.

0853_Kanban_YouTrack_ru/image35.png

Полный список рабочих процессов можно посмотреть в глобальных настройках трекера. Каждый рабочий процесс может включать несколько правил (модулей). Помимо понятного названия у каждого процесса и его правил есть уникальное имя. Например, "assignee-state". Правила можно увидеть, если развернуть узел процесса.

0853_Kanban_YouTrack_ru/image36.png

Для правил имя соответствует файлу сценария js. Например, "check-assignee-state". Имена рабочих процессов с префиксом "@jetbrains/youtrack-workflow-" указывают на стандартные (предустановленные) рабочие процессы YouTrack.

Правило может быть одного из пяти типов:

On-change: применяется при изменении задачи;
On-schedule: применяется по расписанию;
State-machine: контролирует смену значений для настраиваемых полей;
Action: применяется при выборе пользователем действия (настраиваемой команды для интерфейса);
Custom: применяется при вызове из модулей других рабочих процессов.

Перейдем к списку наших рабочих процессов и разберем его.

Assignee and State

Нестандартный рабочий процесс (был добавлен нами), который содержит единственное правило типа "On-change":

Block users from setting an invalid assignee.

Правило отслеживает изменение полей "State" и "Assignee" у задачи и препятствует установке некорректной комбинации значений. Например, у задачи нет ответственного, при этом её пытаются взять в работу или сразу закрыть. В этом случае скрипт выведет сообщение об ошибке, а изменения не будут зафиксированы. В YouTrack есть стандартный рабочий процесс "Issue Property Combinations" с похожей функциональностью. Но мы решили, что удобнее будет не модифицировать имеющийся, а сделать свой рабочий процесс. Почему бы и нет? К тому же, данный рабочий процесс использует имена настраиваемых полей, заданные в YouTrack по умолчанию. Мы же заменили многие имена полей на более подходящие, на наш взгляд. Это также осложнило бы модификацию стандартного рабочего процесса.

Assignee Visibility

Стандартный (предустановленный) рабочий процесс, состоящий из единственного правила типа "On-change":

Warn when issue is not visible to assignee.

Правило проверяет, чтобы назначаемый ответственный имел доступ к задаче. Ситуация типична для команд, в которых ведётся несколько проектов, доступ к каждому из которых контролируется на уровне групп пользователей. Если пользователя забудут включить в соответствующую группу, он не сможет открыть задачу. Такое лучше проверять на этапе назначения ответственного, что и делает правило. Это не очень актуально для нас, так как при использовании одного проекта, к которому по умолчанию имеют доступ все пользователи, описанная ситуация маловероятна. Тем не менее, правило было предложено к использованию по умолчанию, и мы решили оставить его "на всякий случай".

Common

Нестандартный рабочий процесс, который содержит три модуля:

common-datetime (тип "Custom");
common-users (тип "Custom");
DEBUG ACTION (тип "Action").

Для первых двух модулей я привел имена вместо понятных названий. Дело в том, что эти модули содержат разделяемый код, на который ссылаются другие правила. У таких модулей нет понятных названий. Третий модуль отладочный, поэтому для него необязательно (хотя и возможно) указание понятного названия, поэтому я указал такое. Модуль при этом называется "common-debug-action".

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

Модуль "common-users" содержит код, автоматизирующий отправку пользователям критичных уведомлений из других правил. Это уведомления, например, о превышении дедлайна задачи. Также сюда относятся уведомления о забытых задачах, то есть задачах, по которым не было активности (комментариев) за последнее время. Мы решили, что более эффективно отправлять такие уведомления не только ответственному за задачу, но и его руководителю. Я уже упоминал про это в контексте описания групп пользователей.

Наконец, модуль "DEBUG ACTION", как можно догадаться из названия, предназначен для отладки. Это правило типа "Action". При помощи таких правил в YouTrack можно создавать быстрые действия для задач. Список действий доступен в меню карточки задачи при выборе пункта "троеточие".

0853_Kanban_YouTrack_ru/image38.png

Также действие может быть выбрано и выполнено в окне действий:

0853_Kanban_YouTrack_ru/image40.png

При выборе действия будет сразу же выполнен определенный код. Видимостью таких правил (пунктов меню) можно управлять. Например, отладочное действие "DEBUG ACTION" отображается только для пользователя с определенным именем (меня). Также можно настроить, например, отображение действий лишь при создании новых задач и т.п.

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

Dependencies

Стандартный рабочий процесс, включающий единственное правило типа "On-change":

Block users from resolving issues with unresolved dependencies.

Правило контролирует работу связанных задач, а именно связи типа "Depend" (depends on — is required for). При такой связи предполагается, что одна задача зависит от другой и не может быть закрыта, пока другая задача находится в работе. Мы используем связи между задачами, поэтому данное правило полезно.

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

Про связи (ссылки) между задачами можно почитать в документации.

Due Date

Еще один стандартный рабочий процесс. Предназначен для работы с дедлайном задачи. По умолчанию он содержит два правила, но мы решили ограничиться только вторым:

Require due dates for submitted issues (не используем);
Notify assignee about overdue issues.

Первое правило типа "On-change" требует обязательной установки значения в поле "Due Date" при создании задачи. Мы не стали вводить такое жёсткое требование, поэтому правило было отключено.

Второе правило, которое посчитали полезным, мы используем для оповещения ответственного и его руководителя в случае, если дедлайн задачи превышен. Это правило относится к типу "On-schedule". Оно позволяет обрабатывать задачи по расписанию (параметр "cron"). Список задач будет получен при помощи поискового запроса (параметр "search"). Мы немного доработали это правило, добавив дополнительное условие выполнения только по рабочим дням, так как выполнение по расписанию ограничивает выполнение задачи рабочими днями с понедельника по пятницу, но не учитывает выходные и праздничные дни. Для этого используются функции проверки из разделяемого модуля "common-datetime". В дополнение к этому, как уже говорилось ранее, мы используем расширенную функцию рассылки уведомлений из модуля "common-users".

Duplicates

Стандартный рабочий процесс, который управляет поведением задач-дубликатов. Мы не так часто создаем задачи-дубликаты, но иногда такое всё же случается. Поэтому этот рабочий процесс был подключен к проекту. По умолчанию он содержит пять правил типа "On-change" (одно из правил мы не используем):

Attach duplicate links to single duplicated issue;
Raise priority when issue is duplicated by another issue (не используем);
Reopen issue when all duplicates links are removed;
Set state to "Duplicate" when duplicates link is added to issue;
Require links to duplicate issue when state becomes "Duplicate".

Задача в YouTrack может быть отмечена как дубликат другой задачи двумя способами:

установка дублирующей задаче статуса "Duplicate". При этом необходимо обеспечить установку связи типа "Duplicate" (duplicates — is duplicated by) между задачами;
обратная ситуация: установка связи типа "Duplicate" между задачами. Здесь необходимо обеспечить установку статуса "Duplicate" дублирующей задаче.

Также необходимо обеспечить корректное поведение при удалении связи между задачами-дубликатами или при смене статуса "Duplicate" задачи на другой. Все эти нюансы контролирует рабочий процесс. Мы не вносили значительных правок в правила данного рабочего процесса. А те, что вносили, были связаны с использованием других названий у статусов задачи (отличных от имён по умолчанию).

In Progress Work Timer

Мы подошли к стандартному рабочему процессу, настройка которого потребовала несколько больше усилий, чем представлялось сначала. Как я уже говорил ранее, нам хотелось попробовать учёт времени и мы были рады увидеть такую возможность в списке предустановленных. Однако реализация "из коробки" не вполне нас устроила.

По умолчанию процесс включает два правила типа "On-change":

Start timer when issue is in progress;
Stop timer when issue is fixed.

Первое правило отслеживает изменение статуса задачи. При установке значения "In Progress" (задача взята в работу) в служебное поле "Timer Time" задачи будут записаны текущие дата и время. Когда работа над задачей будет завершена (статус сменят с "In Progress" на любой другой), автоматически добавится единица работы. Это делает скрипт второго правила. Затраченное время будет подсчитано как разница в минутах между текущей датой и значением, сохраненным ранее в поле "Timer Time" задачи. Алгоритм выглядит достаточно просто, при этом он имеет недостатки:

предполагается наличие только одного "рабочего" состояния задачи — "In Progress". У нас есть дополнительные состояния, когда требуется учёт времени, например "Review". Эти состояния были дополнительно учтены в скриптах (достаточно простые правки);
в первоначальном варианте скрипта "Stop timer when issue is fixed" при добавлении единицы работы в качестве автора (исполнителя) будет указан текущий пользователь YouTrack (ctx.currentUser). Это проблема, так как часто задачи может закрывать тимлид. Тогда единица работы будет записана на него. Никак не влияет на подсчет суммарного затраченного на задачу времени, но делает бессмысленным работу с отчётом по единицам работы: удобный встроенный отчет, который позволяет увидеть конкретный вклад каждого сотрудника в работу над задачами. Наш вариант правки скрипта предполагает использование текущего ответственного по задаче при создании единицы работы. Наличие ответственного у задач, находящихся в работе, контролирует описанный ранее рабочий процесс "Assignee and State";
не учитывается смена ответственного. Над задачей могло последовательно работать несколько сотрудников, но при ее закрытии всё рабочее время будет зачислено на того, кто закрыл задачу. Для решения этой проблемы мы добавили дополнительный модуль с именем "Restart timer when the assignee is changed". Это несложное правило отслеживает смену ответственного у задач, находящихся в работе. При этом единица работы создаётся для предыдущего ответственного и учитывается время, которое именно он затратил на работу. Таймер перезапускается;
скорее, улучшение, а не решение какой-то проблемы. Если задача долго (например, несколько дней) находится в работе у одного ответственного, то нет наглядного отображения того, сколько времени уже было затрачено. Ведь единица работы будет добавлена только при смене статуса или ответственного. И только тогда будет пересчитан общий показатель затраченного на задачу времени, что будет отражено на графическом индикаторе в списке задач:

0853_Kanban_YouTrack_ru/image41.png

Допустим, задачу забыли в статусе "In Progress" и работают с другой. Потом про задачу вспомнили и решили ее закрыть. При этом будет начислен большой интервал рабочего времени, в который фактически ничего не делали. Это нестрашно, так как ранее созданные единицы работы для задачи можно править (вручную менять значение начисленного времени). Но мы же хотим полной автоматизации, не так ли? :) Поэтому мы добавили ещё одно небольшое правило типа "On-schedule" с именем "Update timer on schedule". Каждое утро по рабочим дням это правило перезапускает таймер для задач, находящихся в работе. Конечно, это приводит к ежедневному созданию единицы работы. Зато по любой задаче всегда можно посмотреть актуальное значение затраченного времени с точностью до одного дня;

при добавлении единицы работы в правиле "Stop timer when issue is fixed" используют встроенную функцию "intervalToWorkingMinutes" из класса "Project" для подсчета разницы в минутах между двумя датами. Функция использует минимальный набор настроек YouTrack для учёта времени:

0853_Kanban_YouTrack_ru/image42.png

Учитывается только продолжительность рабочего дня и дни недели, указанные как рабочие. Не учитываются начало и конец рабочего дня, продолжительность обеденного перерыва, праздничные дни. Поэтому, несмотря на то, что функция вернёт результат в минутах, он будет достаточно приблизительный. Например, в вашей компании (как у нас) рабочий день начинается в 9:00 и закачивается в 18:00. Вы берете задачу в работу во вторник вечером в 17:45. Утром следующего дня, в среду, вы продолжаете работу над задачей и закрываете ее в 9:15. При использовании функции "intervalToWorkingMinutes" результат составит восемь с половиной рабочих часов (510 минут). Это нормально, так как переход задачи на следующий день сразу же даст нам один рабочий день (1*8*60 = 480 минут). Плюс дополнительное время в минутах для выравнивания до полного часа (15 + 15).

Нам хотелось большей точности, поэтому мы написали свой вариант функции "intervalToWorkingMinutes", которая удовлетворяет нашим условиям. Для указанного выше примера она вернёт 30 минут. Также в отдельную функцию мы вынесли проверку переданной даты не только на то, что это выходной день (суббота или воскресенье), но и на то, что это день, объявленный нерабочим праздничным в нашей стране. Это удобно для использования как при расчёте разницы между двумя датами, так и при рассылке уведомлений пользователям из других рабочих процессов (например, "Due Date"), чтобы не тревожить их письмами в нерабочее время. Обе функции помещены в разделяемый модуль "common-datetime".

Таким образом, с учётом всех модификаций, стандартный рабочий процесс "In Progress Work Timer" у нас был расширен до четырех правил:

Start timer when issue is in progress;
Stop timer when issue is fixed (было переименовано в "Stop timer when the issue is resolved or paused");
Update timer on schedule (правило было добавлено);
Restart timer when the assignee is changed (правило было добавлено).

Может показаться, что мы немного увлеклись учётом времени, и отчасти это так. Но сам YouTrack подталкивает к тому, чтобы максимально кастомизировать рабочие процессы, поэтому мы не смогли устоять :)

К тому же, все эти правки и улучшения были сделаны не одномоментно. Мы и сейчас время от времени там что-то подкручиваем. Расскажу про одну интересную ошибку, с которой мы столкнулись уже после начала активного использования этого рабочего процесса. Это ошибка (или особенность работы) самого трекера. Речь про поле "Scope", которое содержит скоуп задачи.

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

0853_Kanban_YouTrack_ru/image44.png

У второй и пятой задачи наблюдается указанная проблема. Опытным путем мы выяснили, что нужно явно указывать значение в поле "Scope". При этом что-то происходит "под капотом" YouTrack, и далее это значение будет корректно учтено. Пришлось отказаться от использования дефолтного значения. К тому же, требование обязательно указать скоуп задачи полезно, так как побуждает к проведению большего анализа на этапе постановки задачи. Возможно, это известная проблема и разработчики её уже устранили. Я поленился подробно изучать данный вопрос.

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

Простой пример – введение практики своевременного перевода задач, над которыми приостановлена работа, в статус отложенных (для остановки таймера) и наоборот. Своевременность переключения статусов позволяет иметь более точную картину происходящего. Но у этого, казалось бы, очевидного подхода есть и обратная сторона. С первых дней использования сотрудники пытались взломать систему: реальная работа часто велась над отложенными задачами (On hold), так как там "не тикает таймер и не портит статистику". Поэтому поначалу можно было наблюдать картину, как команда буквально ни над чем не работает – было всего несколько задач в работе.

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

Overdue work activities

Нестандартный рабочий процесс, включающий единственное правило типа "On-schedule":

Notify assignee on overdue work activities.

По принципу работы этот модуль очень похож на описанный выше модуль "Notify assignee about overdue issues" из рабочего процесса "Due Date". Но здесь мы регулярно оповещаем ответственного и его руководителя в случае, если по задаче не было комментариев за какой-то период. Для этого используется поисковый запрос вида:

State:{In progress},Review
  commented:-{minus 3d}..Today
  created:-{minus 1d}..Today

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

Subtasks

Стандартный рабочий процесс. По умолчанию содержит набор из двух правил типа "On-change", автоматизирующих работу с подзадачами:

Open parent task when subtask changes to an unresolved state;
Fix parent task when all subtasks are resolved (не используем).

Для создания иерархии задач в YouTrack используется связь типа "Subtask" (subtask of — parent for). Про связи я уже говорил при описании рабочего процесса "Dependencies". Работа с подзадачами очень удобна и это одна из возможностей, которых нам не хватало в Bitbucket. Интересное наблюдение: в YouTrack мы наблюдаем большее число задач (в среднем по компании), находящихся в работе в единицу времени, по сравнению с Bitbucket. При сопоставимом числе сотрудников. Я думаю, что одна из причин – активное использование подзадач в YouTrack, что даёт возможность более простой декомпозиции. Но вернёмся к правилам.

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

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

Зато нам не хватило другой возможности: запрещать пользователям закрывать родительскую задачу, если есть хотя бы одна подзадача в работе. Для этого мы расширили стандартный рабочий процесс, добавив свое правило "Block users from resolving issues with unresolved subtasks".

На этом я заканчиваю описание наших рабочих процессов. Возможно, получилось несколько затянуто. Но мне хотелось показать, насколько удобно вы можете настроить YouTrack под себя, даже для нестандартных режимов работы. Кажется, нам это удалось.

Отчёты

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

Тем не менее, мы настолько привыкли к своему старому формату отчётов (в Bitbucket использовали собственный генератор отчётов), что решили не отказываться от него. Тем более, в YouTrack есть все возможности для доступа к задачам через API. Таким образом, на данный момент каждый заинтересованный сотрудник может настраивать и использовать любые встроенные отчёты YouTrack. В дополнение к этому каждый месяц менеджеры получают большой сводный отчёт "старого образца".

Обучение сотрудников

Напоследок немного расскажу, как происходило внедрение нового трекера с точки зрения команды. Это не первый наш подобный инструмент, поэтому именно с интерфейсом YouTrack особых проблем у пользователей не возникало. Да, там довольно много возможностей, и поначалу теряешься в обилии кнопочек. Но это не проблема. В последнее время команда YouTrack делает определенные шаги по упрощению интерфейса: был введен облегченный режим "Light", изменена структура меню и т.п. Ранее я слышал много отзывов о сложности YouTrack для пользователя и частично согласен с ними. Но повторюсь, что разобраться и привыкнуть к этому инструменту — просто вопрос времени.

Другое дело – смена подхода к организации рабочих процессов, серьезная переработка структуры полей, связи задач, добавление учёта времени. Всё то, что команда внедрения проделывала постепенно и успела освоить, было представлено остальным сотрудникам практически одномоментно. Новшества потребовали от людей дополнительных усилий, что не всегда воспринималось положительно. Понадобилось две больших презентации для сотрудников по разъяснению общих принципов работы с новым трекером. До настоящего времени ведётся планомерная работа с вопросами и возражениями.

Еще хочется оставить тут пасхалку для наших сотрудников. Одна из идей написания данной статьи – дополнительное ознакомление внутренних пользователей с особенностями YouTrack. Прилежный сотрудник PVS-Studio, если ты дочитал до этого момента и готов ответить на дополнительные вопросы о прочитанном, подходи ко мне за подарком. :)

Заключение

Оглядываясь назад, я испытываю гордость и удовлетворение от проделанной работы. Думаю, что и другие сотрудники, которые принимали участие в работах по внедрению kanban и переходу на YouTrack, испытывают подобные чувства. Завершён важный этап на пути развития нашей компании. Это был непростой, но очень увлекательный процесс. Пришлось решать много административных и технических задач: проводить встречи и обсуждения, согласовывать сроки и отстаивать своё видение процессов, программировать на JavaScript.

Хочу поблагодарить всех причастных и пожелать нам всем не расслабляться. Мы ещё только в начале пути. И это здорово!

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Khrenov. PVS-Studio team's kanban board. Part 2: YouTrack.

Kanban команды PVS-Studio. Часть 2: YouTrack