Сравнение TrackStudio Enterprise 5.0 и Redmine 3.2

Redmine - это одна из наиболее популярных, современных и продвинутых open source систем управления задачами. По нашему мнению, возможности Redmine значительно превосходят возможности таких систем, как Bugzilla, Mantis, Trac. Redmine поддерживает иерархию проектов и задач, позволяет управлять правами доступа к проектам и поддерживает настраиваемые процессы (workflow).

Однако Redmine принципиально не отличается от JIRA и других open source систем управления задачами, а значит его архитектура не позволяет решить многие их тех проблем, которые были описаны в Jira's Top 50 issues и нашем сравнении с JIRA. Наиболее существенные проблемы Redmine связаны с хранением файлов, документов, правами пользователей и обработкой workflow.

• В Redmine возможности работы с файлами и документами очень ограничены. В TrackStudio файлы и документы можно организовывать в дерево, как главы в книге или файлы на диске. Можно дать пользователю доступ только к каким-то конкретным документам или отфильтровать список документов по автору. Можно настроить оповещение по e-mail при изменении документа или автоматически создавать документы при необходимости поместить информацию в базу знаний. При просмотре документа TrackStudio автоматически сформирует оглавление с ссылками на вложенные документы.
• В Redmine можно управлять правами доступа на уровне проектов, но нельзя назначить права на какую-то версию проекта или отдельную задачу. Это значит, что если пользователю нужен доступ всего к одной задаче, то придется давать доступ ко всему проекту. В TrackStudio можно легко настроить права доступа для каждой задачи и каждый сотрудник или клиент будет видеть только то, что ему нужно.
• Если пользователь Redmine получил доступ к проекту, то нельзя ограничить его активность какими-то отдельными типами задач (трекерами). Например, нельзя разрешить просматривать только "свои" задачи (это часто бывает нужно для организации техподдержки) или разрешить создавать задачи только какого-то определенного типа. В TrackStudio права пользователя могут быть заданы для каждого типа задачи.
• В Redmine нет прав на отдельные типы переходов в workflow, у них даже названий нет. Например, вы не можете указать, что когда кто-то заканчивает исправлять ошибку, он должен выбрать ответственным тестировщика и должен указать номер билда. Также вы не можете скрыть внутреннюю переписку между программистами от клиента. В TrackStudio можно указать детальные права пользователей для каждой операции (изменения состояния задачи).
• В Redmine роль администратора является глобальной, вы не можете делегировать управление отдельным проектом кому-то еще, не открывая доступ ко всей системе. Это значительно затрудняет использование одного экземпляра системы для интеграции различиных отделов и видов деятельности. В JIRA соответствующая задача также весьма популярна и уже набрала более 1000 голосов. В TrackStudio поддерживаются локальные администраторы (и вообще пользователи с любой ролью) для отдельных проектов или задач - эти пользователи обладают всеми правами администратора, но только для "своих" проектов и пользователей. Это особенно важно, если системой пользуются в нескольких отделах организации, при этом руководству нужен доступ к статистике не только по отделам, но и в целом по организации. Так же эта возможность часто используется, если у компании есть несколько крупных клиентов, которыми занимаются различные сотрудники.
• В Redmine приоритеты и состояния задачи являются глобальными для всех workflow и проектов. На данный момент аналогичная проблема в JIRA (там она тоже есть) занимает первое место в top 50. Она набрала наибольшее количество голосов (около 2000), но была отложена на неопределенное время после 8 лет ожидания, а в 2016 году была реализована плагином. В то же время настройка приоритетов и состояний для каждого workflow была реализована в первой версии TrackStudio много лет назад.

Интересной особенностью Redmine является возможность создавать иерархию задач неограниченной глубины вложенности, этого нет ни в других популярных open source багтрекерах, ни в JIRA. Если проанализировать (например, на основе этой страницы) комментарии пользователей, то видим следующие варианты использования этой возможности:

• использование продукта для управления проектами или для интеграции с MS Project. В продукте в данном случае хранится не иерархия задач для программистов, а иерархия целей (результатов) проекта.
• использование продукта для управления требованиями. В этом случае мы группируем требования в дерево, на основе которого потом генерируется техническое задание.
• использование для управления тестированием. В этом случае верхний уровень - это test suite, нижний - test case.
• использования для взаимодействия с пользователями. В задаче верхнего уровня пользователь описывает проблему, а для исправления проблемы создаются подзадачи исполнителям ("исправить код", "написать документацию", "подготовить перевод", "обновить сайт").
• использование для управления документами. Иерархия позволяет удобно организовывать документы в разделы и главы.
• использование системы для решения бизнес-задач. В этом случае элементами дерева могут быть производимые компанией изделия, подразделения компании, клиенты или принадлежащее компании имущество.

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

Кроме того, практически во всех этих случаях нам нужна иерархия не однотипных, а разнородных задач. В багтрекинге мы имеем проекты, сообщения об ошибках, компоненты, версии. В управлении тестированием это test case и test suite. Для бизнес-задач это могут быть подразделения, товары, клиенты.

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

В TrackStudio эти возможности есть, а вот в Redmine - нет. Ряд "генетических" особенностей Redmine указывают, что и в дальнейшем указанные возможности вряд ли получится добавить в систему:

• В Redmine есть разделение на проекты, задачи, документы и файлы. Это подходит для багтрекинга, но для для использования системы в других областях необходимо перейти к единому объекту - "задача", поведение которого настраивается пользователем. В чем смысл "проекта", если внутри задачи можно создавать подзадачи, их можно удобно искать, на них можно назначать права ? На данный момент в Redmine делают 2 параллельных иерархии - иерархию проектов и иерархию issues, а для файлов и документов иерархия вообще не поддерживается.
• В Redmine права настраиваются для проектов, но в данном случае нужна возможность настраивать права для любой задачи. Поддержка подобной системы прав в сочетании с иерархией задач приводят к многократному росту нагрузки на SQL-сервер (ведь права приходится проверять для каждой выводимой задачи и даже для каждого поля) и означают полное переосмысливание (и переписывание) ядра системы. Но пользовательские плагины "цементируют" систему и делают подобные изменения крайне дорогими для пользователей.

Можно выделить ряд других проблем в Redmine (сложности при управлении задачами с большим количеством подзадач, переносом задач между проектами, поиском по истории изменения задачи, настройкой шаблонов оповещения по e-mail и т.п.), но эти проблемы относительно легко исправить и скорее всего соответствующая функциональность появится в Redmine в течение ближайших нескольких лет - время тут лучший доктор. А вот проблемы с правами доступа и с поддержкой иерархии являются следствием неудачной архитектуры системы, бороться с такими проблемами после выхода первой публичной версии уже очень сложно. Думаем, что Redmine может стать отличным выбором для небольших команд, но для больших проектов без коммерческих систем управления задачами будет обойтись довольно сложно.