Jira что это за программа

Jira что это за программа

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

Agile-разработка с Jira

В Jira работают Samsung, Coca Cola, Visa, Dropbox и Audi. NASA использует Jira для создания ПО, которое управляет беспилотными исследовательскими аппаратами в космосе, например марсоходом Curiosity. Еще все эти компании придерживаются методологии Agile.

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

Главные принципы Agile:

Есть два подхода к работе над проектом, основанные на Agile.

1. Методика Kanban — это способ визуализации задач с помощью досок, на которых задачи располагаются в соответствии со статусом. Стандартная канбан-доска делится на три колонки:

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

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

Для чего используют Jira

Этот инструмент создавали для отслеживания статуса задач и ошибок, но со временем его функционал расширился. Сегодня в Jira можно управлять процессом разработки от идеи до запуска готового продукта. Кроме IT-команд, ее используют маркетологи, аналитики, тестировщики и другие специалисты.

Для чего может помочь Jira:

Как пользоваться Jira

Зайдите на сайт проекта и зарегистрируйтесь с помощью электронной почты, Slack, Microsoft или Google-аккаунта.

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

После регистрации инструменты для управления будут доступны.

Интерфейс

Внешне Jira похожа на любой другой таск-менеджер.

В верхней строке меню шесть вкладок:

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

Боковое меню состоит из элементов управления проектами:

В нижней части бокового меню расположены компоненты проекта:

Создание первого проекта

После регистрации в Jira кнопка «Создайте проект» появится в рабочей области в самом центре экрана:

Шаг 1. Jira предлагает на выбор три шаблона проектов, которые подходят для разных методов работы команд:

В первых двух шаблонах рабочий процесс разбит на колонки «К выполнению», «В работе» и «Готово», и в них доступны одинаковые типы задач: эпик, история, баг, задание, подзадача.

Шаг 2. При выборе шаблонов Kanban и Scrum Jira предлагает выбрать тип управления проектом:

Шаг 3. Проекту присваиваются название и ключ:

После этого новый проект будет создан, и внутри него уже можно создавать задачи:

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

Добавить задачу в проект можно двумя способами: кликнуть на кнопку «Создать» в верхнем меню или на «+ Создать задачу» в колонке «К выполнению». Во всплывающей форме заполняются атрибуты задачи:

Повышение производительности Jira

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

Вот что рекомендуют специалисты из Atlassian, чтобы повысить эффективность работы в Jira.

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

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

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

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

Готовиться к спринтам. Подготовка — это составление списка задач, расстановка приоритетов, оценка целей, сроков выполнения работы и сложности. На планирование создатели Jira советуют отводить не менее двух часов в неделю, а при оценке сложности использовать разные способы и обозначения. Например, можно использовать размеры одежды для обозначения величины задач, где XS — это небольшая, простая в решении задача, а XXL — объемная и сложная, которая не решается за один спринт.

Аналоги Jira

Это тоже инструмент для управления процессами на основе канбан-досок, который разработали Fog Creek, но в 2017 году его выкупила компания Atlassian, и теперь и Trello, и Jira принадлежат ей. Trello считается интуитивно понятным инструментом, который подходит любым, даже небольшим командам.

Работа, как и в Jira, организована по методу Kanban, задачи располагаются на досках и делятся на колонки: запланированные, в работе и завершенные. Для каждой задачи заводится новая карточка с названием, описанием, метками, исполнителем и другими атрибутами. Но в отличие от задач в Jira, карточки в Trello могут содержать подзадачи, списки или чек-листы.

Инструмент для управления процессами, организующий задачи в группы, которые и называются Basecamp, то есть «базовый лагерь». Таких групп шесть: новостная лента (Message Board), лист задач (To-dos), общий чат (Campfire), календарь (Schedule), автоматический чек-лист (Automatic Check-ins), документы и файлы (Docs & Files).

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

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

В Asana предусмотрено три уровня коммуникации: общение происходит в комментариях к задаче, в проекте или внутри команды, — это отличает ее от других таск-менеджеров. Для обмена файлами предусмотрена интеграция с Dropbox, Google Диском, Adobe Creative Cloud и другими сервисами.

Позиционирует себя как простая альтернатива другим планировщикам. У Wrike есть готовые шаблоны, выбор которых зависит от целей проекта, — например «Управление маркетинговой кампанией», «Запуск продукта», «Планирование нового проекта» и Канбан-доска.

Wrike, как и Jira, позволяет создавать дашборды с отчетами, отслеживать загруженность команды, чтобы предотвратить переработки и выгорание. Также в планировщике есть система контроля версий. Документы в форматах Word и Excel редактируются прямо во Wrike, скачивать их не нужно.

Источник

Как работать в 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 покажутся до предела понятными и практичными.

Источник

JIRA как средство от бессонницы и нервных срывов

Как наладить эффективный процесс управления проектом в условиях, когда «правильно» и «как лучше» сделать нельзя, но делать все равно надо? В статье дан обзор применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Я буду рад, если описанные подходы помогут лично вам повысить эффективность своей команды и снизить напряженность на проекте. Приветствуется любая критика.

Сын ошибок трудных

Судя по большому количеству типовых статей в Интернете о том, как нужно правильно применять системы управления проектами при разработке программного обеспечения, дело это нехитрое и благодарное. Однако реальное применение автоматизированных систем управления в проектах, в которых довелось поучаствовать, было не таким «радужным», как можно было бы ожидать. Можно выделить несколько типовых случаев, с которыми пришлось столкнуться на практике.

Лучшие варианты сводились к использованию проектной командой одной из многочисленных систем отслеживания ошибок (bug tracking system). Структура задач и бизнес-процессов проекта обычно разворачивалась «из коробки». Данные системы использовались в основном группами программистов и тестировщиков. Такая организация разработки хорошо себя оправдывала на небольших проектах с частными заказчиками или если в задачи исполнителей входило только гарантийное сопровождение программного продукта (исправление выявленных ошибок). Однако с ростом новых требований такой подход начинал буксовать. Это проявлялось в росте временных затрат на сопоставление требований заказчиков и сведений, сохраненных в багтрекере (и ручном составлении интегральных отчетов), а также в разделении команды на два лагеря («хороших» программистов и «плохих» аналитиков).

