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

Управление проектами — не простая наука, для этого нужны знания (и еще больше — опыт) во множестве сфер, связанных и с социальными, и с техническими, и с экономическими технологиями. Я ставлю перед собой более простую задачу: рассказать об "управлении желаниями" и программными продуктами, которые могут вам помочь вести учет пожеланий клиентов, контролировать их выполнение в сфере разработки ПО.

На рынке множество программных продуктов, которые позиционируют себя как "Project Management", "Issue Tracking", "Bag Tracking", "Customer Relationship Management". Взаимопроникновение этих продуктов и прагматичный подход "нашего человека", умеющего использовать для ведения проекта не только специализированный софт, но и все что угодно (я видел "чудеса", когда для общения между заказчиком и клиентом использовался обычный форум, и то, какие проблемы приходилось решать, чтобы построить график работ и следить за его соблюдением). Так вот, все эти факторы часто приводят к тому, что люди часто путают эти приведенные выше понятия и пытаются решать некоторым программным продуктом не свойственные для него задачи. Хотя все приведенные выше категории ПО имеют общие черты, но "дьявол, как известно, кроется в мелочах". И какое бы определение и требования для системы управления проектом я ни сформулировал, всегда найдется человек (точнее, предприятие со своим бизнес-процессом), который скажет: "нет, у нас не так". Я буду рассказывать о небольшой части управления проектами в области ПО — ведении учета ошибок и пожеланий клиентов. Если разработкой программы занимается не один человек, а команда, то важнейшей задачей становится обеспечение коммуникации между всеми участниками. Возьмем сценарий, когда босс (заказчик) водит пальцем по мятому листку бумаги и цедит из себя что-то вроде: "хочу такое, ну… этакое, ну, ты, в общем, понял". Затем программист допридумывает себе задание, делает его в меру своего скромного представления, что же от него хотели. Тестировщики, в свою очередь, сравнивают "непонятно что" с "непонятно каким" эталоном, а затем, набросав пару строчек на листке бумаги, клеят его на монитор программистам и с чувством исполненного долга идут играть в counter-strike. Представили картинку, а, может, узнали что-то родное? Нам нужен инструмент, с помощью которого мы определим перечень задач, которые должны быть выполнены. Нам нужен инструмент, где будет вестись перечень уже сделанных работ и затраченных на это ресурсов. Инструмент, в котором будет вестись журнал ошибок, выявленных в ходе тестирования, и то, какие из этих ошибок были исправлены. И, приходя утром на работу, каждый из участников проекта сможет просмотреть перечень назначенных дел (пришедших от заказчиков или тестеров), а, уходя вечером домой, выставит галочки — мол, сделано. Давайте посмотрим, какие программные продукты помогут управлять Жизненным Циклом ПО. И чем нам поможет JIRA — не зря же я вынес ее в заголовок статьи.

