Настроить бизнес процесс jira

2018-12-18 в 15:01, admin , рубрики: agile, jira, product management, Блог компании Badoo, менеджмент, Разработка веб-сайтов, управление командой, управление людьми, Управление продуктом, управление проектами, управление проектами и командой, управление разработкой

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

• вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
• у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
• у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
• ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
• и, конечно, вы используете Jira!

• участники процесса не понимают, из каких инженерных кусков состоит фича и что ещё необходимо сделать по проекту в текущий момент;
• инженерные команды работают над одним и тем же проектом несинхронно: одна команда может закончить свою часть месяц назад, а вторая — даже не приступить к своей, потому что про её кусок забыли в потоке более важных задач.

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

Знакомо? Давайте подумаем, что с этим можно сделать.

Структура проекта

Я буду разбирать проблему на примере разработки в Badoo. Итак, как ведётся проектная работа? Какие стадии проходит проект? Из каких кусков состоит типичная новая фича, требующая участия нескольких команд?

Идея и дизайн

Продуктовый менеджер (ПМ), придумав, что можно улучшить в продукте, создаёт в Jira тикет PROD с типом Project. Описание этого тикета состоит из единственной ссылки на страницу в Confluence (аналог Wiki от Atlassian, который интегрирован с Jira). Эту страницу мы называем PRD (Product Requirements Document). Она является ключевым элементом разработки. По сути, это подробное описание того, что предстоит сделать в рамках проекта.

Структура типичного PRD

1. Цели.
   Здесь кратко описывается, чего мы хотим достичь, реализовав проект (увеличение прибыли, расширение охвата, иные метрики, на которые планируется повлиять и т. п.).
2. Описание.
   Это самая объёмная часть PRD. Здесь описывается вся бизнес-логика фичи, рассматриваются все возможные кейсы. Здесь же размещаются элементы дизайна (то, как пользователь должен видеть фичу на каждом этапе взаимодействия с ней). Также здесь описываются все лексемы, которые могут быть показаны пользователю.
3. Требования к A/B-тесту.
   Почти все новые фичи мы запускаем после проведения A/B-теста, чтобы иметь возможность проверить влияние нового функционала на небольшой группе пользователей (ведь оно может быть и негативным). В этой секции описываются все возможные группы теста и различия их логики для пользователя.
4. Требования к статистике.
   Здесь фиксируется, какие действия пользователя и бизнес-показатели должны мониториться (нажатия кнопок, показы промоэкранов и т. д.).

При создании этого документа ПМ плотно работает с дизайнером. Для этого создаётся ещё один тикет PROD с типом Design. В нём дизайнер размещает макеты, наборы иконок и т. д. Эти элементы потом вставляются в PRD для наглядности, а также используются инженерными командами в разработке.

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

Когда все нюансы выяснены, первоначальный PROD-тикет переводится в беклог ожидающих разработки. После этого один раз в неделю продуктовая команда сортирует этот беклог по приоритету в соответствии с целями компании, предполагаемому выхлопу и сложности реализации. Проекты, признанные наиболее перспективными, переходят на следующий этап — декомпозицию. Для этого создаётся специальный тикет MAPI (Mobile API) для команды системных архитекторов.

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

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

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

Декомпозиция

Получив новый MAPI-тикет с прикреплённым к нему PRD, системные архитекторы решают:

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

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

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

Результатами работы системных архитекторов являются:

Появление полной технической документации по проекту (описание протокола взаимодействия клиента и сервера с привязкой к кейсам бизнес-логики, описанной в PRD).

Скриншот части документации одной нашей ныне неактивной фичи

Тикеты для команд разработки и локализации. Для этого у нас есть специальный интерфейс, который позволяет создавать нужные тикеты сразу для всех задействованных команд. Он открывается по ссылке из MAPI-тикета. По клику откроется вот такой созданный нами интерфейс: По нажатию кнопки внизу формы (на скриншоте её не видно) появятся нужные тикеты, которые автоматически будут прилинкованы к исходному MAPI-тикету. Тут стоит отметить, что все команды разработки у нас работают в собственном пространстве (проекте) Jira: команда бекенда — в SRV, команда Android — в AND, команда веба — в Web и т. д. Интерфейс реализован на базе Jira REST API.

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

Разработка и запуск

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

Как правило, запуск фичи происходит по такому сценарию:

1. Сервер первый выкладывает свою часть функционала, прикрытую feature-флагом, в продакшен. Таким образом, данная логика остаётся незадействованной до тех пор, пока один из клиентов не начнёт присылать этот feature-флаг.
2. Клиентские команды перед релизом в продакшен тестируют свою часть функционала уже на «боевом» сервере.
3. По мере готовности разные клиенты выпускаются, начинают слать нужный feature-флаг и получать новый ответ сервера.

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

• разные приоритеты у команд разработки; проблем обычно не возникает при работе над суперважными для компании проектами (они у всех на слуху и забыть о них сложно), а вот менее важные могут располагаться в локальном беклоге отдельной команды на последних местах;
• ошибка проджект-менеджмента: менеджер может элементарно забыть правильно приоритизировать задачи команды разработки, то есть её участники даже не будут знать о том, что тикет надо взять в разработку как можно скорее.

Как же нивелировать эти проблемы? Как сделать так, чтобы куски проекта не терялись, а команды уделяли должное внимание приоритетным проектам?

Стандартные возможности Jira

Что для решения этих проблем может предложить менеджеру проектов стандартный функционал Jira? Не так уж много:

• фильтры;
• канбан-доски.

Фильтры

Фильтр позволяет увидеть линейный список тикетов, полученных по произвольному JQL-запросу. Этот инструмент очень удобен для обслуживания беклога одной команды, но как применить его для качественного управления проектом, распределённым по разным командам, мне неизвестно. Максимум, что может сделать менеджер, — это вывести приоритезированный список корневых PROD-тикетов, а дальше нужно заходить в каждый, просматривая прилинкованные тикеты. Но это крайне неудобно и долго, особенно учитывая, что иерархия ссылок может быть многоэтажной. Более того, команда разработки может создать несколько дополнительных тикетов для решения первоначальной задачи, и их статус тоже надо отслеживать.

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

Для тех, кто не знает, как это устроено в Jira, поясню. В общем случае это список задач на основе определённого фильтра, сгруппированный по трём колонкам: «Беклог», «Задачи в разработке», «Завершённые задачи». Интерфейс позволяет повышать приоритет задач простым перетаскиванием мышкой тикета в списке. При этом меняется свойство Rank, по которому потом можно отсортировать тикеты в своих фильтрах.

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

Руководство по внедрению Jira в организации

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

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

1. Убедите своих пользователей в Jira.
2. Введение в гибкое управление проектами.
3. Понимание языка Jira — терминология и др.
4. Правильно организуйте Jira.
5. Работа с Jira.

Убедите своих пользователей в полезности Jira.

Каждый сотрудник поначалу настроен скептически и задает много вопросов. Зачем нужен новый инструмент управления проектами? Какие преимущества у программного обеспечения? В чем отличия от старого решения? Почему мы вообще должны использовать Jira?

Чем Jira поможет мне и компании?

Очень важны своевременные ответы на вопросы сотрудников «Почему» и «Зачем Jira нужна мне?». Это поможет вам ускорить внедрение Jira и, таким образом, получить внутренних чемпионов Jira. Таким образом, вы гарантируете раннюю поддержку делу. Увереность и поддержка со стороны коллектива является одним из наиболее важных факторов.

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

2. Введение в гибкое управление проектами

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

Что такое «Agile»?

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

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

SCRUM

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

Kanban

Структура Kanban, в отличие от SCRUM, основана на непрерывной поставке выполненных задач (тикетов). Кроме того, статус задачи можно видеть в любое время (например, To do, In Progress, Done). Важным компонентом Kanban является управление лимитом незавершенной работы (WIP). Ограничение незавершенной работы позволяет быстрее выявлять и устранять узкие места в рабочем процессе. Kanban идеально подходит для команд, которые не занимаются разработкой программного обеспечения (например: поддержкой маркетингом, дизайном, продажами и т.д.).

Введение Jira также означает использование гибких методов и их усвоение.

Последний вопрос, который следует задать: зачем использовать Agile?

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

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

Таким образом, заинтересованные стороны нуждаются в инструменте и структуре для управления проектом. Таким образом, в Jira несколько команд могут работать над проектом с разными фреймворками; Маркетинг, дизайн и т.д. С помощью досок Kanban. Разработка и инфраструктура с помощью SCRUM.

Понимание паттернов Jira — терминология и пр.

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

Задачи(issues) Jira: рабочие пакеты или задачи любого размера являются фундаментальным элементом Jira и бывают разных типов (например, Story, Epic, Task или Bug и т.д.). Доски(boards): наглядное изображение всех активных вопросов. Проекты(projects): они состоят из набора задач с общим ключом контент и рабочим процессом(может зависеть от типов задач). Терминология в Jira может быть немного сложной.

