Конечно, рядовым юзерам от использования Jira бывает больно, и это даже порождает целые сайты вроде https://ifuckinghatejira.com/. Я же попытаюсь рассказать, как жить с Jira без боли хотя бы для бизнеса.
На протяжении последних трёх лет в компании Karuna я помогал масштабировать и адаптировать Jira под растущие потребности.
В паре статей хочу поделиться нашими лучшими практиками — готовыми решениями и всем тем, что позволит бизнесу закрывать свои боли с помощью этого инструмента.
Я надеюсь, в этих материалах вы найдёте не только прописные истины, но и массу ранее неизвестных вам фич, инструментов и подходов, а также сможете обращаться к статьям в будущем, чтобы подсмотреть, как решить ваши сложности. Я сам именно так и планирую использовать эти материалы.
Long Story Short
Давным-давно, в далёкой-далёкой галактике, нашей Jira пользовались только разработчики, QA и прочие инженеры. Typical. Но как только один из продуктов Каруны обрёл популярность, и мы начали масштабировать бизнес, то оказалось, что всем остальным тоже нужно организовывать их процесс поставки ценности где-то не в блокноте. Это, на секундочку, десятки бизнес-команд, которые никогда ранее не пользовались инструментами типа Jira и привыкли все дела вести в закрытых от лишних глаз гугл табличках.
По счастливо сложившимся обстоятельствам в компанию пришла новая команда project manager’ов, в которой несколько человек умели говорить с Jira на “ты”, в том числе и ваш покорный слуга. Мы-то и стали ответственными за поддержку и развитие инструмента.
Состояние инструмента на тот момент прекрасно иллюстрирует картинка:
Поэтому засучив рукава мы пошли наводить базовый порядок, чтобы бизнес получил саму возможность перетащить в этот инструмент многочисленные команды и подразделения.
База
В наведении порядка мы руководствовались тремя принципами:
Простота. Настройки должны быть простыми и понятными, чтобы если мы вдруг телепортируемся на другую планету, новые менеджеры и инженеры легко в них разобрались, а также чтобы мы не тратили человеко-часы на объяснения новым пользователям.
Переиспользуемость. Должны быть конфигурации, которые можно юзать сразу на множестве проектов.
Эволюционная адаптационность. Конфигурации должны быть легко модифицируемыми под особенности конкретных команд. Мы не хотим плодить Jira диктатуру, когда всю компанию сажают на один-единственный workflow и пытаются натянуть реальный процесс работы людей на фантазии админов.
Причём именно в таком порядке: нужно сделать что-то простое, что легко объяснить и задокументировать, переприменить на соседний проект или скопировать, внести минимальные изменения.
Если бы мы применяли индивидуальный подход к каждому проекту/заказчику, то мы не смогли бы работать в нужном темпе, а значит, не смогли бы перевести на Jira всех желающих, а их тогда было много.
И наоборот, попытайся мы посадить всех на абсолютно идентичные настройки, это привело бы к тому, что люди просто не смогли бы работать в Jira.
Первые 2-3 месяца мы наводили порядок. По затратам ресурсов — один project manager (это я) тратил ~ 40% своего рабочего времени и двое по ~ 20%. Чтобы диверсифицировать нагрузку, мы ввели практику дежурных по Jira. Пользователи всегда могли найти информацию о текущем дежурном в «Header Banner», который показывается на всех страницах самой Jira. Имя было кликабельным и вело в личку Slack.
Далее — детали о конкретных настройках.
Ролевая модель и permissions
Бизнесу было важно разграничивать зоны ответственности, чтобы некоторые задачи, которые требуют согласования бюджетов, могли ставить только руководители, чтобы их подчиненные имели доступ к этим задачам и могли в них работать, чтобы некая команда или сервис одних заказчиков обслуживали, а других нет.
Мы поняли, что базовой ролевой модели будет недостаточно, и добавили в неё роли reporter & leader. Итого в ней стало 5 основных ролей:
Admin — пользователи, которые имеют право изменять настройки и творить всякое.
Leader — пользователи, которые являются руководством в отношении разработчиков проекта.
Developer — пользователи, непосредственно работающие в проекте.
Reporter — пользователи, которые заказывают работы в проекте.
User — пользователи, которые просто видят задачки (иногда не все).
Мы, конечно, могли бы сделать более точные роли — Scrum Master или Team Lead, но они не были бы универсальными даже внутри технического департамента, не говоря уже о том, что были бы вообще не применимы к проектам HR и маркетинга.
Для получившейся ролевой модели мы сделали одну, единственную и универсальную, «permission scheme», в которой отдельно учли права для Project Lead. Основная логика — чем выше ты по ролевой модели, тем больше прав у тебя в проекте. Например, «user» имеет только «browse project» и всё, что связано с комментариями, а вот «reporter» уже может «create issues», и так далее.
В модель добавили динамичные «assignee & reporter» в задачах, чтобы не возникало ситуаций, когда кого-то с ролью «user» назначили на выполнение задачи, а он не может подвинуть её в следующий статус из-за отсутствия прав.
Issue Security Scheme
В Каруне серьёзно относятся к вопросам безопасности. При подготовке переезда некоторых блоков встал вопрос о том, как делать задачи доступными для сильно ограниченного набора пользователей в проекте.
Чтобы решить эту сложность, мы сделали несколько «security schemes», с помощью которых разделили все проекты в Jira на три основных категории:
Полностью публичные проекты — все пользователи, добавленные в проект, видят все задачи в проекте.
Приватные проекты — команда проекта видит все задачи, заказчики и обычные пользователи видят только свои задачи и задачи, в которые они добавлены.
Полностью приватные проекты — все задачи видит только Project Lead, а разработчики видят только те задачи, в которые добавлены.
Для всех категорий есть по 3 уровня, которые в каждой схеме называются одинаково, но имеют небольшие различия в настройках:
Дефолтный (Team) — действует, как написано выше.
Публичный (Public) — если его применить к конкретной задаче, то она станет видна всем, кто добавлен в проект.
Приватный (Private) — если его применить, то задача станет не видна для всех, кроме тех пользователей, которых добавят в задачу через специальное поле.
Чтобы добавлять неограниченное количество пользователей в задачу (например, чтобы задача стала доступна избранной группе из 10 человек), а вся остальная компания её не видела, мы сделали отдельное «multiple user picker» поле — «participants» (участники задачи).
Notification Scheme
Тут мы сделали одну универсальную схему нотификаций — для уведомления всех основных участников задачи (Assignee, Reporter, Component Lead, Watchers), а после реализации настроек приватности добавили отправку уведомлений в поле «participants».
Сделали копию этой схемы и добавили в неё Project Lead — для тех руководителей, которые хотят быть в курсе ВСЕГО.
При создании каждого нового проекта мы обязательно спрашиваем руководителя, хочет ли он получать уведомления обо всём, что происходит в его проекте, или только о тех задачах, к которым он имеет непосредственное отношение.
Screen & Fields
Радостнее всего бизнес оценил изменения по полям и формам, так как вместо десятков самых разных форм во всех проектах Jira мы стандартизировали и сделали единую форму постановки задач, куда добавили вкладки и разнесли по ним поля.
Теперь вместо заполнения произвольной портянки, в которой поля каждый раз идут в разной последовательности, пользователи могут начать привыкать к порядку и единообразию. Все обязательные и наиболее важные к заполнению поля собраны во вкладке «main».
Всё, что требуется для управления поставкой: добавление в спринты, оценка времени, стори поинтов и так далее — во вкладке «Planning». Всё, что нужно разработчикам: ссылки на ветки в гитлабе, ссылка на стейдж — во вкладке «Dev». Ну и наконец, для ограничения доступа к задаче или добавления участников к задаче — во вкладке «Security».
Статусы и Workflow
Придерживаясь тех принципов которые озвучены выше, с процессами всё-таки есть отличие. Мы старались сделать так, чтобы они отображали действительность, а не были совой, натянутой на глобус. Поэтому мы создали около пяти основных Workflow:
Подробный WF для разработчиков.
Сокращённый WF для разработчиков.
Подробный универсальный WF.
Короткий универсальный WF.
Универсальный WF для бизнес-задач/проектов/инициатив.
Каждый из этих WF может использоваться непосредственно в том или ином проекте, но чаще мы использовали его как абстрактный класс, от которого создаём копию, вносим в него минимальные исправления, чтобы получившийся Workflow подходил под рабочий процесс коллег. Это позволило не сильно потерять в гибкости и вообще не потерять в скорости реализации.
Ешё один нюанс, что таким образом мы не ломали всю интеграцию GitLab -> наш сервис -> Jira, который за разработчиков статусы задачи двигал на основе активностей разработчиков в гитлабе.
Группы пользователей
Одно из важнейших изменений для возможности дальнейшего масштабирования — практически полный отказ от персональной выдачи доступов к проектам, доскам, фильтрам, дашбордам и прочим сущностям, за счёт перехода на группы пользователей.
Теперь вместо того, чтобы добавлять на роль «Developer» в проект отдельно Васю/Катю, а на роль «Reporter» Машу/Даню, мы один раз добавляли нужные группы и старались больше ни разу не открывать вкладку роли в настройках проекта.
Сами группы отражали структуру компании. Для примера — hr-team, hr-lead, marketing-team, marketing-lead, и т.п.
Как только появлялся новый сотрудник в компании — мы добавляли его в соответствующую группу, и он сразу получал 95% необходимых ему доступов. Но 5% погрешности всё же порой оставалось. Со временем мы начали приходить к тому, что нам нужно упрощать эту систему за счёт большего количества групп. Например, группа «brand-dep», в которую входит не одна команда, а все сотрудники департамента. Мы начали двигаться к таким изменениям, ведь они позволяют сильно упростить настройки доступа в конкретный проект.
«И сбоку бантик»
Приведя базовую функциональность в удобоваримое состояние, получили из нашей Jira вполне рабочую лошадку, способную закрывать базовые потребности в вопросах управления поставкой ценности.
Но, разумеется, этого было недостаточно, ведь мы хотим не только иметь возможность ставить задачи в Jira на нужных нам сотрудников и команды, мы хотим — удобств, автоматизаций, отчётов, метрик, а также массу всего того, что в базовую функциональность не входит.
Пришла пора обвешивать нашу лошадку красивыми бантиками
При попытке накрутить несколько кастомных решений, мы разок-другой Jira «положили». Прежде чем навешивать новые бантики, решили обзавестись тестовым окружением, где можно спокойно экспериментировать и не бояться сломать рабочий процесс коллегам.
А ещё в компанию приходили новые люди, которые не застали внедрения Jira в процессы своих команд. Они видели этот инструмент впервые в жизни, а у лидов не было времени на то, чтобы «водить их за ручку». Лиды отправляли подчинённых к нам и, разумеется, нас начали засыпать вопросами в личку: «А как то, а как сё?». В общем, требовалось внутреннее обучение, F.A.Q. и масса инструкций.
Задачи по поддержке инструмента с настройкой всякого нетипичного стали жрать сильно больше времени, а ещё всё это начало требовать ведения документации и я, как project, в отдельные дни проводил команде daily синк, остальное рабочее время тратил на ковыряние Jira, разгребание вопросов в личке и написание документации. Руководство задумалось о необходимости выделения отдельного человека на роль «Jira Admin». Решили не ходить на рынок, а повысить человека из нашего helpdesk (Лёша, привет).
В этот же момент к нам впервые начали обращаться с крайне нетипичными задачами из разряда: “Ребят, вы так всё быстро и классно делаете, а, может, нам не нужно покупать инструмент Х за $100500 пользователь/в секунду и вы нам такой процесс в Jira сделаете?”. Иногда мы начинали делать, потому что это было ценно для бизнеса, а пользователям было проще воспользоваться этим в Jira, где всё понятно, чем осваивать новый инструмент. А ещё это были действительно интересные и крутые задачи.
Итак, новая пачка скрупулёзных деталей под катом.
Тестовое окружение
Ну, тестовое окружение, ну что тут такого? Всё не так просто. Есть пара небольших особенностей, которые стоит учесть:
Чтобы тестирование новых фич было релевантным, тестовая Jira должна иметь на 99% аналогичные настройки и данные, а ещё вы наверняка не хотите подтирать за собой следы своих экспериментов, поэтому настройте редеплой тестовой Jira раз в n времени (у нас раз в неделю) с копированием продовой базы данных. Даже авторизовываться сможете под аналогичными кредами и пускать в тестовую Jira коллег, проверять их идеи и настройки своих проектов.
Тестовая Jira не должна отправлять уведомления, чтобы не смущать коллег тем, что в их задачах творится какая-то дичь. Если вы не управляете инфраструктурой (как мы), обратитесь к своим админам, они помогут.
Наверняка вы не хотите, чтобы на тестовой Jira срабатывали всякие автоматизации, которые отправляют коммуникацию в мессенджеры и выполняют что-то по крону. Чтобы не отключать эти автоматизации вручную (какое-то время мы так страдали), мы придумали (спасибо, Даша!) простой доп condition.
Автоматизация сама проверяет отсутствие вхождения строки jira-test в url задачи, и если такое вхождение есть — автоматизация не выполняется. Мы добавили это условие в автоматизацию и перестали каждую неделю страдать.
Первая/вторая линия поддержки… по Jira…
Ситуация с тем, что сотрудник целый день разбирает вопросы в личке, конечно, никуда не годится, так что буквально через пару недель мы завели публичный канал #jira-confluence-help в нашем рабочем мессенджере, стали обрабатывать вопросы публично и от практики дежурных отказались. Руководство осознало масштаб трагедии и стало задумываться о целой выделенной atlassian команде.
Мы, в свою очередь, начали классифицировать запросы в канале, формировать на их основе F.A.Q. и материалы для обучения новичков. Приятным бонусом стало то, что со временем коллеги смотрели на наши ответы, подтягивали свой опыт, и по некоторым вещам начали отвечать не только мы, но и те, кто преисполнился экспертизы.
Чтобы на один вопрос не отвечало одновременно несколько специалистов, мы договорились — кто первый начал отвечать, ставит эмоцию прелоадера, а когда проблема решена, то check.
В случае, когда запрос выходит за пределы короткого ответа (ссылка на инструкцию или 5_min_task), просим поставить задачу в наш собственный проект в Jira.
С тех пор канал ни одного рабочего дня не смолкает, от 3 до 15 запросов стабильно имеем.
Структура команды Atlassian
Я тут пишу только про Jira, но для команды в этой истории был и Confluence. Он развивался так же быстро и требовал эксперта, но скорее с опытом в управлении смыслами, а не процессами. Выделив одного человека на full-time на Jira, мы поняли, что его хватает только на поддержку и мелкие изменения, а на серьёзные задачи (составление обучения, Confluence) уже не хватает.
Так мы пришли к минимально работоспособной схеме:
2 Jira Admin
1 Confluence Admin (Knowledge Manager)
Поиск зверя под названием Knowledge Manager был очень нетривиальной задачей. Сначала мы открыли вакансию «Технического писателя», но все приходящие на неё кандидаты были готовы написать нам увесистую документацию на 100500 страниц по ГОСТ 2.102 2013. Тогда мы поняли, что это никуда не годится — переименовали вакансию и описали её в том стиле, который ждём от будущего сотрудника.
Нам нужно было сформировать структуру внутренней Wiki, ужать регламенты до пары абзацев, полных смысла, которые легко читаются и иллюстрируются смешными и понятными мемасиками. То, что мы нужного человека в итоге нашли (привет, Артур), я лично считаю чистым везением. Нужный бэкграунд у него был за счёт работы специалистом по разработке процессов обслуживания и информационному обеспечению в поддержке крупного телекома, где он занимался базой знаний и процессами для собственно саппорта.
Что же касается администраторов Jira, то, как правило, была ситуация, где один специалист является ведущим, а один зелёным джуном. Операционка в равной степени делится между всей командой, и практически у всех есть возможность тащить по одному крупному проекту в единый момент времени. Джун тащит проект попроще, сеньор — посложнее. Каждый день такая команда решает пачку операционки и выполняет пару задач по реализации некоего крупного проекта.
Первое время командой управлял Project Director (привет, Ксю) но, по мере роста всего PMO и команды Atlassian, потребовался отдельный руководитель.
Наконец, чем дальше мы развивались, тем больше мы понимали, что не можем решить все проблемы только за счёт готовых решений, и нам нужен человек, который будет легко писать кастомные скрипты через Scipt Runner и, возможно, даже разрабатывать собственные плагины — мы пошли согласовывать позицию Jira Developer.
Итоговая структура команды:
Инструкции и документация
Самый главный принцип, который мы взяли на вооружение в подготовке инструкций, звучит примерно так:
Если в чате это спросили больше 1 раза — напиши ответ в виде инструкции и скинь ссылку на инструкцию.
Поэтому, самым первым документом, который мы родили, был F.A.Q. по использованию JQL. Не буду приводить его здесь целиком, но вынесу из него пару нетривиальных запросов, которые могут вам пригодиться.
Получить все свои незакрытые задачи
assignee = currentUser() AND resolution = UnresolvedПолучить все задачи, связанные с задачей ABC-123
issue in linkedIssues(ABC-123)Найти все не закрытые задачи, застрявшие на уволившихся сотрудниках
( reporter in membersOf("inactive-users") AND resolution = Unresolved ) OR ( assignee in membersOf("inactive-users") AND resolution = Unresolved ) Найти все задачи, которые поменяли статус из Х в Y, за определённый период времени
status changed FROM $StatusX TO $statusY AFTER $date1 BEFORE $date2 Задачи, которые комментировал конкретный пользователь
issueFunction in commented("by $user.name") Найти все шаблоны, которые используются в проекте Х
issue in searchTemplates(projectAvailability, $ProjectName) AND project = Templates Найти все задачи, у которых в element чек-листе было что-то про GitLab
Elements in elementsPanelsFilter("Checklist", "Description ~ GitLab") Про шаблоны и чек-лист будет подробнее. Самыми популярными инструкциями в нашей базе знаний являются:
Что такое JIRA, как и зачем она используется? (Добавлено в OnBoarding)
Как создать шаблон
Как перенести задачу в другой проект
Как добавить чек-листы во все задачи по JQL
F.A.Q. по настройке Scrum/Kanban досок
Как выгрузить задачи из Jira в CSV
Как производить массовые операции над задачами
Как перенести subtask в полноценную задачу
Шаблоны
В Data Center нет встроенных шаблонов, поэтому используем плагин — Issue Templates for Jira. Он позволяет запихивать готовую структуру текста с подсказками по заполнению и предзаполняет любое поле выбранным значением. Сам шаблон представляет из себя задачу, которая хранится в проекте Шаблоны. Поэтому создание шаблона — не сложней создания задачи, нужно только не забыть добавить ограничение, к какому проекту и типу задач относится шаблон.
Вот несколько наших лучших практик по работе с шаблонами:
Ссылка на регламент. Чтобы сотрудники не искали регламент по тому или иному процессу, мы вставляем ссылки на эти документы в самом начале описания шаблона, выглядит примерно так:
Если на один тип задач/все типы приходится один общий регламент, мы вставляем его не в шаблон, а в виде не редактируемого поля.
Такое поле можно найти в разделе Advanced в кастомных полях.
Пример заполнения. Если мы просим заполнить какие-то данные в шаблоне, то при его использовании к задаче сразу подставляются данные для примера.
Кто создаёт шаблоны? Можно заказать создание шаблона или целой пачки у нашей команды Atlassian — это совершенно элементарная задача, но пойдёт она с низким приоритетом в джуна, и заказчик получит результат тогда, когда до задачи дойдут руки. Есть инструкция по самостоятельному созданию шаблонов, и у шаблонов есть владельцы, отвечающие за поддержание их в актуальном состоянии (как правило, тимлиды и руководители отделов/подразделений).
Поиск шаблонов. Выше уже приводил JQL, но на всякий случай продублирую его:
issue in searchTemplates(projectAvailability, $ProjectName) AND project = TemplatesПредзаполнение компонентов. Внутри проектов у нас частая история — есть 1 тип задач с определённым набором полей и процессом, но в рамках него сотрудники реализуют кучу разных типов работ. В таком случае они обозначаются компонентом и на каждый тип работ — отдельный бриф. Чтобы не засорять внимание заказчика, компонент прячется на второй вкладке и предзаполняется в зависимости от выбранного шаблона.
Чек-листы
Дефолтных чек-листов в Jira DC нет, поэтому мы используем целых два плагина для работы с чек-листами:
Эти чек-листы важны для нас следующими факторами:
Делегируемость. Мы как администраторы Jira можем просто включить их для того или иного проекта в Jira, и его владельцы сами будут развлекаться с настройками чек-листов, не тратя наши ресурсы.
User Picker & Status’ы. Классические чек-листы имеют простое состояние — сделано или не сделано. В них, как правило, невозможно указать, кто ответственен за выполнение пункта. Elements Checklist позволяют сделать статусы и добавить исполнителя. Правда он не получит уведомления, что его на что-то там назначили, но это больше инструмент для Scrum Master’ов и PM’ов. Да и коллеги бы жаловались, если бы их завалило уведомлениями, так что это даже хорошо. Смотрите, как классно выглядит:
Это позволяет на лету (во время синка, например) фиксировать Action Points прямо в задачу, видеть ответственных, и в каком состоянии задача.
Шаблоны чек-листов. У вас стандартный набор чек-листов для тех или иных работ? Супер. Просто вставьте нужный шаблон в задачу одним кликом.
Множественность чек-листов. В вашей задаче может быть сразу несколько чек-листов: один для фиксации DoR, второй для Action Point, третий для фиксации DoD или приёмочных работ — запросто.
И для каждого чек-листа может быть различная структура по полям внутри него и различные шаблоны.
Поддержка JQL. Выше уже приводил пример запроса, который позволяет искать задачи с определёнными значениями в чек-листе. Иногда это бывает суперполезно.
Elements in elementsPanelsFilter("Checklist", "Description ~ GitLab")В итоге: получается крайне гибкий инструмент, который сильно упрощает жизнь и автоматизирует работу менеджеров, которые занимаются управлением поставкой ценности.
Ну, а для случаев, когда вам нужен инструмент попроще и, что немаловажно, который автоматически будет применяться ко всем задачам, соответствующим некоторому JQL, мы используем — Multiple Checklists for Jira.
У него также есть фичи с множественностью и шаблонами, но эти шаблоны автоматически применяются к задачам по JQL.
А ещё у них есть интересная возможность — элементы такого чек-листа можно легко превратить в саб-таски (если вы их не обвешали кондитионами и валидаторами).
WIP лимиты & jira-helper
Мы в Каруне достаточно активно используем Kanban метод и одну из его практик — ограничение количества задач в работе. Проще говоря — WIP лимиты.
Некоторое время мы пробовали различные плагины, предоставляющие подобную функциональность, но в итоге остановились на решении, которое разрабатывают коллеги из Тинькофф — это Chrome Extension Jira Helper.
С его помощью мы имеем возможность лимитировать буквально всё и как угодно.
Лимиты на свимлайны. Устанавливать лимиты на колонки в Jira можно из коробки, а вот если вы хотите ограничить количество задач, которые идут по конкретному свимлайну, то без этого расширения не справиться.
Важно отметить, что благодаря инструменту мы можем исключать учёт задачи в колонке, если мы поставили галочку «Is Expedite» для свимлайна.
Персональные лимиты. Хотите ограничить количество задач на конкретном сотруднике в момент времени — можно.
Кастомные лимиты. Когда мы начинаем пытаться управлять системой поставки ценности на уровне департамента / кластера / трайба, то появляется желание лимитировать отдельную ячейку или, например, ограничить количество инициатив, в которых будет задействована конкретная команда (в единый момент времени на них не должно приходиться более 3-4 проектов). Такие вещи тоже можно настроить.
Работа с SLA. В случае, если вы организуете работу команды с SLA по скорости выполнения — данный инструмент также позволит вам облегчить жизнь, предоставив возможность настраивать SLA в отчёте Control Chart (в виде отдельной линии, которая накладывается на график), и там сразу же происходит калькуляция процента задач, которые попали под SLA.
За данный инструмент в первую очередь надо сказать спасибо Паше @controlchart Ахмечанову. Вы можете помочь сообществу с доработкой этого плагина — репозиторий на GitHub.
Найти поддержку или обсудить фичу с сообществом можно в телеграм-канале.
Метрики поставки & JFC
Разумеется, мы пользуемся стандартными Jira-отчётами, вот только нам их недостаточно.
Нам нужен был инструмент для того, чтобы считать Lead & Cycle Time выполнения задач по перцентилям (50 и 85), объём поступающих и выполняемых задач, их соотношение, средние значения и разницу. Всё это мы нашли в Chrome Extension — Jira Flow Companion.
Отчёты строятся по вашей Scrum/Kanban доске, поэтому переход к плагину можно найти в виде кнопки на доске:
Подсчёт LeadTime. Во-первых, в отличие от Control Chart, мы получаем гистограмму распределения. Во-вторых, таблицу, отсортированную по времени выполнения, которая позволяет нам легко использовать её для активностей вроде Delivery Review. В-третьих, при наведении курсора на гистограмму, всплывает подсказка с перцентилями.
Если выставить Start state от начально статуса, то вы получите LeadTime, если от статуса принятия обязательств — Cycle Time производства. Инструмент сразу покажет вам среднее и медианное время выполнения задач. Рекомендую устанавливать resolution в 1 день и использовать quick filter с JQL выражением
resolution != Unresolved AND status != RejectedЧтобы отсеять из отчёта задачи над которыми ещё идёт работа, а также задачи которые были выброшены из поставки.
Подсчёт Flow InOut. Позволяет оценить, справляется ли команда / производственная система с потоком бизнес-задач или нет. Самая приятная метрика, которую инструмент нам показывает — это Average Backlog Growth, то есть на сколько задач изменился бэклог команды за итерацию, в среднем. Например, если бэклог прирастает на 10 задач в неделю — команда, очевидно, не вывозит. Если значение около 0 или отрицательное — команда нормально справляется и, возможно даже, вырабатывает бэклог.
Подсчёт пропускной способности — Throughput. Иногда нам важно понять, как меняется исключительно пропускная способность команды под воздействием тех или иных факторов. Например, увеличили количество решаемых задач выходом нового человека, или смогла ли команда решить суммарно больше задач в условиях перегрузки и превышения WIP лимитов? Для этого на той же вкладке отчёта нужно выбрать другой тип отчёта — Throughput. Мы получим гистограмму, которая позволит оценить пропускную способность в динамике и среднюю пропускную способность за выбранный временной промежуток.
Кумулятивная диаграмма потока — CFD. Такая диаграмма есть в стандартных отчётах Jira. Есть она и в этом инструменте. Обладает одной приятной допфичей — всплывающей подсказкой, сколько конкретно задач находится в том или ином статусе в определённый момент времени. Такая информация может быть полезна для первичной установки WIP лимитов.
Прогноз по MonteCarlo. Если быть чуть точнее, то целых два прогноза. Сколько рабочих элементов будет реализовано системой за следующую итерацию, на основе данных «n» количества предыдущих итераций — это поможет найти ответ на вопрос: «Сколько задач вы сделаете за следующий спринт/итерацию?». За какое время будет сделано некоторое количество усреднённых рабочих элементов — может быть полезно, если вы декомпозировали на задачи какой-то большой проект, и руководство ждёт от вас сроков: «А когда вы это всё целиком сделаете?". Или, быть может, компания построила план, в соответствии с которым нужно будет сделать 1000 задач в следующем году. Прогноз позволит дать ответ, насколько это вообще реалистично.
Выберите нужный режим, длину итераций и количество итераций для анализа — вуаля, данные у вас в руках.
Читается как: «Бэклог из 300 типовых задач, при сохранении текущих мощностей, наша команда сделает за 15 недельных спринтов с вероятностью 81%».
Time in Status
Ещё один важный инструмент для сбора отчётности и статистики — плагин Time In Status.
Его название говорит само за себя. Он позволяет измерять время нахождения задач в том или ином статусе, из чего можно формировать достаточно кастомные метрики, а также организовывать вполне специфичные KPI для сервисных команд. Приведу пару примеров его использования.
Обзор поставки с помощью TIS. Многие наши команды и подразделения проводят встречи, на которых оценивают собственную результативность в конце итерации / спринта или просто за какой-то временной промежуток. Многие во время проведения такой встречи двигаются по списку задач, которые удалось / не удалось выполнить и, в том числе, обращают внимание на раздел Time in Status.
Судя по скриншоту, заказчик забил на приёмку работ, которые он сам заказал у команды. Этот кейс можно будет разобрать на ближайшей ретроспективе.
Выгрузки и работа с ними. По большей части этим инструментом пользуются руководители, производя выгрузки и рассчитывая нужные им значения. Плагин позволяет формировать выгрузки по задачам, попадающим под кастомный JQL. Мы можем настраивать: какие статусы попадут в выгрузку, какие данные добавить из задачи (по исполнителям, командам, размерам, приоритетам, типам работ и т.д). Важное значение имеет, по какому календарю мы совершаем выгрузку, будет ли учитываться 24/7 или только рабочее время, скажем с 9:00 до 18:00.
Экран настройки выгрузки — всё интуитивно понятно, за исключением кнопки “Скачать” (она сверху, справа от календаря), от выбора формата времени:
Выгруженный файл, в свою очередь, копируется уже куда-то в Google Sheets или скармливается самописному скрипту, который считает всё, что нам надо. Например, именно таким образом наши менеджеры, когда это действительно необходимо, осуществляют подсчёт таких метрик как Average Wait Time & Flow Efficiency.
Базовое обучение при Onboarding
Новые сотрудники зачастую с Jira никогда не работали, а вот вся остальная компания, буквально каждый отдел и специалист, вели все свои дела именно в Jira. Поэтому потребность в базовом обучении назрела очень быстро. Мы рассматривали несколько вариантов, как его организовать, и в итоге составили следующие DoD:
Команда не должна тратить ни минуты своего времени на проведение обучения.
В процессе обучения учащийся должен чувствовать себя в безопасности и не бояться что-то сломать.
Обучение должно быть практическим. В его рамках стоит перепробовать основные функции Jira.
В итоге мы пришли к следующему формату:
Подготовили серию материалов, снабженных gif'ками и короткими видеороликами на конкретные темы.
После прочтения каждого материала предлагается, для закрепления, выполнить практическое задание в тестовой Jira. Среди выполняемых действий:
Создание задач.
Передвижение задачи по статусам.
Передвижение задачи по статусам на доске.
Написание комментариев к задаче.
Использование быстрых фильтров.
Использование JQL.
Сохранение запроса в фильтр.
Перенос задачи в другой проект.
Смена Assignee.
Редактирование произвольных полей задачи.
Добавление в задачу новых участников.
Для того, чтобы учащийся проникся Jira Power и не чувствовал себя тупо от того, что он в одиночку теребит задачу — на нужные действия в проекте обучения срабатывают автоматизации, которые создают для него минимальную интерактивность.
Вообще мы сейчас не проверяем то, как обучающийся справился с заданиями. Пока это писал, появилась мысль насчёт тех же автоматизаций, чтобы фиксировать результат.
Промежуточные итоги
Внедрение всех этих инструментов, написание инструкций по их использованию, построение обучения для новых сотрудников заняло у нас около года, с хвостиком.
Примерно три квартала бизнес жил с этим набором функциональности, привыкал и просил нас реализовать различные сложные и нетривиальные процессы в Jira, на основе всего этого великолепия.
Именно с этим набором инструментов мы смогли построить первые высокоуровневые визуализации, координационные уровни полёта и прочие крутые менеджерские штуки.
Но в скором времени этого стало недостаточно. В следующей статье я расскажу про диаграммы Ганта, новую иерархию задач под портфельное управление, автоматизации и самое сложное — продвинутое обучение коллег с формированием внутренней Jira гильдии.
