|
|
| (не показаны 4 промежуточные версии 3 участников) |
| Строка 1: |
Строка 1: |
| − | Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это Issue Tracking system — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.
| + | #REDIRECT [[JIRA]] |
| − | | + | |
| − | | + | |
| − | | + | |
| − | == Чем оперирует ==
| + | |
| − | | + | |
| − | Система выполняет учет типизированных запросов/задач с определённым набором полей. Можно описывать новые типы запросов (Custom Issues), помимо встроенных. Начальный набор типов запросов такой:
| + | |
| − | | + | |
| − | {| border=1
| + | |
| − | !Bug
| + | |
| − | |Проблема мешающая функционированию продукта
| + | |
| − | |-
| + | |
| − | !Improvement
| + | |
| − | |Улучшение — не новый функционал, а улучшение старого
| + | |
| − | |-
| + | |
| − | !New Feature
| + | |
| − | |Заказ на новый функционал продукта
| + | |
| − | |-
| + | |
| − | !Task
| + | |
| − | |Задание (дело, задача) которое должно быть выполнено
| + | |
| − | |}
| + | |
| − | | + | |
| − | Группируются запросы/задания в первую очередь по «Проектам» (аналог «Продуктов» Bugzilla), затем по компонентам. Есть дополнительный уровень группировки — «Проекты» могут делится по «Категориям».
| + | |
| − | | + | |
| − | Атрибутика запроса/задания:
| + | |
| − | {| border=1
| + | |
| − | !Информация
| + | |
| − | |Аналог «Bugzilla» «Summary»
| + | |
| − | |-
| + | |
| − | !Тип запроса
| + | |
| − | |Bug,New Feature,Task,Improvement
| + | |
| − | |-
| + | |
| − | !Уровень доступа
| + | |
| − | |-
| + | |
| − | !Приоритет
| + | |
| − | |Аналог «Bugzilla» «Severity» (Blocker,Critical,Major,Minor,Trivial)
| + | |
| − | |-
| + | |
| − | !Срок исполнения
| + | |
| − | |Аналог «Bugzilla» «Deadline»
| + | |
| − | |-
| + | |
| − | !Компоненты
| + | |
| − | |В отличие от «Bugzilla», здесь задание может относится сразу к нескольким компонентам
| + | |
| − | |-
| + | |
| − | !Версии, в которых найдена проблема
| + | |
| − | |Аналог «Bugzilla» «version»
| + | |
| − | |-
| + | |
| − | !Закрыт в версии(-ях)
| + | |
| − | |Аналог «Bugzilla» «Target milestones»
| + | |
| − | |-
| + | |
| − | !Назначен
| + | |
| − | |Аналог «Assignee»
| + | |
| − | |-
| + | |
| − | !Автор
| + | |
| − | |Аналог «Reporter»
| + | |
| − | |-
| + | |
| − | !Окружение
| + | |
| − | |Аналог «Bugzilla» «OS»+"Platforms", но ненормализованное описание — чистый текст
| + | |
| − | |-
| + | |
| − | !Отслеживание сроков
| + | |
| − | |Аналог «Bugzilla» «Time estimated»
| + | |
| − | |-
| + | |
| − | !Вложение
| + | |
| − | |Аналог «Bugzilla» «Attachements»
| + | |
| − | |}
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | Эти атрибуты обязательно существуют в каждом запросе/задании, но есть понятие раскладки полей (Layout Schemes), и в этих раскладках некоторые поля можно делать обязательными или необязательными, прятать и т. п. Каждую раскладку можно связать индивидуально с типом запроса и/или проектом. Можно описывать дополнительные атрибуты (Custom fields), которые отдельны для каждого типа запроса, и также управлять их использованием через раскладки полей. Каждый запрос/задание имеет Статус, аналог состояния в Bugzilla (State).
| + | |
| − | | + | |
| − | Начальный набор состояний-статусов (его можно изменять) приведен ниже:
| + | |
| − |
| + | |
| − | {| border=1
| + | |
| − | |Open
| + | |
| − | |аналог «NEW»
| + | |
| − | |-
| + | |
| − | |In Progress
| + | |
| − | |аналог «ASSIGNED»
| + | |
| − | |-
| + | |
| − | |Resolved
| + | |
| − | |аналог «Resolved»
| + | |
| − | |-
| + | |
| − | |Reopened
| + | |
| − | |аналог «Reopened»
| + | |
| − | |-
| + | |
| − | |Closed
| + | |
| − | |аналог «Closed»
| + | |
| − | |}
| + | |
| − | | + | |
| − | Набор результатов обработки запросов/заданий, или как они названы в русском интерфейсе — резолюций, — также аналогичен багзилльному. Этот набор тоже можно изменять. Начальный набор — следующий:
| + | |
| − | | + | |
| − | {|
| + | |
| − | |Fixed:
| + | |
| − | |-
| + | |
| − | |Won't Fix:
| + | |
| − | |-
| + | |
| − | |Duplicate:
| + | |
| − | |-
| + | |
| − | |Incomplete:
| + | |
| − | |Недостаточно информации
| + | |
| − | |-
| + | |
| − | |Cannot Reproduce:
| + | |
| − | |«Works for me»
| + | |
| − | |}
| + | |
| − | | + | |
| − | == Схема жизненного цикла (workflow) ==
| + | |
| − | | + | |
| − | В отличие от багзильного, схему обработки запросов (workflow scheme) можно настраивать, т. е. создавать альтернативные графы перехода состояний (+можно заводить дополнительные состояния), и заставлять задания в проектах подчиняться этой схеме. Новый схемы обработки привязываются к проектам и к типам запросов для отдельных проектов.
| + | |
| − | | + | |
| − | == Пользователи ==
| + | |
| − | | + | |
| − | Учетные записи пользователей управляются как администратором, так и самим пользователем. Пользователи могут быть объединены в группы, то есть совершенно привычная структура. При чём как отдельному пользователю так и группе можно запретить/разрешить одно вполне конкретное действие (к примеру такая экзотика, как запрет на удаление приложенных файлов и создание комментариев для менеджеров из других проектов).
| + | |
| − | | + | |
| − | == Безопасность ==
| + | |
| − | Умеет создавать и вести «схемы безопасности» для каждого из проектов. То есть можем создать группу пользователей на конкретный проект, раздать на этот же проект права, или использовать стандартную схему безопасности на этот проект.
| + | |
| − | | + | |
| − | == Оповещение ==
| + | |
| − | | + | |
| − | Как узнают пользователи о том, что их сообщение было отредактировано, или о том, что им адресовано новое сообщение. По аналогии со «схемами безопасности» каждому проекту может быть создана «схема оповещения», в которой указывается на какое событие как должна реагировать система оповещения, которая рассылает почтовые сообщения.
| + | |
| − | В отличие от [[Bugzilla]], где схема оповещения («email settings») — настраивается каждым пользователем для себя индивидуально, здесь схемы оповещения глобальные.
| + | |
| − | | + | |
| − | Атрибута «CC:» здесь нет, но каждый пользователь вправе подписаться на оповещения по любому делу, либо вписать кого-то еще. Правда, я ([[Участник:StasFomin|Стас Фомин]]), не нашел, как узнать, кто еще подписан на данное задание.
| + | |
| − | | + | |
| − | == Плюсы и минусы относительно Bugzilla ==
| + | |
| − | | + | |
| − | === Плюсы ===
| + | |
| − | | + | |
| − | * Возможность заведения своих workflow-схем. Это можно реализовать в bugzilla (поменяв один файл шаблонов), но эти изменения надо будет уже аккуратно синхронизировать с следующими версиями.
| + | |
| − | * Настройка видимости полей и дополнительные атрибуты, т. е. по сути настройка атрибутики дела — в Bugzille это решаемо только изменением кода.
| + | |
| − | * Всякие красивости (много иллюстрирующих иконок, заготовки для просмотра статистки по отфильтрованым багам и т. д.).
| + | |
| − | * Есть русифицированный интерфейс
| + | |
| − | * Комментарии по заданиям можно делить по типу — комментарий или worklog, и регулировать уровень видимости по каждому комментарию.
| + | |
| − | * Зависимости между заданиями можно делать разных типов.
| + | |
| − | * Есть также иерархия подзаданий, т. е. под каждым заданием, можно создать дерево из ПодЗаданий (SubTask).
| + | |
| − | * Есть гибкая настройка схем оповещения: схема определяет, кто получает оповещения на каждое из имеющихся событий, задавая пользователя, группу, или метаадреса (как например: текущий исполнитель, руководитель проекта и т.д). Кроме того, можно оформлять подписки на результат определенного фильтра (аналог поискового запроса в Bugzilla).
| + | |
| − | * Возможно задание произвольного количества типов связей между запросами/заданиями. Зависимости и дублирование — лишь частные случаи (типы) связей.
| + | |
| − | * Возможна интеграция с CVS. При ведение комментариев на commit определенным образом (теги) — возможен просмотр от запроса (аналога бага) списка файлов в cvs, измененных для его выполнения.
| + | |
| − | | + | |
| − | === Минусы ===
| + | |
| − | | + | |
| − | * Нет отображения графов зависимостей в виде диаграммы: зависимости отображаются в виде списка с отступами.
| + | |
| − | * Нет ключевых слов и соответствующей функциональности, но это легко добавляется пользовательским полем.
| + | |
| − | * Нет флагов и соответствующей функциональности.
| + | |
| − | * Уебищный интерфейс (POST-запрос при открытии формы создания бага, куча никому не нужных pop-ups, длинная простыня атрибутов для поиска на пустом экране)
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | [[Category:Программирование]]
| + | |
| − | {{replicate-from-custiswiki-to-lib}}
| + | |