Итак, вот пример: Планируется разработка нового корпоративного сайта (проект — project). Затем проект включает в себя несколько более крупных этапов проекта, таких как контент, эксплуатация веб-сайта и дизайн. Это так называемые эпики(Epic). В эпиках есть и другие индивидуальные задачи. Для эпика который мы назовем контент это могут быть тексты и графика(задачи — Tasks).

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

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

Как уже упоминалось, в гибком управлении проектами этапы работы отображаются в соответствии с рабочими процессами. Рабочий процесс(workflow) — это, так сказать, жизненный цикл задач. Каждый шаг рабочего процесса представляет определенный статус. Изначально статус заявлен как «Сделать»(To Do). Только когда вы начинаете работать над задачей, она переходит в «Выполняется»(In Progress).

Когда вы закончите задание, вы переместите её в «Готово»(Done).

4. Как правильно организовать Jira

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

Метки(Labels), компоненты(Components) и версии(Version)

С появлением все большего количества заявок, задач и проектов Jira может сбивать с толку. Чтобы не терять фокус и/или иметь возможность сквозного связывания, Jira предлагает дополнительный организационный уровень. Это метки, компоненты и версии. Это увеличивает доступность ваших задач/(issues) в Jira и упрощает поиск.

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

Разрешения и роли пользователей

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

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

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

➞ Как автоматизировать разрешения пользователей: PROCEX JUPM

5. Работа с Jira

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

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

После создания задачи вы можете найти ее в Backlog соответствующего проекта и при необходимости установить статус «To Do».

Сотрудничество

Резюме

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

Источник: procex.ru

Configuring Workflow

A JIRA workflow is the set of statuses and transitions that an issue goes through during its lifecycle .

Workflows typically represent business processes.

On this page we’ll learn about:

JIRA ships with a built-in workflow called jira, which is the default system workflow. It cannot be edited, however you can copy this workflow to quickly start creating your own workflow. You can also create your own workflows from scratch, or import workflows from Atlassian Marketplace. You can associate each workflow with particular projects and, optionally, specific issue types, by using a workflow scheme.

This is JIRA’s default workflow:

Statuses and transitions

A status represents the state of an issue at a particular point in a specific workflow. An issue can be in only one status at a given point in time.

When defining a status, you can optionally specify properties .

A transition is a link between two statuses that enables an issue to move from one status to another. In order for an issue to move between two statuses , a transition must exist.

A transition is a one-way link, so if an issue needs to move back and forth between two statuses , two transitions need to be created. The available workflow transitions for an issue are listed on the View issue screen.

Active and inactive workflows

There are slight differences between editing an inactive and an active workflow. We place restrictions on the modifications you can make to an active workflow, due to the impact the changes will have on projects and/or issue types that use this workflow.

Inactive

An inactive workflow is a workflow that is not currently being used by any projects . Because there are no issues currently transitioning through an inactive workflow, you can edit the workflow’s steps and transitions directly . For details on this, see Working in text mode.

Note that by default, inactive workflows are hidden at the bottom of your Workflow page. Expand the link to view them.

Active

An active workflow is a workflow that is currently being used by one or more projects .

When you edit an active workflow, JIRA first creates a draft of it, that you can then modify as you see fit. When you’ve finished, you can publish your draft and, optionally, save your original workflow as an inactive backup.

The following limitations apply when editing the draft for an active workflow:

• It is not possible to edit the workflow name (only the description) if a workflow is active.
• Workflow statuses cannot be deleted.
• If a status has no outgoing transitions (Global transitions are not considered), it cannot have any new outgoing transitions added, regular or global.
• The step ID cannot be changed. See Cannot Add Transitions or Delete Steps in Draft Workflows.

To make any of the modifications listed above, you need to copy the workflow (see Creating a workflow), modify the copy and then activate it.

Workflow designer

Workflow designer is a graphical tool that allows you to see the layout of your workflow and to create and edit a workflow’s steps and transitions.

The JIRA workflow designer looks like this:

The workflow designer allows you to:

• Add a status or transition.
• Click and drag a status or transition to reposition it.
• Select a status or transition to edit its properties, rename it, or to delete it (from the workflow but not JIRA), from the properties panel. As status names are stored on the global level, renaming one would affect all of JIRA immediately, even if the workflow draft is not published.
• Add a global transition that allows every other status in the workflow to transition to the selected status. Select Allow all statuses to transition to this one in the properties panel for the transition.
• Change the screen that a transition uses. See Working in text mode for details.
• Configure advanced transition options, such as triggers, conditions, validators and post functions . See the Advanced transition configuration page .
• Set properties for a status or transition. Please see Workflow properties for details.