Наиболее простым (и наиболее часто используемым) инструментом в разработке ПО является Bag Tracking. Они представляют собой базу данных, каждая запись в которой — сообщение о выявленной в ходе тестирования/эксплуатации ошибке. Пользоваться такими продуктами могут как ваши штатные тестировщики, так и бета-тестеры и даже конечные клиенты. Они заходят на специальную страницу вашего сайта, выбирают программный продукт, для которого они нашли ошибку, указывают ее категорию, описывают ситуацию, в которой возникла ошибка, версию О.С., программы, прикладывают файлы со скриншотами и т.д. Приходя утром на работу, вы просматриваете перечень добавленных за ночь сообщений об ошибках, определяете из них те, которые рапортуют об устраненных проблемах (может быть, клиент сообщает об ошибке, которая характерна для старой версии программы, и ее нужно просто обновить). Возможно, сообщения об ошибках дублируются, и вы уже решали ранее эту проблему. Отфильтровав ошибки, вы выставляете им приоритет и беретесь за работу, с тем чтобы к концу рабочего дня выложить в ту же Bag Tracking систему описание способа решения проблемы. По крайней мере, вы всегда будете четко знать, что вы сделали за рабочий день, и что осталось сделать завтра. Не зря же говорят, что "след самых бледных чернил на бумаге ярче, чем самая крепкая память". JIRA — это не только система учета ошибок, это система учета пожелания Issue Tracking — у нее веб- интефейс, система дополнений и интеграция с другими программами, поддерживающими Жизненный Цикл разработки ПО. Хорошая система "управления желаниями" должна уметь решать задачу согласования видений проекта у различных его участников. К примеру, заказчик проекта оперирует такими понятиями, как задача, степень ее готовности (в процентах), затраченные человеко-часы и деньги. С другой стороны, для программистов важны другие критерии деления — например, сделать форму с двумя кнопками, сделать отчет с перечнем всех товаров… Подобное детальное представление работ мало интересует заказчика — он не должен вникать в то, что делается, ему нужен конечный продукт. Программисты — наоборот. И хорошая система "управления желаниями" должна уметь сочетать эти две стороны. Кроме того, важным является наличие средств интеграции со средствами автоматизированного тестирования, управления версиями файлов. Я покажу, как установить, настроить и использовать JIRA тем, кто с ней еще не сталкивался. За продвинутыми трюками и хаками прошу обращаться на сайт разработчиков JIRA ( сайт ). JIRA — веб-приложение, написанное на java. Значит, для запуска ее нам нужен java-хостинг. Есть множество веб-серверов, способных запускать java- приложения (tomcat, jetty, resin…). По адресу сайт есть инструкции, рассказывающие, как настроить jira для различных серверов. После того, как вы скачали и разархивировали JIRA, необходимо отредактировать файл с параметрами подключения к базе данных. По умолчанию jira работает с базой данных hsqldb, хотя не обязательно, но рекомендуется ее заменить для повышения скорости работы. Для этого я создал базу данных jiradb, пользователя jirauser (с паролем jirapass) и дал этому пользователю полные права доступа к базе jiradb:
create database jiradb default character set utf8;
grant all on jiradb.* to jirauser identified by 'jirapass';

