JIRA: Все, что пожелаешь, Хозяин. Часть 4

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

Прошлая статья была посвящена методике применения JIRA для моделирования бизнес-процессов строительной организации. Сегодня забудьте об этом — я посвящаю рассказ задачам программирования, и только им. Проект — это набор задач и подзадач. Для каждой задачи есть статус, в котором она находится, есть еще и список всевозможных полей с характеристиками задачи, описанием того, что, когда, кем было или будет сделано. В практике этого мало. Часто задачи связаны между собой не примитивным отношением "задача-подзадача", а произвольными связями. Например, с помощью Issue Linking можно ввести понятие зависимости задач друг от друга, подчиненности, дублирования задач. Так, при добавлении записи об обнаруженной ошибке тестер может ошибиться и ввести запись об уже обнаруженной и внесенной в базу данных ошибке. Давайте рассмотрим, как настроить и использовать Issue Linking. Прежде всего, нужно в режиме администратора перейти на закладку Issue Linking, затем с помощью кнопки Activate включить режим связи между задачами. После чего на этой же странице внизу появляется табличка с перечнем видов связей (изначально табличка пустая) — мы должны ее заполнить. Например, я добавлю связь с именем Duplicate (признак того, что данный Issue дублируется другой Issue). В качестве значений поля Outward Link Description я ввожу слово duplicates, а для поля Inward Link Description указываю значение is duplicated by. Значения, которые вводятся в эти три поля — на ваше усмотрение — просто стремитесь к тому, чтобы это были корректные синтаксические конструкции: "связь от чего-то" и "связь к чему-то". Теперь попробуем сделать связь между двумя Issue.

Для этого я с помощью меню BROWSE PROJECT перехожу к экрану с перечнем всех проектов, выбираю среди них любое задание, а теперь внимание: в карточке товара на панели инструментов появился новый пункт Link this issue to another issue. На появившемся Экране я в падающем списке This issue указываю отношение, которое существует между текущим Issue и другим issue (для выбора второго Issue используйте ссылку select issue). Удобно, что в поле Issues можно ввести сразу несколько кодов задач через запятую — например, CALC-4,CALC-10 (здесь предполагается, что CALC — это код текущего проекта). Также можно из задачи (Issue) для одного проекта сослаться на задачу, принадлежащую к другому проекту. Не забывайте, что отношение связи является двунаправленным, и, если вы для одной задачи сказали "duplicates", то та, другая, задача в своей карточке будет иметь значение is duplicated by. Внешний вид карточки задачи со связями показан на рис. 1. Однако это еще не все: если ссылки между заданиями сложны, и вы хотите видеть не "ближайшие" прикрепленные задачи, но увидеть весь граф задач сразу, то встроенных средств JIRA не хватает. К счастью, для JIRA есть множество плагинов. Часть из них разрабатывается создателем JIRA компанией Atlassian, часть — посторонними организациями, часть плагинов идут "за бесплатно", а за некоторые нужно платить денежки. Вот адрес страницы, где можно найти перечисление доступных для JIRA плагинов: сайт .