Другие ситуации сводились к «гениальным» озарениям руководства, когда, используя административные рычаги, в деятельность проектных групп «внедрялись» лучшие методологии разработки программного обеспечения. Правда, эти руководители считали, что их действия ограничивались только процессом нахождения этой «серебряной пули». Они не заморачивались такими понятиями, как «спринт», «диаграмма сгорания задач» или «диаграмма совокупного потока». А даже если и заморачивались, отчетные документы, которые требовалось формировать о состоянии проекта (опять же вручную), были слабо связаны с этой самой лучшей методологией. Попытки приобщить заказчиков к этим методикам приводили к тому, что условия проекта не менялись, а к старым отчетам дополнительно требовалось формировать новые дополнительные отчеты (по новой методике). Особенно ярко такие противоречия проявлялись на проектах по госконтрактам, условия организации которых напрямую конфликтовали с условиями успешности применения Agile, RUP или PMBOK.

Апофеозом автоматизации управления стал проект по доработке информационной системы федерального уровня в интересах одного крупного государственного заказчика. В рамках этого проекта сам заказчик использовал HP Service Manager и JIRA. HP Service Manager использовался для сбора и анализа ошибок программного обеспечения. C помощью JIRA заказчик планировал деятельность своих сотрудников, связанную с исправлением этих ошибок и дальнейшим развитием системы. Перечень состояний задач в этих системах предусматривал все многообразие возможных вариантов их обработки. Подробнейшие регламенты сопровождения этих задач, сформированные проектным офисом заказчика (т.е. людьми, не отвечающими за сопровождение и разработку), были размещены на платформе Confluence. Сотрудники исполнителя были допущены к обеим системам, и на них были возложены обязанности по сопровождению инцидентов и требований (с временными нормативами по обработке задач и прогрессивной шкалой штрафов). Кроме того, на площадке исполнителя был развернут свой экземпляр JIRA, с помощью которого планировалась деятельность проектной группы. Синхронизация деятельности всех трех систем осуществлялась вручную (для этого приходилось вести «простыню» в Excel, в которой отмечались взаимосвязи задач и их текущее состояние). Кроме того, отчеты, которые формировала JIRA, руководство не устраивали, и поэтому сотрудники проектной группы должны были предоставлять почасовые отчеты о своей деятельности, также создаваемые ими вручную в Excel. Не редкостью была ситуация, когда руководитель группы разработки или руководитель групп сопровождения «зависали» на работе до поздней ночи, формируя сводные отчеты о состоянии проекта по результатам деятельности проектной команды. Данный проект был успешно завершен точно в перенесенные сроки и запомнился, кроме рекордно низкой производительности, повышенным количеством нервных срывов, стремительным профессиональным выгоранием и, судя по премиям «выживших» сотрудников, неожиданно невысокой маржинальностью. После таких проектов долго не дает покоя мысль: «Если мы создаем инструменты, которые значительно облегчают жизнь заказчиков, то почему, за счет подобных инструментов, мы так изощренно ухудшаем свою жизнь?»

Особенности национальной разработки

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

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

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

Победа надежды

Второй брак – это победа надежды над жизненным опытом.
Сэмюэл Джонсон

Два года назад я был приглашен в качестве ведущего аналитика на проект, выполняемый компанией ЛАНИТ по госзаказу. Проектная группа была сформирована ранее, проект заключался в существенной доработке автоматизированной системы, существующей более десятка лет. В целом, условия проекта соответствовали описанным выше. На тот момент коллектив разработчиков не применял в своей работе ни одну из существующих систем управления проектами (хотя практически все сотрудники участвовали в проектах, где такие системы использовались и имели довольно скептическое мнение о необходимости автоматизации управления). Однако сложившаяся исходная ситуация предоставила возможность выпестовать автоматизацию управления проектом «с чистого листа».

В качестве платформы для автоматизации была выбрана JIRA. Этому выбору поспособствовала совокупность следующих факторов:

Автоматизация управления проектом изначально преследовала следующие цели:

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

Гарантии преемственности. Одной из целей автоматизации управления проектом является обеспечение преемственности, чтобы любой квалифицированный сотрудник мог «подхватить» обязанности выбывшего члена команды без «испытательного срока» и с минимальной головной болью, чтобы «отряд не заметил потери бойца». В этой связи вспомнился случай, который мне рассказал один из заказчиков. Однажды он остался за начальника, который, уехав в отпуск, сообщил ему пароль от своего компьютера с репликой: «Ну, там все понятно, разберёшься в случае чего…». Этот сотрудник потратил несколько бессонных ночей на осознание содержания нескольких папок с названиями «xxxxx1», «xxxxx11» и «xxxxx111» (названия папок изменены, в интересах соблюдения правил приличия). Предотвращение таких ситуаций требует регистрации в JIRA результатов работы всех сотрудников проектной команды, включая руководителя проекта.

Минимализм. Цель автоматизации управления проектом состояла не в том, чтобы посчитать с точностью до минуты, сколько тот или иной сотрудник потратил рабочего времени на решение поставленных перед ним задач, а в том, чтобы обеспечить решение задач с заданным качеством в требуемые сроки. Поэтому при развертывании проекта в JIRA был принят принцип минимизации данных, регистрируемых в системе. Т.е. набор параметров, регистрируемых в системе управления, должен был быть минимально необходимым для принятия обоснованных решений («Совершенство достигнуто не тогда, когда нечего добавить, а когда нечего убрать»). При этом подразумевалось, что принятая модель автоматизации управления проектом должна работать в условиях высокой неопределенности и непоследовательности (например, можно знать дату документа, но не знать его номер и наоборот). При типизации регистрируемых сведений использовалось, где только возможно, правило Миллера, говорящее о том, что оптимальное количество типов (состояний) должно лежать в пределах «семь плюс-минус два» (что значительно упрощает понимание работы системы сотрудниками). Так, например, при проектировании жизненного цикла задач (workflow) изначально предполагалось, что количество состояний должно соответствовать данному правилу.

