Я продолжаю рассказ об JIRA. Управление процессом разработки ПО, ведение журнала пожеланий, задач, обнаруженных багов – все это сфера применения JIRA. В прошлый раз я показал, как установить JIRA у себя на компьютере, рассказал о политике безопасности. Теперь самое время создать проект, разобраться в его составляющих, попробовать пройтись по шагам Жизненного Цикла.
Для создания проекта вам нужно войти в JIRA от имени администратора, затем перейти на закладку “ADMINISTRATION”, затем по ссылке “Add Project”. В появившемся окне вам нужно указать основные характеристики проекта: Name (Название проекта), здесь можно указать произвольный текст на русском языке. Затем идет Key(Код проекта) - это несколько букв на английском, например, для проекта калькулятор, его код может быть равен CALC. Если у вас есть уже подготовленная документация по проекту (его описание, Т.З.), то в графе URL вы указываете адрес сайта, где эта документация опубликована. Следующий шаг – указание Project Lead – ведущего разработчика проекта (в качестве project lead не может выступать пользователь не входящий в состав группы jira-developers или jira-administrators). Затем идет Default Assignee – по-умолчанию это тот же человек что и Project Lead. Т.к. проект в основе своей состоит из некоторого количества задач, то Default Assignee – это тот человек, который будет отвечать за выполнение каждой из поставленных задач (естественно, что в последующем он сможет делегировать свои обязанности кому-нибудь другому). Следующий параметр, который нужно указать при создании проекта – это Description (описание проекта). Затем идет Notification Scheme - это правила, по которым при изменении проекта (добавление новой задачи, завершение работы над ней) будут посылаться извещения пользователям JIRA. Также нужно указать схему прав доступа (Permission Scheme), она определяет, какой пользователь и что может делать в JIRA с этим проектом (подробнее о политике безопасности и схемах я писал в прошлой статье). Последняя характеристика проекта - Issue Security Scheme (схема безопасности для каждой из задач). Это специфическая функция только для версии JIRA Enterprise. Идея в том, что пользователи/группы/роли проекта делятся на уровни безопасности, затем при добавлении в JIRA новой задачи ей будет назначен некоторый уровень защиты. По-сути, Issue Security Scheme – неплохой способ защитить информацию, если организация разместила JIRA не в локальной сети, а в internet, так чтобы пользователи некоторого продукта могли добавлять свои пожелания, сообщать об выявленных ошибках. Важно, что одновременно эту установку JIRA используют и в самой организации, а значит что не все задачи проекта (те которые создают разработчики внутри самой организации) должны быть доступны для обычных пользователей internet. Пример того, как выглядит карточка проекта, показан на рис. 1.
На этой карточке находится несколько полезных ссылок для “донастройки” проекта. Прежде всего, Project Category – создаваемые проекты можно группировать по категориям. Создать категорию можно на закладке “ADMINISTRATION”, раздел “Project categories”. В дальнейшем, если перейти на закладку “BROWSE PROJECTS”, то увидите список проектов, сгруппированный по назначенным им категориям. Следующая опция в карточке проекта - CVS Modules, она служит для интеграции JIRA с системой управления версиями файлов (изначально в JIRA встроен модуль CVS, однако есть плагины для интеграции с SVN, Perforce). Следующая опция проекта – Workflow Scheme, ее назначение – настроить этапы, через которые может проходить решаемая задача (подробнее об Workflow Scheme чуть позже). Каждая задача, из которых состоит проект, имеет набор характеристик, например, название, категория (ошибка, или новая функциональность) …, таких характеристик (в терминологии JIRA полей) много. Но не все ситуации можно заранее предусмотреть и возможно для некоторого проекта вам потребуется, чтобы к каждому из заданий было добавлено еще одно поле характеристики (например, признак того, что задание должно быть выполнено только в полночь пятницы 13 числа). Так вот подобная фунциональность обеспечивается с помощью Field Configuration Scheme. Помните только, что поведение JIRA зависят от того какая у вас версия: Standard, Professional, Enterprise (в младших версиях количество доступных функций меньше).
Создав проект, мы должны наполнить его содержимым, но до создания задач необходимо разбить проект на компоненты и указать версии. Компоненты это части проекта, например, проект графического редактора будет условно состоять из модуля загрузки/сохранения, модуля печати, модуля рисования. Чтобы создать компонент вы на закладке “ADMINISTRATION” переходите по ссылке “Projects”, затем в таблице с перечнем проектов, вы выбираете проект, для которого хотите отредактировать его карточку и внизу карточки находится перечень компонент. Для добавления компонента используйте ссылку “Add a new component”,
затем вы указываете название компонента, примечание к нему, а также выбираете кто из разработчиков будет за него отвечать (Lead). Создав несколько компонент? вы может выполнить донастройку проекта, и для каждого из компонентов указать лицо, которое будет играть роль Default Assignees (лицо ответственно за выполнение задачи добавленной в проект или его компоненту), для этого используйте ссылку “Select assignees for components”. Проект не статическое образование, он развивается во времени, поэтому было введено понятие версий (редактировать версии нужно здесь же, в карточке проекта). При добавлении версии указывается, собственно, ее номер (возможно указать не только цифры, но и более сложные комбинации, например, 1.1.2, или кодовое название Chicago). Кроме номера версии, нужно указать планируемую дату завершения работ над версией (Release Date) и некоторый текст примечания к версии. Если вы будете добавлять вторую и последующие версии, то добавится еще одно поле Schedule, в нем нужно указать номер версии предшествующей добавляемой. Создав версии ими можно управлять, например, менять статус, с Release на Unrelease (версия вышла или в стадии разработки), выполнять слияние версий (в ходе этого выполняется перенос всех запланированных для этой версии задач в другую версию). В случае удаления версии, вас спросят, что делать с задачами назначенными для нее: следует ли эти задачи аннулировать или перенести в другую версию проекта?
Завершив создание проекта самое время перейти к наполнению его задачами. Для этого не обязательно быть администратором проекта: создавать задачи может и пользователь, включенный только в группу jira-users, однако для того, чтобы редактировать задачи, перемещать их … нужно входить в группу jira-developers. Итак: после регистрации, вы заходите на закладку “CREATE NEW ISSUE”, затем выбираете в падающем списке проект для которого хотите добавить задание, и тип задания. Среди предопределенных типов работы Bug, New Feature, Task, Improvement. Этот перечень не фиксированный, и его можно изменить, если в режиме администрирования перейти по ссылке “Issue Types”. Возвращаясь к созданию задачи, давайте выберем тип добавляемой задачи как “Task”, затем мы попадаем на форму где нужно указать для задачи все ее свойства. Прежде всего, Summary (название задачи), Priority (степень важности задачи). Она может варьироваться в диапазонах Trivial, Minor, Major, Critical, Blocker, соответственно, от минимальной важности до наивысшей и даже критической, такой, что до решения задачи дальнейшая работа над проектом нецелесообразна. Список приоритетов не является фиксированной величиной и его можно изменять (правда мне это ни разу не потребовалось, но все же). Итак, для редактирования перечня приоритетов в режиме администратора зайдите на страницу “Priorities”. Возвращаясь к созданию задачи, теперь нужно указать перечень компонентов проекта, к которым привязана добавляемая задача (можно выбрать несколько компонентов). Графа “Affects Versions” служит для выбора тех версий проекта, к которым будет привязана создаваемая задача. А поле “Fix Versions” указывает то, для каких версий данная функциональность уже реализована. К каждой задаче привязан срок ее завершения (поле Due date в карточке задачи). Для детального описания задачи используется поле “Description” (в тексте можно использовать ссылки вида http://site.ru, они автоматически будут преобразованы в теги “a”). Поле Environment должно содержать информацию об окружении (операционная система и ее версия, тип браузера) для которого актуальная задача. Наконец, мы можем указать кто (какой разработчик) будет ответственным за выполнение задачи и планируемые затраты на выполнение работы.
Завершив создание задачи, мы можем ее редактировать (см. рис. 3, панель слева).
JIRA – замечательный инструмент: она ведет учет всех правок выполненных над задачей. К примеру, если я хочу добавить к списку операционных систем еще одну, то нажав на ссылку “Edit”, ввожу новое значение в графу “Environment” и должен указать текст примечания к выполненной мною правке. Затем, вернувшись назад, в режим просмотра задачи я вижу под карточкой задачи перечисление всех правок, которые я выполнил (старое значение свойства и новое значение свойства), также вижу примечания к выполненным правкам. К задаче можно приложить файлы: ссылка “Attach file” служит для того, чтобы загрузить с вашего компьютера файл на сервер, а ссылка “Attach Screenshot” пригодится, если вы хотите приложить к задаче пример скриншота (например, вы тестер, нашли ошибку сделали скриншот, но не сохраняете файл с картинкой на диск а хотите чтобы на сервера сразу же отправилось содержимое буфера обмена). Задачу можно перемещать (ссылка Move) в другой проект. Также за задачу можно голосовать. Например, компания adobe создала общедоступную JIRA инсталляцию в internet, так чтобы пользователи продуктов adobe могли участвовать в их разработке. Но очевидно, что если некто, Вася добавил пожелание “чтобы в photoshop была большая красная кнопка”, то не факт что эта функция нужна всем. А если разрешить голосование за задачу, то можно определить степень заинтересованности в этой функции у других пользователей. Функция Watching служит для подписки, так чтобы пользователю отправлялись сообщения об изменениях в состоянии задачи. Возможно, что решение некоторой задачи достаточно сложно и поэтому имеет смысл ее разбить на отдельные шаги (подзадания). Вообще-то, такая функциональность в JIRA по-умолчанию отключена, но это можно исправить в режиме администрирования, меню “Sub-tasks”, затем ссылка “Enable sub-tasks”. Теперь можно вернуться назад в режим добавления задачи, добавим новую задачу, например, рисование геометрических фигур, и теперь мы хотим ее детализировать, выделить подзадачи: рисование линий, прямоугольников, кругов. Для этого я перехожу в режим редактирования задачи “рисование фигур” и вижу что в расположенной слева панели инструментов добавились кнопки “Create Sub-task” и “Convert to Sub-task”. Т.е. мы можем добавить к текущей задаче под-задачу или превратить текущую задачу как составную часть чего-то другого. Как будет выглядеть карточка задачи с подзадачами показано на рис. 4.
Теперь пора разобраться с понятием Workflow. После создания задачи (отчета об обнаруженной ошибке) мы начинаем работу над ее реализацией (исправлением). Если задача не тривиальна, то на это требуется время, требуется участие других специалистов (например, тестеров) и не факт, что мы с первого раза решим поставленную задачу. Поэтому было введено понятие Workflow, т.е. это набор этапов, через которые проходит задача. Также Workflow - это набор правил перехода между этими состояниями. Это еще и набор действий, которые выполняются в ходе перехода, условий которые могут быть наложены на состояние и переход. В различных версиях JIRA (Standard, Professional, Enterprise) работа с Workflow выполняется по-разному, например, в старших версиях можно создавать собственный Workflow, и даже можно сделать так, чтобы задача одновременно проходила по нескольким Workflow одновременно. Сначала я приведу диаграмму (я взял ее в справке JIRA), где показаны состояния и переходы, реализованные в Workflow по-умолчанию (см. рис. 5).
Сразу после создания задачи ей назначается статус OPENED (открыта и подлежит решению). Затем некто Вася, приходит утром на работу, смотрит то, какие ему были назначены задания, выбирает одно из них и погружается в работу. Для того чтобы злобный босс не кричал на Васю, чем же он занимается, Вася ставит задаче статус IN_PROGRESS (задача в разработке). Вечером Вася завершает работу и поставив для задачи статус RESOLVED (задача был решена) с чувством выполненного долга уходит домой. Однако, следующим утром когда Вася обнаруживает что за ночь тестеры проверили Васину работу и нашли массу недоделок, поэтому они перевели задачу из состояния RESOLVED в состояние REOPENED (открыта повторно). Так что Васе приходится исправлять свои ошибки и снова рапортовать RESOLVED. Только после того как задача была проверена и все ошибки исправлены, ей меняется статус на CLOSED (задач завершена). Если вы вернетесь в карточку задачи, то обратите внимание на набор ссылок помещенных в группу “Available Workflow Actions”, там будут перечислены те действия, которые можно выполнить над текущим состоянием задания. Каждый раз, когда вы меняете это состояние вы должны ввести текст примечания. Механизм создания собственных Workflows очень важен, если модель разработки (взаимодействия между участниками) отличается от приведенной выше, например, если вы хотите применить JIRA не для управления проектом по разработке ПО, а для других видов проектов. Например, вы разрабатываете архитектурные проекты, и у вас есть шаги: “нарисовать дизайн”, “начертить схему”, “утвердить проект в санэпидемстанции”, “утвердить у пожарников”, …, “заплатить бакшиш”. Каждый из этих шагов может следовать только после другого шага (нельзя утвердить проект до того как будет создан чертеж). Попробуем создать собственную схему Workflow, для этого в режиме администратора переходим по ссылке “Workflows”, там мы увидим описанную выше схему по-умолчанию (ее нельзя редактировать). Внизу страницы вы видите форму добавления новой схемы. Указав название (на латинице) и примечание к схеме, мы переходим на этап наполнения ее содержимым. Прежде всего, необходимо спланировать шаги (состояния обработки запроса). Каждый шаг имеет название и привязанный к нему статус (например, RESOLVED). Перечень статусов не является жестко фиксированным и его можно изменять (режим администрирования, ссылка Statuses). После того как вы создали нужные статусы и привязанные к ним состояния, необходимо создать переходы (Transitions). При создании перехода кроме указания начальной и конечной точки можно (хотя и не обязательно) указать еще и Экраны (например, для перехода от состояния “Дать бакшиш” к состоянию “Утвердить” нужно ввести примечание, что денег не хватило). Экран представляет собой html-форму с некоторым полями (да вы можете создавать собственные формы), которую нужно заполнить для успешного завершения перехода (Transition). Фактически JIRA представляет собой гибкий конструктор позволяющий создать систему управления проектами, выполняемыми работами и подстроить ее под вашу бизнес-модель. Если вам не будет хватить каких-то функций, то можно воспользоваться плагинами или создать собственное расширение возможностей JIRA.
Часть 1
Часть 3
Часть 4
Оригинал статьи - black-zorro.com
