Сравнение TrackStudio Enterprise 5.0 и Atlassian JIRA 6.1

TrackStudio - это не только управление задачами.

Прежде всего, TrackStudio позволяет управлять не только задачами, но и файлами, документами. Например, в TrackStudio файлы и документы можно организовывать в дерево, как главы в книге или файлы на диске. Можно дать пользователю доступ только к каким-то конкретным документам или отфильтровать список документов по автору. Можно настроить оповещение по e-mail при изменении документа или автоматически создавать документы при необходимости поместить информацию в базу знаний. При просмотре документа TrackStudio автоматически сформирует оглавление с ссылками на вложенные документы.

В то же время Atlassian JIRA не позволяет управлять документами и файлами, для этих целей нужно использовать Confluence. TrackStudio предлагает интегрированное решение, что позволяет упростить инсталляцию и избавляет от необходимости синхронизировать системы.

Т.к. JIRA не предназначена для управления документами и файлами, то дальнейшее сравнение относится только к использованию Atlassian JIRA и TrackStudio Enterprise с точки зрения управления задачами.

"Большие" и "маленькие" системы управления задачами.

Развитие систем управления задачами последние 10-20 лет происходило в двух противоположных направлениях. С одной стороны, "маленькие" open source системы постоянно усложнялись и улучшались. Успех open source систем породил коммерческие продукты, которые были основаны на той же архитектуре, но имели гораздо более развитую функциональность. Одновременно в лагере "больших" систем изменения шли в противоположном направлении - изначально сложные и дорогие системы сохраняли свои архитектурные особенности, но становились проще и дешевле.

Пересечения функциональности "маленьких" и "больших" систем до сих пор не произошло. Продукты (в том числе коммерческие) на базе open source систем так и не смогли реализовать базовый функции "больших" систем, а "большие" системы стали похожи на "маленькие" лишь с точки зрения пользователя, но не администратора.

Рассмотрим особенности "больших" и "маленьких" систем на конкретном примере. В качестве примера "маленькой" системы возьмем Atlassian JIRA. Почему именно JIRA ? Дело в том, что JIRA создавалась как замена Bugzilla, повторяет архитектурные особенности open source систем (Bugzilla, Mantis, Trac, Redmine), но значительно превосходит другие "маленькие" системы. Если какая-то функциональность нужна пользователям JIRA и не реализована там, то скорее всего на это есть серьезные архитектурные причины, в других "маленьких" системах этой функциональности тоже не будет. В качестве примера "большой" возьмем TrackStudio, ведь нашей целью было сделать легкую, недорогую и удобную замену типичной "большой" системы - IBM Rational ClearQuest.

Изначально "большие" и "маленькие" системы создавались в разных условиях и для разных задач. Большие системы предназначались для управления задачами в коммерческих организациях. Для этих условий характерны большое количество проектов, задач, множество разных процессов, ограничение доступа к информации. Фактически, "большие" системы были ориентированы на обработку задач внутри организации и не были предназначены для общения с внешними пользователями.

С другой стороны, open source системы создавались как раз для общения с пользователями в open source проектах. В таких проектах огромное количество внешних пользователей сочетается с простотой внутренних процессов. Команда разработчиков, как правило, плоская и однородная, все задачи открыты всем, внутренние процессы простые, а один экземпляр трекера часто используется лишь для одного проекта. Архитектура "маленьких" систем изначально создавалась для работы в именно таких условиях, но для коммерческих организаций такие условия не характерны, при использовании даже очень мощных "маленьких" систем там возникает ряд типичных трудноразрешимых проблем.

В качестве основы для нашего анализа возьмем список построим список из 50 наиболее популярных (по количеству голосов), но все еще нерешенных проблем в JIRA: https://jira.atlassian.com/browse/JRA#selectedTab=com.atlassian.jira.plu...

