Jira — различия между версиями

Версия 18:49, 3 сентября 2008

Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это Issue Tracking system — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.

Система платная ($4800 в год), пробная версия у нас установлена: (http://morra.office.custis.ru:8080/jira2/).

Инсталляция более не работает.

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

Чем оперирует

Система выполняет учет типизированных запросов/задач с определённым набором полей. Можно описывать новые типы запросов (Custom Issues), помимо встроенных. Начальный набор типов запросов такой:

Группируются запросы/задания в первую очередь по «Проектам» (аналог «Продуктов» Bugzilla), затем по компонентам. Есть дополнительный уровень группировки — «Проекты» могут делится по «Категориям».

Атрибутика запроса/задания:

Стас Фомин: При вводе заданий мне не удалось заполнять поле с датой из календаря — (ошибка инсталляции?), только путем экспериментов, удалось выяснить, что надо забивать туда даты в формате «1-Апр-05» (формат этот настраивается глобально — «Date Picker Format»).

Эти атрибуты обязательно существуют в каждом запросе/задании, но есть понятие раскладки полей (Layout Schemes), и в этих раскладках некоторые поля можно делать обязательными или необязательными, прятать и т. п. Каждую раскладку можно связать индивидуально с типом запроса и/или проектом. Можно описывать дополнительные атрибуты (Custom fields), которые отдельны для каждого типа запроса, и также управлять их использованием через раскладки полей. Каждый запрос/задание имеет Статус, аналог состояния в Bugzilla (State).

Начальный набор состояний-статусов (его можно изменять) приведен ниже:

Набор результатов обработки запросов/заданий, или как они названы в русском интерфейсе — резолюций, — также аналогичен багзилльному. Этот набор тоже можно изменять. Начальный набор — следующий:

Схема жизненного цикла (workflow)

В отличие от багзильного, схему обработки запросов (workflow scheme) можно настраивать, т. е. создавать альтернативные графы перехода состояний (+можно заводить дополнительные состояния), и заставлять задания в проектах подчиняться этой схеме. Новый схемы обработки привязываются к проектам и к типам запросов для отдельных проектов.

Пользователи

Учетные записи пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы, то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление приложенных файлов и создание комментариев для менеджеров из других проектов).

Безопасность

Умеет создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.

Оповещение

Как узнают пользователи о том, что их сообщение было отредактировано, или о том, что им адресовано новое сообщение. По аналогии со «схемами безопасности» каждому проекту может быть создана «схема оповещения», в которой указывается на какое событие как должна реагировать система оповещения, которая рассылает почтовые сообщения. В отличие от Bugzilla, где схема оповещения («email settings») — настраивается каждым пользователем для себя индивидуально, здесь схемы оповещения глобальные.

Атрибута «CC:» здесь нет, но каждый пользователь вправе подписаться на оповещения по любому делу, либо вписать кого-то еще. Правда, я (Стас Фомин), не нашел, как узнать, кто еще подписан на данное задание.

Плюсы и минусы относительно Bugzilla

Плюсы

• Возможность заведения своих workflow-схем. Это можно реализовать в bugzilla (поменяв один файл шаблонов), но эти изменения надо будет уже аккуратно синхронизировать с следующими версиями.
• Настройка видимости полей и дополнительные атрибуты, т. е. по сути настройка атрибутики дела — в Bugzille это решаемо только изменением кода.
• Всякие красивости (много иллюстрирующих иконок, заготовки для просмотра статистки по отфильтрованым багам и т. д.).
• Есть русифицированный интерфейс
• Комментарии по заданиям можно делить по типу — комментарий или worklog, и регулировать уровень видимости по каждому комментарию.
• Зависимости между заданиями можно делать разных типов.
• Есть также иерархия подзаданий, т. е. под каждым заданием, можно создать дерево из ПодЗаданий (SubTask).
• Есть гибкая настройка схем оповещения: схема определяет, кто получает оповещения на каждое из имеющихся событий, задавая пользователя, группу, или метаадреса (как например: текущий исполнитель, руководитель проекта и т.д). Кроме того, можно оформлять подписки на результат определенного фильтра (аналог поискового запроса в Bugzilla).
• Возможно задание произвольного количества типов связей между запросами/заданиями. Зависимости и дублирование — лишь частные случаи (типы) связей.
• Возможна интеграция с CVS. При ведение комментариев на commit определенным образом (теги) — возможен просмотр от запроса (аналога бага) списка файлов в cvs, измененных для его выполнения.

Минусы

• Нет отображения графов зависимостей в виде диаграммы: зависимости отображаются в виде списка с отступами.
• Нет ключевых слов и соответствующей функциональности, но это легко добавляется пользовательским полем.
• Нет флагов и соответствующей функциональности.
• Убогий интерфейс (POST-запрос при открытии формы создания бага, куча никому не нужных pop-ups, длинная простыня атрибутов для поиска на пустом экране).

Аргументы за переход на JIRA

GeorgeShamanov 17:12, 21 Apr 2005 (MSD) Данный раздел отражает личную позицию. Позиция заключается в необходимости перехода на JIRA (разработки регламента и его внедрения для нового инструмента).

Основными аргументами являются:

1. Внедрение регламента (изменение привычной схемы работы) является встряской для рядовых сотрудников сама по себе.

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

2. Общий аргумент: инструмент предназначен для поддержки организации работ в определенной области. На мой (GeorgeShamanov 17:12, 21 Apr 2005 (MSD)) взгляд Bugzilla предназначена для поддержки служб сопровождения и тестирования, тогда как JIRA для полноценного управления задачами.

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

В этом плане JIRA имеет следующие преимущества перед Bugzilla:

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

4. Попытки реализации идей, заложенных в JIRA, с помощью Bugzill'a приведут к увеличению нагрузки на исполнителей и контролеров регламентов.

Например, подписка в CC всех заинтересованных требует работы от reporter'а бага, тогда как в JIRA такой список формируется один раз, исходя из зон ответственности проекта.

А идеи заложенные в JIRA, как в более близком к предметной области инструменте, начнут использоваться при формировании регламентов обязательно.

5. JIRA предоставляет возможность контролируемой расширяемости.

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

Основные недостатки JIRA, несомненно, будут выявлены только в ходе работы на ней, поэтому на данный момент основными аргументами против перехода могут являться (на мой взгляд):

1. Не готовность группы стандарта и компании к внедрению в столь сложного инструмента области управления issue tracking'ом (за неимением русского аналога вынужден употреблять данный термин).

Хотелось бы уточнить, что накладные расходы на аудит и внедрение полноценных (а иначе и не может быть — идеи из JIRA уже известны) регламента в компании на слабо приспособленном инструменте.

2. Сложность и множественность классификаций в инструменте

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

3. Невозможность закрыть все потоки сразу при начале работ и расползание бардака в новом инструменте.

Возможности администрирования Bugzilla несомненно ниже и бардак при использовании одинаковых идей будет больше.

4. Снижение скорости создания и внедрения в рамках компании нового регламента.

Скорость этой работы несомненно замедлится. Выигрыш виден в некой временной перспективе. Поскольку в начале разработка регламента типа Bugzilla, затем переход, затем разработка регламента на JIRA (или чем-нибудь еще) и опять переход. Накладные расходы возрастают несомненно.

Извините за неконкретность оценки времени (некой временной перспективе), однако прогноз на временной интервал устаревания Bugzilla сделать на данном этапе невозможно. Под устареванием понимается момент, при котором суммарная поддержка сложных регламентов станет отнимать более 2 человеко-норм в месяц.