Теперь необходимо внести правки в файл /edit-webapp/WEB-INF/classes/entityengine.xml. Найдите там строку field-type-name="hsql" и замените ее на field-type-name="mysql", также нужно удалить строку schema-name="PUBLIC". Затем вы запускаете процесс компиляции JIRA с помощью файла build.bat (он находится в корне распакованного дистрибутива jira). После этого в папке dist-tomcat/tomcat-6 будет сформирован файл atlassian-jira-НОМЕР- ВЕРСИИ.war — его можно скопировать в папку webapps инсталляции tomcat, а можно не копировать (в дальнейшем примере при создании Context'а явно указывается путь к архиву). Осталось только настроить параметры подключения к БД и указать путь к веб-приложению. Для этого я скопировал файл jira.xml в папку conf/Catalina/localhost/ и отредактировал его. Прежде всего обратите внимание на корневой тег Context и его атрибут docBase — здесь мы должны указать путь к созданному на прошлом шаге war-файлу. Значения атрибутов username и password необходимо поменять на имя и пароль созданной ранее учетной записи. Значение атрибута driverClassName меняется так, чтобы указывать на имя драйвера для работы с базой данных mysql (com.mysql.jdbc.Driver), а атрибут url меняется так, чтобы указать на подключение к базе данных jiradb, например:

url="jdbc:mysql://localhost/jiradb?autoReconnect=true&useUnicode=true&characterEncoding=UTF8"

Настоятельно рекомендуется (а в случаях, когда при вводе текста на русском языке в JIRA появляются "кракозюбры", то обязательно) в файл conf/server.xml добавить следующую строку useBodyEncodingForURI="true" для тега Connector. Раз мы работаем с базой mysql, то необходимо файл с драйвером ( сайт ) скопировать в папку WEB-INF/lib приложения. Еще с сайта сайт вы должны скачать архив с нужными для работы JIRA над tomcat библиотеками и скопировать их в папку tomcat/lib.

В приведенной выше инструкции я пропустил некоторые детали, связанные с повышением производительности JIRA: они не столь важны для первого знакомства, и в последующем вы сможете выполнить эти процедуры с помощью инструкций на сайте JIRA. Теперь осталось только запустить tomcat и открыть в браузере адрес httр://localhost:8080/jira. Если процедура установки прошла без ошибок, то вы увидите мастера настройки JIRA — вам нужно будет пройти через три шага установки. На первом из них выбирается язык интерфейса (среди вариантов есть и русский, но его лучше не использовать — перевод не полный), название вашей компании, пути к трем каталогам, где будут храниться нужные для работы JIRA файлы и резервные копии. Там же нужно указать режим работы JIRA: public или private. Отличаются эти режимы тем, что в режиме public любой пользователь может зарегистрироваться и оставлять комментарии, в противном случае регистрация нового пользователя должна быть выполнена только администратором. Да… самое главное: нужно ввести лицензионный ключ. Есть три версии JIRA: Standard, Professional, Enterprise, и, хотя их стоимость зашкаливает за несколько тысяч "$", но JIRA отрабатывает вложенные в нее деньги до последней копейки, подтверждением чему будет многотысячный перечень организаций, использующих JIRA и смежные с ним продукты (Confluence, Bamboo, FishEye…). К тому же, всегда можно получить пробную версию на 30 дней (на сайте сайт ). На второй форме процедуры установки вам нужно придумать имя и пароль для администратора. Третья форма служит для указания настроек почтового сервера. Все указанные настройки можно изменить в будущем.
Объекты, которыми может управлять JIRA — это проекты, задачи, подзадачи. Прежде, чем мы начнем создавать проект, необходимо разобраться в терминологии JIRA, политике безопасности.

Для этого, завершив процедуру установки, вы возвращаетесь на первую страницу jira и для входа в систему указываете имя и пароль администратора. Либо, воспользовавшись ссылкой signup, регистрируете нового пользователя (учтите, что создание новых проектов, равно как и задачи настройки JIRA, может выполнить только администратор). Главное меню JIRA состоит из следующих пунктов: HOME, BROWSE PROJECTS, FIND ISSUES, CREATE NEW ISSUE, для администратора добавляется еще пункт ADMINISTRATION — именно сюда вам и нужно зайти. Все функции администрирования перечислены в колонке слева и делятся на категории. Во-первых: управление учетными записями, группами пользователей и ролями. Затем изменение глобальных настроек JIRA; управление сценариями или схемами выполнения некоторых задач; средства для настройки и конструирования по своему вкусу "задач", из которых состоят проекты; функции экспорта и импорта информации и многое другое. Начнем мы с простого: разберемся с правами доступа. Политика безопасности JIRA оперирует тремя понятиями: пользователь, группа, роль. Пользователь — это человек, который может входить внутрь JIRA и выполнять какую-то работу. Для того, чтобы легче было назначить нескольким пользователям сходные права, мы объединяем их в группу, а затем привязываем права (роли) к этой группе (роль может быть назначена и непосредственно отдельной учетной записи). Для просмотра списка пользователей используйте меню Users, Groups & Roles -> User Browser (см. рис. 2). Так вы увидите табличку с перечнем пользователей, для каждого из которых указано его ФИО, адрес почты (этот адрес важен, т.к. мы можем настроить рассылку извещений разработчикам проекта, дабы никто из них не сказал "я не сделал работу, т.к. не знал, что мне нужно что-то делать…"). Если вам кажется, что ФИО и e-mail — не слишком большой объем информации о человеке, и вы хотите указать для пользователя его телефон, домашний адрес и т.д., то вам понравится Свойства (Properties). Так, если на закладке User Browser вы нажмете на ссылку с именем пользователя, то откроется окно профиля, где можно изменить имя, пароль, членство в группах, роли и назначить человеку произвольный список свойств. Каждое свойство — это пара вида "ключ и значение" — например, "phone = 12345" (см. рис. 1).

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

Для каждой учетной записи перечисляется список групп, в которые включен данный пользователь, и все, что было перечислено выше, мы можем изменить с помощью кнопок-ссылок Groups, Project Roles, Edit, Delete. Для добавления нового пользователя используйте меню ссылку Add User. Никаких сложностей в создании и редактировании пользователей нет, поэтому переходим к созданию группы. Для этого в главном меню JIRA выбираем пункт Users, Groups & Roles -> Group Browser и видим табличку с перечнем групп (для каждой группы указывается, сколько пользователей вошло в ее состав, и можно просмотреть их поименно). По умолчанию есть три группы: jira-administrators, jira-developers и jira-users, но вы можете создать и собственную группу. Все создаваемые пользователи изначально попадают в группу jira-users. В группу jira-developers должны входить те пользователи, которые имеют право заниматься работой (брать на выполнение задачи проекта). Ожидаемо, что один пользователь может входить сразу в несколько групп. Также есть понятие автоматического членства, когда каждый создаваемый пользователь автоматически будет входить в состав некоторой группы. Теперь разберемся с правами доступа (ролями) — для этого переходим по меню Users, Groups & Roles -> Project Role Browser и видим привычную уже картинку с табличкой, в которой перечислены роли. Есть три предопределенные роли: administrators, developers, users, — которые назначены "почти одноименным" группам (список ролей также не является фиксированным, и вы можете создать собственную роль). И тут возникает вопрос: а что такое роли, и как они отображаются на конкретные действия, которые можно или нельзя выполнять в JIRA. Дело в том, что система безопасности JIRA вводит еще одно понятие — "разрешение" (Permission), и это те самые элементарные "кубики", из которых и складываются роли. Разрешения делятся на две категории: Глобальные и Проектные.

Глобальные привилегии разрешают работать с JIRA в целом (например, входить в систему), проектные же привязаны к конкретному проекту (например, просмотреть список задач, редактировать их). Глобальные Разрешения назначаются конкретным группам пользователей, а Проектные Разрешения можно назначить не только группам пользователей, но их Проектным Ролям, конкретным пользователям. Проектные Роли и группы схожи, и те, и другие являются средством привязать пользователя к Разрешениям. Вот только группы являются глобальными (Вася входит в группу программистов), а Проектные Роли специфичны для каждого из проектов (Вася в проекте "калькулятор" играет роль программиста, а в проекте "блокнот" играет роль "тестировщика"). Проектные Роли являются общими для всех проектов, и в Проектную Роль могут быть назначены пользователи и группы по умолчанию, так что, когда создается новый проект, то перечисленные люди/группы автоматически получат назначение (функции, которые они должны выполнять) в новом проекте. Но это еще не все: чтобы окончательно вас запутать, ввели понятие Permission Scheme. Предположим, что, если у вас есть команда разработчиков (с четкой структурой и разделением ролей), перед началом разработки проекта вы сгруппировали программистов в группы, назначили им роли. Когда проект был завершен, команда не была расформирована и в том же составе и с теми же функциональными обязанностями должна взяться за еще один проект. Так вот, для того, чтобы каждый раз заново не назначать участникам проекта их роли, мы можем создать одну Permission Schema (таблицу, в которой хранятся связи между пользователями-ролями-группами) и назначить ее новому проекту. Для примера вызовите меню Schemas -> Permission Schemas — там вы увидите таблицу с перечнем схем и того, к каким проектам они привязаны (пока список пуст). Нажав на ссылку Permissions, вы попадете на страницу с перечнем всевозможных действий, которые можно выполнить над проектом, для каждого действия указаны пользователи и группы и роли, которыми они наделены (см. рис. 3).

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