Мы используем куки, чтобы пользоваться сайтом
было удобно.
Мы ответим вам на
Если вы так и не получили ответ, пожалуйста, проверьте, отфильтровано ли письмо в одну из следующих стандартных папок:
Привет всем. Это продолжение истории про переход команды PVS-Studio на работу по методике kanban. На этот раз речь пойдет про YouTrack, как мы выбирали и внедряли этот трекер задач и с какими вызовами столкнулись в процессе. Статья не имеет цели рекламировать или ругать YouTrack. Тем не менее замечу, что по мнению нашей команды ребята из JetBrains проделали (и продолжают делать) отличную работу.
Про историю перехода на kanban и о предпосылках смены трекера задач я рассказывал в предыдущей статье "Kanban команды PVS-Studio. Часть 1: agile". Рекомендую ознакомиться с ней для лучшего понимания некоторых аспектов текущей статьи. Также хочу заметить, что здесь я не планирую подробно рассказывать обо всех особенностях YouTrack, так как их очень много. При желании вы можете заглянуть в документацию и убедиться в этом сами. Думаю, статья будет интересна в первую очередь тем, кто планирует или уже использует этот трекер.
Если вам не хочется читать первую часть статьи, то вот краткая предыстория. После внедрения методики kanban нам очень понравилась идея использования kanban-доски для проведения ежедневных митингов. Однако в связи с переходом на удаленный режим работы наша первоначальная физическая доска оказалась не у дел. Немного помучавшись, мы решили форсировать работы по выбору и внедрению альтернативного трекера задач на замену Bitbucket. При выборе отдавалось предпочтение инструментам с электронной доской. На самом деле, выбор изначально был между YouTrack и чем-то другим, так как YouTrack активно лоббировался тимлидом нашей С++ команды (Филипп, привет). В качестве основного конкурента YouTrack рассматривали Jira, но в итоге остановились всё же на YouTrack.
Bitbucket в команде PVS-Studio мы использовали с середины 2014 года. Долгое время он нас вполне устраивал. Но с ростом размера компании мы столкнулись с рядом неудобств, вызванных отсутствием или сложностью реализации некоторых возможностей:
Даже при поверхностном изучении 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. Но основная работа носила административный характер:
Далее в ходе изложения я буду придерживаться этого плана работ.
Основной вопрос перехода на YouTrack для нас состоял в том, какую часть команды мигрировать вначале. Переводить сразу всех мы опасались. Слишком много доработок пришлось бы делать с участием большого количества пользователей. Выбор пал на отдел маркетинга. Во-первых, это отдел, который наравне с разработчиками уже давно привык использовать kanban в повседневной работе. Во-вторых, там около десяти сотрудников, а этого вполне достаточно чтобы опробовать все основные сценарии работы с новым трекером. Наконец, их было просто не так жалко наш отдел маркетинга очень креативен и весьма гибок по части нововведений. Хочу выразить отдельное спасибо руководителю отдела Екатерине за бесконечное терпение и поддержку на этапе экспериментов с YouTrack. :)
Другой вопрос заключался в том, делать ли нам один проект на всю команду или разделить проекты по направлениям работы (отделам). YouTrack предлагает удобные средства для работы с несколькими проектами одновременно, и поначалу нам показалась разумной идея отделить разработку от маркетинга. Можно было бы разделить сущности и таким образом уменьшить общий объём значений в полях, количество тэгов и т. п., что в итоге упростило бы работу с трекером для пользователей. Но был очень важный аргумент против: наши задачи постоянно переназначаются между сотрудниками маркетинга и разработкой. Пример – задача про написание статьи. Первоначально статья пишется, допустим, разработчиком отдела С++. Далее она попадает на сотрудников отдела маркетинга для вычитывания и перевода. Затем снова возвращается автору для публикации. Наконец, после публикации задача вновь назначается на отдел маркетинга для дальнейшего продвижения в соцсетях и на тематических сайтах. Таким образом, наличие двух проектов осложнило бы процесс совместной работы. YouTrack умеет перемещать задачи между проектами, но при этом рекомендуется соблюдать соответствие между полями проектов. А ещё есть рабочие процессы, которые привязаны к проекту и также зависят от полей.
В итоге мы решили создать один общий проект и сразу настраивать его с учётом возможности одновременной работы всех команд. А переход начать с отдела маркетинга. Так третьего декабря 2020 года был создан проект "Marketing", впоследствии переименованный в "PVS-Studio".
Идеология работы с пользователями, группами и правами доступа (ролями) в YouTrack довольно проста, но имеет особенности. Поэтому я остановлюсь на этом вопросе подробнее. Начнём с иерархии.
Облачная реализация YouTrack является одним из сервисов в инфраструктуре JetBrains для командных продуктов. Все такие сервисы объединены в единое целое, могут управляться и обмениваться данными через связующий сервис верхнего уровня JetBrains Hub. Там же содержатся все общие настройки, такие как глобальные права доступа, пользователи, группы. Они называются ресурсами.
Родительским для всех проектов является проект c именем "Global". Все создаваемые группы по умолчанию предлагается добавлять как ресурсы к этому проекту. Это позволит использовать их во всех дочерних проектах. Вы можете ограничить видимость группы, добавив ее в конкретный проект.
Иерархия групп по умолчанию представлена родительской группой "All Users", куда включены вообще все пользователи. Также есть подгруппа "Registered Users" с признаком автоматического добавления в нее новых пользователей после регистрации. Группы пользователей YouTrack можно использовать для разграничения доступа, в запросах на выборку задач, в рабочих процессах.
Так как мы решили использовать один проект, задача разграничения доступа при помощи групп у нас не стояла. Тем не менее мы добавили несколько групп, которые отражают структуру отделов компании.
Эти группы мы используем главным образом при рассылке уведомлений из рабочих процессов, чтобы уведомление, например, о просроченной задаче получал не только сотрудник, но и его непосредственный руководитель. Реализовали это просто. В группу "Managers" включены все тимлиды. Группа каждого отдела, помимо сотрудников, также содержит одного или нескольких тимлидов. При отправке уведомления пользователю проверяем, в какой группе тот состоит. Если в группе "Managers", то сообщение получит только он. Иначе, производится поиск рабочей группы пользователя. Уведомление получит как пользователь, так и все тимлиды, состоящие в его рабочей группе. Более подробно про наши рабочие процессы я расскажу далее.
Вернёмся к списку групп. Обратите внимание, все группы относятся к проекту "Global" (являются его ресурсами), а группе "Registered Users" назначена роль "Global Observer". Роль в YouTrack – это именованный набор (контейнер) разрешений двух типов: "Hub" и "YouTrack". Тип "Hub" содержит доступы для работы с глобальными сущностями: группы, проекты, роли, пользователи и т.п. Тип "YouTrack" предназначен для настройки доступа к возможностям трекера: работа с задачами (создание, комментирование, добавление вложений и т.п.), отчёты, сохраненные списки и т.п. Мы не стали создавать дополнительных ролей. Имеющихся по умолчанию вполне хватает для работы.
Каждый новый пользователь будет автоматически добавлен в группу "Registered Users" и в соответствии с ролью "Global Observer" получит минимальный набор из трёх разрешений.
Это разрешения уровня "Hub". Нам хотелось максимально автоматизировать процесс добавления новых пользователей, чтобы они сразу получали нужный набор разрешений для работы с проектом "PVS-Studio" (уровень разрешений "YouTrack"). Давайте посмотрим, как это было реализовано. Откроем свойства группы "Registered Users".
Видите, помимо роли "Observer" группе также назначена роль "Developer" в проекте "PVS-Studio". В YouTrack эта роль предлагается по умолчанию для работы с проектом. Она унаследована от родительской группы "All Users", для которой мы её назначили явно.
В общем, довольно бесхитростно. Это были настройки непосредственно групп. Давайте ещё посмотрим, как это выглядит в настройках проекта, чтобы получить полную картину с разрешениями в YouTrack.
У проекта есть такое понятие, как команда. Это группа пользователей, которые могут работать с проектом в соответствии с заданными ролями. У нашего проекта эта настройка выглядит так.
Ничего неожиданного. Видим ту же группу "All Users" и командную роль "Developer". Уровень доступа для участников команды можно настроить (ссылка "Edit"), задав одну или несколько ролей.
Наконец, чтобы увидеть, кто имеет доступ к проекту, необходимо перейти на соседнюю вкладку "Access" в свойствах проекта.
Здесь отображаются не только командные доступы, но и назначенные напрямую роли, а также глобальные доступы.
Роли могут быть дополнительно настроены. Так как у нас одна роль "Developer" для всех пользователей проекта, меняли только её настройки. Внесли незначительные правки для уровня разрешений "Hub", а именно: добавили возможность чтения групп. Это позволило пользователям при желании использовать группы в произвольных фильтрах задач. Обратите внимание, если настройка отличается от дефолтной (была изменена), это будет указано справа от чек-бокса.
Помимо этого, мы внесли изменения и для уровня доступа "YouTrack" роли "Developer". Разрешили вносить правки в чужие статьи внутреннего портала "Knowledge Base", а также удалять и обновлять комментарии к статьям. Запретили удалять задачи, такая возможность у нас доступна только администраторам. Также отключили видимость приватных полей. Пример такого поля у нас – сохраняемое значение таймера задачи (дата и время), которое используется при учёте затраченного времени.
Ну и пара слов про пользователей. Задача создания пользователей и назначения им прав достаточно тривиальна. Нужно запросить требуемое число лицензий в глобальных настройках трекера, создать пользователей, задать им email и временные пароли. Кстати, YouTrack не учитывает лицензии для заблокированных пользователей. Это позволило нам на начальном этапе миграции создать всю структуру компании, а разблокированными оставить только пользователей-маркетологов, не запрашивая дополнительных лицензий до момента миграции всех остальных.
Переходим к настройке ключевого компонента любого трекера – полям задачи.
Изначально в YouTrack предполагалось создать такую же структуру полей, как в Bitbucket. А затем уже вносить изменения в соответствии с возникающими потребностями. Но просто так сделать это не удалось. Дело в том, что наша старая физическая kanban-доска была своего рода виртуальной надстройкой над Bitbucket. Поэтому многое из того, что мы использовали на физической доске (дополнительные состояния задачи, цвета карточек), просто отсутствовало в Bitbucket.
В свою очередь, электронная agile-доска в YouTrack базируется на сущностях, которые должны быть настроены в трекере. И доску мы хотели начать использовать сразу. Таким образом, стояла задача доработки привычной нам структуры полей с учётом отображения их на электронной доске, то есть некая компиляция полей Bitbucket и сущностей физической доски.
Не буду утомлять подробным описанием процесса сопоставления полей и выбора оптимальной конфигурации. После довольно продолжительного периода доработок нам удалось зафиксировать набор полей, удовлетворяющий всем требованиям. Также отмечу, что для некоторых рабочих процессов YouTrack нужны дополнительно настроенные (служебные) поля. Приведу текущий вариант наших полей в YouTrack и кратко расскажу о них.
Project. Этого поля нет в списке, но оно всегда присутствует в карточке любой задачи и содержит имя проекта, к которому задача прикреплена. Мы работаем с единственным проектом "PVS-Studio".
Assignee. Исполнитель задачи, текущий ответственный. В перечисление типа "user" должны быть явным образом добавлены все пользователи, которые могут быть назначены исполнителями. Значения данного поля используются для наименования строк на электронной kanban-доске (отображение задач по ответственным).
State. Текущее состояние задачи. Может иметь значения:
Значения данного поля используются для наименования столбцов на электронной 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. Содержит диапазон рабочего времени, которое было фактически (суммарно) затрачено на выполнение задачи. Это второе поле, которое потребуется настроить при включении режима учёта времени в настройках проекта. Поле доступно в режиме только чтения. Затраченное на задачу время (единица работы) может быть добавлено двумя способами:
Идеология добавления единицы работы очень удобна, так как позволяет указать не только затраченное время, но и пользователя, который выполнил свою часть работы по задаче. Как я упоминал ранее, эту информацию можно использовать в специальных отчётах для получения полной картины вклада каждого сотрудника в работу над задачами.
Если значение в данном поле превышает значение, указанное в поле "Scope", специальный графический индикатор затраченного времени для задачи будет окрашен в красный цвет (отображается в карточке задачи и списке задач). Если превышения нет, графический индикатор отображает круговую пропорцию между потраченным и оставшимся временем.
TimerTime. Служебное поле, которое скрыто от пользователей. Хранит дату и время одного из последних событий: смена статуса задачи, смена ответственного. Применяется в рабочем процессе для учёта затраченного времени.
Due Date. Содержит дату и время, по достижении которых задача должна быть решена (закрыта). Если в этом поле задано значение и к моменту наступления указанной даты задача не закрыта, ответственный за задачу (а также его руководитель) начнёт получать ежедневные уведомления на почту. Данное поведение также настроено при помощи рабочего процесса.
Для полей с типом перечисления (state или enum) есть дополнительная настройка – выбор цвета значения в поле. Цвета отображаются в списках задач и на досках. Пример такой настройки для поля "State":
Помимо полей, YouTrack предлагает возможность указания специальных меток для задач, называемых тегами. Могут быть задачи как без тегов, так и с несколькими тегами. Это весьма удобно и позволяет увеличить число различных комбинаций возможных состояний задачи. Замечу, что у полей с типом перечисления (enum) тоже есть возможность установки более одного значения, но работа именно с комбинациями полей и тегов кажется более эффективной. На данный момент мы используем около 18 тегов.
Вот так выглядит заголовок карточки задачи с тэгами.
Также обратите внимание на выделение цветом перечислимых полей в легенде этой же задачи.
По комбинации полей и тэгов данной задачи можно понять, что она назначена на Филиппа и временно отложена. Работы ведутся по направлению диагностик для языка C++ (причем идет работа над новой диагностикой по запросу клиента, так как установлены теги "New Rule" и "Client", а сама диагностика относится к классу "General Analysis"). Это обычная задача со средним приоритетом. Трудоемкость (скоуп) задачи на момент создания оценили в четыре рабочих дня (32 часа при восьмичасовом рабочем дне). При этом на работу с задачей уже потратили более 16 рабочих дней и это повод задуматься. :) Отсутствие значения в поле "TimerTime" говорит о том, что в данном состоянии (On hold) учёт времени не ведётся. Дедлайн задаче не задан.
А вот как выглядит список задач.
Кстати, список отфильтрован по задачам компонента С++ (для всех подотделов) при помощи запроса:
Component: {C++ *}Запрос получает все задачи, значения компонента которых начинаются со строки "C++". Вообще, поисковые запросы YouTrack – одна из мощнейших возможностей. К тому же, это удобно и интуитивно понятно. Теги и поисковые запросы можно сохранять, настраивать для них оповещения, делиться ими с коллегами или использовать приватно. Мы ещё немного поговорим про запросы, когда доберёмся до рабочих процессов.
Все поля и теги задачи можно использовать в поисковых запросах, а также отчётах.
Я столько говорил про электронные доски, что просто не могу не показать хотя бы одну. :) Вот фрагмент kanban-доски для команды C++ (отображение задач по ответственным).
Столбец "Resolved" свернут. Доска генерируется на базе запроса, который можно задать в ее настройках:
Таким образом, будут отображены все нерешённые задачи, а также задачи, закрытые после 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 практически за три клика. Всего-то и нужно было включить этот режим в настройках проекта, добавив пару полей.
Сразу после этого в задачах появляется возможность вручную добавлять так называемые единицы работы, а также пользоваться специальными отчётами. Я упоминал про это, когда приводил описание полей. Кстати, единицы работы можно настраивать, задавая свои типы работ. Таким образом, будет видно, какую именно работу делал пользователь в рамках задачи в течение указанного периода.
Но если остановиться только на этом этапе и больше ничего не настраивать, то вся ответственность за фиксацию затраченного времени ложится на пользователей. Поработав над задачей, сотрудник должен самостоятельно добавить единицу работы и указать затраченное время в карточке задачи. Часто люди забывают или банально ленятся делать такие вещи. Поэтому YouTrack предлагает автоматизацию. Для этого на выбор предлагается два стандартных рабочих процесса с несколько разными подходами:
Второй рабочий процесс более приближен к ручному режиму, но даже такой полуавтоматический вариант работы значительно лучше ручного. Пользователь должен по-прежнему инициировать процесс, но ему не нужно самостоятельно подсчитывать время, затраченное на работу, так как за него это сделает скрипт.
Мы выбрали первый вариант работы с таймером, который предлагает полную автоматизацию, но и требует гораздо больших усилий для настройки. Подробно про работу этого и других рабочих процессов читайте в следующем разделе.
Список рабочих процессов, прикрепленных к проекту, можно увидеть в его свойствах. Вот наш текущий набор.
Полный список рабочих процессов можно посмотреть в глобальных настройках трекера. Каждый рабочий процесс может включать несколько правил (модулей). Помимо понятного названия у каждого процесса и его правил есть уникальное имя. Например, "assignee-state". Правила можно увидеть, если развернуть узел процесса.
Для правил имя соответствует файлу сценария js. Например, "check-assignee-state". Имена рабочих процессов с префиксом "@jetbrains/youtrack-workflow-" указывают на стандартные (предустановленные) рабочие процессы YouTrack.
Правило может быть одного из пяти типов:
Перейдем к списку наших рабочих процессов и разберем его.
Assignee and State
Нестандартный рабочий процесс (был добавлен нами), который содержит единственное правило типа "On-change":
Правило отслеживает изменение полей "State" и "Assignee" у задачи и препятствует установке некорректной комбинации значений. Например, у задачи нет ответственного, при этом её пытаются взять в работу или сразу закрыть. В этом случае скрипт выведет сообщение об ошибке, а изменения не будут зафиксированы. В YouTrack есть стандартный рабочий процесс "Issue Property Combinations" с похожей функциональностью. Но мы решили, что удобнее будет не модифицировать имеющийся, а сделать свой рабочий процесс. Почему бы и нет? К тому же, данный рабочий процесс использует имена настраиваемых полей, заданные в YouTrack по умолчанию. Мы же заменили многие имена полей на более подходящие, на наш взгляд. Это также осложнило бы модификацию стандартного рабочего процесса.
Assignee Visibility
Стандартный (предустановленный) рабочий процесс, состоящий из единственного правила типа "On-change":
Правило проверяет, чтобы назначаемый ответственный имел доступ к задаче. Ситуация типична для команд, в которых ведётся несколько проектов, доступ к каждому из которых контролируется на уровне групп пользователей. Если пользователя забудут включить в соответствующую группу, он не сможет открыть задачу. Такое лучше проверять на этапе назначения ответственного, что и делает правило. Это не очень актуально для нас, так как при использовании одного проекта, к которому по умолчанию имеют доступ все пользователи, описанная ситуация маловероятна. Тем не менее, правило было предложено к использованию по умолчанию, и мы решили оставить его "на всякий случай".
Common
Нестандартный рабочий процесс, который содержит три модуля:
Для первых двух модулей я привел имена вместо понятных названий. Дело в том, что эти модули содержат разделяемый код, на который ссылаются другие правила. У таких модулей нет понятных названий. Третий модуль отладочный, поэтому для него необязательно (хотя и возможно) указание понятного названия, поэтому я указал такое. Модуль при этом называется "common-debug-action".
Модуль "common-datetime" содержит логику для поддержки учёта времени. В частности, производственный календарь на текущий год, а также нашу версию функции вычисления разницы в минутах между двумя датами с учётом рамок рабочего дня, нерабочих и праздничных дней. Я ещё вернусь к этому модулю, когда буду рассказывать про рабочий процесс для учёта времени.
Модуль "common-users" содержит код, автоматизирующий отправку пользователям критичных уведомлений из других правил. Это уведомления, например, о превышении дедлайна задачи. Также сюда относятся уведомления о забытых задачах, то есть задачах, по которым не было активности (комментариев) за последнее время. Мы решили, что более эффективно отправлять такие уведомления не только ответственному за задачу, но и его руководителю. Я уже упоминал про это в контексте описания групп пользователей.
Наконец, модуль "DEBUG ACTION", как можно догадаться из названия, предназначен для отладки. Это правило типа "Action". При помощи таких правил в YouTrack можно создавать быстрые действия для задач. Список действий доступен в меню карточки задачи при выборе пункта "троеточие".
Также действие может быть выбрано и выполнено в окне действий:
При выборе действия будет сразу же выполнен определенный код. Видимостью таких правил (пунктов меню) можно управлять. Например, отладочное действие "DEBUG ACTION" отображается только для пользователя с определенным именем (меня). Также можно настроить, например, отображение действий лишь при создании новых задач и т.п.
Зачем потребовался такой модуль? Есть определённые нюансы с отладкой скриптов рабочих процессов в облачной версии YouTrack. Собственно, вся отладка заключается в анализе выходных данных консоли в редакторе рабочего процесса после его выполнения. В принципе, этого достаточно. Но хотелось иметь возможность запуска произвольного кода (модулей) прямо в облачной среде. Для решения этой задачи я и использовал отладочное действие. Возможно, есть какие-то более изящные и технически грамотные варианты, но меня вполне устроил такой.
Dependencies
Стандартный рабочий процесс, включающий единственное правило типа "On-change":
Правило контролирует работу связанных задач, а именно связи типа "Depend" (depends on - is required for). При такой связи предполагается, что одна задача зависит от другой и не может быть закрыта, пока другая задача находится в работе. Мы используем связи между задачами, поэтому данное правило полезно.
Интересная особенность: в YouTrack вы можете использовать встроенный (или доработанный) набор типов связей задач, устанавливать связи между задачами. Но без соответствующих рабочих процессов связи не будут работать. Поэтому нужно аккуратно отказываться от рабочих процессов, которые YouTrack предлагает по умолчанию. Похожая история и с именами настраиваемых полей. Все стандартные рабочие процессы настроены на работу с набором полей по умолчанию. Меняя какие-то значения, будьте готовы к внесению множественных правок в рабочие процессы.
Про связи (ссылки) между задачами можно почитать в документации.
Due Date
Еще один стандартный рабочий процесс. Предназначен для работы с дедлайном задачи. По умолчанию он содержит два правила, но мы решили ограничиться только вторым:
Первое правило типа "On-change" требует обязательной установки значения в поле "Due Date" при создании задачи. Мы не стали вводить такое жёсткое требование, поэтому правило было отключено.
Второе правило, которое посчитали полезным, мы используем для оповещения ответственного и его руководителя в случае, если дедлайн задачи превышен. Это правило относится к типу "On-schedule". Оно позволяет обрабатывать задачи по расписанию (параметр "cron"). Список задач будет получен при помощи поискового запроса (параметр "search"). Мы немного доработали это правило, добавив дополнительное условие выполнения только по рабочим дням, так как выполнение по расписанию ограничивает выполнение задачи рабочими днями с понедельника по пятницу, но не учитывает выходные и праздничные дни. Для этого используются функции проверки из разделяемого модуля "common-datetime". В дополнение к этому, как уже говорилось ранее, мы используем расширенную функцию рассылки уведомлений из модуля "common-users".
Duplicates
Стандартный рабочий процесс, который управляет поведением задач-дубликатов. Мы не так часто создаем задачи-дубликаты, но иногда такое всё же случается. Поэтому этот рабочий процесс был подключен к проекту. По умолчанию он содержит пять правил типа "On-change" (одно из правил мы не используем):
Задача в YouTrack может быть отмечена как дубликат другой задачи двумя способами:
Также необходимо обеспечить корректное поведение при удалении связи между задачами-дубликатами или при смене статуса "Duplicate" задачи на другой. Все эти нюансы контролирует рабочий процесс. Мы не вносили значительных правок в правила данного рабочего процесса. А те, что вносили, были связаны с использованием других названий у статусов задачи (отличных от имён по умолчанию).
In Progress Work Timer
Мы подошли к стандартному рабочему процессу, настройка которого потребовала несколько больше усилий, чем представлялось сначала. Как я уже говорил ранее, нам хотелось попробовать учёт времени и мы были рады увидеть такую возможность в списке предустановленных. Однако реализация "из коробки" не вполне нас устроила.
По умолчанию процесс включает два правила типа "On-change":
Первое правило отслеживает изменение статуса задачи. При установке значения "In Progress" (задача взята в работу) в служебное поле "Timer Time" задачи будут записаны текущие дата и время. Когда работа над задачей будет завершена (статус сменят с "In Progress" на любой другой), автоматически добавится единица работы. Это делает скрипт второго правила. Затраченное время будет подсчитано как разница в минутах между текущей датой и значением, сохраненным ранее в поле "Timer Time" задачи. Алгоритм выглядит достаточно просто, при этом он имеет недостатки:
Допустим, задачу забыли в статусе "In Progress" и работают с другой. Потом про задачу вспомнили и решили ее закрыть. При этом будет начислен большой интервал рабочего времени, в который фактически ничего не делали. Это нестрашно, так как ранее созданные единицы работы для задачи можно править (вручную менять значение начисленного времени). Но мы же хотим полной автоматизации, не так ли? :) Поэтому мы добавили ещё одно небольшое правило типа "On-schedule" с именем "Update timer on schedule". Каждое утро по рабочим дням это правило перезапускает таймер для задач, находящихся в работе. Конечно, это приводит к ежедневному созданию единицы работы. Зато по любой задаче всегда можно посмотреть актуальное значение затраченного времени с точностью до одного дня;
Учитывается только продолжительность рабочего дня и дни недели, указанные как рабочие. Не учитываются начало и конец рабочего дня, продолжительность обеденного перерыва, праздничные дни. Поэтому, несмотря на то, что функция вернёт результат в минутах, он будет достаточно приблизительный. Например, в вашей компании (как у нас) рабочий день начинается в 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" у нас был расширен до четырех правил:
Может показаться, что мы немного увлеклись учётом времени, и отчасти это так. Но сам YouTrack подталкивает к тому, чтобы максимально кастомизировать рабочие процессы, поэтому мы не смогли устоять :)
К тому же, все эти правки и улучшения были сделаны не одномоментно. Мы и сейчас время от времени там что-то подкручиваем. Расскажу про одну интересную ошибку, с которой мы столкнулись уже после начала активного использования этого рабочего процесса. Это ошибка (или особенность работы) самого трекера. Речь про поле "Scope", которое содержит скоуп задачи.
Изначально мы задали значение по умолчанию для этого поля, равное трём рабочим дням (3d). Спустя какое-то время мы заметили аномалию. У задач, для которых это значение так и оставили без изменений, не отображался индикатор оставшегося времени. Взгляните на скриншот:
У второй и пятой задачи наблюдается указанная проблема. Опытным путем мы выяснили, что нужно явно указывать значение в поле "Scope". При этом что-то происходит "под капотом" YouTrack, и далее это значение будет корректно учтено. Пришлось отказаться от использования дефолтного значения. К тому же, требование обязательно указать скоуп задачи полезно, так как побуждает к проведению большего анализа на этапе постановки задачи. Возможно, это известная проблема и разработчики её уже устранили. Я поленился подробно изучать данный вопрос.
Закрывая тему учёта времени, хочу сказать пару слов об административной стороне вопроса. Кажется, нам удалось создать удобный механизм. Но этого ещё недостаточно. Инструментом нужно научиться правильно пользоваться, выработать оптимальные сценарии работы.
Простой пример – введение практики своевременного перевода задач, над которыми приостановлена работа, в статус отложенных (для остановки таймера) и наоборот. Своевременность переключения статусов позволяет иметь более точную картину происходящего. Но у этого, казалось бы, очевидного подхода есть и обратная сторона. С первых дней использования сотрудники пытались взломать систему: реальная работа часто велась над отложенными задачами (On hold), так как там "не тикает таймер и не портит статистику". Поэтому поначалу можно было наблюдать картину, как команда буквально ни над чем не работает – было всего несколько задач в работе.
Также многие пользователи опасались, что учёт времени будет использован для подсчёта каких-то тайных KPI с целью корректировок заработной платы и т.п. Конечно, такой идеи не было и нет. Главное, для чего сейчас используется данный механизм, повышение эффективности планирования новых задач, более точная оценка возможных трудозатрат.
Overdue work activities
Нестандартный рабочий процесс, включающий единственное правило типа "On-schedule":
По принципу работы этот модуль очень похож на описанный выше модуль "Notify assignee about overdue issues" из рабочего процесса "Due Date". Но здесь мы регулярно оповещаем ответственного и его руководителя в случае, если по задаче не было комментариев за какой-то период. Для этого используется поисковый запрос вида:
State:{In progress},Review
commented:-{minus 3d}..Today
created:-{minus 1d}..TodayБерутся все задачи в работе, кроме тех, которые комментировали в течение последних трёх дней или недавно создали (днём ранее). Цель рабочего процесса – выявление забытых задач, а также привитие у сотрудников дисциплины описывать работу над задачами в комментариях.
Subtasks
Стандартный рабочий процесс. По умолчанию содержит набор из двух правил типа "On-change", автоматизирующих работу с подзадачами:
Для создания иерархии задач в 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.
Хочу поблагодарить всех причастных и пожелать нам всем не расслабляться. Мы ещё только в начале пути. И это здорово!
0
0
0
0