Jira что это: Обзор Jira | Продукты, проекты и размещение

Содержание

Использование JIRA и Confluence в большом проекте / Хабр

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

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

Хранить проектные документы

Вести рабочие материалы: протоколы, риски, открытые вопросы

Информировать участников о правилах, событиях, планах

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

Раздавать задания и поручения

Собирать информацию по выполнению задач и поручений

Есть бесконечное число вариантов решения — вместе или по отдельности. Мы использовали связку Confluence + JIRA, и это было удобно и эффективно.

Портал проекта — Confluence

Confluence — это удобный и продвинутый wiki движок от компании Atlassian. Он позволяет организовать внутренний интернет портал и дать доступ к нему всем пользователям — для редактирования или для чтения.

Он очень прост и удобен, для обучения достаточно нескольких часов. У нас на проекте странички создавали и редактировали почти все участники.

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

Написано огромное количество плагинов для расширения функциональности.

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

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

Можно ограничивать доступ в целом на сайт проекта или на отдельную страницу.

Полнотекстовый поиск осуществляется по всем страницам и вложенным документам портала, включая pdf.

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

Проектные материалы

Проектный портал содержал все проектные материалы, часть которых мы сделали в виде иерархии страниц.

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

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

Справочная информация

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

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

Процедуры и регламенты

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

Риски и открытые вопросы

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

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

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

Поручения

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

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

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

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

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

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

Ведение протоколов

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

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

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

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

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

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

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

На странице протокола появится ссылка на задачу, а в задаче JIRA будет ссылка на страницу в Confluence.

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

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

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

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

Кроме Confluence, в интеграции с JIRA, мы также использовали BitBucket, также продукт Atlassian — репозиторий разработок, позволяющий отслеживать версии кода. Для этих же целей на другом проекте использовали бесплатный SVN.

Множество плагинов позволяет расширять функциональность системы, в частности, для интеграции с MS Project или реализации диаграммы Гантта непосредственно в JIRA.

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

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

Jira DataCenter — что это? Как работает? Как развернуть? / Хабр

Введение

С распространением философии Agile российские IT-специалисты с каждым годом накапливают все больше экспертизы и компетенций в области настройки и управления продуктами для команд разработчиков, самым популярным из которых до сих пор остается Jira. Однако работа с самой «старшей», производительной и высокодоступной ее версией — Jira Data Center — все еще вызывает очень много вопросов. В этом посте я расскажу о некоторых принципах и механизмах работы Jira DataCenter, которые мы применяем на практике. Начну с рассказа о структуре кластера Jira.

Что такое Jira DataCenter?

Jira DataCenter – это, по сути, серверная версия, но с возможностью использовать общую базу данных и совместный индекс.

Важно понимать, что сама по себе Jira DataCenter, как продукт и как приложение – НЕ обеспечивает отказоустойчивость и балансировку нагрузки. За это отвечают модули и системы, к которым продукт Atlassian отношения не имеет.

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

С подробным описанием продукта можно ознакомиться на сайте Atlassian.

Вариантов построения предлагается несколько:

1. На собственной инфраструктуре

2. В облаке Amazon (AWS)

3. В облаке MS (Azure)

В данной статье будет описываться решение для собственной инфраструктуры.

Какие проблемы решает Jira DataCenter?

Jira Data Center помогает достичь следующих целей:

Реализация отказоустойчивости.

Обеспечение стабильной работы под высокой нагрузкой. Под высокой нагрузкой подразумеваются large/enterprise scale инстансы, согласно Jira Sizing Guide.

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

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

Из каких компонентов состоит Jira DataCenter?

Как видно на рисунке ниже, кластер Jira DataCenter представляет собой набор из нескольких выделенных машин

Рисунок 1. Архитектура Jira Data Center

Ноды приложений (Application nodes или cluster nodes). Они принимают и обрабатывают всю рабочую нагрузку и запросы. Роль нод выполняют обычные сервера, с идентичным содержимым и установленным приложением, а также подмонтированной общей файловой системой.

Файловая система (Shared file system) со стандартными возможностями импорта/экспорта файлов, плагинами, кэшированием и так далее. Файловый сервер — тоже отдельный сервер, на котором создается общая папка или ресурс, который монтируется к нодам и используется для общих файлов.

База данных (Shared database). Сервер баз данных также, в данном случае, является отдельным сервером и может быть построен на решениях MS SQL, PostgreSQL, MySQL, Oracle.

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

Топология кластера Jira Data Center

Приведу основные принципы, по которым строится кластер в JDC:

инстансы Jira используют общую базу данных;

индекс Lucene реплицируется в реальном времени и сохраняется локально на каждый инстанс;

вложения хранятся в общем хранилище;

инстансы Jira следят за консистентностью кэшей;

в любой момент могут быть одновременно активны несколько инстансов;

доступны кластерные блокировки;

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

Все ноды делятся на активные и пассивные. Активные ноды отличаются тем, что они:

Обрабатывают запросы

Выполняют фоновые процессы и задачи

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

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

На рисунке ниже изображена работа кластера Jira