Системность. Автоматизация управления проектом должна способствовать согласованности и слаженности действий всех сотрудников проектной команды (предотвращение ситуации «лебедь, рак и щука»).

В одном из проектов, в котором мне довелось поучаствовать, команда аналитиков в течении месяца разрабатывала модель автоматизируемой деятельности в нотации IDEF0. Как казалось, само использование методологии, созданной ВВС США (!), гарантировало успешность такого подхода. Однако, когда многостраничный аналитический отчет изучил начальник отдела программирования, его первым вопросом был: «Так, что собственно надо сделать?». Сформированная модель оказалась непригодной для использования, как описание постановки задач для программистов. Представители заказчика несколько раз восхитились, бегло просматривая многочисленные схемы, однако также не нашли применения этой модели для оптимизации своей деятельности. В конце концов эти схемы украсили описание технологических процессов, придав этому документу невиданную доселе толщину и солидность, однако на этом положительный эффект проведенного анализа был исчерпан. Результаты месяца работы нескольких аналитиков фактически оказались невостребованными в рамках проекта.

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

Канбан-доска наизнанку

По моему убеждению, успех автоматизации управления в решающей степени зависит от того, насколько точно смоделирован объект управления в автоматизированной системе. Поскольку предполагалось автоматизировать управление процессом создания программного обеспечения, был проведен анализ этого процесса. На мой взгляд, процесс создания отдельных программных модулей всегда представляет классический каскадный жизненный цикл waterfall. Сначала появляется перечень требований к создаваемому продукту. Требования могут приходить из разных источников и имеют разную степень детализации. Часть требований взаимосвязаны между собой, другая часть относительно независима. По отдельным требованиям можно сразу сформировать задачу на разработку, другие — требуют уточнения и конкретизации. Т.е. всегда существуют работы, связанные со сбором, сортировкой и уточнением требований заказчика (при этом формулировки отдельных требований могут носить неоднозначный характер до окончания проекта). После того, как требования максимально конкретизированы, как правило, по группам взаимосвязанных требований формируются так называемые описания постановки задач, которые детализируют особенности реализации этих требований и являются исходным материалом для начала работы программистов. После окончания программирования созданные модули тестируются автономно, интегрируются в систему, тестируются повторно. По выполненным доработкам ПО вносятся соответствующие изменения в проектную и эксплуатационную документацию, после чего проводится ряд мероприятий, направленных на признание выполненной доработки чаяниям (требованиям) заказчика и последующее внедрение разработанного функционала в промышленную эксплуатацию.

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

Для прозрачности распределения ответственности при автоматизации управления проектом был реализован принцип «1 задача – 1 исполнитель». Т.е. процесс выполнения задачи заведомо не предполагал ее передачу другим исполнителям. Этот принцип позволил применить одинаковый бизнес-процесс ко всем типам задач, поскольку статус выполнения работы определялся прежде всего, с точки зрения исполнителя этой задачи. Стандартный для JIRA рабочий процесс (workflow) был немного изменен. Главное изменение заключалось в замене статуса «переоткрыт» на статус «в ожидании», т.е. состояния, когда работы по задаче приостановлены по какой-либо причине. Для регистрации переоткрытых задач стало применяться пользовательское поле «Счетчик переоткрытий». При этом, были детализированы виды причин перевода задач в ожидании решения:

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

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

Созданный дашборд, на первый взгляд, слабо отличался от классической Канбан-доски, однако в нашем случае столбцы означали не статус выполнения задач, а их тип. В этом дашборде для каждого требования формировалась отдельная строка, в которой были отражены все связанные с этим требованием задачи, сгруппированные по видам деятельности (в классической последовательности waterfall). Если задача была создана в интересах выполнения нескольких требований, то карточка этой задачи повторялась в каждой из строк связанных требований. Статус выполнения задач отражался на данном дашборде цветом, который создавал «третье измерение». Степень готовности требования определялась при этом готовностью всех связанных с этим требованием задач. Получилась как бы Канбан-доска вывернутая наизнанку. С другой стороны, с позиции положений PMBOK, сформированный дашборд представлял собой усовершенствованный вариант классической матрицы отслеживания требований (Requirements Traceability Matrix).

Для отображения статуса выполнения задач была принята следующая цветовая схема:

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

— обычный;

— важный;

— критический;

— блокирующий.

Метки о рамках требования:

— развитие (требования в рамках проектов, направленных на существенную доработку существующих систем);

— расширенное сопровождение (требования по оперативной доработке отдельных модулей системы по текущим изменениям бизнес-процессов заказчика);

— гарантийное сопровождение (выявлены ошибки программного обеспечения);

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

Метки причины ожидания:

— запрос дополнительных сведений у заказчика;

— согласование с заказчиком;

— ожидание решения связанных задач/подзадач;

— требуется уточнение постановки.

— в задаче была доработана база данных;

— количество связанных с задачей требований (чем больше связанных требований, тем более важно выполнение задачи);

— количество нерешенных подзадач;

— задача переоткрыта.

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

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

Waterfall нельзя Agile

В интересах регистрации результатов работ по всем типам задач были развернуты два репозитория (для документации проекта и для кода программного обеспечения). Добавление (изменение) материалов в этих репозиториях автоматически отражалось в связанных задачах JIRA и являлось основным видом отчетности исполнителей.

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

