Atlassian *

Как заставить поставщика признать ошибку и исправить её за два часа, а не за неделю, руководство для Jun-аналитиков.

Хочу представить вашему вниманию материалы по обучению Jira, которые я бережно собирал на протяжении последних 10 лет на очных или онлайн-тренингах в нескольких учебных центрах.

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

Курс лучше всего подойдёт начинающим пользователям Jira, делающим первые шаги в системе. Хотя для опытных пользователей и даже админов наверняка найдутся интересные темы, и возможность дополнить и структурировать имеющиеся знания.

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

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

Jira, EvaTeam, Kaiten и другие аналоги — отличное решение для сквозного управления задачами. Но чем больше проект и число стейкхолдеров, тем сильнее чувствуешь нехватку базовой логики таск-менеджеров. Заказчик не понимает, на каком этапе задача, а разработчики — что в приоритете. 

В этом кейсе расскажу, как мне удалось доработать стандартную логику Jira, чтобы она стала максимально удобной для всех сторон. И (что важно!) сама двигала задачи: от одного ответственного к другому — без вмешательства менеджера.

Это — вторая часть цикла “Начало работы с Jira Automation”, в которой мы разбираем Smart Values и учимся применять их на практике внутри автоматизаций Jira.

OKR — штука в целом полезная, если знаете, зачем и как её внедрять.

Сегодня я не собираюсь вам продавать OKR как «идею» или «мечту» как способ достичь того, что не получается с помощью обычных средств. Моя цель сейчас — скорее, рассказать вам, как сделать в инструменте удобный механизм ведения Целей и Результатов (а именно так переводятся Objectives and Key Results) их дальнейшего отслеживания. В качестве инструмента будет выступать Jira, в качестве дополнительного удобства — плагин Structure с его удобными фишками. Рассказ будет поделен на 2 части — о создании механизма и о создании мониторинга.

В конце вас ждёт инструмент, который поможет вам сэкономить на покупке платного плагина для Jira. И который вы сделаете сами с помощью этого гайда.

Часть 1. Создаём механизм

На этапе, когда в компании началось массовое внедрение и команды начали знакомиться с этим подходом, предлагалось ведение всех целей в таблицах и файлах-документах. Для одной команды — вполне себе неплохой вариант, но когда команд за 30 и часть Целей зависит от других Целей, то понять общую картину в куче Excel-таблиц, где каждая команда, хоть и соблюдая общие принципы, но всё же ведет все по-своему — становится крайне тяжело.  И мне это очень не понравилось.

Я решил попробовать найти или сделать механизм для этого.

В командах часто тратят часы на ручное обновление статусов задач, проставление дат релизов и уведомления коллег о готовности работы.
В этой статье я покажу, как с нуля настроить правило в Jira Automation: от выбора триггера и условий до действий с задачами. Даже если вы никогда не работали с Jira Automation, следуя шагам, вы сможете создать свой первый рабочий сценарий за 10 минут.

(спойлер: в конце будет ссылка на GitHub)

Таск-менеджеры вроде Jira — хороший инструмент для ведения проектов. Вот только есть одна проблема — на них очень быстро забивают. В первую очередь — проектные менеджеры (на всякий случай: я тоже забиваю). Когда проект стартует, менеджер с командой, как правило, делают волевую попытку декомпозировать его на эпики и задачи. Каждая задача получает красивое описание, а иногда даже назначенных исполнителей и дедлайны.

Потом проект стартует…

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

В какой-то момент наиболее ответственный член команды решает устроить субботник и позакрывать то, что уже сделано. Отсюда — популярность следующих вопросов в поддержке Jira:

Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.

Компания Atlassian, известный производитель систем для управления проектами и разработки, объявила о прекращении продаж и поддержки on-premise версий своих продуктов в 2029 году. Эта новость вызывает серьезные опасения среди российских компаний, активно использующих эти продукты для своей работы.

Почему Jira прекращает поддержку on-premise версий?

Atlassian начала поэтапный отход от серверной модели ещё в 2020 году, когда была провозглашена стратегия Cloud First. Инновационные функции последних лет разрабатывались исключительно для облачных решений, оставляя on-premise версии позади. Изначально компания отказалась от версии Server, теперь же процесс коснулся всех серверных решений:

Чтобы освободить команду от рутины, я возглавил инициативу по внедрению автоматизации. Мы добились этого с помощью Jira Automation и Telegram Bot API, полностью избавившись от отчётов и ускорив работу команды — о результатах расскажу в этой статье. Стоит сказать, что до этого я был обычным пользователем Jira, без глубокого погружения в её внутренние возможности. Тем интереснее этот кейс оказался для меня!

В этой статье расскажу, как мы реализовали гибкое многоэтапное согласование в Jira. Особенность подхода — все согласование зациклено в одном статусе, без громоздких схем workflow. Вся логика задается в Assets и управляется через Groovy‑скрипт.

Всем привет!

Я Полина — старший системный аналитик на проекте разработки и развития решений по управления данными в компании "Цифровые сервисы". В целом мой опыт в аналитике более 10 лет на позициях, как бизнес , так и системного аналитика.

На одной из конференций по аналитике[1] увидела интересный слайд, на котором был перечислен набор аббревиатур и вопрос для размышления: «Должен ли аналитик уметь все?».

Наверняка тебе знакома ситуация: начинается утренний синк, и ты задаёшься вопросом: «А что вообще сейчас происходит с задачами?». Кто‑то что‑то делал, кто‑то ждал ревью, у кого‑то что‑то зависло, а кто‑то вообще сидит без работы. На расспросы команды уходит много времени, а картина всё равно остаётся неполной. И самое важное не про все вспомнишь в момент синка.

Чтобы быстро и точно понять текущее состояние дел, удобнее всего использовать так называемый LiveBoard — дашборд, который показывает тебе реальную ситуацию в моменте. Он не про эффективность на дистанции, а про то, чтобы сразу видеть: что сейчас в работе, где возникли проблемы, и на какие задачи обратить внимание прямо сегодня.

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

Знаете, кто ещё больше не любит ожидания? Бизнес. Бизнес очень не любит, когда ожидания копят важные проекты и инициативы. Согласно исследованиям средняя эффективность потока в Delivery составляет 35%, а всё остальное время - задачи ждут. (Данные на основе опросов специалистов — ссылка. Метаанализ тысяч workflow от Nave - ссылка ) Справедливо, что ключевая точка роста для ускорения поставки — уменьшение ожиданий.

Именно об этих "фантастических" ожиданиях и пойдёт речь в статье. Я расскажу о системной работе с блокировками и зависимостями, которые повинны в значительном количестве задержек. Мы погрузимся в необходимую теорию, рассмотрим наш успешный практический кейс в hh.ru и, что особенно ценно, я поделюсь конкретными пошаговыми инструкциями по настройке Jira & n8n, а также способами работать с визуализацией блокеров в удобных плагинах, чтобы вы могли применить этот подход у себя.

Этот материал будет полезен IT-менеджерам, тимлидам, руководителям проектов, delivery менеджерам и руководителям функций — всем, кто стремится более осознанно и эффективно распоряжаться временем и ресурсами.

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

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

В этой статье я поделюсь результатами исследования, посвященного унификации процессов создания проектов в Jira, используя возможности автоматизации и API. Статья была написана с помощью GPT Deep Research в целях изучения различных подходов к унификации рабочих процессов и настройки проектов в Jira. Основная цель — собрать мнения и комментарии от других экспертов, чтобы понять, как они подошли к созданию стандартов и оптимизации процессов в своей практике. Буду рад услышать ваши истории и советы по унификации в Jira, а также обсудить лучшие методы для повышения эффективности и согласованности в работе команд.

Меня зовут Дина, я занимаюсь аналитикой в одной из команд «Ростелеком Информационные Технологии» (РТК ИТ). В статье хочу осмыслить полученный опыт переноса документации и поделиться своими соображениями. Возможно вы тоже думаете о переходе на базу знаний. Такой переход может занять больше времени, чем ожидается. Я расскажу, как это было у нас. В конце подведу итоги: что получили и что потеряли.

Всем привет, меня зовут Денис, я хотел бы поделиться опытом использования AWX в рамках одной из наших потребностей. Статья может быть полезна ребятам с «инфры», если в компании используется vmware и подобное cloud решение для частого деплоя, а для всяческой бюрократии и запросов вы обращайтесь в Jira.

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

Предлагаю познакомиться с нашим опытом по внедрению метрик по JIRA для измерения продуктивности команды разработки 1С в компании Moex.