Рисунок 2. Упрощенная схема работы архитектуры

О балансировщиках нагрузки

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

1. Аппаратные балансировщики:

• Cisco

• Juniper

• F5

2. Программные балансировщики:

• mod_proxy (Apache) — прокси-сервер для Apache HTTP Server, поддерживающий большинство популярных протоколов и несколько разных алгоритмов балансировки нагрузок.

• Varnish представляет собой обратный HTTP прокси-сервер и ускоритель, он предназначен для сайтов с большим трафиком. В отличие от других, он представляет собой только прокси-сервер и балансировки нагрузки HTTP-трафика. В частности Varnish используют Wikipedia, NY Times, The Guardian и многие другие крупные проекты.

• Nginx — веб-сервер номер №1 по популярности среди балансировщиков нагрузки и прокси-решений для сайтов с большим трафиком. Он активно развивается, производитель предлагает бесплатную и корпоративную версии. Используется на многих из самых посещаемых сайтов в мире, например, WordPress.com, Zynga, Airbnb, Hulu, MaxCDN.

• Nginx Plus — собственно, упомянутая выше платная корпоративная версия Nginx.

• HAProxy — свободный инструмент с открытым исходным кодом, который обеспечивает балансировку нагрузки и возможности прокси-сервера для протоколов TCP / HTTP. Он быстрый и потребляет немного системных ресурсов, совместим с Linux, Solaris, FreeBSD и Windows.

Хорошее сравнение прокси-серверов можно найти вот по этой ссылке.

«Прямые» и «обратные» прокси

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

1. «Прямой прокси» (Forward proxy). Прокси-событие в этом случае заключается в том, что «прямой прокси» извлекает данные с другого веб-сайта от имени первоначального запрашивающего. В качестве примера я приведу список трех компьютеров, подключенных к Интернету.

X = компьютер или компьютер «клиент» в Интернете

Y = веб-сайт прокси, proxy.example.org

Z = веб-сайт, который вы хотите посетить, www.example.net

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

2. «Обратный прокси» (Reverse proxy). Представим себе ту же ситуацию, только на сайте Y настроен обратный прокси. Обычно можно подключиться непосредственно из X —> Z. Однако в некоторых сценариях администратору Z лучше ограничивать или запрещать прямой доступ и заставлять посетителей сначала проходить через Y. Таким образом, как и раньше, мы получаем данные, получаемые Y —> Z от имени X, который следующим образом: X —> Y —> Z.

Этот случай отличается от «прямого прокси» тем, что пользователь X не знает, что он обращается к Z, потому что пользователь X видит, что он обменивается данными с Y. Сервер Z невидим для клиентов, и только внешний прокси-сервер Y виден внешне. Обратный прокси не требует конфигурации на стороне клиента. Клиент X считает, что он только взаимодействует с Y (X —> Y), но реальность такова, что Y перенаправляет всю связь (X —> Y —> Z снова).

Далее мы рассмотрим работу с программным балансировщиком.

Какой программный балансировщик выбрать?

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

Sticky session — метод балансировки нагрузки, при котором запросы клиента передаются на один и тот же сервер группы. В Nginx существует метод sticky, использующий cookie для балансировки, правда только в коммерческой версии. Но есть и бесплатный способ — использование внешних модулей.

Модуль создает cookie, и таким образом делает каждый браузер уникальным. Далее cookie используется для переадресации запросов на один и тот же сервер. При отсутствии cookie (например, при первом запросе) сервер выбирается случайным образом.

Подробнее о методе sticky можно прочитать по этой ссылке, а также вот в этом Хабрапосте.

А теперь, переходим к практической части…

Инструкция по созданию кластера Jira DataCenter

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

1. Начнем с сервера баз данных. Можно использовать как существующий, так и создать новый. Опять же, для иллюстрации, была выбрана ОС Windows Server 2016 + PostgreSQL 9.4. Устанавливаем ОС, ставим PG сервер, устанавливаем PG Admin, добавляем пользователя и базу.

2. Создаем первую ноду на ОС Ubuntu 16.04 LTS. Устанавливаем необходимые пакеты, обновления репозиториев.

3. Скачиваем и устанавливаем Jira DataCenter, запускаем, настраиваем базу (на всякий случай, у Atlassian имеется подробный гайд).

4. Выключаем Jira, выключаем ноду.
service jira stop

5. Для дальнейших манипуляций, лучше временно отключить автозапуск Jira:
update-rc.d -f jira remove

6. Клонируем выключенную ноду.

7. Запускаем первую ноду, выключаем Jira (по умолчанию Jira после установки прописывается в автозапуск).

8. Запускаем вторую ноду, выключаем Jira.

9. Создаем отдельный инстанс для балансировщика. Я выбрал Ubuntu 16.04, т.к. это довольно быстро, просто и не требует дополнительных затрат в виде лицензий.

10. Устанавливаем nginx (в примере использована версия 1.13.4).

11. Качаем и распаковываем nginx-sticky-module-ng:

git clone bitbucket.org/nginx-goodies/nginx-sticky-module-ng.git

12. Готовим nginx к перекомпиляции и добавлению модуля.

13. Компилируем nginx с модулем nginx-sticky-module-ng. В моем случае строка компиляции получилась такой:
./configure —prefix=/etc/nginx —sbin-path=/usr/sbin/nginx —modules-path=/usr/lib/nginx/modules —conf-path=/etc/nginx/nginx.conf —error-log-path=/var/log/nginx/error.log —http-log-path=/var/log/nginx/access.log —pid-path=/var/run/nginx.pid —lock-path=/var/run/nginx.lock —http-client-body-temp-path=/var/cache/nginx/client_temp —http-proxy-temp-path=/var/cache/nginx/proxy_temp —http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp —http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp —http-scgi-temp-path=/var/cache/nginx/scgi_temp —user=nginx —group=nginx —with-compat —with-file-aio —with-threads —with-http_addition_module —with-http_auth_request_module —with-http_dav_module —with-http_flv_module —with-http_gunzip_module —with-http_gzip_static_module —with-http_mp4_module —with-http_random_index_module —with-http_realip_module —with-http_secure_link_module —with-http_slice_module —with-http_ssl_module —with-http_stub_status_module —with-http_sub_module —with-http_v2_module —with-mail —with-mail_ssl_module —with-stream —with-stream_realip_module —with-stream_ssl_module —with-stream_ssl_preread_module —with-cc-opt=’-g -O2 -fstack-protector —param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC’ —with-ld-opt=’-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,—as-needed -pie’ —add-module=/usr/local/src/nginx-sticky-module-ng

14. Находим файл /etc/nginx/nginx.conf, копируем его в .bak, настраиваем nginx на режим обратного прокси.

15. Далее, нам потребуется файловый сервер (желательно тоже отказоустойчивый). Для примера я выбрал Windows-сервер, где создал NFS-шару.

16. На каждой ноде устанавливаем пакеты для поддержки NFS:
apt-get install nfs-common

17. Создаем папку /media/jira и выполняем:
chmod -R 0777 /media/Jira

18. Монтируем NFS шару как общую (обязательно монтировать не в root-папку, а, например, в /media/jira ) — НА КАЖДОЙ НОДЕ

19.1. Далее, можно осуществить либо ручное монтирование (однократное):
sudo mount -t nfs -O uid=1000,iocharset=utf-8 xx.xx.xx.xx:/jira /media/jira

где xx.xx.xx.xx – ip адрес сервера с NFS шарой

19.2. Либо сразу автоматическое монтирование (при запуске ОС):
mcedit /etc/fstab

В конце необходимо добавить строчку:
192.168.7.239:/jira /media/jira nfs user,rw 0 0

Затем сохранить и выйти.

20. Присваиваем ID: первой ноде node1, на второй ноде node2, и так далее.
#This ID must be unique across the cluster

jira.node.id = node1

#The location of the shared home directory for all Jira nodes

jira.shared.home = /media/jira

21. Запускаем джиру на первой ноде
service jira start

проверяем:

заходим в system -> system info -> ищем cluster ON и номер ноды.

22. Настраиваем балансировку nginx

23. Т.к. ранее мы отключили автозапуск Jira на нодах, то включить его можно командой:
update-rc.d -f jira enable

24. Проверяем работу кластера и по необходимости добавляем ноды.

Порядок запуска кластера

1. Включить Shared file system сервер
2. Включить Load balancer
3. Включить node1
4. Включить node2
5. …

Порядок остановки кластера

1. Остановить Jira на обеих нодах командой service Jira stop
2. Выключить ноду 2
3. Выключить ноду 1
4. Выключить балансировщик нагрузки
5. Выключить сервер файловой системы

На этом все…

Разумеется, описанный метод не является единственно верным. Это всего лишь один из путей реализации.

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

Комментируйте, задавайте вопросы и благодарю за внимание.

Jira (программное обеспечение) — Национальная библиотека им. Н. Э. Баумана

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 22:14, 23 октября 2016.

Jira — коммерческая система отслеживания ошибок, предназначена для организации взаимодействия с пользователями, хотя в некоторых случаях используется и для управления проектами. Разработана компанией Atlassian, является одним из двух её основных продуктов (наряду с вики-системой Confluence). Имеет веб-интерфейс.

Название системы получено путём усечения слова «Gojira» — японского имени монстра Годзилла, что, в свою очередь, является отсылкой к названию конкурирующего продукта — Bugzilla; создавалась в качестве замены Bugzilla и во многом повторяет её архитектуру. Система позволяет работать с несколькими проектами. Для каждого из проектов создаёт и ведёт схемы безопасности и схемы оповещения.

До версии 3.13.5 (включительно) различались редакции Enterprise, Professional и Standard, после — осталась только редакция Enterprise (для крупных организаций).^[3]

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

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

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

Пользователем JIRA Software считается каждый, кто имеет полный доступ ко всем встроенным функциям и функциональным возможностям JIRA Software, созданным специально для команд разработчиков. Это подразумевает доступ к scrum- и kanban-доскам, десяткам отчетов (в том числе отчету по спринту и диаграммам сгорания и контроля), глубокую интеграцию с инструментами для разработки и многое другое.

