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

Мы поняли, что базовой ролевой модели будет недостаточно, и добавили в неё роли 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» назначили на выполнение задачи, а он не может подвинуть её в следующий статус из-за отсутствия прав.

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

Чтобы решить эту сложность, мы сделали несколько «security schemes», с помощью которых разделили все проекты в Jira на три основных категории:

• Полностью публичные проекты — все пользователи, добавленные в проект, видят все задачи в проекте.

• Приватные проекты — команда проекта видит все задачи, заказчики и обычные пользователи видят только свои задачи и задачи, в которые они добавлены.

• Полностью приватные проекты — все задачи видит только Project Lead, а разработчики видят только те задачи, в которые добавлены.

Для всех категорий есть по 3 уровня, которые в каждой схеме называются одинаково, но имеют небольшие различия в настройках:

• Дефолтный (Team) — действует, как написано выше.

• Публичный (Public) — если его применить к конкретной задаче, то она станет видна всем, кто добавлен в проект.

• Приватный (Private) — если его применить, то задача станет не видна для всех, кроме тех пользователей, которых добавят в задачу через специальное поле.

Чтобы добавлять неограниченное количество пользователей в задачу (например, чтобы задача стала доступна избранной группе из 10 человек), а вся остальная компания её не видела, мы сделали отдельное «multiple user picker» поле — «participants» (участники задачи).

Тут мы сделали одну универсальную схему нотификаций — для уведомления всех основных участников задачи (Assignee, Reporter, Component Lead, Watchers), а после реализации настроек приватности добавили отправку уведомлений в поле «participants».

Сделали копию этой схемы и добавили в неё Project Lead — для тех руководителей, которые хотят быть в курсе ВСЕГО.

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

Радостнее всего бизнес оценил изменения по полям и формам, так как вместо десятков самых разных форм во всех проектах Jira мы стандартизировали и сделали единую форму постановки задач, куда добавили вкладки и разнесли по ним поля.

Теперь вместо заполнения произвольной портянки, в которой поля каждый раз идут в разной последовательности, пользователи могут начать привыкать к порядку и единообразию. Все обязательные и наиболее важные к заполнению поля собраны во вкладке «main».

Всё, что требуется для управления поставкой: добавление в спринты, оценка времени, стори поинтов и так далее — во вкладке «Planning». Всё, что нужно разработчикам: ссылки на ветки в гитлабе, ссылка на стейдж — во вкладке «Dev». Ну и наконец, для ограничения доступа к задаче или добавления участников к задаче — во вкладке «Security».

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

• Подробный WF для разработчиков.

• Сокращённый WF для разработчиков.

• Подробный универсальный WF.

• Короткий универсальный WF.

• Универсальный WF для бизнес-задач/проектов/инициатив.

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

Ешё один нюанс, что таким образом мы не ломали всю интеграцию GitLab -> наш сервис -> Jira, который за разработчиков статусы задачи двигал на основе активностей разработчиков в гитлабе.

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

Теперь вместо того, чтобы добавлять на роль «Developer» в проект отдельно Васю/Катю, а на роль «Reporter» Машу/Даню, мы один раз добавляли нужные группы и старались больше ни разу не открывать вкладку роли в настройках проекта.

Сами группы отражали структуру компании. Для примера — hr-team, hr-lead, marketing-team, marketing-lead, и т.п.

Как только появлялся новый сотрудник в компании — мы добавляли его в соответствующую группу, и он сразу получал 95% необходимых ему доступов. Но 5% погрешности всё же порой оставалось. Со временем мы начали приходить к тому, что нам нужно упрощать эту систему за счёт большего количества групп. Например, группа «brand-dep», в которую входит не одна команда, а все сотрудники департамента. Мы начали двигаться к таким изменениям, ведь они позволяют сильно упростить настройки доступа в конкретный проект.

Ну, тестовое окружение, ну что тут такого? Всё не так просто. Есть пара небольших особенностей, которые стоит учесть: 

1. Чтобы тестирование новых фич было релевантным, тестовая Jira должна иметь на 99% аналогичные настройки и данные, а ещё вы наверняка не хотите подтирать за собой следы своих экспериментов, поэтому настройте редеплой тестовой Jira раз в n времени (у нас раз в неделю) с копированием продовой базы данных. Даже авторизовываться сможете под аналогичными кредами и пускать в тестовую Jira коллег, проверять их идеи и настройки своих проектов.

2. Тестовая Jira не должна отправлять уведомления, чтобы не смущать коллег тем, что в их задачах творится какая-то дичь. Если вы не управляете инфраструктурой (как мы), обратитесь к своим админам, они помогут.
   

3. Наверняка вы не хотите, чтобы на тестовой Jira срабатывали всякие автоматизации, которые отправляют коммуникацию в мессенджеры и выполняют что-то по крону. Чтобы не отключать эти автоматизации вручную (какое-то время мы так страдали), мы придумали (спасибо, Даша!) простой доп condition.
   
   Автоматизация сама проверяет отсутствие вхождения строки jira-test в url задачи, и если такое вхождение есть — автоматизация не выполняется. Мы добавили это условие в автоматизацию и перестали каждую неделю страдать.