В этом списке можно выделить следующие группы однотипных проблем:

  • Если стандартная иерархия типов задач не устраивает, то изменить ее или создать свою иерархию нельзя. Например, для управления требованиями (requirements management) необходима возможность создать иерархии требований неограниченной глубины. Для управления активами (asset management) необходима иерархия здание-комната-оборудование. Подобные ситуации очень часто встречаются на практике, но реализовать их на основе модели проект-версия-задача нельзя. В JIRA top 50 по этому поводу созданы следующие задачи: JRA-4446 (нужна поддержка иерархий для задач), JRA-846 (нужна поддержка иерархий для компонентов), JRA-12241 (поддержка групп проектов и подпроектов), JRA-5225 (доступность компонентов и версий в подзадачах), JRA-568 (нужны билды внутри версий), JRA-3501 (нужны версии компонентов), JRA-6398 (нужно наследование свойств в подзадачах), JRA-6896 (нужно создание подзадач через SOAP), JRA-5721 (нужны вложенные категории), JRA-1072 (нужны общие подпроекты), JRA-2698 (нужны версии для нескольких проектов), JRA-8663 (нужны общие компоненты).
  • Многие настройки системы глобальные и их нельзя изменить для конкретной группы проектов, проекта, задачи. Это приводит к необходимости устанавливать отдельный экземпляр системы для каждой группы проектов или пользователей, что значительно усложняет администрирование и использование системы (например, быстро собрать "свои" задачи из нескольких трекеров нельзя). Из top 50 к этой категории относятся следующие проблемы: JRA-3821 (приоритеты, состояния, резолюции должны быть изолированы для разных проектов), JRA-3156 (нужен подчиненный администратор для проекта), JRA-6381 (права указываем для каждого состояния), JRA-9997 (нужно учитывать подчиненность пользователей при редактировании объектов), JRA-2364 (нужен доступ к полям для разных групп пользователей), JRA-5865 (нужна настройка прав для каждого типа задач), JRA-161 (нужны разные шаблоны оповещения для разных проектов).
  • Многие возможности реализованы лишь для каких-то конкретных типов задач. В top 50 попали задачи JRA-1991 (кастом-поля есть для задач, но нужны для проектов) и JRA-2764 (есть права для проектов, нужны для отдельных задач).

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

Причиной всех этих проблем является общая архитектурная особенность "маленьких" систем - в них типы задач и связи между ними жестко заданы на этапе разработки. Т.е. программисты еще при разработке системы указывают, что проекты будут храниться в одной табличке, версии - в другой, а сообщения об ошибках - в третьей. Для каждой таблицы пишется отдельный интерфейс для просмотра, создания и редактирования записей. Это позволяет быстро реализовать базовый функционал трекера, но когда клиентам потребуются кастом-поля для проектов, версий и задач, то придется реализовывать их трижды. Фактически, любую из вышеперечисленных проблем можно решить, но попытка решить "в лоб" все вышеперечисленные задачи приведет к увеличению объема кода и сложности интерфейса в разы. В то же время в "больших" системах (и в TrackStudio тоже) эти и многие другие проблемы решаются автоматически, отсутствие этих недостатков в TrackStudio - просто следствие другой архитектуры системы.

Почему же при всех недостатках "маленькие" системы столь популярны сейчас? Причин несколько:

  • Вышеперечисленные проблемы "маленьких" систем не видны при формальном сравнении систем и не проявляются при тестировании системы на 1-2 проектах. Проблемы становятся очевидны при увеличении количества проектов, либо когда возникает необходимость изменить конфигурацию одного проекта, не трогая остальные проекты. Обычно к этому времени система управления задачами уже настолько тесно интегрирована с другими системами в компании, что возможный "переезд" становится слишком дорогим.
  • Из-за высокой цены "большие" системы раньше использовались лишь в крупных компаниях, а значит опыт их администрирования есть лишь у небольшого количества пользователей (хотя пиратство сделало эту проблему менее актуальной для России). У большинства пользователей есть опыт работы с "маленькими" системами, но архитектура "больших" систем отличается, интуиция подсказывает неверные решения, а система производит впечатление "не интуитивной". Примечательно, что проблема не решается упрощением интерфейса: в этом случае возникает даже больше похожих ситуаций и интуиция чаще подсказывает неверные решения. Скрыть за интерфейсом другую архитектуру системы можно от пользователя, но не от администратора.
  • Маленькую систему можно запустить на LAMP-хостинге, большие системы написаны обычно на Java/C++ и требуют выделенного или виртуального сервера. Для многих open source проектов этот критерий является решающим.