Так же Jira используют различные корпорации в разных сферах :

Технологические корпорации
Банки и финансы
Fortune 500 и другие крупные корпорации
Инженерия и авиакосмическая промышленность
Медицина и биотехнологии
Наука и научные исследования
Телекоммуникации и СМИ
Университеты и академии
Технологические предприятия в начальной стадии развития
Разработчики компьютерных игр
Консалтинг
Сообщества профессионалов
Малобюджетные и благотворительные предприятия
Организации и проекты программного обеспечения с открытым кодом

Ценовая политика

Как рассчитывается использованный объем

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

Использование JIRA Software бесплатно

Первые 7 дней будут за наш счет. Зарегистрируйтесь, и команда Jira развернет для вас JIRA Software Cloud: вы сможете начать профессиональную работу с JIRA Software в мгновение ока.
Если вам понравится, вы сможете продолжить работу с JIRA Software, просто предоставив свои платежные реквизиты.

Виды оплаты

Принимается оплата по картам MasterCard, Visa или American Express. Клиенты, оформившие годовую подписку, могут также оплатить услуги банковским переводом или чеком.

Оплата раз в год

Годовая подписка на JIRA Software Cloud также доступна:

Чтобы оформить годовую подписку на JIRA Software Cloud, просто подпишитесь на бесплатную 7-дневную пробную версию, после чего свяжитесь с командой Jira . Они с радостью изменят ваш тарифный план и оформят годовую подписку.

Стоимость годовой подписки на JIRA Software Cloud.

пользователи	цена
1–10	100 $
11–15	750 $
16–25	1500 $
26–50	3000 $
51–100	4500 $
101–500	7500 $
501–2000	15 000 $

Что делать, если JIRA Software не устраивает, а деньги уже заплачены

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

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

Отличие версии Cloud от версии Server

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

При покупке JIRA Software Server и JIRA Software Data Center вы сами осуществляете хостинг JIRA Software на своем оборудовании. Это дает вам полный контроль над вашей инсталляцией. Как правило, этот вариант лучше всего подходит командам, которые хотят управлять всеми деталями процесса установки и готовы взять на себя сложности самостоятельного хостинга.^[4]

Функции

Scrum-доски

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

Kanban-доски

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

Agile-отчеты

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

Планирование Portfolio

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

Планируйте	Создайте план на основе данных, уже существующих в JIRA Software, и превратите эпики в инициативы, охватывающие все команды и проекты.
Прогнозируйте	Оптимизируйте график работ в режиме реального времени и сразу же прогнозируйте реалистичные даты релизов.
Управляйте	Управляйте доступностью и компетенцией команд, чтобы избежать «узких мест» и обеспечить доступность нужных людей в нужный момент.
Будьте гибкими	Быстро расставляйте приоритеты и принимайте оптимальные решения: результаты сразу же отобразятся в плане, так что вы без труда ответите на вопрос «А что, если…».
Отслеживайте	Задавайте бизнес-цели и следите за их реализацией, чтобы уверенно следовать выбранной стратегии и точно знать, что приоритеты для всех едины.
Создавайте отчеты	Опирайтесь на единый достоверный источник сводных данных по всем командам и будьте уверены, что все будут в курсе происходящего.

Project roadmap

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

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

количество задач созданных одним пользователем

среднее время решения задачи

отношение реального и заданного времени решения задач

количество задач созданных в день, неделю, месяц, год

популярные задачи (набравшие большинство голосов)

задачи назначенные для указанной версии или этапа

задачи имеющие определенные статус

задачи имеющие определенный приоритет

отчет по использованию времени

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

отчет о нагрузке на разработчиков

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

Основные возможности JIRA:

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

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

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

Решение вопросов — документы, почта, общение — всё в одном месте, решение каждого вопроса происходит быстро и легко.

Планирование рабочего процесса — построение рабочего процесса эффективнее и удобнее.

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

Совместная работа — обмен информацией по проекту, совместное решение вопросов и обращение за помощью к коллегам.

Видимость-онлайн — новости, почта, просмотр работы в режиме реального времени в одном месте.

Интеграция с различными разработками и дополнениями Altassian и другими разработчиками.^[6]

Управление и разделение ролей

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

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

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

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

Администратора
Руководитель проекта
Сотрудника работающего над проектом
Другие сотрудники

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

Установка Jira

Попробовать бесплатную версию вы можете здесь :[1]

Найти информацию по установке данного продукта вы можете здесь : [2], здесь :[3] и здесь: [4]

Примечания

Что такое проект JIRA

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

разработка программного обеспечения;
проведение маркетинговой кампании;
сопровождение (поддержка) административно-справочной системы;
сопровождение работы веб-сайта.

Каждая задача (запрос) принадлежит только одному проекту. Каждый проект имеет имя (например, «Сопровождение работы веб-сайта») и ключ (например, WEB). Ключ проекта становится первой частью индексов задач (запросов) этого проекта (например, WEB-101, WEB-102 и т. д .).