Ситуация с тем, что сотрудник целый день разбирает вопросы в личке, конечно, никуда не годится, так что буквально через пару недель мы завели публичный канал #jira-confluence-help в нашем рабочем мессенджере, стали обрабатывать вопросы публично и от практики дежурных отказались. Руководство осознало масштаб трагедии и стало задумываться о целой выделенной atlassian команде.

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

Чтобы на один вопрос не отвечало одновременно несколько специалистов, мы договорились — кто первый начал отвечать, ставит эмоцию прелоадера, а когда проблема решена, то check.

В случае, когда запрос выходит за пределы короткого ответа (ссылка на инструкцию или 5_min_task), просим поставить задачу в наш собственный проект в Jira.

С тех пор канал ни одного рабочего дня не смолкает, от 3 до 15 запросов стабильно имеем.

Я тут пишу только про 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 нет, поэтому мы используем целых два плагина для работы с чек-листами:

Elements Cheklist

Эти чек-листы важны для нас следующими факторами:

Делегируемость. Мы как администраторы 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.

А ещё у них есть интересная возможность — элементы такого чек-листа можно легко превратить в саб-таски (если вы их не обвешали кондитионами и валидаторами).

Мы в Каруне достаточно активно используем Kanban метод и одну из его практик — ограничение количества задач в работе. Проще говоря — WIP лимиты.

Некоторое время мы пробовали различные плагины, предоставляющие подобную функциональность, но в итоге остановились на решении, которое разрабатывают коллеги из Тинькофф — это Chrome Extension Jira Helper.

С его помощью мы имеем возможность лимитировать буквально всё и как угодно.

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

Важно отметить, что благодаря инструменту мы можем исключать учёт задачи в колонке, если мы поставили галочку «Is Expedite» для свимлайна.

Персональные лимиты. Хотите ограничить количество задач на конкретном сотруднике в момент времени — можно.

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

Работа с SLA. В случае, если вы организуете работу команды с SLA по скорости выполнения — данный инструмент также позволит вам облегчить жизнь, предоставив возможность настраивать SLA в отчёте Control Chart (в виде отдельной линии, которая накладывается на график), и там сразу же происходит калькуляция процента задач, которые попали под SLA.

За данный инструмент в первую очередь надо сказать спасибо Паше @controlchart Ахмечанову. Вы можете помочь сообществу с доработкой этого плагина — репозиторий на GitHub.

Найти поддержку или обсудить фичу с сообществом можно в телеграм-канале.

Разумеется, мы пользуемся стандартными 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.

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

Обзор поставки с помощью TIS. Многие наши команды и подразделения проводят встречи, на которых оценивают собственную результативность в конце итерации / спринта или просто за какой-то временной промежуток. Многие во время проведения такой встречи двигаются по списку задач, которые удалось / не удалось выполнить и, в том числе, обращают внимание на раздел Time in Status.

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

Выгрузки и работа с ними. По большей части этим инструментом пользуются руководители, производя выгрузки и рассчитывая нужные им значения. Плагин позволяет формировать выгрузки по задачам, попадающим под кастомный JQL. Мы можем настраивать: какие статусы попадут в выгрузку, какие данные добавить из задачи (по исполнителям, командам, размерам, приоритетам, типам работ и т.д). Важное значение имеет, по какому календарю мы совершаем выгрузку, будет ли учитываться 24/7 или только рабочее время, скажем с 9:00 до 18:00. 

Экран настройки выгрузки — всё интуитивно понятно, за исключением кнопки “Скачать” (она сверху, справа от календаря), от выбора формата времени:

Выгруженный файл, в свою очередь, копируется уже куда-то в Google Sheets или скармливается самописному скрипту, который считает всё, что нам надо. Например, именно таким образом наши менеджеры, когда это действительно необходимо, осуществляют подсчёт таких метрик как Average Wait Time & Flow Efficiency.

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

• Команда не должна тратить ни минуты своего времени на проведение обучения.

• В процессе обучения учащийся должен чувствовать себя в безопасности и не бояться что-то сломать.

• Обучение должно быть практическим. В его рамках стоит перепробовать основные функции Jira.

В итоге мы пришли к следующему формату:

• Подготовили серию материалов, снабженных gif'ками и короткими видеороликами на конкретные темы.

• После прочтения каждого материала предлагается, для закрепления, выполнить практическое задание в тестовой Jira. Среди выполняемых действий:

  • Создание задач.

  • Передвижение задачи по статусам.

  • Передвижение задачи по статусам на доске.

  • Написание комментариев к задаче.

  • Использование быстрых фильтров.

  • Использование JQL.

  • Сохранение запроса в фильтр.

  • Перенос задачи в другой проект.

  • Смена Assignee.

  • Редактирование произвольных полей задачи.

  • Добавление в задачу новых участников.

Для того, чтобы учащийся проникся Jira Power и не чувствовал себя тупо от того, что он в одиночку теребит задачу — на нужные действия в проекте обучения срабатывают автоматизации, которые создают для него минимальную интерактивность.

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