Study & DevО программировании и не только

Управление проектами вместе с JIRA. Часть 3

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

В прошлый раз я начал рассказ о методике создания Workflow, соответствующего особенностям тех проектов и этапов их разработки, которые приняты в вашей организации. Напоминаю, что Workflow состоит из этапов, правил перехода между этапами. Для примера я завершу создание Workflow некоторой строительной организации. Работы, выполняемые ею, включают составление дизайн-документа, разработку пакета чертежей, утверждение документов и выполнение, собственно, строительных работ. Примечание: в дальнейшем я буду часто употреблять словосочетание “в режиме администратора перейдите на закладку X”. Здесь предполагается, что для выполнения некоторой операции вы должны не только войти внутрь JIRA от имени пользователя с административными привилегиями. Но следующий шаг заключается в переходе в главном меню на пункт “ADMINISTRAION” и выбор в расположенной слева экрана панели инструментов кнопки “X”.

Итак, начали. Первым шагом нужно в режиме администратора зайти на страницу “Issue Types”, затем на закладке “Global Issue Types” мы должны создать виды Issue (заданий), которые специфичны для вас (те виды работ, которыми занимается наша строительная фирма). Например, я добавлю Issue: “Construction Order” (строительный заказ). В качестве параметров при его создании следует указать название, комментарий, иконку, а также тип (т.е. будет ли данный Issue служить для представления задач или подзадач). В качестве подзадач я создам еще два вида Issue, таких как “Разработка документации” (Development of the documentation) и “Выполнение строительных работ” (Construction Work). Затем нужно создать новую “Issues Types Schema” (схему типов задач), которая будет использована для управления некоторым проектом. Изначально в JIRA уже есть одна схема (Default Issue Type Scheme), которая описывает процесс разработки ПО. Она нам не очень подходит, поэтому я перехожу на закладку “Issues Types Schema”. Затем говорю, что надо добавить новую схему (я назвал ее “Building Schema”) и указываю то, какие типы Issue (задач) входят в ее состав (см. рис. 1).



Теперь я перехожу к настройке “Custom Fields” (пользовательских полей). Дело в том, что раз я планирую создать систему управления проектами специфическую для строительной организации, то мне нужно будет полностью перестроить экранные формы для добавления нового Issue (задания). Начну я с того, что создам несколько нестандартных полей. Дело в том, что обычные поля, такие как информация об аппаратном обеспечении, операционной системе (которые отображаются на форме создания нового Issue) мне не нужны. А вот поле “Тип Строения” с перечислением возможных вариантов (жилое, склад, административное) будет полезным. Также я хочу создать текстовое поле для хранения адреса, по которому будут выполняться работы. Итак, в режиме администратора я перехожу по ссылке “Custom Fields”, там я вижу список пользовательских полей (изначально он пуст) и жму на кнопку “Add Custom Field”. В появившейся форме я должен указать тип нового поля. Среди вариантов: и падающие списки для выбора значений (вот мое поле с перечнем типов строений), и список радиокнопок, и поле для ввода числа. Есть набор checkbox кнопок, найдется текстовое поле для ввода URL-адресов, также есть поле для ввода даты и поле, где можно ввести произвольный текст (ага, вот и поле для хранения адреса). Более того, часть вариантов типов полей тесно интегрирована с информацией хранящейся в JIRA. Например, есть падающий список для выбора пользователей, групп. Выбрав тип поля вы попадаете на второй экран, где нужно указать название поля и то к каким типам Issue, он может быть применим (я выбрал все три Issue созданные шагом ранее) см. рис. 2.



Завершающим этапом создания поля будет указать то, к каким Экранам оно будет привязано (здесь я ничего не выбрал т.к. методы работы с Экранами хочу показать чуть позже). При добавлении второго поля “Тип Строения” я выбрал тип “Select List”. Затем, для того чтобы указать возможные значения для этого List-а, я после создания поля в таблице (где перечислены все пользовательские поля), в графе “Operations” нажал на кнопку “Configure”, затем кнопка “Edit Options” (см. рис. 3).