В рамках предложенного подхода хорошо зарекомендовало себя планирование работ с использованием метода «набегающей волны» (Rolling Wave Planning). При этом, отчасти благодаря вышеописанному дашборду, удавалось избегать разрозненности и несогласованности планируемых работ. На начальных этапах регистрации выборка по требованиям напоминала красный зонтик, когда для большинства требований не определены сроки готовности и ответственные исполнители, а работы запланированы только по их малой части. Однако постепенно дашборд требований превращался в сине-зеленый ковер. Появляющийся на этом ковре красные и оранжевые пятна заставляли проводить ежедневную корректировку намеченных задач, что способствовало снижению проектных рисков.

Предложенная модель организации данных показала хорошую масштабируемость. Изначально в своей работе JIRA использовали только три сотрудника из проектной группы (один аналитик и два программиста), при этом регистрировались требования по отдельным подсистемам. Однако к окончанию проекта 100% требований на развитие и на расширенное сопровождение регистрировалось и отслеживалось в JIRA с участием всех сотрудников проектной группы.

Несмотря на то, что замысел автоматизации управления проектом базировался на каскадной модели разработки (waterfall), оказалось, что в рамках предложенного подхода, при желании, могут безболезненно применяться элементы Agile. А кто, вообще, сказал, что водопад не гибкий? Например, для применения Scrum, в рамках предложенной модели, достаточно обеспечить регулярность проведения мероприятий (задач) по внедрению программного обеспечения, и тогда, соответственно, все работы, связанные с этим мероприятием, будут «вынуждены» подчиниться правилам спринтов, заданных таким образом.

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

Продолжение следует

Что в итоге? Разработанное программное обеспечение принято в промышленную эксплуатацию. В ходе проведения предварительных испытаний, опытной эксплуатации и приемочных испытаний заказчик зафиксировал множество замечаний к реализованному программному продукту. Однако впоследствии на основании материалов уточнения требований, которые хранились в JIRA, 25% замечаний заказчик был вынужден признать как новые требования, выходящие за рамки проекта (планируемая трудоемкость выполнения этих требований была соизмерима с реализованным техническим заданием). Проблемы, связанные с выполнением контракта по госзаказу, не исчезли, однако контроль исполнения требований с использованием JIRA позволил выявлять риски срыва на стадии зарождения и оперативно на них реагировать. Это, в свою очередь, обеспечивало положительную динамику проекта на всех его этапах, несмотря на особенности национальной разработки программного обеспечения. Было замечено, что если требования заказчика зарегистрированы в JIRA и по ним сформированы задачи на анализ, разработку и тестирование, то в отношении таких требований происходило гораздо меньше разногласий и споров.

На текущем этапе (этапе сопровождения) все требования находят отражение в JIRA. Все сотрудники проектной группы так или иначе используют JIRA в своей работе. Затраты программистов на регистрацию результатов своей работы в JIRA отнимают менее 1% их рабочего времени. Для аналитиков, напротив, JIRA стала одним из основных рабочих инструментов. Поиск полного набора сведений по любому из требований заказчика составляет менее минуты. Отчетные документы по результатам выполненных работ формируются автоматически на основании данных, содержащихся в JIRA. Также на основе этих данных формируется сопроводительная документация к релизам (перечень изменений и программа испытаний релиза).

Двухлетний опыт применения JIRA по новым правилам подтвердил старые истины:

P.S. Эта статья является первой из цикла статей под названием «Правила своевременного приготовления вкусного программного обеспечения» который я использую как неформальный регламент команды на заказных программных проектах в интересах государственных организаций. В этот цикл входят следующие статьи:
— «JIRA как средство от бессонницы и нервных срывов» — основная идея по организации работ на проекте с использованием JIRA;
— «JIRA: границы проекта» — основные положения по унификации проекта и общие требования ко всем типам задач JIRA;
— «JIRA: управление требованиями» — ключевые особенности регистрации, уточнения и контроля реализации требований заказчика в рамках предложенной модели;
— «Проектные решения: игра по твоим правилам» — основные аспекты управления аналитической работой и формирования постановок задач для разработчиков;
— «Матрица компетенций аналитика для самурая в запасе» — критерии оценки уровня зрелости аналитиков на заказных программных проектах;

В рамках этого цикла настоящее время готовится к публикации:

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

Основной лейтмотив этой серии статей — обеспечить эволюционное совершенствование качества программных проектов на основе повышения эффективности управления. Другими словами — сформировать прикладные способы роста по уровням модели CMMI.
Если вы придумали как эффективней использовать JIRA на своем программном проекте — делитесь своими идеями. Только в описании этих идей избегайте словосочетания «как-нибудь» и «как-то». Приглашаю к обсуждению всех. Жду замечаний/предложений/сомнений/пожеланий в комментариях.

Источник

Краткий обзор Jira

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

О семействе продуктов Jira

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

Команды разработчиков ПО работают лучше с помощью Jira Software — лучшего инструмента для agile-команд. Предоставляйте обслуживание высочайшего уровня ИТ-командам, командам разработчиков, а также операционным и другим командам с помощью Jira Service Management. Бизнес-команды могут открыть возможности методики Agile и повысить эффективность совместной работы с помощью Jira Work Management. Кроме того, существует Jira Align — платформа для корпоративного agile-планирования и координации работы при любом масштабе.

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

Обзор продуктов Jira

Для всех участников agile-команды и не только: планируйте, отслеживайте и выпускайте ПО мирового уровня.

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

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

Платформа для корпоративного agile-планирования — связующее звено между стратегиями на уровне продуктов, программ и портфелей и техническим воплощением при любом масштабе.

Пользователи

Примеры использования

Размещение

Лицензирование

Основные интеграции для Jira Software

Пользователи

Примеры использования

Размещение

Лицензирование

Пользователи

Примеры использования

Размещение

Лицензирование

Основные интеграции для Jira Work Management

Пользователи

Примеры использования

Размещение

Облако, выделенное облако

Лицензирование

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

Пользователи Jira Align Enterprise имеют доступ ко всем функциональным возможностям версии Standard, а также модулям решений, портфелей и корпоративным модулям.

Основные интеграции для Jira Align

Варианты размещения Jira Software