Что такое компоненты проекта JIRA?

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

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

Что такое версия проекта JIRA?

Для некоторых типов проектов, особенно для разработки программного обеспечения, полезно уметь связывать задачу с конкретной версией разрабатываемого продукта (например, 1.0 beta, 1.0, 1.2, 2.0).

Задачи имеют два поля, которые относятся к версиям:

Затронуты версии (Affects Versions) — это версии, в которых выявлена проблема в рамках решаемой задачи. Например, ошибка программного обеспечения может повлиять на версии 1.1 и 1.2.
Исправлено в версии (Fix Version) — это версия , в которой проблема будет исправлена. Например, ошибка, влияющая на версии 1.1 и 1.2, будет исправлена в версии 2.0. Обратите внимание, что задачи, у которых не заполнено поле Исправлено в версии (Fix Version), классифицируются как Незапланированные (Unscheduled).

Версии могут находиться в одном из трех состояний: выпущены (Released), не выпущены (Unreleased) или архивированы (Archived). Версии также могут иметь дату выпуска и автоматически будут выделены как «просроченные», если версия не выпущена, когда эта дата пройдет.

Дополнительные ресурсы

Как мы работаем над проектами в Jira

Преимущества Jira

Jira — гибкий инструмент. Есть много разных таск-трекеров: Basecamp, Trello, Asana, но Jira — не просто программа, она позволяет настраивать и контролировать бизнес-процессы по разработке до мельчайших подробностей. Если не нужно много настроек, она может работать как тот же Basecamp или Trello, но на самом деле её возможности намного шире. Не важно, делаете ли вы плакаты или программы, — всё равно должен быть стандартизированный производственный процесс. Так вот, если есть регламент, то Jira поможет оцифровать его и контролировать. Возможности для настройки управления проектами в системе практически безграничные:

диаграмма Ганта,
диаграмма сгорания задач,
управление временем,
расстановка задач по приоритетам,
фильтры,
делегирование задач,
отслеживание объема работы в процентном соотношении,
настраиваемые scrum и kanban-доски,
и многое другое.

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

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

Если вы только начинаете бизнес по разработке, лучше выберите что-то более простое, а потом, набив шишки и выстроив все процессы, смело переходите на Jira.

Постановка задач

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

Epic — самая большая задача, из частей которой складывается работа над проектом. Для реализации такой задачи нужно выполнить несколько меньших задач. Эпик у нас длится спринт и больше.
Story — описание задачи без подробностей. В рамках этой задачи выполняются подзадачи, которые должны привести к результату, описанному в Story. Особенность: после закрытия задачи Story должна быть создана задача с заданием на реализацию выработанного решения.
Task — конкретная задача с четким описанием, которая требует выполнения. Длится в течение спринта.
Bug — задача, связанная с ошибкой в коде.
Easy-task — небольшая задача с упрощенным Workflow без статусов Review и Test.
Sub-task — конкретная далее неделимая задача с подробным описанием. Часть Story, Task, Bug или Easy-task.
Quick-subtask — маленькая конкретная далее неделимая задача с упрощённым Workflow без статусов Review и Test. Часть Story, Task, Bug или Easy-task.

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

Задачи Story, Task, Bug, Easy-task появляются в бэклоге. Сразу после создания задачи Jira в отдельном окне предлагает переместить её в текущий спринт

Для перемещения задачи между спринтами можно использовать поле Sprint в окне просмотра задачи

Процесс работы над задачами

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

Наш Воркфлоу

Тот, кто ответственен за задачу, перемещает её по всему Воркфлоу. Вот такой путь проходят задачи в наших проектах в Jira:

Новая задача автоматически получает статус Backlog.
После переноса задачи в спринт, она готова к работе и получает статус Ready4Dev.
Разработчик взял задачу в работу и прямо сейчас трудится над ней — статус Development.
Разработчик пошел спать, переключился на другую задачу, выключил компьютер или как-то иначе отвлекся от выполнения текущей задачи — он ставит статус On Hold.
Задача готова, и результат работы требует одобрения руководителем? Способ об этом сообщить — поставить статус Review.
Если ревьювер решил, что задачу нужно дорабатывать, то он ставит её в статус On Hold, а разработчик уже потом в Development. То есть возвращаемся на пункт 3.
Если задача требует доработки — Development.
Задача одобрена, и нужно тестирование — статус Ready4Test.
Тестировщик взял задачу на тестирование и прямо сейчас тестит — статус Testing.
Задача прошла тестирование и готова к мержу с продакшном — статус Ready4Merge.
Статус Canceled используется только в том случае, если задача перестала быть актуальной и больше не нужна, либо её выполнение по какой-то причине нужно прервать.
Выполненные задачи переносятся в статус Merged.

Все задачи перемещаются по четкому Воркфлоу без пропуска этапов, за исключением специальных задач Quick-subtask и Easy-task. Для них используется упрощенный Воркфлоу.

