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

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

В данной статье попробуем понять, что нового нам стоит ждать в новой версии JIRA.

Несколько недель назад, 15 февраля, мы проводили нашу первую конференцию для тестировщиков LoveQA. Спасибо всем тем, кто пришел и кто смотрел online трансляцию. У нас есть видео докладов и мы с удовольствием ими с вами делимся. Сегодня выкладываем первые 4 доклада и в конце недели опубликуем остальные.
Если у вас остались какие-то вопросы, то их можно задавать в комментариях к посту.
Фото с конференции в FB и Вконтакте.

Доклады

«Есть ли жизнь после релиза? Наш опыт тестирования мобильных приложений»
Александр z3us Хозя & Николай Козлов, Badoo.

Многие люди жалуются, что в Java чего-то не хватает, что-то глючит или медленно работает. Хорошая новость: у вас есть возможность не жаловаться, а своими силами сделать Java лучше. Java практически полностью открыта в виде проекта OpenJDK. У этого проекта есть свои особенности, но в целом вам ничего не мешает самим сообщать о проблемах, исправлять их и даже разрабатывать новую функциональность. В этой статье я немного расскажу, как это делать новичку.

Распространённая проблема менеджера проектов — определить, от кого зависит дальнейшее исполнение задачи. Часто задача назначается на разработчика, да так и остаётся “висеть” на нём вплоть до релиза. Однако разработчик отвечает только за часть исполнения. QA — тестирует, DevOps — включает в релиз, продакт-менеджер — оценивает готовую работу (в каждой организации эта цепочка своя). Задача путешествует от статуса к статусу (In Progress, Done, Tested, Shipped, Closed и т.п.), но исполнителем значится всё тот же разработчик.

В небольших командах это не представляет сложности, ведь и так примерно понятно, кто должен тестировать, кто релизить и т.д. Но даже команде из нескольких QA уже необходимо изобретать правила, по которым тестировщики должны разбирать себе задачи, помеченные разработчиками как Done. Либо специальный человек должен вручную распределять такие задачи между членами команды. И что самое неприятное — нет гарантии, что задача не будет позабыта и не застрянет в каких-то промежуточных статусах.

0. О чем это все

История началась с того, что в компании, в которой я работал, была старая и, субъективно, несколько неудобная система обработки заявок (OTRS), с которой работала техническая поддержка. Разработка использовала JIRA, а отсутствие интеграции между JIRA и OTRS мешало толком формализовать процесс взаимодействия отделов. Кроме этого, в OTRS было несколько существенных недостатков, например письмо, взятое в работу одним сотрудником поддержки, не мог видеть другой. Эти проблемы надо было как-то решать и в процессе раздумий все свелось к двум вариантам:

1. Обновление OTRS и настройка ее интеграции с JIRA
2. Полный перенос работы техподдержки в JIRA и отключение OTRS

Делать решили второй вариант: это позволяло унифицировать рабочие инструменты, перестать поддерживать лишний сервис (который админы поддерживали по принципу «работает — не трожь», что не позволяло его оптимизировать и развивать), реализовать автоматическую сборку статистики по работе технической поддержки и использовать различные плюшки JIRA: канбан-доски, создание шаблонного бага на разработку одной кнопкой, гибкий поиск, автоматическую рассылку писем при исправлении ошибки и прочее.

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

Во вторник, 21 апреля, Mail.Ru Group организует первый Moscow Atlassian Meetup. В офисе компании соберутся эксперты в области организации общения с пользователями и управления проектами. В программе события — доклады по продуктам Atlassian (JIRA, Confluence и другим), а после — их обсуждение и общение единомышленников в свободной обстановке.

Вступление

Эта статья должна помочь тем, кто так или иначе связан с настройкой процессов обработки заявок в JIRA и хочет гораздо больше, чем предлагается в стандартной поставке, но сам не является разработчиком на Java и не имеет таких людей под рукой.