Решение Jira Software предполагает два варианта размещения: в облаке и на собственном хостинге. Не уверены, какой вариант лучше выбрать? Ознакомьтесь с обзором ниже.

Cloud

При покупке версии Cloud мы выполняем для вас размещение и настройку сайта Jira Software в облаке. Этот вариант подходит командам, которые хотят приступить к работе как можно быстрее или не хотят тратить время и силы на техническое обеспечение самостоятельного хостинга. Подробнее

Data Center

При выборе версии Jira Software Data Center можно разместить Jira Software на собственном оборудовании или у поставщиков IaaS-инфраструктуры, например AWS или Azure. Этот вариант, как правило, подходит корпоративным командам, которым нужен постоянный доступ к Jira Software и высокая производительность при любом масштабе. Подробнее

Основные понятия

Неполадки

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

Подсказка: для обозначения задач используются также термины «запросы», «заявки» или «задания». Мы рекомендуем все-таки называть их «задачами», чтобы избежать путаницы в команде при работе с семейством продуктов Jira.

Проекты

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

Проекты Jira Software — это адаптируемые рабочие пространства, позволяющие группировать похожие задачи по командам, бизнес-подразделениямм, продукта или направлениям деятельности. Проекты не обязательно прикреплять к одной дате поставки. Например, сгруппировав задачи по команде, вы можете получить проект по маркетингу, проект по разработке и проект юридического характера, в каждом из которых будет отслеживаться работа соответствующих команд. Каждая задача будет отмечена ключами задачи (у каждого проекта свои ключи) и номером задачи, например MKT-13, DEV-4, LEG-1.

Доски

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

Процессы

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

Здесь Open (Открыто), Done (Завершено) и все промежуточные метки обозначают статус, который задача может принимать, а стрелки обозначают возможные переходы из одного статуса в другой. Рабочие процессы могут быть простыми или сложными, содержать условия, триггеры, валидаторы и пост-функции. Такие сложные конфигурации будут рассмотрены в этом руководстве далее. На данном этапе администраторам, впервые работающим с Jira Software, рекомендуется не усложнять рабочие процессы, если сложный рабочий процесс не является изначальным требованием бизнеса.

Гибкая методология Agile

Термин agile не относится напрямую к Jira Software. Это рабочая методика, сложившаяся в сфере разработки ПО и впоследствии перенесенная во многие другие отрасли. Мы не будем специально останавливаться на определении (для этого есть другие специализированные ресурсы по agile). Скажем лишь, что agile опирается на итеративный подход к работе, обратную связь с клиентами и непрерывную инкрементальную поставку результатов работы. Идеальная agile-команда способна действовать быстро и приспосабливаться к меняющимся требованиям без существенного снижения скорости работы.

Мы затронули здесь тему agile неспроста. Основные наборы возможностей Jira Software были разработаны специально для работы по методикам agile, в том числе scrum и kanban. Поэтому, встретив такие понятия, как «доски», «оценка» или «карточки», задумайтесь, подходят ли для вашего порядка работы принципы agile.

Помните, что agile — это философия и культура работы, поэтому само по себе использование Jira Software не означает, что ваша команда теперь придерживается этих принципов. Это инструмент, который поможет вашей команде приобщиться к agile.

С помощью Jira Software команды, следующие принципам Agile, могут работать еще эффективнее. Для получения дополнительной информации ознакомьтесь с рекомендациями по использованию методик Agile для Jira. Перейти к руководству.

Источник

Система управления проектами и задачами JIRA компании Atlassian и ее применение

О продукте JIRA

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

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

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