Упрощенный Воркфлоу

Структура задачи

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

Пример задачи проекта в Jira

Обязательные поля

Summary (Название задачи) — кратко, что нужно сделать; желательно использовать глагол в инфинитиве: сделать, создать, исправить и так далее.
Description (Описание) — собственно, само описание. Дать столько информации, чтобы этого хватило для самостоятельной работы над задачей без дополнительных вопросов.
Labels (Метки или теги) — ярлык для задачи по теме: Backend, Frontend, Design, Data, OPS.
Reporter — ответственный за постановку задачи — тот, кто её создавал.
Priority — приоритет задачи: Highest, High, Medium, Low. Обычный приоритет для задачи — Medium.

Необязательные поля

Linked Issues — ссылки на связанные задачи, которые как-то относятся к создаваемой. Нужно выбрать подходящую связь: relates to, blocks, is blocked by и т.д.
Epic Link — ссылка на Epic, для которого создаваемая задача будет его частью. Не работает для подзадач.
Component/s — подраздел проекта, к которому относится задача. Компоненты используются для объединения задач в рамках проекта в небольшие группы по выбранной логике. Для каждого компонента определён свой ответственный, он назначается на задачу автоматически при выборе компонента для задачи.

Оценка задач

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

Time Spent (Work Log) — время, фактически затраченное на работу с задачей.
Time Estimate — время, которое планируется затратить на задачу.
Remaining Time — оставшееся время на выполнение задачи.

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

Поработал над задачей — запиши затраченное время. Поработал над задачей — запиши в комментариях, что было сделано.

Показатели здоровья проекта

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

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

Главная причина работы в Jira

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

Если хотите больше узнать про автоматизацию бизнес-процессов и контроль команды разработки, напишите нам.

Изучите версии с помощью Jira Software

Учебное руководство по версиям Jira

Из этого учебного руководства вы узнаете, как можно работать с версиями в Jira Software.

Продолжительность:

10 минут на прочтение. Прохождение учебного курса занимает 2 недели или больше.

Аудитория:

Вы знакомы с принципами работы Scrum и (или) Kanban в Jira Software
У вас есть права на администрирование всех проектов на вашей доске Scrum или Kanban. См. страницу Управление разрешениями проекта для получения дополнительной информации.

Предварительные требования:

Попробовать бесплатно

Что представляет собой версия в Jira Software?

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

Шаг 1. Создание версии в Jira Software

Перейдите в проект.
В меню проекта нажмите «Релизы».
Выберите текстовое поле «Название версии» , введите название и нажмите «Добавить».
Названия версий обычно состоят из цифр, например 1.0 или 2.1.1. Вы также можете использовать внутреннее кодовое название.

Сколько версий следует создать?

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

После создания версии для ваших задач станут доступны поля «Затрагиваемая версия» и «Версия исправления».

Шаг 2. Добавление задач к версии

Если у проекта есть бэклог

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

Если у проекта нет бэклога

Откройте задачу, которую нужно добавить к версии.
Найдите поле «Версия исправления» и укажите название версии, к которой нужно добавить задачу.

В чем разница между версией исправления и затрагиваемой версией?

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

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

Шаг 3. Отслеживание работы над версией

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

Центр управления релизами

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

Переход в центр управления релизами:

Перейдите в проект.
В меню проекта выберите пункт «Релизы».

Быстрые фильтры. Сосредоточьтесь на конкретных версиях, исключив ненужные версии.
Список версий. Перетаскивайте версии, чтобы изменить их порядок.
Состояние. У версий есть три состояния: «Не выпущена», «Выпущена», или «В архиве».
Прогресс. Здесь показано количество задач, связанных с конкретной версией, а также состояние каждой задачи.

Burndown-диаграмма релиза (только для Scrum)

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

Обратите внимание, что Burndown-диаграммы релиза подразумевают оценку сроков для выполнения задач. Подробную информацию см. в нашем руководстве по диаграммам сгорания.

Для просмотра Burndown-диаграммы релиза:

Перейдите в проект.
В меню проекта выберите пункт «Отчеты».
Выберите «Диаграмма Burndown».

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

Более подробную информацию см. в нашей документации по диаграммам сгорания.

Шаг 4. Завершение работы над версией

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

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

Завершение работы над версией

Перейдите в проект.
В меню проекта выберите пункт «Релизы».
Выберите «Действия» () > «Выпустить» для версии, которую нужно выпустить.

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

Хотите узнать больше?

Более подробную информацию о работе с версиями в Jira Software см. в нашей документации по версиям.

Есть вопросы? Задайте их сообществу Atlassian.

Поделитесь этой статьей

Max Rehkopf

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

Изучение версий с программным обеспечением JIRA | JIRA

Изучите версии с помощью программного обеспечения Jira

Узнайте, как использовать версии в Jira Software

Руководство по использованию версий в Jira Software

Учебник по версиям в Jira

В этом уроке мы расскажем, как работать с версиями в Jira Software.

Время:

10 минут чтения. Завершить в течение 2 недель или более.