Workflow designer tips

• Statuses are global objects in JIRA. Changing the name of a status on one workflow also changes the name of the status on all workflows that use that status.
• Hover over a transition or a status to see the relevant transition labels.
• Zoom the diagram with your mouse wheel. Pan the diagram by clicking and holding the mouse while on white space, then moving your mouse across the diagram.
• You cannot clone transitions in the workflow designer.
• You cannot create annotations in the workflow designer.
• You cannot directly set the issue . editable property. To do this, simply add the issue . editable property to the status properties.

Creating a new workflow

There are a few ways you can start a new workflow to work on:

• Clone an existing workflow
• Create a new workflow
• Import a workflow

Clone an existing workflow

1. Log in as a user with the JIRA Administratorsglobal permission.
2. Choose >Issues. Select Workflows to open the Workflows page, which displays all of the workflows in your system.
   
3. Copy an existing workflow using the Copy link in the Operations column (shown above).

1. Enter a name and description for your workflow.
2. Click the Copy button. The workflow opens in edit mode.

Once you have created your new workflow, you may customize it by adding or editing steps and transitions .

When you have finished customizing your workflow, see Activating workflow for details on how to use it with a JIRA project.

Create a new workflow

For advanced administrators

1. Click Workflows in the left-hand nav panel, then Add Workflow at the top of the screen.
2. Enter a name and description for your workflow. Click Add.
   The workflow opens in edit mode and contains a step called Open and an incoming transition called Create.
3. Continue with your workflow customizations, by adding and editing steps and transitions.

Import a workflow

Configuring a workflow

• Editing a project’s workflow
• Setting the Resolution field
• Renaming workflow transition buttons
• Working in text mode

Editing a project’s workflow

Whenever you create a new JIRA project, your project automatically uses the default workflow scheme. The scheme associates all available issue types in the project with the JIRA system workflow . Since neither the JIRA system workflow nor the default workflow scheme are editable , JIRA creates an editable copy of the system workflow and workflow scheme for your project.

To begin editing your project’s workflow for the first time:

1. Log in as a user with the JIRA Administratorsglobal permission.
2. Choose >Projects, and click the name of a project.
3. On the Administration page for the project, click Workflows.
4. Click the ‘edit’ icon at the top-right of the box.

JIRA automatically does the following:

• Creates a draft copy of the system workflow named ‘Your Project Name Workflow (Draft)’.
• Creates a new workflow scheme for the workflow named ‘Your Project Name Workflow Scheme’.
• Associates any existing issues in your project with the new workflow.

You can now edit your draft workflow. Click on a status or transition to see editing options in the panel that appears.

When you are finished, click Publish Draft. The dialog allows you to publish your draft and, optionally, save your original workflow as an inactive backup.

Usage notes:

• If you have only a small number of existing issues in your JIRA project, this process is relatively quick.
• If you have many (e.g. thousands of) existing issues in your JIRA project, this process may take some time.
• Once this process begins, it cannot be paused or cancelled. Please avoid editing or transitioning any issues within your project while this process is taking place.

Setting the Resolution field

In JIRA, an issue is either Open or Closed, based on the value of its Resolution field — not its Status field!

• An issue is Open if its Resolution field has not been set.
• An issue is Closed if its Resolution field has a value (e.g. Fixed, Cannot Reproduce).

This is true regardless of the current value of the issue’s Status field (Open, In Progress, etc ).

Therefore, if you need your workflow to force an issue to be Open or Closed, you will need to set the issue’s Resolution field during a transition. There are two ways to do this:

• Set the Resolution field automatically via a post function.
• Prompt the user to choose a Resolution via a screen . See Working in text mode for details on this.

Renaming workflow transition buttons

If you copied the system workflow and you wish to rename the workflow transition buttons on the View issue page, you must delete the following properties from all transitions in the copied workflow:

• jira . i18n . title
• jira.i18n.description

Otherwise, the default names (i.e. values of these properties) will persist. Read more about transition properties.

Working in text mode

Text mode is an advanced way of working with workflows, and it shows the difference between steps and statuses. In text mode, you work directly with steps. For details, see Working in text mode.

Источник: www.cwiki.us