Единственный способ решения всех вышеописанных проблем - превращение JIRA в иерархическую систему управления задачами. Но сделать это сейчас невозможно, т.к. иерархия должна лежать в основе архитектуры системы, ее нельзя доделать потом. Большинство вышеперечисленных проблем стали нерешаемым в рамках JIRA уже в 2003-2004 годах, дальнейшее накапливание голосов вряд ли способно изменить ситуацию.

В Atlassian хорошо понимают это, еще в 2003 году Jeff Turner, один из разработчиков JIRA, писал:
There are many cases where it would be useful to have issue-level concepts (type, lifecycle, priority, due date, scheduling, custom fields) apply to projects, and project-level concepts (permissions, notifications, URLs) apply to issues. Effectively treating projects as aggregate issues. [...]
In general, JIRA needs to keep a balance between simplicity for 80% who don't need advanced features, and generality for the 20% who do. Giving users the source (or just JSP source, as illustrated above) lets us err on the side of simplicity.

В TrackStudio все вышеперечисленные проблемы "маленьких" систем решены за счет того, что проекты, версии, компоненты, ошибки, требования являются всего лишь разными конфигурациями одной сущности - задачи. Вы сами можете определить свои категории задач, возможные состояния задачи и правила перехода между ними, детально задать права для пользователей. Кроме того, практически все элементы конфигурации в TrackStudio не являются глобальными, а привязаны к конкретной задаче и доступны только для подзадач. Например, для создания глобального фильтра его нужно создать в корневой задаче, а для создания фильтра для проекта - создать в этом проекте. Эти архитектурные особенности позволяют настроить и использовать TrackStudio для управления самыми разными процессами, даже не связанными с IT. Процесс конфигурирования TrackStudio документирован и выполняется мышкой из web-интерфейса, уметь программировать не требуется.

Стоимость и условия поставки

Ценовая политика разработчиков TrackStudio и JIRA отличается, для некоторых вариантов использования разница в стоимости будет минимальна, для других может отличаться в десятки раз. Хотя Atlassian JIRA значительно дешевле TrackStudio для команд в 6-10 пользователей, для компаний с большим количеством серверов, пользователей ценовое преимущество TrackStudio может быть до 40 раз и даже больше. Такая разница вызвана следующими особенностями лицензирования продуктов:

  • Стоимость Atlassian JIRA быстро растет при увеличении количества пользователей, в то время как для TrackStudio неограниченная лицензия доступна уже за 45 950 рублей. Это дает большое ценовое преимущество TrackStudio для крупных компаний и для компаний с большим количеством внешних клиентов.
  • На каждый сервер Atlassian JIRA нужно покупать отдельную лицензию, в то время как для TrackStudio доступна лицензия на неограниченное количество серверов и пользователей за 114 950 рублей. Это дает большое ценовое преимущество TrackStudio при использовании нескольких серверов.
  • Поддержку и обновления для Atlassian JIRA необходимо покупать для каждого сервера, в то время как для TrackStudio доступна лицензия Global, где продление лицензии не зависит от количества пользователей и серверов. Это дает большое ценовое преимущество TrackStudio при использовании трекера в течение нескольких лет.

Выводы