Теперь я хочу заняться созданием Workflow соответствующего работе строительной организации. Начну я с создания статусов. Статус – соответствует определенному этапу работы (составление дизайн-документа, разработку пакета чертежей, утверждение документов и строительные работы). Для этого я в режиме администратора перехожу на вкладку “Statuses” и добавляю туда эти четыре новых типа. Для каждого из них указывается название, комментарий, и иконка. Теперь мы готовы к созданию Workflow. Для этого я перехожу на вкладку “Workflows”, там я увижу таблицу с одной единственной схемой jira (это стандартная схема по которой работает JIRA и ее можно использовать как основу при проектировании собственной схемы). Внизу страницы есть форма добавления нового Workflow, там нужно указать название и примечание к создаваемой схеме (я назвал схему “Architecture”). Когда мы сделаем это, то увидим, что в таблице Workflows будут уже две строки: jira и Architecture. Пора заняться наполнением схемы рабочего процесса конкретными состояниями и правилами перехода. Для этого я перехожу по ссылке “Steps” и попадаю на экран конструирования схемы. Устроен он очень просто: посередине страницы находится таблица с зарегистрированными состояниями (изначально в ней только один элемент “open” – т.е. проект был открыт). Я последовательно добавляю четыре новых этапа работ и привязываю их к созданным ранее шагам (создание дизайна, конструкторские работы, утверждение документов и строительные работы). Последним элементом Workflow я помещаю элемент “Closed” (проект был закрыт). Можно было бы развить пример и добавить состояния соответствующие исправлению ошибок на каждом из шагов, но я решил упростить схему и не делать этого. Конструирование workflow еще не завершено: нужно написать правила переходов из одного состояния в другое. Для этого в таблице с перечислением шагов, нужно нажать на ссылку “Add transition”, так я попаду на экран планирования переходов. Каждый переход состоит из названия, примечания, шага, к которому будет выполнен переход, и Transition View (Экрану, который мы увидим при выполнении подобного перехода). Экран нужен для того, чтобы организовать ввод дополнительной информации, например, при переходе от стадии “Утверждения документов” к “Строительным работам” нужно ввести регистрационные номера утвержденных документов. Учтите, что переходы (Transitions) являются однонаправленными, например, можно выполнить переход от состояния “создание дизайна” к “чертежным документам”, но вот обратный переход не возможен (как будто бы). Поэтому для сложного бизнес-процесса, будет просто огромнейшее количество переходов (см. рис. 4).



Завершив проектирование workflow, необходимо указать правила, по которым при создании проекта будет выбран соответствующий workflow. Итак, я в режиме администратора перехожу на закладку “Workflow Schemes”, где вижу, что таблица схем пока пуста. Затем я нажимаю на ссылку “Add workflow scheme” и попадаю на форму создания новой схемы. Там нужно указать название схемы и примечание к ней (схему я назвал Building Schema). Следующий шаг – наполнить схему правилами (ищем ссылку “Assign Workflow”). Настройка ассоциации построена на выборе комбинации “Тип задания” (Issue) и “Workflow”. В падающем списке я выбираю, соответственно, “Construction Order” и “Architecture”. По аналогии я добавляю ассоциации и для двух оставшихся типов issue (строительные работы, разработка документации).

Теперь мы полностью готовы к созданию проекта выполняющегося по схеме строительных работ. На начальных шагах (ввод имени проекта, его кода, ответственных за выполнение работы лиц) нет никаких отличий от того, как мы создавали проект разработки программного обеспечения. Только после того как проект был создан, нужно перейти в его карточку, затем нажать в графе “Workflow scheme” кнопку “Select” и выбрать созданную на предыдущем этапе схему “Building Scheme”. Поздравляю, первый этап пройден, и мы можем начать наполнять проект конкретными задачами.

Делается все это также как и в прошлый раз (как для задач разработки ПО). Вот только после создания задачи, если перейти в ее карточку, то в меню “Available Workflow Actions” будут находиться не команды “RESOLVE, REOPEN”, а созданные нами действия “Начать дизайнерские работы”, “Утвердить документацию” и т.д. Если я создам задачу “строительство гаража”, то смогу поместить в нее подзадачи “создание проекта документов” и “строительные работы” (вернитесь к началу статьи, там я создавал именно вот эти типы Issue). Осталось только разобраться, как в карточку задания поместить пользовательские поля (адрес и тип строения). Пользовательские поля не являются самостоятельной сущностью – они должны быть добавлены на Экран (форму интерфейса JIRA, которая показывается при наступлении определенных событий). Начну я с того, что создам новый экран и наполню его нужными для меня характеристиками. Например, когда я создаю Issue проекта разработки, то такие поля, как версия программы, для которой данная задача актуальна или версии, для которых проблема уже решена, мне не нужны.

