Устранение ошибок и оповещений при входе в JIRA
При первом входе, как Вы помните, всплыли ошибки в виде оповещений в интерфейсе JIRA. Устраним их.
Первая это на верхнем экране сообщение.
Это говорит о том, что при попытке войти в системные настройки JIRA.
Вы будете каждый раз вводить логин/пароль.
Если мы этого не хотим, то отключим это сообщение следующим образом. Заходим через putty под учеткой root на наш сервер и создаем следующий файл в директории командой
В итоге должно получиться как на скрине. Выходим из режима редактирования нажав на клавишу ESC. Сохраним изменения и выходим из файла командой :wq!
Так как мы произвели изменения под рутом, то при создании файла его владельцем стал root и соответствующие права на файл. Это можно просмотреть командой
Исправим так как должно быть. Для этого введем следующие 2 команды. Первая меняет права доступа к файлу, вторая владельца файла.
Смотрим, что получилось. Теперь все ровно. Едим дальше.
Исправим ошибку Base URL for gadgets (URL канала гаджетов)
Если мы войдем в Администрирование — Система — Инструменты для устранения неисправностей и поддержки, то мы увидим более подробную информацию об этой ошибке.
Если вкратце, то JIRA сама проверяет свое состояние периодически. И ключевой момент здесь, она проверяет себя по тому адресу, который мы дали еще на этапе установки, т.е. по адресу http://jira.companyname.com:8080.
Вы можете сами проверить доступность JIRA по URL введя следующую команду. Если Вы сразу настроили работу JIRA Service Desk через 80 или 443 порт, то команды вводим без указания порта.
И получите примерно такой результат. JIRA не может подключиться и проверить саму себя, так как доменное имя имеет внешний IP адрес. Здесь нужно понимать как работает сеть. Трафик из NAT-а в тот же NAT ходить не будет.
Не решив сразу эту проблему, вскоре Вы обнаружите, что при каждом выходе из JIRA и последующем входе, процесс входа будет занимать примерно около 10 минут. А также не сможете добавить на системный рабочий стол новые гаджеты. При попытке перейти в Администрирование — Система — Системный рабочий стол — Добавить гаджет получите сообщение. We’re still trying to fetch all of the available gadgets
Обычно в компаниях/организациях есть правила/стандарты именования объектов ИТ-Инфраструктуры и не всегда внутреннее имя сервера будем совпадать с именем домена по которому мы обращаемся к JIRA извне. На сайте Atlassian по этой ошибке есть рекомендации, чтобы внутреннее имя сервера совпадало с внешним именем. Т.е. если мы обращаемся к JIRA извне организации по адресу http://jira.companyname.com:8080, которые имеет внешний IP адрес, к примеру 123.123.123.123, то и внутреннее имя сервера должно быть jira.companyname.com, но IP-адрес будет уже внутренний, к примеру 10.10.10.10. Их рекомендации нам не подходят. Мы пойдем другим путем. В файле /etc/hosts добавим строчку
Для этого вводим следующую команду в putty нашего JIRA-сервера
Устраним последнее сообщение Проверка состояния End of Life (Окончание поддержки) в вашей системе не удалась.
Для этого необходимо просто обновить все плагины в Администрирование — Плагины — Управление плагинами
Нажимаем обновить на все плагины по очереди. И вот как должно быть после установки.
Для вступления изменений в силу останавливаем службу jira командой
дожидаемся остановки. Должно быть так
Если служба JIRA не остановится в отведенное системой время, появится сообщение и будет немного другого содержания. Это норма :).
Запускаем службу командой
команда отработает быстро, дожидаемся только полного запуска службы в фоновом режиме. Занимает примерно, в зависимости от мощности сервера, минут 3-5.
После перезапуска службы снова заходим в Администрирование — Система — Инструменты для устранения неисправностей и поддержки. И видим никаких сообщений нет. Все идеально.
Также переходим в Администрирование — Система — Системный рабочий стол — Добавить гаджет и видим возможность загрузить все гаджеты
Нажимаем на Load all gadgets и получаем такой список
Вывод Jira из состояния помойки, с чего начать
Вдруг мы понимаем, что Jira превратилась в помойку. Каждый второй РП настраивал Jira как ему было удобнее бесконтрольно. А когда проект начал гореть, начал тушить пожары вручную, оставляя задачи в трекере в каком-то состоянии, далеком от завершения. Если в проекте создан полноценный CI/CD, то большая часть задач на разработку будет в правильном финальном статусе, но остальные…
Часть проектов заморозилась, часть отвалилась, РП выгнали, но задачи в Jira не почистили. У вас на руках 10-20 идущих “проектов” и нужно быстро понять где больше болит.
Сопоставив опыт участников посиделок КиФБ (клуб имени Фрэнсиса Бекона) в решении этой задачи, мы представили этот опыт в записанном виде (за что спасибо всем участникам).
В начале вы пришли в организацию где 50+ проектов, где внедрен трекер с острым желанием наладить системное управление проектами, обеспечив в том числе прозрачную объективную отчетность.
В объективность вкладывается понимание состояния проекта, опирающееся на что-то кроме мнения руководителя проекта (РП).
Зачем так? РП как большинство людей, привыкли к тому, что за ошибки их бьют. Что делает РП? Скрывает свои ошибки до момента, пока не становится слишком поздно.
Часть отчетов дает финансовое и юридическое управление. Оплаты, договоры, расходы, акты и пр. Но эти средства мало годятся для ранней диагностики проблем, если проблемы возникают в самом рабочем процессе. Если рабочий процесс управляется через трекер задач, то возможно получать информацию из него.
(Но разумеется это работает, если кто-то над РП будет эти отчеты читать, делать выводы и принимать решения, за которые нести ответственность).
Зачем нужны отчеты
Отчет не нужен для отчета
Кадр из фильма “Войны Пентагона”. Аудитору принесли отчеты. ВСЕ отчеты.
Руководитель, сталкивающийся с массой данных в массе отчетов может впасть в ступор. (Форма забастовки: хотите отчеты — получите отчеты).
Компания получает деньги выполняя задачи.
Отчеты должны показывать прежде всего входящий поток будущих денег, связанный капитал, скорость генерации прибыли и операционные расходы. Если трекинг используется для управления изменениями, то это еще и скорость изменений.
Есть разные виды деятельности (проходящие совместно и дополняющие друг друга): проектная, процессная, организационная и исследовательская, анализ которых несколько различается.
Проектная деятельность
В проектах с фиксированной стоимостью важно отслеживать скорость сгорания работы. Если работы заведены в виде задач в Jira, этому могут помогать отчеты (которых мы в этой статье не касаемся). Другой распространенный способ — отслеживать статус проекта по диаграмме Ганта вместе с план-фактом по бюджету (увы задачи в Jira часто забывают закрывать).
Исследования
Исследовательская деятельность не требует решения всех поставленных задач с одной стороны, с другой стороны решенные задачи как правило не создают дохода. Организации для которых это не основная деятельность проводят исследования небольшими командами и короткими циклами, управление в которых происходит “на пальцах” по полученному результату. Jira отчетность мало помогает в управлении.
Процессная деятельность
Рассмотрим процессную деятельность — это выполнение входящего потока задач с оплатой, привязанной к их выполнению, при этом задачи поступают постоянно с некоторой регулярностью (иными словами нет фиксированного scope). К примеру, доработки ИТ системы. В этом случае отчеты могут напрямую отражать состояние процесса.
Входящая задача — это будущие деньги. Зависшая задача = зависшие деньги. Задача, которая протухла (больше не нужна) = потеря денег. Задача, по которой выполнялись работы, но которая не закрыта = связанный капитал, который может быть выкинут если задача протухнет.
Сколько у вас заложено будущего оборота? Это новые задачи, с согласованной оценкой с заказчиком. Но чтобы увидеть это, нужны вычистить шлак — устаревшие не актуальные задачи.
Какой связанный капитал? В ценах продажи — это задачи, которые были взяты в работу и не завершенные. В ценах себестоимости — это трудозатраты по таким задачам в часах или в стоимости ФОТ. За вычетом шлака.
Какая скорость генерации дохода? Обьем денег решаемых задачи в спринт за вычетом стоимости владения команды. Но для этого нужно, чтобы задачи меняли свой статус + люди отмечали время, потраченное на проект. Впрочем, с этими показателями проблем, как правило, возникает меньше всего.
Организационная деятельность это прежде всего деятельность по изменению.
Насколько быстро вы меняетесь? Успеваете меняться? Это скорость выполнения организационных задач и скорость накопления новых. И отчетность по зависшим на сотрудниках задачи, позволяющим не забывать выполнять принятые решения.
Дальнейший путь в Lean поддерживается более сложными отчетами (которые мало затрагивались на посиделках, и подробно не расписываются).
Какие идеи приходят на ум:
Вычищаем Jira
Шаг 1. Ничего не настраиваем
Не меняем workflow, статусы, резолюции. Хотя непривычно разбиратся с непривычными статусами, но это данные, в которые люди вкладывали какой-то смысл.
Шаг 2. Убираем старые проекты
Отчет в формате (Проект, Последняя дата последнего изменения статуса задачи).
Проекты, по которым не было движений — кандидаты на перевод в архив.
Если ответственный по проекту еще работает, он скажет статус, если нет — начинается квест поиска концов.
Задачи архивных проектов переводим в финальный статус с won’t fix. Встречаются замороженные проекты. Статус таких задач переводит в заморожено.
Шаг 3. Убираем старые задачи
Отчет по незакрытым задачам с последним изменением статуса менее Х (два года более чем достаточно. Но обычно, если задача висит 90 дней — она “протухла”) дней, сгруппированный по assignee. Скорее всего они протухли, ответственный скажет (если он назначен и не уволен).
Шаг 4. Убираем лишние типы задач
Отчет распределения незакрытых задач по типам задач для отсева ненужных типов.
Шаг 6. Разбираем задачи уволенных
Выделяем задачи с уволенными исполнителями.
Особенно интересно смотреть за задачами уволенных сотрудников в разрезе их начальников. Начальник сотрудника допустил “слив” связанного капитала потраченного на задачу времени и не организовал доведение задачи до конца.
Вписываем в регламент по увольнению обязательство перевесить/закрыть неактуальные задачи.
Шаг 5. Поиск и разбор самой большой кучи
Отчет по статусам незакрытых задач. Выявляем в каком статусе больше всего задач.
Если статус — задача в работе, то строим отчет по распределению задач в этом статусе по исполнителям. Выделяем задачи без назначенного исполнителя, смотрим задачи по “живым” исполнителям. На каком-то исполнителе накопилось 2000 задач. Хм….
Шаг 7. Стандартизируем статусы, резолюции, жизненные циклы
Возможность взглянуть одинаково на любой проект. Встречаемся и ломаем сопротивление РП. Увы, люди не любят думать о своей заменимости, типичный аргумент: “Я уникально умею вести проект, мне нужен уникальный жизненный цикл.”
Шаг 8. Ищем самые проблемные проекты. Смотрим на отчеты сгорания
Jira — проектов может быть два типа
Если пул задач заведен, то смотрим на прогноз завершения и принимаем меры если прогноз не утешительный.
Смотрим решенные задачи против входящих задач.
Решенные задачи делим на внешние и внутренние (обучение, рефакторинг и пр), отображаем на графике только внешние.
Как читать графики
Есть три условных графика:
Реальность ИТ такова, что трудозатраты на релизацию задач имеют значительный статистический разброс (если это конечно не задачи типа выдачи прав).
Как следствие, для обеспечения нужного SLA по поддержке нужно планировать ресурсы с запасом, иначе это будет приводить к накоплению задач в буферах входящих задач что сделает сроки выполнения недопустимыми. Люди будут не всегда загружены входящими задачами, занимаясь в перерывах обучением или другой не основной работой.
В процессе развития продуктов стараются не допускать простоя разработчиков для обеспечения максимальной скорости развития=зарабатывания денег. Для этого нужно всегда иметь запас задач в беклоге, что означает, что часть задачи чаще всего не будут сделаны, а так как задачи постепенно теряют актуальность это означает, что задачи не будут сделаны никогда.
Вариант А
Нормально, если это реализация фич. На вход поступает больше фич, чем может переварить команда.
Если это поддержка (администрирование и багфиксинг), то ситуация хреновая. Чем больше ошибок, тем медленнее их исправление. Чем медленнее исправление, тем больше накапливается ошибок. Под бочкой с порохом что-то тикает. Тик-так-тик-так….
Вариант В
Если команда делает ровно столько задач, сколько приходит в беклог, то это означает, что
Вариант С
Нормально, если это поддержка. Команда должна иметь простои, чтобы можно было быстро и оперативно решать проблемы и задачи.
Если это реализация фич, то ситуация чаще всего не нормальна. Когда-то был накоплен беклог задач, который разбирается быстрее появления новых. Почему это может быть?
Шаг по безопасности доступа к постановкам
Ловим задачи со ссылками в интернет на гугл докс. Все документы должны быть внутри периметра, ставим задачу на перенос материалов внутрь
Шаг контроля аналитиков
Постановки делаются где?
Вариант А. Прямо в жире.
Вариант Б. В личном гугл доксе сотрудника.
Правильный вариант: Изменение функционала чаще всего должно сопровождаться изменением техно-рабочей документации в Confluence. Как это контролировать?
Связываем страницу постановки с задачей в жире (достаточно вставить ссылку, это автоматом приведет к созданию двунаправленных связей).
Строим отчет по изменениям страниц в confluence и сводим его по аналитику с отчетами Jira по доработкам с трудозатратами. Все доработки с значимыми трудозатратами должны коррелировать с изменениями статей.
Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.
Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.
Статья ориентирована прежде всего на тех, кто уже использует Jira, но, возможно, испытывает сложности с интеграцией её стандартных возможностей в существующие в компании процессы. Также статья может быть полезна компаниям, которые используют другие таск-трекеры, но столкнулись с некоторыми ограничениями и подумывают о смене решения. Статья построена не по принципу «проблема — решение», в ней я описываю сложившийся инструментарий и фичи, построенные нами вокруг Jira, а также технологии, которые мы использовали для их реализации.
Дополнительные возможности Jira
Чтобы последующий текст был более понятным, давайте разберёмся, какие инструменты предоставляет нам Jira для реализации нестандартных хотелок — тех, что выходят за рамки стандартного функционала Jira.
REST API
В общем случае вызов команды API — это HTTP-запрос к URL API с указанием метода (GET, PUT, POST and DELETE), команды и тела запроса. Тело запроса, а также ответ API — в JSON-формате. Пример запроса, который вернёт JSON-представление тикета:
С помощью API вы можете, используя скрипты на любом языке программирования:
Мы написали собственный высокоуровневый Jira API-клиент на PHP, который реализует все необходимые нам команды. Вот пример команд для работы с комментариями:
Webhooks
С помощью webhook можно настроить вызов внешней callback-функции на вашем хосте на различные события в Jira. При этом можно настроить сколько угодно таких правил таким образом, что различные URL будут «дёргаться» для разных событий и для тикетов, которые соответствуют указанному в webhook фильтру. Интерфейс настройки webhooks доступен администратору Jira.
В результате можно создавать правила вроде этого:
Name: “SRV — New Feature created/updated”
URL: www.myremoteapp.com/webhookreceiver
Scope: Project = SRV AND type in (‘New Feature’)
Events: Issue Updated, Issue Created
В данном примере указанный URL будет вызываться для событий создания и изменения тикетов, соответствующих фильтру Scope. При этом в теле запроса будет содержаться вся необходимая информация о том, что именно изменилось и какое событие произошло.
Тут важно понимать, что Jira не гарантирует, что ваше событие будет доставлено. Если внешний URL не ответил или ответил с ошибкой, это нигде видно не будет (кроме логов, пожалуй). Поэтому обработчик событий webhook должен быть максимально надёжным. Например, события можно складывать в очередь и пытаться обработать до тех пор, пока это не закончится успехом. Это поможет решить проблемы с временно недоступными сервисами, например, какой-либо внешней базой данных, необходимой для правильной обработки события.
Подробная документация о webhooks представлена по ссылке.
ScriptRunner
Это плагин к Jira, очень мощный инструмент, который позволяет кастомизировать в Jira очень многое (в том числе он способен заменить собой webhooks). Для пользования этим плагином требуется знание Groovy. Основное преимущество инструмента для нас состоит в том, что можно встраивать во флоу кастомную логику в режиме онлайн. Код вашего скрипта будет исполняться сразу в среде Jira в ответ на определённое действие. Например, можно сделать в интерфейсе тикета свою кнопку, клик по которой будет создавать связанные с текущей задачей тикеты или запускать юнит-тесты для данной задачи. И если вдруг что-то пойдёт не так, вы как пользователь сразу об этом узнаете.
Желающие могут ознакомиться с документацией.
Флоу: что скрыто под капотом
А теперь о том, как мы применяем дополнительные возможности Jira в наших проектах. Рассмотрим это в контексте прохождения нашего типичного тикета по флоу от создания до закрытия. Заодно и про сам флоу расскажу.
Open/Backlog
Итак, сначала тикет попадает в беклог новых тикетов со статусом Open. Далее лид компонента, увидев новый тикет на своём дашборде, принимает решение: назначить тикет прямо сейчас разработчику либо отправить его в беклог известных тикетов (статус Backlog), чтобы назначить его позже, когда появится свободный разработчик и более приоритетные тикеты будут закрыты. Это может показаться странным, так как кажется логичным делать наоборот: создавать тикеты в статусе Backlog, а потом переводить в статус Open. Но у нас прижилась именно эта схема. Она позволяет легко настроить фильтры, чтобы сократить время принятия решения по новым тикетам. Пример JQL-фильтра, который показывает новые задачи лиду:
Project = SRV AND assignee is EMPTY AND status in (Open)
In Progress
Надо отметить, что у нас работа над каждой задачей ведётся в отдельной Git-ветке. Насчёт этого у нас есть соглашение, что имя ветки в начале должно содержать номер тикета. Например, SRV-123_new_super_feature. Также комментари к каждому коммиту в ветку должны содержать номер тикета в формате [SRV-123]:
Эти требования контролируются Git-хуками. Например, вот содержимое prepare-commit-msg, который подготавливает комментарий к коммиту, получая номер тикета из имени текущей ветки:
Если коммит с «неправильным» комментарием попытаться запушить, такой пуш будет отклонён. Также отклонена будет попытка запушить ветку без номера тикета в начале.
Когда тикет попадает на разработчика, первым делом он декомпозируется. Результатом декомпозиции является представление разработчика о способах решения задачи и о том, сколько времени займёт решение. После того как все основные детали выяснены, тикет переводится в статус In Progress, а разработчик начинает писать код.
У нас принято выставлять задаче due date в момент, когда она переводится в статус In Progress. Если же разработчик этого не сделал, ему придёт напоминание в корпоративный мессенджер HipChat. Специальный скрипт раз в два часа:
Что ещё?
Ещё с помощью API и webhooks Jira мы делаем такие вещи:
Итоги
Jira — прекрасный инструмент, который в стандартной поставке позволяет решать большинство проблем, связанных с организацией ведения проектов. Но, как известно, в любом бизнесе есть свои нюансы. И для адаптации Jira к особенностям ваших процессов этот продукт обладает дополнительными возможностями, которые в умелых руках позволят вам решить практически любую проблему.
В следующей статье я планирую поделиться нашим опытом по настройке дашбордов — лидских и девелоперских. Также расскажу про настройку уведомлений в Jira и поделюсь секретами о том, как мы организуем синхронизацию работы разных команд на базе Jira. Надеюсь, что-то из нашего опыта пригодится и вам.
Как работать в Jira
Рассказываем об одном из популярнейших инструментов для совместной работы. О том, как работать с Jira, зачем это нужно и какие есть альтернативы.
Что такое Jira?
Jira – это программный инструмент для управления проектами, разработанный компанией Atlassian. Jira часто используется в IT-компаниях для формирования списка задач, отслеживания общего прогресса команды и решения возникающих по ходу разработки продукта проблем.
Приложение Atlassian построено по принципам канбан- и скрам-досок, давней практики организации задач. Но эти принципы дополняются массой вспомогательных механизмов, которые добавлялись в приложение исключительно с целью упростить создание новых приложений, добавить в них функции, исправить ошибки и т.п. Также эта система управления проектами исповедует Agile-методику разработки.
Название, кстати, происходит от японского слова Gojira, что переводится как «Годзилла».
Что такое канбан/скрам-доска?
Канбан – это методика планирования задач, разработанная в сороковых годах. Суть канбан-доски заключается в наглядном расположении задач в соответствии с их статусом. Типичная доска делится на 3 колонки:
Задачи, которые необходимо выполнить (обычный to-do-лист).
Задачи, которые в текущий момент находятся в работе.
Задачи, которые уже выполнены и висят на доске исключительно для отслеживания прогресса.
Но доску можно дополнить и своими колонками. Например, в отдельный блок вынести реализованные функции, проходящие стадию проверки. Сценариев масса: можно приспособить канбан под что угодно, вплоть до семейного списка покупок на холодильнике.
Скрам-доска – это канбан-доска для разработчиков, исповедующих Agile. Ее обычно дополняют колонками с заданиями на проверке и с отложенными делами.
Что такое Agile-разработка?
Agile – это методика организации рабочего процесса, подразумевающая деление больших целей на мелкие, легко «перевариваемые» задачи и выполняющиеся в период спринтов (то есть недельных забегов активной работы).
Спринт создается на основе заранее сформированных целей. Цели же формируются исходя из пожеланий пользователей продукта. Лидер команды разработчиков организует спринт, добавляя туда те задачи, которые находятся у компании в приоритете и должны быть решены раньше остальных. Скрам-доски и продукты в духе Jira помогают организовывать спринты, следить за прогрессом команды и анализировать проведенную работу.
Перед тем как начать работу с Jira, стоит ознакомиться с основными принципами канбан и Agile подробнее.
Для чего используют Jira?
Как я уже сказал ранее, разного рода канбан-инструменты можно адаптировать под любые виды планирования и менеджмента – под персональные и командные. Но с Jira все складывается немного иначе.
Эту программу создавали для программистов. «Затачивали» каждый аспект под нужды разработчиков. Поэтому работает и выглядит она иначе. Не слишком универсально. В связи с этим вырос ряд конкретных сценариев, в которых применяется JIRA:
Наглядная организация списка задач.
Управление проектом и командой, занимающейся его развитием.
Разработка ПО с нуля или добавление новых функций.
Управление задачами, связанными с маркетинговой составляющей продукта.
Отслеживание ошибок в программе и их своевременное исправление.
Вариантов применения Jira больше, но это основные. Они дают понять, кому вообще нужен подобный программный инструмент.
Алгоритм работы с Jira
Процесс работы с Jira можно разложить на 6 простых шагов:
Для начала нужно загрузить Jira, создать профиль и запустить утилиту. Можно использовать аккаунты Apple и Google.
В окне приложения необходимо выбрать пункт Create Project.
Программа предложит список шаблонов для доски с задачами (для разработчиков, для маркетологов и т.п.). Выбираем ту, что лучше всего соответствует целям команды и стилю работы в вашей компании.
Затем Jira задаст пару вопросов по поводу того, пользовались ли вы ранее Agile и канбан. На основе ответов программой будет принято решение о целесообразности внедрения обучения в интерфейс.
Настраиваем колонки под своим нужды (если то, что было предложено в шаблоне, не на 100% удовлетворяет вашим требованиям).
Создаем задачу (пункт Create).
Приглашаем других пользователей (то есть членов команды) работать с созданной вами доской (пункт Invite).
Как устроена Jira?
Далее разберем основные компоненты Jira. Из чего состоит интерфейс, как создавать задачи, где и какую информацию искать.
Интерфейс
Интерфейс Jira делится на несколько ключевых вкладок. Во вкладке «Projects» хранятся все канбан/скрам-доски, которые вы можете просматривать или редактировать. Фактически это основное рабочее пространство. Здесь же можно перейти в режим отслеживания релизов продукта, взглянуть на все активные спринты, проанализировать отчеты о проделанной работе и т.п.
Также в списке вкладок есть окно с дашбордами – удобно скомпонованными аналитическими сводками. Отдельное окно со списком сотрудников, с которыми вы взаимодействуете, система планирования релизов на манер инструментов в духе OmniPlan и вкладка с приложениями от сторонних компаний, интегрированными в ваш профиль Jira.
Задачи
Задачи в оригинале называются Issues, что можно перевести как «проблемы». Issue – это единица информации. В нее закладывается либо какая-то функция, которую нужно реализовать, либо ошибка в программе, которую необходимо исправить.
Issues – это составные части проекта и спринта. Именно список задач формирует рабочий процесс. Поэтому он и состоит из создания задач, наблюдения за ними, выполнения, анализа, дополнения, изменения и т.п.
Типы задач
У задач в Jira есть типы. Для более удобной категоризации можно выбрать один из вариантов, например новую функцию, баг, подзадачу, эпики и т.п.
Выбор типа задач зависит от целей команды и компании. Можно создавать свои типы для удобного распределения, фильтрации и поиска задач. Соответствующий раздел настроек находится в Project settings.
Дорожная карта (расписание)
В этом разделе можно создавать цели и планировать работу команды наперед. Ключевой единицей информации тут является эпик. Это объединение большого количества issues, связанных друг с другом.
К примеру, если есть ряд новых функций для приложения, которые совместно формируют какую-то общую важную особенность ПО, то их объединяют в эпик как некую общую цель, к которой стремится команда в ходе спринта (или нескольких спринтов).
На дорожной карте хорошо видны далеко идущие планы компании, визуально оформленные в своего рода горизонтальный календарь.
Релизы
Каждый набор новых функций в приложении или пакет исправленных ошибок отправляется к пользователям в виде новой версии этого самого приложения. Версионность – самый удобный, часто используемый и фактически ставший индустриальным способ развития программных продуктов.
Поэтому в Jira такой акцент сделан на контроле новых версий. В соответствующем разделе можно создавать версии программ, указывать дату выпуска и закреплять за ними исправления багов, новые функции и issues, входящий в конкретный релиз.
Здесь сразу видно, какая версия продукта должна выйти в ближайшем будущем, какие уже вышли и т.п. В общем, это еще один удобный способ планирования и отслеживания выполняемой работы.
Код и деплой
Одно из преимуществ Jira – возможность тесно интегрировать ее с другими продуктами, например с платформами Bitbucket, Github и Gitlab.
Такое объединение добавляет дополнительный контекст в систему управления проектами. У лидеров команды появляется возможность наблюдать не только за прогрессом как за набором меняющихся активных задач, но и смотреть на реальные изменения в коде.
Интеграция позволяет разработчикам напрямую отправлять каждый коммит в Jira, чтобы другие члены команды могли видеть изменения из условного Github прямо в системе управления проектами.
Pages
Еще одна разработка Atlassian – проект Confluence. Это что-то в духе Google Docs, только работающее в рамках Jira и менее функциональное.
Это онлайн-текстовый редактор с базовыми инструментами для форматирования написанного. Суть Confluence в создании дополнительной удобной среды для общения лидеров команды и разработчиков. С помощью полноценного текстового редактора и неограниченного количества знаков гораздо проще изложить свои мысли и подробно рассказать о планах компании.
В Pages по умолчанию есть несколько шаблонов для текста:
Пустая страница с небольшим описанием функциональности Pages.
Страница для описания продукта. Сюда можно вписать, как продукт выглядит в глаза клиента и что он в итоге должен собой представлять.
Тестовая форма для указания глобальных целей компании с целью донести ее до команды и сподвигнуть к обсуждению дальнейших действий.
Форма для заполнения расписания встреч и создания заметок по ходу общения с коллегами.
Ретроспективная заметка с описанием проделанной работы. Здесь лидер команды указывает, что в ходе работы пошло хорошо, что пошло не очень и т.п.
Дашборды
В Jira дашборды выводят кучу полезной информации. Всяческие отчеты, статистика комментариев, список выполняемых задач, аналитические данные, графики, таблицы, схемы. Все, что может быть полезно для аналитиков компании и бизнеса в целом.
Дашборды позволяют собрать все необходимые данные в одно пространство без необходимости следить за процессом работы команды и фиксировать какие-то значимые аспекты, чтобы потом вручную делать аналитические сводки. В Jira можно формировать дашборды автоматически.
Они подходят не только для аналитики, но и для постоянного наблюдения за тем, как протекает рабочий процесс, и для принятия радикальных решений в случае упадка производительности или возникновения других проблем.
Плагины
Jira можно сделать еще функциональнее, если подключить к ней плагины сторонних компаний.
Некоторые из них продвигает сама Atlassian. В их числе интеграция с Git-системами, к примеру. Это один из наиболее распространенных и очевидных вариантов использования плагинов.
Также разработчики Jira активно развивают идею тесного взаимодействия между пользователями системы управления проектами и пользователями мессенджера Slack. Есть даже отдельный набор программных модулей для интеграции одного в другое.
В коллекции плагинов можно найти инструменты для создания диаграмм, более удобной визуальной презентации рабочего расписания, отправки задач по почте и т.п.
Коллекция плагинов в Atlassian Marketplace насчитывает сотни дополнений. Как платных, так и бесплатных. Есть из чего выбирать.
Как создать задачу в Jira?
Научиться создавать Issues – понять, как работать с Jira в целом. Создать новую задачу в Jira можно двумя путями:
Кликнув по кнопке Create в верхней панели управления.
Кликнув по кнопке Create issue в нужной колонке канбан-доски.
В первом случае нужно будет выбрать проект, в котором необходимо создать задачу.
Во втором – указать название задачи и прописать дополнительные атрибуты.
Уже после этого можно кликать по кнопке Create, и новая issue автоматически появится в списке и на выбранной доске. А если поставить галочку напротив Create another, то тут же появится окно для добавления еще одной задачи.
Список issues также можно импортировать из другого приложения. Для этого нужно загрузить в Jira CSV-файл с соответствующим содержанием.
Атрибуты задач
Создавая issue, можно указать для нее ряд атрибутов:
Summary. Краткое описание текущей задачи. Буквально в одно предложение.
Description. Полноценное описание, если таковое требуется.
Assignee. Член команды, которому нужно делегировать создаваемую задачу.
Labels. Что-то вроде тегов для более удобной сортировки задач по другим признакам, не входящим в список типов.
Fix version. К какой версии относится создаваемая issue.
Story point estimate. Потенциальные трудозатраты, требующиеся на добавление новой функции или исправление бага.
Reporter. Пользователь, который будет отчитываться за выполнение задачи.
Attachment. Файл, прикрепленный к задаче. Это может быть что угодно: аудио, картинка, документ docx и т.п.
Linked issues. То, с чем связаны создаваемые задачи (другие задачи/проекты).
Настройка отчетов
В графе Reports можно взглянуть на автоматически сгенерированные отчеты о проделанной работе. Пользователям Jira доступны 4 вида отчетов.
Burnup report
График, показывающий результаты работы по конкретному спринту в сравнении с общей производительностью команды разработчиков. Его используют для оценки эффективности текущего спринта.
Sprint burndown chart
График, показывающий, какой еще объем работы необходимо выполнить команде, чтобы продвинуться к завершению текущего спринта. Используется для оценки индивидуальной и общей производительности, а также для приблизительной оценки сроков реализации установленных планов.
Velocity report
Используется для отображения потенциальной производительности команды в будущем. То есть на основе уже завершенных спринтов Jira пытается предугадать, как много задач удастся выполнить разработчикам в ходе следующего «забега».
Cumulative flow diagram
Показывает, как менялся статус активных задач с течением времени. В каких колонках созданные issues задерживаются дольше всего. Используется для поиска так называемых бутылочных горлышек – проблемных этапов работы, на которых резко падает производительность всей команды.
Основные принципы повышения производительности в Jira
Есть как минимум 5 способов сделать работу с Jira эффективнее.
Делите большие задачи на мелкие
Это главная заповедь канбан и скрам, но люди все равно об этом забывают и продолжают лепить карточки с очень массивными задачами. Необходимо всегда создавать максимально компактные задачи. Такие, которые легко понять, выполнить, зафиксировать, объяснить и так далее.
Каждая issue должна быть понятной единицей информации, представляющей собой компонент более глобальной цели.
Делите даже небольшие цели на еще более маленькие составные части. Так всем будет проще. Легче будет выполнять работы, легче будет отслеживать прогресс. Не будет зависаний на выполнении какой-то одной задачи. Интерфейс Jira позволяет без проблем ориентироваться даже в большом списке задач.
Комментируйте задачи
Не стесняйтесь оставлять комментарии под каждой карточкой в каждой колонке. Освобождайте свою голову сразу по ходу создания issues и работы с ними. Нужно помнить о какой-то особенности исправляемой ошибки? Напишите об этом в комментариях. Есть какая-то идея по более прагматичной реализации запланированной функции? И это тоже зафиксируйте в комментариях.
Сохранив все записи в едином пространстве, вы сохраните кучу времени себе в будущем, когда будете вспоминать или искать что-то связанное с конкретной задачей.
Записывайте все выполненные действия
Комментарии отражают процесс выполнения задачи и помогают с решением поставленных целей. Но есть еще логи. Они отражают результаты выполненной работы в течение определенного времени.
Логи работают по тому же принципу, что и коммиты. Коммит – это фактически выгрузка любого изменения приложения в git-систему. Поменяли цвет иконки? Сделайте коммит и отправьте его в git-систему. Добавили новую функцию в код? Сделайте еще один коммит. И так на любой чих.
Лог – это способ фиксировать коммиты в Jira. По сути, те же текстовые комментарии. Просто лидеру команды будет легче отслеживать ваш прогресс с помощью логов. Это показывает, что вы действительно работаете и постоянно выполняете какие-то задачи.
Планируйте спринты
Спринт – удобная схема оптимизации рабочего процесса, но к ней тоже нужно готовиться. Важно заранее спланировать список задач, оценить адекватность поставленных целей, приблизительно оценить сроки выполнения работы, расставить приоритет по задачам. Заранее понять, что, скорее всего, будет отложено на следующий «забег», а что можно сделать быстро и в первую очередь.
Планирование даст возможность быстрее влиться в спринт и без переработок выполнить все поставленные задачи. Четко и без аврала.
Делайте записи на регулярной основе
Вышеописанные процедуры нужно выполнять раз в час-два. Постоянно что-то коммитить, комментировать, записывать и т.п. Все, что не записано, то утеряно. Ваша задача – выработать полезную привычку фиксировать каждое выполненное действие, постоянно делать полезные заметки и всячески демонстрировать свою полезность и эффективность в команде. Большое количество записей действительно облегчает работу коллегам, так как канбан-доска постепенно обрастает всей необходимой информацией. Не приходится все искать самостоятельно.
Стоимость Jira
В бесплатной версии Jira есть ограничение на количество участников в команде и на количество сохраняемых файлов. Чтобы их снять, нужно оплатить подписку. Она стоит около 500 рублей на пользователя. То есть команда из 20 человек заплатит за месячную подписку 10 000 рублей.
Аналоги Jira
Jira – популярный и удобный инструмент. Но многим он кажется чересчур сложным, а иногда недостаточно функциональным. Претензий к продукту Atlassian хватает. Но есть и альтернативные приложения для организации командной работы и управления проектами.
Trello
Trello появился раньше, чем Jira. Это тоже продукт Atlassian, но более универсальный. Trello не заточен исключительно под нужды разработчиков и может использоваться для решения любых задач. Его используют маркетологи, бизнесмены, HR, копирайтеры и т.п.
Подойдет для небольшой команды, не нуждающейся в сложных аналитических инструментах из Jira.
Basecamp
Мощная система для организации командной работы. Она не так сильно похожа на Jira, но тоже пользуется спросом среди команд разработчиков. Здесь есть удобное совместное хранилище файлов, простой механизм для создания задач и отслеживания прогресса, а также собственная платформа для общения между коллегами.
YouTrack
Система управления проектами от знаменитой компании JetBrains, создавшей популярные IDE для разных языков программирования. У YouTrack много преимуществ: встроенная база знаний, принадлежащая конкретной команде, умный поиск по задачам, комментариям и другим единицам информации, удобные методы организации карточек на досках.
Подойдет тем, кому нужна альтернатива для Jira с базой знаний и другими дополнительными опциями.
ClickUp
ClickUp – это своего рода прокаченная версия Jira. Здесь есть возможность делегировать комментарии, создавать упрощенные списки задач, работать с полноценным текстовым редактором, устанавливать рабочие статусы пользователям и так далее. Много мелочей, которые будут полезны для разработчиков.
Вместо заключения
На этом все. Базовое знакомство окончено. Теперь вы знаете, как работать с Jira. Освоиться с функциональностью платформы нетрудно. Куда сложнее влиться в Agile и канбан. Нужно научиться исповедовать эти практики в работе. Тогда интерфейс и возможности Jira покажутся до предела понятными и практичными.