Atlassian *

Как мы все знаем, Atlassian ушел из России вместе со своим флагманским и уже ставшим культовым продуктом Jira. Но на место Jira на пьедестале ITSM-платформ и систем для баг-трекинга уже активно претендуют решения из России, а также из Китая. 

Сегодня я расскажу об одном из лидеров сегмента – продукте китайской компании ZenTao Software и о том, как установить ZenTao на Windows. Меня зовут Алексей Пешков, работаю в GlowByte старшим менеджером по развитию направления.

В данной статье мы рассмотрим процесс создания формы на базе JavaScript и включения ее в экран создания запроса в JIRA.

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

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

Если вы не читали статью про базовую автоматизацию, то советую сначала прочитать ее.

Анализ результатов работы с базовой автоматизацией

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

После ухода компании Atlassian мы взялись за задачу по импортозамещению её продуктов. И если ранее мы уже заменили Jira и Confluence, то теперь пришла очередь другого крупного продукта - Jira Service Management. 

Наконец-то можно рассказать о том, что мы успели сделать в его замене - EvaServiceDesk. Мы уже показывали альфа-версию продукта для сообщества Atlassian Community Moscow, теперь официальный релиз в проде.

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

Михаил Михайлец, руководитель группы аналитиков направления облачных решений Лиги Цифровой Экономики, рассказал, как его команда попробовала быстро подготовить задачи по классическому ТЗ (ГОСТ 19) в Jira при работе с государственным заказчиком и что из этого получилось.

Пожалуй, большинству известно, что ГОСТ предусматривает водопадную модель разработки ПО. До недавнего времени она была зафиксирована в постановлении Правительства Российской Федерации от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации».

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

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

Всем привет, меня зовут Алексей - я руководитель отдела интеграции EvaTeam. Это статья о том, как реализована настройка автоматизаций в EvaProject - российском аналоге Jira. В ней рассказывается о том, с чем пришлось столкнуться при переезде с Jira, и как мы реализовали функционал в нашей системе.

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

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

Из распространенного:

В статье расскажем, как произвести импорт данных из системы Jira в систему EvaTeam. При импорте будет использоваться API система Jira. В результате импорта в EvaTeam будет перенесена вся необходимая информация: задачи, списки, доски, пользователи, а также все статусы и бизнес‑процессы, которые используются в системе.

На определенном этапе роста компании наступает момент, когда часть процессов необходимо  перевести в цифровой формат и хотя бы частично их автоматизировать, чтобы снизить нагрузку на сотрудников.

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

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

Дисклеймер: В марте 2022 года компания Atlassian прекратила сотрудничество с российскими юридическими лицами. Однако это не распространяется на уже купленные экземпляры Jira (не по подписке), а также на юридические лица, зарегистрированные вне РФ. Так или иначе, многие нашли выход, который позволил им дальше пользоваться привычным инструментом.  

Atlassian (Jira, Confluence) ушёл из России. +‑ с июня 2022г. в 8 раз выросло количество обращений на импортозамещение этих сервисов в EvaTeam. Мы в EvaTeam полгода закрывали разрыв по функциональности с Jira и Confluence.

К декабрю 2022 закрыли разрыв (Осталось улучшить популярные плагины типа «structure») + сделали крутой импорт.

Основной болью на декабрь 2022г. оставался интерфейс (по словам клиентов). Он был немного другой, пользователи не хотели привыкать. Было принято стратегическое решение — сделать полный клон. Вариант интерфейса «Jira».

Ниже описание со скриншотами того, что удалось разработать за полгода. Российские разработчики сделали за полгода то, что разрабатывалось и внедрялось 20 лет (первый релиз Jira 2002 год).

Кратко, что будет в этой статье:

WorkFlow, GitHub, GitLab, Автоматизация, Миграция из Jira № 1, Гант, Отчеты, Дашборды, Time‑tracker, BQL, аналоги плагинов Tempo, Scriptrunner, draw.io, а также On‑Premise‑версия и т. д. в обновленной EvaProject и EvaWiki

Бот - для работы с репозиторием проекта в BitBucket.

Приветствую любителей ботов :-) Позвольте представить вашему вниманию бота для работы с репозиторием проекта в BitBucket.

Краткое описание моих скромных трудов.

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

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

Спойлер: не откладывайте резервное копирование данных на потом.

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

Хабр, привет! Мы российская компания EvaTeam и мы создаем ПО для управления разработкой. Тема первого поста возникла из нашей деятельности, но вот в чем штука — нельзя так просто сделать пост о методологиях разработки и не скатиться в холивар. И хотя материалов о методологиях хватает, о том откуда они произошли — не особо и пишут (видимо потому, что мы бежим только вперед и оглядываться назад некогда). Но если мы хотим получить представление о том, что будет дальше, полезно иногда возвращаться к истокам. Под катом мы пройдемся по эволюции методологий разработки за более чем три десятилетия, по истокам «гибкой» разработки и поразмыслим о том, как новейшие знания приведут нас ко все более быстрым циклам разработки (но это не точно).

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

После этого перед нами появились новые вызовы — многие проблемы бизнеса всё ещё не решались, или решались с помощью откровенных костылей. Поэтому нам предстояло превратить Jira в настоящий звездолёт.

Конечно, рядовым пользователям от использования Jira бывает больно, и это даже порождает целые сайты вроде — https://ifuckinghatejira.com/. Я же попытаюсь рассказать, как жить с Jira без боли хотя бы для бизнеса.

На протяжении последних трёх лет в компании Karuna я помогал масштабировать и адаптировать Jira под растущие потребности.

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

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

Привет, Хабр.

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

 Очень часто в различных организациях (от Банков до госорганов и ИТ-компаний) приходится решать одну и ту же проблему: как создать целостную и прозрачную картину происходящего на всех уровнях менеджмента?

Топ-менеджеры либо пребывают в состоянии ложного умиротворения по типу «В Багдаде все спокойно», либо Руководству недостаточно понятно, либо совершенно непонятно как в моменте идет достижение стратегических целей (А происходит ли?), чем заняты подчиненные и почему никто не может дать прогнозы и качественно спланировать roadmapы по ключевым проектам / продуктам. (я уже не говорю о портфелях).

Среднее звено часто изменяет стратегические цели в рамках своего их понимания и в угоду своим интересам и спускает вниз на исполнение часто в искаженном виде.

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

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

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

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

Всем привет.

Меня зовут Саша, я технический писатель в CSI, но занимаюсь и проектами в нашей команде разработки. Считайте, что сегодня вы зашли ко мне на работу, плюхнулись в пуфики, взяли кофе — и я просто так рассказываю вам про наш портальчик. Всю публичную техническую документацию по ИТ-продуктам компании мы ведем на портале поддержки, который развернут в инстансе Atlassian Confluence Cloud. Расскажу, как мы к этому пришли, как работали над структурой и принципами подготовки материалов, какой от этого профит.

Картинка тут не случайно. Буквально вчера знакомый художник прислал мне такой портрет меня — и я подумал, что она тут в тему: думаю, многим знакома ситуация, когда в одной голове или ресурсе сосредоточены все знания. Это про меня. Но сейчас я с вами с удовольствием поделюсь!