Я думаю, всем должно быть известно, что JIRA — открытая система для внешней разработки дополнительных плагинов (это кстати очень хорошо). Т.е. умея разрабатывать на java + maven + eclipse, зная хорошо вебдизайн, и т.д и т.п., к JIRA можно приделать все, что только хочется: делай плагины, устанавливай и пользуйся. Более того, можно эти плагины продавать и даже на это жить.

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

Решение есть!

Так вот, есть один плагин, хотя и платный, но умеющий очень многое

JIRA широко используется в Mail.Ru Group. Сейчас мы применяем эту систему не только для управления проектами и отслеживания ошибок, но и для организации самых разнообразных операционных процессов — рекрутинга, согласования договоров, командировок и так далее. Это с одной стороны очень удобно, так как многие бизнес-процессы отлично ложатся на модель Issue в JIRA. Однако часто требуются также и специфичные функции, реализуемые с помощью специально написанных нами плагинов.

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

Сейчас многие JIRA-плагины сторонних разработчиков не могут похвастаться качественным интерфейсом. Это касается даже некоторых платных плагинов. Однако все средства для быстрой разработки удобных и красивых интерфейсов есть. В статье рассматривается одно из них — AUI Framework (Atlassian User Interface Framework).

Предполагается, что читатель знаком с тем, как можно сделать плагин в принципе. Если нет, то об этом можно почитать, например, здесь.

5 лет мы развиваем инфраструктуру Mail.Ru Group, используя продукты Atlassian. Все это время мы постоянно сталкивались с дефицитом специалистов по этим продуктам, к тому же сообщество в России практически не развито. Ответы на все вопросы приходилось искать самим, сражаясь с проблемами, трудностями и службой поддержки Atlassian.

Здравствуйте, дорогие хабражители! Сегодня мы бы хотели рассказать о календаре, который используем в JIRA. Не так давно мы обновили его, а так как статьи о нем никогда и не было, то решили написать о нем в целом, а не только об изменениях. Подробности под катом.

20 октября в офисе компании Mail.Ru Group во второй раз соберутся участники сообщества Moscow Atlassian. Единомышленники поделятся практическим опытом и обсудят тонкости использования продуктов линейки Atlassian. В программе, как обычно, несколько докладов и общение гостей за чашкой кофе.

Общие принципы

1. Задания создаются и пишутся для удобства исполнителей.
2. Результатом работы геймдизанеров являются полные и понятные даже новичкам задания.
3. Исполнители читают задания и меняют их статус. (они пишут код, а не задания)
4. Долго висящие задачи — удаляются (надо будет — еще раз заведем)

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

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

После третьей страницы текста моей статьи, я решил разделить ее на 2 блока:

• Настройка ПО, сопровождающего процесс разработки.
• Описание Workflow.

Итак. Настройка ПО, сопровождающего процесс разработки

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

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

Работа в основном в стиле стартапа, когда нет конкретной и подробной постановки. Очень часто эксперименты вроде “а давайте попробуем так, посмотрим что получится” или “вы классно все сделали, но теперь надо все совсем по-другому”.
За эти годы концепцию нашей работы можно описать одной фразой — это “стремительная смена концепции”.
Понятное дело, что применить в таких условиях различные методологии никак не удавалось.

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

В рамках проходящей сейчас конференции GeekWeek-2015 мы общаемся с нашими спикерами. Сегодня на связи Денис Измайлов, CEO Startup Makers, уже известный многим из вас по своим статьям DenisIzmaylov

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

К сожалению, именно веб-разработкой я занимаюсь не 15, а 13 лет. :) Летом 1998 года я открыл для себя программирование и спустя год увлекся разработкой программного обеспечения для Windows. А немного позже — даже созданием собственной операционной системы. Тогда у меня не было доступа к Интернет. Это была далекая Сибирь. И вот весной 2002 года судьба свела меня с удивительным человеком. Он открыл для меня возможности Web, Apache, PHP. Сделав несколько экспериментальных проектов, я увидел, что мои способности к исследованиям, самообучению, созиданию и красивому могут быть интересны и полезны большому количеству людей. Это захватывает и вдохновляет, когда твой рост и результаты приятны и полезны обществу.