Аудитория: Вы знакомы с тем, как Scrum и / или Kanban работают в Jira Software

У вас есть разрешение на управление проектами для всех проектов на вашей доске Scrum или Kanban.

См. Управление разрешениями проекта для получения дополнительной информации.

Необходимое условие (Предпосылки):

Вы создали учетную запись в Jira Software.
Вы создали проект Jira Software Scrum или Kanban.
Вы заполнили свой проект задачами.

ЧТО ТАКОЕ ВЕРСИЯ В ПРОГРАММНОМ ОБЕСПЕЧЕНИИ JIRA?

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

Шаг 1. Создайте версию в Jira Software

Перейдите к вашему проекту.
В меню проекта нажмите «Релизы» (Releases).
Выберите текстовое поле «Имя версии» (Version name), введите имя и нажмите «Добавить» (Add).

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

СКОЛЬКО ВЕРСИЙ Я ДОЛЖЕН СОЗДАТЬ?

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

После того, как вы создадите версию, поля «Затронутая версия» (Affects version) и «Исправленная версия» (Fix version) станут доступными для ваших проблем.

Шаг 2. Добавьте задачи в версию

Если ваш проект имеет список основных требований (backlog):

Перейдите к списку основных требований (backlog) проекта.
Откройте панель «Версии» (Versions) слева.

РИСУНОК

Перетащите задачу в версию, в которую вы хотите ее добавить.

Если ваш проект не имеет списка основных требований (backlog), откройте задачу, которую вы хотите добавить в версию.

Найдите поле «Исправленная версия» (ии) (Fix version / s) и введите версию, к которой хотите добавить задачу.

В ЧЕМ РАЗНИЦА МЕЖДУ ИСПРАВЛЕННОЙ ВЕРСИЕЙ И ЗАТРОНУТОЙ ВЕРСИЕЙ

Затронутая версия — это версия в которой была обнаружена ошибка (баг) или проблема. Хотя это может быть полезно для отслеживания задач, в Jira она используется не очень часто.

«Исправленная версия» (Fix version) — это версия, в которой вы планируете выпустить функцию или исправление ошибок (багов) для клиентов. Это поле используется для планирования выпуска релиза, мониторинга прогресса работы и скорости, и оно широко используется в отчетах. Наиболее вероятно, что это поле, которое вы захотите.

Шаг 3: Отслеживание прогресса версии

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

Центр выпуска релиза

Центр выпуска релизов предоставляет вам место для управления всеми вашими релизами. Он также дает вам информацию о состоянии ваших выпусков релизов и разбивку по количеству задач в каждой версии.

Чтобы перейти к центру выпуска релиза:

Перейдите к вашему проекту.

В меню проекта выберите Релизы (Releases).

РИСУНОК

Быстрые фильтры: сосредоточьтесь на определенных версиях, отфильтровывая те, которые вам не интересны.
Список версий: перетащите версии, чтобы изменить их порядок.
Статус: Версии могут иметь один из трех статусов: «Не выпущено», «Выпущено» или «Архивировано» (Unreleased, Released, или Archived.).
Прогресс (Ход) выполнения: показывает, сколько задач было назначено версии, и сколько в каждом статусе.

ХОТИТЕ УЗНАТЬ БОЛЬШЕ ИНФОРМАЦИИ ЧТОБЫ ПОМОЧЬ ВАМ КОНТРОЛИРОВАТЬ ВЫПУСКИ РЕЛИЗОВ?

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

Выпуск релиза диаграммы сгорания (только Scrum)

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

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

Чтобы просмотреть диаграмму сгорания выпуска релиза:

Перейдите к вашему проекту.
В меню проекта выберите Отчеты (Reports).
Выберите сгорание Релиза.

РИСУНОК

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

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

Шаг 4: Завершите версию

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

Чтобы развернуть выпуск релиза, вы обычно выпускаете версию в программном обеспечении Jira Software, собираете выпуск релиза и затем развертываете его в требуемой среде.

Для завершения версии

Перейдите к вашему проекту.
В меню проекта выберите «Релизы» (Releases).
Для версии, которую вы хотите выпустить, выберите «Действия» (кнопка Ellipses)> «Релиз» ( Actions (Ellipses button) > Release.).

На досках Kanban вы также можете выпустить релизы всех задач в колонке «Готово» (Done) в виде новой версии непосредственно с самой доски.

Что узнать больше?

Более подробную информацию о работе с версиями в программном обеспечении Jira Software можно найти в документации по нашим версиям.

Есть вопросы? Спросите Сообщество Atlassian.

Обзор Jira | Продукты, проекты и хостинг

Проблемы

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

Совет. Другие часто используемые термины для обозначения проблем — это «запросы», «тикеты» или «задачи». Мы рекомендуем использовать «проблемы», чтобы помочь вашей команде оставаться на одной странице при работе с семейством продуктов Jira.

Проекты

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

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

Рабочие процессы

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

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

Agile