Для примера я загрузил плагин Links Hierarchy Reports со страницы сайт . Плагин идет в виде jar-файла. Затем я устанавливаю плагин — для этого просто скопирую jar-файл в папку E:\Program_Files_2\apache-tomcat- 6.0.14\webapps\jira\WEB-INF\lib (путь к самому tomcat, конечно, будет отличаться). В принципе, это стандартная методика установки и любого другого плагина, хотя прочитать инструкцию по установке никогда не вредно. Проверить то, что плагин был успешно установлен, можно, если в режиме администратора зайти на вкладку Plugins и найти на странице с перечнем всех установленных в JIRA плагинов строку Links Hierarchy Reports. После того, как были созданы несколько Issue, а затем связаны отношениями, давайте перейдем на страницу BROWSE PROJECT. Там на правой боковой панели мы видим информацию о проекте и, помимо привычных статистик, сколько в составе проекта задач, и к каким категориям они относятся (открытые, решенные, в ходе работы) плагин Links Hierarchy добавил в раздел Reports два новых вида отчета: Link Hierarchy Report For Versions и Link Hierarchy Report For Issues. Для построения первого отчета необходимо указать то, для какой версии проекта (вспоминайте, что проекты состоят из компонентов и версий) будет построен отчет, также укажите вид связи между issue (отчет нельзя построить сразу для всех видов Link'ов). Внешний вид отчета показан на рис. 2. Созданный отчет не является статическим образованием: мы можем сразу, не выходя из него, с помощью управляющих кнопок на карточке задания добавлять на диаграмму новые связи, а также выполнять такие действия, как "закрытие issue", "начать работу". Второй вид отчета, который появился на карточке проекта Link Hierarchy Report For Issues, приводит к появлению точно такой же диаграммы, но теперь отбор issue выполняется не на основании принадлежности к одной версии, а номер issue, от которого будет построен граф зависимостей, должен быть введен вами самими.

Есть особый вид связи между задачами — точнее, их текстовыми примечаниями, — называемый trackback linking. С этим термином вы наверняка уже встречались в сфере, совершенно не связанной с JIRA, и это… блоги. Смотрите: когда некто Вася написал в internet на своем блоге классную статью, то ему очень хочется, чтобы все ее читали и хвалили Васю. Для этого он ввел возможность комментировать свою статью (стоит упомянуть также и то, что часто эти комментарии публикуются в виде RSS-ленты). Но давайте ближе к trackback linking: другой блогер — Петя — прочитал статью Васи, восхитился ею и пишет в своем блоге заметку — мол, я прочитал такую классную статью от Васи. А чтобы Вася знал, что его статью прочитали, программное обеспечение Петиного блога посылает блогу Васи сообщение, мол, на тебя ссылаются. Фактически trackback'и упрощают разработку документации. Так, если вы на одной html-странице создали ссылку на другую страницу, теперь вам не нужно открывать и редактировать текст второй страницы, чтобы показать, кто же ссылается на нее. Для работы с trackback нужно, прежде всего, в режиме администратора перейти на закладку trackbacks. В появившейся форме с настройками trackback есть три параметра: будет ли JIRA принимать trackback-запросы от посторонних сайтов (по умолчанию включено), также будет ли JIRA отправлять trackback-запросы на другие сайты (по умолчанию выключено), и опция URL Patterns to Exclude from Outgoing Trackback Pings. Эта опция необходима в случае, если вы включили отправку trackback'ов, но хотите, чтобы на определенные адреса такие извещения не посылались. Одним словом, если вы укажете в графе URL Patterns to Exclude from Outgoing Trackback Pings некоторое регулярное выражение, то оно будет играть роль блокирующего фильтра для тех адресов сайтов, куда trackback'и посылать не нужно. Итак, я включил в настройках отправку trackback'ов по всем адресам. Теперь попробуем в JIRA создать две задачи (предположим, что их коды PAINT-2 и PAINT-3). Затем я перехожу в режим редактирования задачи PAINT-3 и в графе текста примечания пишу:

Пример двух trackback-ссылок
Пример первого вида ссылок PAINT-2
Пример второго вида ссылок сайт

Обратите внимание, что ссылку на другую задачу в JIRA я могу создать не только путем указания полного http-адреса к ней, но и просто указав короткий код "PAINT-2". Jira проверяет все такие коды на предмет корректности. И если в локальной инсталляции jira есть задача под таким номером, то комментарий к issue будет преобразован в ссылку. Более того, если код принадлежит задаче, которая была разрешена, то она будет отображена в виде перечеркнутой надписи. Если перейти ко второй задаче, то увидите, что ее карточка изменилась и содержит в графе External references примечание о том, что другая задача ссылается на нее. Важной частью управления проектами является вопрос оценки времени затраченных на выполнение работ. Хотя JIRA при изменении статуса issue сохраняет в карточке задачи время, когда статус был изменен. Но использовать эти даты/время для анализа… ни за что! Начнем с того, что просто глупо подсчитывать время на выполнение работы путем отнимания от одной даты другой, практически невозможно вести учет времени, если задача несколько раз меняла состояние, переходя из OPENED -> RESOLVED и обратно. Для кардинального решения проблемы в jira был введен модуль Logging Work on an Issue. Как и многие другие модули, его нужно предварительно включить. Для этого в режиме администратора переходим на закладку Time-tracking. Затем жмем на большую кнопку с надписью "Activate", предварительно введя информацию о графике работы (количество часов в рабочем дне и количество рабочих дней в неделе). Теперь попробуем создать задачу и проверим то, как jira ведет учет рабочего времени. Однако перед этим, когда вы создаете новый issue, обратите внимание на то, что внизу формы есть поле для ввода Original Estimate, т.е. здесь мы должны ввести планируемое время выполнения работы (например, 2h — работа займет два часа). После включения мониторинга за временем работы поменялся внешний вид карточки issue: на левой панели появилась новая кнопка Log work done. Фактически всякий раз, завершая какой-то этап работы над задачей, вы должны нажать на эту кнопку, а затем в появившемся окне указать, сколько времени вы потратили на работу. Также нужно указать, какая операция будет выполнена над предварительно спланированным временем работы (приемлемый вариант по умолчанию, когда из времени Estimate будет вычтено указанное вами время работы).

Внешний вид карточки задания также изменится: на ней появятся три разноцветные полосы с планируемым временем работы, затраченным временем и оставшимся временем (см. рис. 3). Для того, чтобы получить подробную информацию о проекте, его составляющих, наилучшим выбором будет установить для jira плагин сайт . После этого в карточке проекта в графе Reports появится "пачка" новых отчетов. Во-первых, отчет Recently Created Issues Report отображает в виде столбчатой диаграммы количество задач, которые были созданы и решены за последние X дней (количество дней указывается при создании отчета). Отчет Pie Chart Report отображает в виде круговой диаграммы соотношение между пользователями, работавшими над задачами проекта (можно оценить, кто сделал больше задач). Для оценки работы не по количественному показателю, а по затраченному времени используйте отчет User Workload Report. Отчет Version Workload Report строит таблицу с детальными и итоговыми сведениями, сколько работы еще осталось сделать для каждого из типов задач и для каждого из участников (грубо говоря, когда разработчики освободятся).

Для того, чтобы видеть не остатки времени, а реальное соотношение запланированных, выполненных работ и их остатков, лучше всего использовать отчет Time Tracking Report (см. рис. 4). Для работы остальных отчетов требуется выполнить дополнительные шаги: нужно добавить к задачам три пользовательских поля. Во-первых, Resolution Date (тип поля с таким же названием, и это не ошибка), затем поле Time in Status (тип поля тоже имеет название Time in Status), затем поле Date of First Response (и тип его Date of First Response). Когда мастер создания пользовательского поля будет просить вас привязать поле к каким-то Экранам, ничего не делайте. Теперь в режиме администрирования вы должны перейти на закладку Indexing и выполнить переиндексацию данных JIRA (просто нажмите кнопку Re-index). После чего вы можете вернуться обратно к карточке проекта и увидите, что остальные отчеты заработали. Так, отчет Created vs Resolved Issues Report покажет соотношение между созданными задачи и тем, сколько их было решено. Отчет Resolution Time Report покажет время, затраченное на разрешение задач. Отчет Average Age Report покажет вам то, сколько времени (дней) ожидалось решение задач.

Теперь рассмотрим методику интеграции JIRA и системы управления версиями (СУВ) документов. В состав JIRA изначально входит модуль связи с CVS, однако я с этой СУВ никогда не работал (да и в своих статьях описывал только SVN и Perforce). К счастью, для JIRA есть плагины интеграции с SVN (даже два, только один нужно отдельно покупать). Сначала загрузите архив с плагином с сайта: сайт (будьте внимательны: разные версии JIRA требуют разных версий плагина). Теперь скопируйте все файлы, находящиеся в каталоге lib плагина, в папку E:\Program_Files_2\apache-tomcat-6.0.14\webapps\jira\WEB-INF\lib, затем в папку E:\Program_Files_2\apache-tomcat-6.0.14\webapps\jira\WEB-INF\classes нужно скопировать файл subversion-jira-plugin.properties. Теперь этот файл нужно отредактировать. Внутри файла хранятся адреса подключения к SVN-репозиториям — к примеру:

svn.display.name=Repository for Project "A"
svn.root=svn://localhost/test/project
svn.display.name.1=Repository for Project "B"
svn.root.1=svn://localhost/test/project2

Здесь определены названия и пути к двум репозиториям (если потребуется третий, четвертый и т.д. репозиторий, то их имена строятся по правилу svn.root.НОМЕР). Надо сказать, что при настройке репозиториев можно указать еще и путь к веб-интерфейсу для SVN, но, раз я в серии про СУВ не рассказал ни об одном из таких продуктов, то пропускаю. Теперь перейдем к настройке СУВ на примере всеми любимой TortoiseSVN. В SVN для каждого файла или каталога введено понятие свойств. Проще говоря, мы можем присоединить к каждому файлу пары "ключ=значение". Есть небольшой список предопределенных свойств, и, кроме того, мы (или какая-нибудь программа, работающая с SVN) можем добавлять собственные значения. Итак, создайте в проводнике папку и выгрузите в нее с помощью checkout'а содержимое репозитория (одного из тех двух, которые я указал в примере файла настроек выше). Затем вызываем контекстное меню проводника TortoiseSVN -> Properties. В появившемся диалоговом окне нужно указать параметры JIRA (просто выбираем в падающем списке название свойства и вводим его значение):

bugtraq:label — Текст подсказки, что нужно вводить при отправке commit'а на сервер. Например: "enter JIRA issue #".
bugtraq:message — Текст, который будет показан в журнале правок. Например, "JIRA issue #: %BUGID%" (внимание: здесь и далее %BAGID% — это место для подстановки кода задания).
bugtraq:url — Адрес веб-страницы с карточкой задания. В моем примере это сайт
bugtraq:number — Признак того, будет ли код задачи только числовым (тогда значение этого свойства должно быть true, если же нет — false).

Теперь, как только вы измените файлы и отправите их на сервер, в появляющемся диалоговом окне commit'а, помимо поля примечания к правке, появится еще поле для ввода кода задачи, к которой относится данная правка. Изменения произойдут и в самой JIRA. Так, в карточке задания появится закладка Subversion commits, на которой отображается информация обо всех выполненных правках: название репозитория (где была выполнена правка), также дата и время правки, номер ревизии, сообщение (которое вы ввели как комментарий к commit'у), а также сведения о файлах, которые были изменены (см. рис. 5).

black-zorro@tut.by, black-zorro.com