Для поддержки гибких методик разработки (Agile software development, Scrum и Kanban вы можете установить add-on JIRA Agile (ранее называвшийся Greenhopper).

Смотрите страницу на сайте Atlassian обо всех продуктах компании.

Области применения JIRA

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

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

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

Главное преимущество этого продукта в его ни с чем не сравнимой способности настройки под ваши нужды.

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

Проекты и задачи

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

Проекты

Также, JIRA формирует отчеты по каждому проекту.

Задачи

Задачи создаются в проектах. Задачи имеют типы, например: Задание, Ошибка, Новая идея. Можно создавать и свои типы задач. При описании каждого типа задачи имеется возможность управления набором полей.

Фильтры

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

Управление доступом, разделение ролей

Для организации работы с пользователями JIRA имеет группы пользователей и роли.

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

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

Типичное простейшее разделение ролей в JIRA включает в себя роли:

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

Движение задач

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

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

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

Движение задачи можно сделать зависимым от условий, применять логику И/ИЛИ, выполнять определенны действия на каждом этапе движения задачи.

Нотификации

Задачи JIRA в каждый момент времени имеют определенный статус. Пользователи информируются по e-mail в случае любых действий с заданиями, для этого служит настраиваемая система нотификации пользователей. Совместно с системой управления движением задачи и настраиваемыми рассылаемыми фильтрами это позволяет очень эффективно информировать всех заинтересованных лиц о ходе выполнения задачи.

Отчеты и диаграммы

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

Кроме стандартных отчетов, JIRA позволяет написать свои отчеты.

Приборная панель

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

Безопасность

JIRA может работать через защищенное соединение с применением SSL.

Расширенные возможности JIRA, JIRA API

JIRA позволяет создавать задачи через e-mail и таким образом автоматизировать работу.

Имеется возможность просмотра хранилища файлов CVS (Система Конкурентных Версий).

JIRA имеет опубликованный программный интерфейс, обеспечивающий программный доступ к основным функциям системы (SOAP API), расширения позволяющие дополнять систему собственными сервисами для решения специфичных задач предприятия.

Пользователи JIRA

JIRA используют для контроля ошибок и проектов в более чем 20 000 организациях в более 138 странах по всему миру. В Fortune 1000, общественных организациях, в научных и технологических сферах:

Например, здесь список некоторых из пользователей JIRA в сфере государственного управления:

Отзывы пользователи JIRA

Новости

Источник

BYTEX BLOG

JIRA: ПОДРОБНОЕ РУКОВОДСТВО ДЛЯ НОВИЧКОВ

JIRA — приложение, разработанное австралийской компанией Atlassian. Его название произошло от японского слова «Gojira», что значит «Годзилла».

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

1. Система JIRA

JIRA состоит из ряда компонентов, каждый из которых можно настроить. Это:

2. Задачи JIRA и их типы

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

Во вкладке «Задачи» (Issues) можно обнаружить следующие функции:

9
Типы задач (Issue Types)

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

В JIRA есть две системы организации типов задач.

Стандартная система организации типов задач (Default Issue Type Scheme).

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

Agile Scrum система организации типов задач (Agile Scrum Issue Type Scheme).

Задачи и проекты, которые ассоциируются с Agile Scrum, используют эту систему.

Помимо этих двух схем вы можете создавать собственные типы задач, настраивая функционал под себя. Например, мы можем создать схему IT и Поддержка (IT & Support), перетащив типы задач из вкладки «Доступные типы задач» (Available Issue type) на вкладку «Типы задач для текущей схемы» (Issue type for current scheme), как показано на скриншоте ниже.

3. Компоненты JIRA

Компоненты — это подразделы проекта. Они используются, чтобы комбинировать задачи текущего проекта в малых разделах. Компоненты добавляют проекту структурированность, разбивая его на функции, группы, модули, подпроекты и прочее. Используя компоненты, вы можете генерировать отчеты, собирать статистику, отображать ее на панелях управления.

Как показано на скриншоте, вы можете добавлять новые компоненты, такие как Название (Name), Описание (Description), Руководитель отдела/команды (Component lead) и Назначенный ответственным по умолчанию (Default assignee).

4. Окна JIRA (JIRA screen)

Если задача создана в JIRA, она будет организована и представлена на различных рабочих пространствах, которые называются экранами. Эти рабочие пространства могут переводиться и редактироваться в ходе рабочего процесса. Как можно увидеть на скриншоте, каждой задаче вы можете назначить тип экрана. Чтобы ассоциировать осуществление задачи с определенным экраном, нужно зайти в главное меню, кликнуть Задачи (Issues), кликнуть Схемы (Schemes), после этого кликнуть Ассоциировать осуществление задачи с экраном (Associate an issue operation with a screen) и добавить экран, соответствующий требованиям.

5. Свойства задач (Issue Attributes)

В свойства задач входят:

Различные статусы используются, чтобы обозначить прогресс проекта: Ожидает выполнения (To do), Выполняется (InProgress), Открыт (Open), Закрыт (Closed), Переоткрыт (ReOpened), Решен (Resolved). Также имеются решения и приоритеты. Решения обозначают прогресс выполнения задачи: Исправлено (Fixed), Не будет исправлено (Won’t fix), Дубликат (Duplicate), Не завершено (Incomplete), Не воспроизводится (Cannot reproduce), Выполнено (Done). Также вы можете указать приоритеты задач: Критический (Critical), Высокий (Major), Малозначимый (Minor), Блокирующий (Blocker) и Тривиальный (Trivial).

6. Схемы защиты задач JIRA (Issue Security Schemes)

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

Также имеется Стандартная схема защиты (Default Permission Scheme), которая будет назначена любому новому проекту. Схемы защиты позволяют вам создавать наборы уровней доступа и применять их к любому проекту.

Системная администрация (System Administration)

Вот несколько полезных функций, которые JIRA предоставляет администраторам:

Логи ревизий (Audit Log). В этой вкладке вы можете увидеть детали созданной задачи, а также изменения, внесенные в задачу.

Связывание задач (Issue Linking). Здесь указывается связана ли ваша задача с какой-то другой, существующей в данном проекте. Также в этой панели можно отменить данную связь.

Система почты JIRA (Mail in JIRA). Используя систему почты в качестве администратора, вы можете пересылать задачи на почтовые сервера POP и IMAP, а также отправлять их в виде сообщений на внешние почтовые ящики.

События (Events). В этой вкладке описан статус, стандартный шаблон, схемы оповещения и передача ответственности за событие. События разделены на два типа: Системные события (System event, те, что установлены в JIRA по умолчанию) и Пользовательские события (Custom event, соответственно, те, что были созданы пользователями).

Контрольный список (Watch list). Позволяет просматривать определенные задачи, видя уведомления, связанные с ними. Чтобы просмотреть задачу, кликните «просмотр» в окне задачи, а если вы хотите увидеть, кто еще просматривает эту задачу, вы можете нажать на число в скобках.

Счетчик задач (Issue Collectors). Позволяет собирать информацию с любого сайта. Будучи администратором, можно кликнуть по счетчику задач, после чего появится опция, позволяющая его добавить. Как только вы настроите внешний вид счетчика, автоматически сгенерированный JavaScript можно перенести на сайт для передачи информации.

Инструменты разработки (Development Tools). Вы можете также подключить ваши инструменты разработки ПО к JIRA, используя функции администратора. Вам необходимо ввести URL приложения для подключения его к JIRA.

7. Как создать задачу в JIRA (How to create an issue in JIRA)

Панель задач JIRA откроется, как только вы введете свой ID и пароль. Под панелью управления вы обнаружите вкладку Проекты (Project). Кликнув по ней, вы откроете окно со списком таких опций, как Простое отслеживание задач (Simple Issue Tracking), Управление проектами (Project Management), Agile Kanban, Классическая JIRA (Jira Classic), соответственно скриншоту.

Если вы кликните по опции Простое отслеживание задач (Simple Issue Tracking), откроется другое окно, в котором упоминаются детали задачи, а также назначение определенному ответственному лицу.

После нажатия кнопки Подтвердить (Submit) откроется окно, в котором можно выполнить ряд действий, вроде создания и назначения задач, проверок их статуса и т. д.

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

Теперь, если вы захотите отредактировать задачу или экспортировать ее в виде XML/Word документа, вы можете навести курсор на главную панель и кликнуть Задачи (Issues). В появившемся списке выберите Поиск задач (Search for issues), после чего откроется окно, с помощью которого вы можете обнаружить ваши задачи и выполнить другие действия.

Когда вы выберете Поиск задач (search for Issues), откроется такое же окно, как на скриншоте ниже.

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

Воспользовавшись функцией Сводка (Summary), вы откроете окно с диаграммой, на которой можно увидеть все детали, связанные с вашим проектом, и прогресс работы над ним. В правой части окна сводки вы можете увидеть Журнал активности (Activity Stream), на котором отображаются детали, связанные с задачей, и комментарии, оставленные ответственным за задачу человеком.

Подзадача (Sub-Task)

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

Как создать подзадачу

Подзадача может быть создана двумя способами:

Чтобы создать подзадачу в JIRA, вам нужно выбрать задачу, к которой вы хотите ее прикрепить. В окне задачи выберите опцию Назначения. Прочее (Assign more), после этого выберите Создать подзадачу (Create sub-task), как показано на скриншоте. Вы можете также конвертировать задачу в подзадачу (convert to sub-task), выбрав соответствующую опцию.

Выбрав опцию Создать подзадачу (Create sub-task), вы откроете соответствующее окно. Заполните поля с деталями, касающимися данной задачи, и нажмите кнопку Создать (Create), как показано на скриншоте ниже.

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

Несколько важных вещей, которые нужно помнить, создавая подзадачи:

Рабочий процесс (WorkFlow)

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

Рабочий процесс JIRA состоит из статусов (statuses), переходов (transitions), назначений (assignee), решений (resolution), условий (conditions), проверок (validators), и свойств (properties).

Статусы определяют статусы задач во время рабочего процесса.

Переходы подразумевают под собой процесс смены статуса.

Назначения указывают ответственных за определенные задачи и определяют пути решения задачи.

Решения объясняют, по какой причине задача может считаться закрытой.

Условия контролируют доступ к переходам.

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

Свойства определяются JIRA при переходах.

Вы можете назначить статус задаче в соответствующем ей окне, кликнув на флажок статуса В работе (IN Progress), как показано на скриншоте ниже. Это отобразит статус задачи на ее рабочей панели, выделив его желтым цветом.

Для созданной нами задачи JIRA отобразит таблицу рабочего процесса, на которой указан путь, пройденный задачей во время работы над проектом. Все статусы, которые мы устанавливали для задачи, отображаются на таблице. Как показано на скриншоте, в нашей таблице появился ряд статусов, а статус «В работе» (IN Progress), который является текущим, выделен желтым цветом. Таблица рабочего процесса дает возможность быстро просмотреть, через какие стадии прошла задача.

Плагины JIRA (Plug-ins in JIRA)

Для JIRA существует множество плагинов, позволяющих вам эффективнее работать. Это такие плагины, как Zendesk, Salesforce, GitHub, Gitbucket и т. д. Часть из них позволяет команде поддержки отчитываться о работе напрямую в JIRA, создавать неограниченные приватные репозитории с полной поддержкой задач, инструментов управления тестированием и т. д.

JIRA Agile (JIRA Agile)

Agile метод в основном используется командами разработчиков, которые пользуются концепцией «дорожная карта» (roadmap), подразумевающей под собой последовательный переход между запланированными функциями в процессе разработки новых версий продукта. Agile следует той же «дорожной карте», что и другие проекты в JIRA «Ожидает выполнения — В работе — Завершено» (To do — In Progress — Done). Как вы можете увидеть на скриншоте ниже, у нас есть одна задача со статусом «Ожидает выполнения» и вторая со статусом «В работе». Как только задача «В работе» будет решена, ее статус изменится на «Завершено», и точно так же задача «Ожидает выполнения» получит статус «В работе».

Создание задачи в Agile

Чтобы создать agile-задачу, перейдите в главное меню на вкладке «Agile», нажмите «Начать работу» (Getting Started), после чего вас попросят выбрать, какой использовать метод управления: «Scrum» или «Kanban». Вы можете выбрать одну из опций в зависимости от ваших требований. В данном примере мы выбрали «Scrum».

Создания Эпика в Agile

Эпик (Epic) — способ описания требований к разрабатываемой системе, представляющий из себя большую user story («пользовательскую историю»), которая может состоять из нескольких меньших. В JIRA эпик представляет из себя еще один тип задач, охватывающий огромный объем работы. Для завершения эпика потребуется несколько спринтов (sprint — список работ на ближайший отчетный период, который команда определила и согласовала с владельцем продукта). Вы можете либо создать новый эпик в Agile, либо использовать задачу, которую вы создали на обычной рабочей панели JIRA. Точно так же вы можете создать пользовательскую историю для agile scrum.

Режим планирования (Plan Mode) в Agile:

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

Режим работы (Work Mode) в Agile:

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

Связывание и клонирование (Clone and Link) задач в JIRA

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

Помимо этого в JIRA есть такая полезная функция, как «Связывание» (Link). Связывание задач, что понятно из названия, позволяет создавать связи между существующими задачами на этом же или другом сервере JIRA. Как показано на скриншоте, мы связали задачу «ST-6 Выпадающее меню не работает» (ST-6 Drop down menu is not working) с другой «ST-4 Интерфейс не работает — необходим ретест функционала интерфейса» (ST-4 GUI is not responsive- retest GUI functions).

Создав данную связь, мы запустили однодневный спринт, который будет продолжаться определенный период времени, как можно увидеть на скриншоте ниже. Если вы работаете со «scrum» и хотите изменить приоритет или ранг задачи, вы просто можете перетащить ее в бэклог (backlog — журнал оставшейся работы, которую необходимо выполнить команде).

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

8. Отчеты (Reports) в JIRA

Для отслеживания прогресса в Agile существует диаграмма сгорания задач (Burndown Chart), отображающая выполненный и запланированный объем работы, необходимый для завершения спринта. Типичная диаграмма будет выглядеть примерно так же, как на скриншоте ниже. Красная линия отображает фактический объем выполненной работы, в то время как синяя отображает идеальный объем выполненной на протяжении scrum-цикла работы.

Помимо диаграммы сгорания задач в JIRA существует множество других опций: Отчет по спринту (Sprint Report), Отчет по эпику (Epic Report), Отчет по версиям (Version Report), Диаграмма производительности (Velocity Chart), Диаграмма управления (Control Chart), Диаграмма совокупного потока (Cumulative flow diagram). Вы можете использовать разные способы отслеживания прогресса работы над вашим проектом.

Как вы можете увидеть на скриншоте ниже, мы выбрали круговую диаграмму для отображения задач по приоритетам. На ней в процентном формате отображена статистика по задачам, включающая в себя их количество и важность. Круговая диаграмма может быть использована для отображения различных типов данных: Назначения (Assignee), Компоненты (Components), Типы задач (Issue Type), Приоритеты (Priority), Решения (Resolution), Статусы (Status) и т. д.

Вы также можете настроить то, как будет отображаться рабочая панель Scrum — для этого имеется множество опций. Элементы Scrum, которые можно настроить подобным образом, включают в себя: колонки (Columns), Swim Lane блок-схемы, быстрые фильтры (Quick Filters), цвета элементов (Card colors) и т. д. Здесь, например, мы выбрали управление колонками, а для типа отображаемой информации указали «Подсчет задач» (Issue count), что позволило нам увидеть точное число задач, находящихся в процессе выполнения, выполненных и ожидающих выполнения. Помимо этого можно выбрать множество других типов колонок, которые будут отображать ту информацию, которая вам необходима.

Фильтры (Filters)

Вы можете создавать свои фильтры в придачу к установленным по умолчанию. Фильтры могут быть по данным (date), компонентам (component), приоритетам (priority), решениям (resolution) и т.д.

Kanban-панели и управление задачами

Точно так же, как с панелью Agile Scrum, мы можем создать Kanban-панель. В данном примере мы создали проект под названием «Облачное тестирование» (Cloud Testing). Kanban-панель полезна для управления и ограничения находящейся в процессе выполнения работы. Kanban-панели отображаются в режиме работы, но не в режиме планирования.

Так мы создали две задачи на Kanban-панели: «Баг, обнаруженный во время нагрузочного тестирования» (Bug detected while load testing) и «Проверить задачи, относящиеся к облачному серверу» (Check issues related to cloud server).

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

Сравнение JIRA Scrum и JIRA Kanban

Источник

Jira: что это за программа и как в ней работать

Разбираем, как работает один из таких сервисов – Jira.

Что такое Jira

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

Для чего используют Jira

В Jira ведут проекты от идеи до полной разработки. Какие задачи помогает решать Jira:

Преимущества и недостатки сервиса

Что привлекает пользователей:

Что может смутить:

Soft skills: что это такое и как развитие мягких навыков влияет на карьеру

Soft skills: что это такое и как развитие мягких навыков влияет на карьеру

Как устроена Jira

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

Интерфейс

Задачи

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

Типы задач

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

Дорожная карта (расписание)

Чтобы ее создать, откройте справа вкладку Roadmap. Внутри дорожной карты нажмите Create Epic и объедините несколько задач в эпики. Затем команда устанавливает зависимости – связи между эпиками. Разработчики адаптируются под зависимости и планируют альтернативные пути. Картой можно поделиться, добавить в презентацию или распечатать.

Релизы

Новые версии проекта разработчики отправляют пользователям в приложение. В Jira есть контроль новых версий и список всех релизов. Его можно открыть, нажав на значок корабля.

Код и деплой

Приложение интегрируется с системы управления версиями программного кода: Bitbucket, Github и Gitlab. Лидеры команд могут отслеживать изменения в коде.

Pages

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

Дашборды

Дашборд – это рабочий стол в Jira. Он формируется автоматически, корректировки вносятся вручную.

Их там много, выберите актуальные для вашего проекта. Достаточно 5–7. Например: «Лента активности» (Activity Stream), «Назначено мне» (Assigned To Me), « Задачи в процессе» (In Progress), «Статистика задач» (Issue Statistics), «Дорожная карта» (Roadmap).

Плагины

Atlassian продвигает дополнительные плагины сторонних программ, которые можно подключить к Jira. Например, Hip-Chat – плагин, который отправляет оповещения и помогает команде оставаться на связи, или Gliffy Diagrams – инструмент для создания диаграмм.

Как создать задачу в Jira

Атрибуты задач

В новую задачу можно добавить дополнительные атрибуты:

Настройка отчетов

Burnup report

Этот отчет отражает объем выполненной работы и сравнивает его с запланированной. Чтобы определить отклонение от плана, проанализируйте график:

Sprint burndown chart

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

Velocity report

Этот график показывает скорость команды. Здесь руководители могут увидеть каких сотрудников стоит добавить, чтобы увеличить темп работы и сколько времени оставить для следующего проекта.

Cumulative flow diagram

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

Отслеживайте общие показатели вашего бизнеса со Сквозной аналитикой Calltouch. Она поможет узнать, какой рекламный канал работает лучше. Вставьте скрипт в код вашего сайта, подключите CRM и получайте понятные и полезные отчеты. Настройка сервиса займет всего 20 минут. Две недели аналитики – бесплатно.

Алгоритм работы с Jira

С чего начать и как работать:

Как повысить производительность

Есть лайфхаки, которые упрощают работу в Jira. Используйте их, чтобы создать идеальный рабочий процесс для своей команды. Самый простой трюк – используйте горячие клавиши. Рассмотрим, как еще можно оптимизировать разработку проекта:

Стоимость Jira

Бесплатный тариф ограничивает число участников до 10 и память до 2 Гб.

Вы можете рассчитать стоимость на каждого пользователя.

Что такое бриф и как его правильно составить

Источник