Преимущества TrackStudio особенно заметны в следующих ситуациях:

  • Системой будут пользоваться разные команды внутри компании. Создайте внутри одной системы несколько независимых проектов со своими командами (отделами) и своими администраторами. Использование единой системы позволяет значительно упростить администрирование, делегировать полномочия, улучшить интеграцию. Кроме того, вы значительно экономите на стоимости лицензий.
  • Система будет использоваться как для организации работы внутри компании, так и для общения с клиентами. Atlassian использует JIRA только для общения с внешними пользователями ([1], [2]), но не для управления разработкой программного обеспечения. Более гибкие правила доступа и возможность блокировать клиентам доступ к отдельным полям задачи (затраты времени, приоритет, бюджет и т.п.) делают TrackStudio лучшим выбором и в этом случае.
    7 сентября 2007. Charles Miller из Atlassian сказал, что это "patently untrue". Прочитайте статьи по ссылкам выше целиком и решите для себя сами. Наш ответ и комментарии к нему можно прочитать тут.
  • У компании есть несколько крупных клиентов, и вы хотите интегрировать свои процессы с процессами клиентов.Возможность независимой настройки системы для каждого клиента позволит добиться лучшей интеграции с каждым из них. Вы сможете использовать единую систему для работы со всеми клиентами, а клиенты не будут даже подозревать о наличии чужих проектов в системе.
  • Ваша компания ведет большое количество проектов. TrackStudio позволяет эффективно управлять тысячами проектов: проекты можно организовывать в иерархию, можно делать поиск проектов по параметрам, к проектам можно прикладывать файлы (например, с техническим заданием), для проектов можно создавать пользовательские поля (дата релиза, клиент, номер договора) и многое другое.
  • Вы хотите автоматизировать периодически меняющийся процесс или сложный процесс, состоящий из большого количества состояний. Перед выполнением задачи ее должны утвердить несколько менеджеров? Требуется возможность параллельного утверждения? Хотите включить в процесс подготовку документации, отправку счетов, или техническую поддержку пользователей? TrackStudio поможет вам автоматизировать сложный и изменчивый процесс максимально эффективно.
  • Вы планируете использовать систему для управления проектами разработки программного обеспечения. TrackStudio поддерживает иерархию задач (WBS), ключевой элемент систем управления проектами. Подробнее об использовании TrackStudio для управления проектами
  • Вы хотите интегрировать разные службы (bug tracking, help desk, knowledge base, asset management, requirements management,...) внутри одной системы. Использование одного продукта значительно упростит интеграцию всех отделов компании: вам не нужно будет создавать учетные записи сотрудников, проекты, настраивать правила доступа и оповещения по e-mail в каждой системе. Перенос задач из help desk в bug tracking, из bug tracking в knowledge base станет значительно проще.
  • Вы используете почасовую оплату при расчетах с работниками или клиентами. В TrackStudio вы можете учитывать затраты времени не только по проектам и людям, но и по операциям. Например, можно узнать, сколько времени было потрачено на исправление высокоприоритетных ошибок, а сколько - на тестирование. Можно указать, кто из разработчиков может вводить затраты времени и могут ли клиенты смотреть затраты времени разработчиков. Можно задать любые ограничения на комментарий, который поясняет что было сделано (например, программисты должны описать не менее 20 символов комментария на каждый час работы, а менеджеры - не менее 30). Подробнее о возможности использования TrackStudio для учета рабочего времени.
  • Вам нужно интегрировать систему управления задачами с внутренним программным обеспечением. Мощные возможности оповещения по e-mail, импорта e-mail, импорта из CSV файлов и полный SOAP API делают TrackStudio лучшим выбором, если вас интересует интеграция с другими продуктами.
  • Вы ищите замену пиратской копии "большой" коммерческой системы управления задачами. Если вам нужна функциональность Rational ClearQuest или Serena TeamTrack, но вы не готовы платить $1000 (и более) за одного пользователя — TrackStudio будет отличным выбором. TrackStudio не только не уступает этим системам, но и в ряде областей превосходит их.
  • Ваша компания находится в одной из стран СНГ. У TrackStudio никогда не было проблем с кириллицей и другими национальными кодировками. TrackStudio Enterprise изначально разрабатывается на русском языке и имеет нормальную русскую локализацию. В России и в странах СНГ мы можем оформить покупку согласно всем требованиям бухучета. Скорее всего, мы находимся в близких часовых поясах, поэтому мы часто можем дать ответ на ваш вопрос в течение нескольких часов.Нам можно позвонить и рассказать о проблеме. Мы можем показать решение. Мы говорим с вами на одном языке!