Снова в режиме администрирования я перехожу на закладку “Screens”, там я вижу таблицу с перечнем Экранов (изначально там будут три экрана: Default Screen, Resolve Issue Screen, Workflow Screen) и того, где эти Экраны используются. Например, экран Workflow Screen используется когда нужно ввести данные о новой задаче. Редактировать данный Экран я не буду, чтобы не смущать тех, кто добавляет проект разработки ПО, таким полями как тип строения или его адрес. А вот внизу страницы есть форма для добавления нового Экрана. Использую ее, и создаю Экран с именем “Building Initiated Screen”. После создания Экрана он появится в таблице, а я должен наполнить его полями (ссылка “Configure”). Форма редактора Экрана разделена на две части: поля и закладки. Я создаю две закладки: “Основные свойства” и “Дополнительные свойства”. Затем, последовательно выбирая эти закладки, с помощью формы “Add Field” добавляю на каждую из них некоторые поля (в форме добавления поля есть список “Fields to add”, где отображаются все доступные поля, как служебные, так и созданные мною). Интерфейс конструктора экрана очень удобен: легко добавлять, удалять закладки, менять их порядок расположения. Поля, которые были ошибочно размещены на какой-то закладке, без проблем перемещаются в нужное место. Момент в том, что вы не имеете права выбирать какие попало поля: есть поля обязательные и нет. Обязательно нужно чтобы в состав Экрана было включено поле: “Summary Of Issue”. Завершив планирование экрана нужно выполнить его привязку к определенному этапу работы над проектом.

Делается это не просто, но привычно. Также как мы создавали новый тип Workflow, а затем схему его применения, так и здесь нужно создать новую Экранную Схему. Для этого переходим на закладку “Screen Schemes”, там мы увидим таблицу со всеми доступными схемами управляющими, когда и какой Экран должен быть показан. Нам нужно добавить новую схему (внизу страницы), указав при этом ее название, примечание к схеме, и то какой экран будет показан по-умолчанию (указываю созданный на предыдущем шаге “Building Initiated Screen”). Новую схему я решил назвать “Building Screen Sheme”. Если мы создали несколько Экранов (например, отдельный экран для начала строительного проекта, отдельный экран для каждого из шагов его выполнения или завершения), тогда нужно не уходя с закладки “ Screen Schemes” нажать кнопку “Configure” и добавить там ассоциации “операция-экран”. К этой работе я вернусь чуть попозже. Теперь будем привязывать созданную схему к определенному набору задач (Issue). Для этого снова в режиме администрирования переходим на закладку “Issue Type Screen Schemes”. Там мы увидим ассоциации между Набором Экранов и списком проектов. Внизу страницы расположена форма добавления новой “Issue Type Screen Schemes”. Используем ее, вводим название схемы (я назвал схему “Building Type Screen Sheme”), затем вводим примечание к схеме, и в падающем списке “Screen Scheme” выбираем созданную чуть ранее схему “Building Screen Scheme”. После создания схемы мы видим в таблице уже две строки. Вот, правда, созданный на предыдущем этапе проект “Строительство гаража” привязан не к нашей схеме, а используемой при разработке ПО. Пора это исправить. Для этого переходим на закладку с перечнем проектов, далее переходим в карточку проекта и в графе “Issue Type Screen Scheme” используем кнопку “Select” для того чтобы выбрать “Building Type Screen Sheme”. Теперь проверим, что же у нас получилось, для этого переходим на экран создания новой задачи, выбираем проект “Строительство гаража”, затем тип задачи “Construction Order”. И видим, что внешний вид экрана добавления задачи поменялся, теперь он состоит из двух закладок (“Основные свойства” и “Дополнительные свойства”) и на второй из этих закладок находятся созданные мною в самом начале статьи пользовательские поля “Адрес” и “Тип строения” (см. рис. 5).



Попробуем начать работу над свежесозданной задачей и выполнить переход к состоянию “дизайнерские работы”. Для этого я перехожу в карточку задания, в меню “Available Workflows Actions” жму на ссылку “Начать дизайнерские работы” и … вижу совсем не тот экран, который хотел бы. Я снова вижу поля список версий ПО, для которых актуален этот переход, еще вижу требования к операционной системе, а вот полей адреса и типа строения нет. Будем исправлять. Для этого я должен вернуться на форму редактирования шагов Workflow (в административном режиме закладка “Screen Schemes”). Затем в таблице с перечнем схем я выбираю созданную мною же “Building Screen Sheme” и перехожу по ссылке “Configure”. Теперь я должен с помощью расположенной внизу формы добавить ассоциацию между Экраном и конкретным этапом Workflow, когда появляется форма для ввода пользователем некоторой информации. Так я добавил связь между событием создание задачи (“Create Issue”) и “Building Initiated Screen”. Такой же Экран был присоединен и к операциям “Edit Issue” и “View Issue”. Если теперь вернуться назад к карточке задания и попробовать ее редактировать, переходить с одного состояния в другое, то внешний вид экрана будет тот, что нужно: созданная мною форма, с двумя закладками и пользовательскими полями.

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

« Управление проектами вместе с JIRA. Часть 2

Управление проектами вместе с JIRA. Часть 4 »