Agile — термин, не относящийся к Jira Software. Эта философия работы зародилась в области разработки программного обеспечения и с тех пор распространилась на множество других отраслей. Хотя мы не будем вдаваться в подробности определения здесь (для этого есть отличные ресурсы!), Agile подчеркивает итеративный подход к работе, основанный на обратной связи с клиентами, когда доставка осуществляется постепенно и непрерывно.Идеальная гибкая команда может быстро двигаться и адаптироваться к меняющимся требованиям, не теряя при этом ни малейшего внимания.

Так почему мы здесь воспитываем agile? Потому что в Jira Software есть основные наборы функций, специально разработанные для гибкой разработки, включая scrum или kanban. Итак, когда вы видите такие термины, как доски, оценка или карточки, пора задуматься о том, насколько agile вписывается в вашу рабочую практику.

Важно отметить, что, поскольку гибкость — это философия и культура работы, простое использование Jira Software не сделает вашу команду действительно гибкой.Тем не менее, это инструмент, созданный, чтобы помочь вашей команде достичь этого.

Как использовать Jira Software Tool для начинающих

Home
Testing
- - Back
  - Agile Testing
  - BugZilla
  - Cucumber
  - Database Testing
  - Database Testing
  - ETL
  - Назад
  - JUnit
  - LoadRunner
  - Ручное тестирование
  - Мобильное тестирование
  - Mantis
  - Почтальон
  - QTP
  - Назад
  - Центр качества (ALM)
  - Центр качества (ALM)
  - Управление тестированием
  - TestLink
SAP
- - Назад
  - ABAP
  - APO
  - Начинающий
  - Basis
  - BODS
  - BI
  - BPC
  - CO
  - Назад
  - CRM
  - Crystal Reports
  - QM4000
  - QM4
  - Заработная плата
  - Назад
  - PI / PO
  - PP
  - SD
  - SAPUI5
  - Безопасность
  - Менеджер решений
  - Successfactors
  - Учебники SAP
- Обязательно учите!
  - - Назад
    - Бухгалтерский учет
    - Алгоритмы
    - Android
    - Блокчейн
    - Business Analyst
    - Создание веб-сайта
    - CCNA
    - Облачные вычисления
    - COBOL

Ноябрь 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

Jira что это: Обзор Jira | Продукты, проекты и размещение

Использование JIRA и Confluence в большом проекте / Хабр

Jira DataCenter — что это? Как работает? Как развернуть? / Хабр

Введение

Что такое Jira DataCenter?

Какие проблемы решает Jira DataCenter?

Из каких компонентов состоит Jira DataCenter?

Топология кластера Jira Data Center

О балансировщиках нагрузки

«Прямые» и «обратные» прокси

Какой программный балансировщик выбрать?

Инструкция по созданию кластера Jira DataCenter

Порядок запуска кластера

Порядок остановки кластера

На этом все…

Jira (программное обеспечение) — Национальная библиотека им. Н. Э. Баумана

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

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

Ценовая политика

Как рассчитывается использованный объем

Использование JIRA Software бесплатно

Виды оплаты

Оплата раз в год

Что делать, если JIRA Software не устраивает, а деньги уже заплачены

Отличие версии Cloud от версии Server

Функции

Scrum-доски

Kanban-доски

Agile-отчеты

Планирование Portfolio

Project roadmap

Основные возможности JIRA:

Управление и разделение ролей

Установка Jira

Примечания

Что такое проект JIRA

Что такое компоненты проекта JIRA?

Что такое версия проекта JIRA?

Дополнительные ресурсы

Как мы работаем над проектами в Jira

Преимущества Jira

Постановка задач

Процесс работы над задачами

Структура задачи

Обязательные поля

Необязательные поля

Оценка задач

Показатели здоровья проекта

Главная причина работы в Jira

Изучите версии с помощью Jira Software

Учебное руководство по версиям Jira

Шаг 1. Создание версии в Jira Software

Шаг 2. Добавление задач к версии

Если у проекта есть бэклог

Если у проекта нет бэклога

Шаг 3. Отслеживание работы над версией

Центр управления релизами

Burndown-диаграмма релиза (только для Scrum)

Шаг 4. Завершение работы над версией

Завершение работы над версией

Хотите узнать больше?

Изучение версий с программным обеспечением JIRA | JIRA

Изучите версии с помощью программного обеспечения Jira

Руководство по использованию версий в Jira Software

Учебник по версиям в Jira

Шаг 1. Создайте версию в Jira Software

Шаг 2. Добавьте задачи в версию

Шаг 3: Отслеживание прогресса версии

ХОТИТЕ УЗНАТЬ БОЛЬШЕ ИНФОРМАЦИИ ЧТОБЫ ПОМОЧЬ ВАМ КОНТРОЛИРОВАТЬ ВЫПУСКИ РЕЛИЗОВ?

Выпуск релиза диаграммы сгорания (только Scrum)

Шаг 4: Завершите версию

Для завершения версии

Что узнать больше?

Обзор Jira | Продукты, проекты и хостинг

Проблемы

Проекты

Рабочие процессы

Agile

Как использовать Jira Software Tool для начинающих

Полное практическое руководство по использованию JIRA