В крупных организациях часто возникает необходимость прикрутить к JIRA какой-либо дополнительный функционал, которого нет в стандартной поставке: автоматизацию, интеграцию с другими системами и прочие кастомизации. Зачастую это решается сторонними плагинами, в Atlassian Market их огромное количество. Но что делать, если подходящего плагина нет? Очевидно, написать свой. Ещё один вариант для расширения — плагины, добавляющие возможность использовать свои скрипты в JIRA: ScriptRunner (Groovy), Jira Scripting Suite (SIL), JJupin (Jython).

В этой статье я расскажу о самом популярном и функциональном из них — ScriptRunner от Adaptavist.

В северном полушарии Земли наступила календарная зима, и мы спешим обрадовать новостью всех интересующихся нашим проектом: запущен релизный цикл эпичной версии ReactOS 0.4!

22 ноября 2015 Amine Khaldi коммитом под номером 70000 создал ветку для подготовки релиза 0.4. Это значит, что отныне и вплоть до самого релиза все изменения, попадающие в транк (основную ветвь разработки), должны быть намеренно перенесены в релизную ветвь, если в этом возникнет необходимость. Такая методика позволяет избежать неожиданных регрессий и случайных багов, однако не является достаточной — необходимо еще и целенаправленное тестирование. Поэтому мы приглашаем всех желающих принять участие в предрелизном тестировании работы программ в ReactOS. Установочные и загрузочные для тестирования следует брать здесь, предлагается использовать билды с номером 69999 (в первую очередь) или новее.

Если вы хотите, чтобы ваша программа (которую вы создали или просто пользуетесь) или ваше устройство заработало в 0.4, самое время прислать баг-репорт. Патчи мы тоже принимаем с радостью, как, например, в истории с СУБД Линтер.

Привет, Хабр! Я работаю в Mail.Ru Group в отделе разработки плагинов JIRA. Плагины позволяют расширять или изменять функциональность приложения. Например, с их помощью можно создавать новые типы полей, гаджеты, JQL-запросы, панели с различной информацией, графики и многое другое.

Большинство наших плагинов требуют хранения дополнительных данных, которые они используют. В этой статье я хочу рассказать, как мы решаем эту задачу. Существует два основных способа хранения таких данных: Active Objects и Plugin Settings. Рассмотрим их поподробнее и разберемся в каком случае лучше и удобнее использовать один, а в каком — другой.

Все мы в IT сталкивались с системами отслеживания ошибок — с так называемыми баг-трекерами, с issue-трекерами. Один из популярных продуктов такого рода — Atlassian JIRA.

На самом деле, Atlassian JIRA — это больше, чем просто система отслеживания ошибок. JIRA может использоваться довольно широко — в том числе и для управления проектами. Можно сказать, что JIRA — это система для отслеживания статуса задач. Задачи могут быть разными: это сбор требований, тестирование, непосредственно разработка и т. д. Я видел даже попытки подсадить на JIRA бухгалтеров — а что, мол, будет у нас agile-бухгалтерия!

На официальном же сайте JIRA описывается следующим образом:
JIRA is the tracker for teams planning and building great products. Thousands of teams choose JIRA to capture and organize issues, assign work, and follow team activity. At your desk or on the go with the new mobile interface, JIRA helps your team get the job done. В общем, основная идея JIRA в том, что она позволяет планировать работу.

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

В Alconost мы делаем видеоролики о сервисах и приложениях. За 4 года мы перещупали сотни IT-продуктов, среди которых встречаются интересные разработки, достойные поста на Хабре. Например, недавно мы сделали ролик о плагине HelpDesk for JIRA для компании «Тимлид».

Чем интересен этот проект? Тем, что он прямо конкурирует с родным модулем саппорта для «Джиры», который, кстати, сам по себе довольно неплохой, но дорогой (например, 5 юзеров — $1500). Получается, что плагин решает ту же проблему, что и «материнский» продукт, только дешевле.

Кстати, а вот и ролик, который мы сделали:



Чуть больше информации про HelpDesk for JIRA — под катом.