Support Forum

[angestar]

Добрый день!

Стоит задача выбора системы управления проектами и заявками заказчиков в одном флаконе. Т.е. PM tool + issue tracking system.

Краткое описание ситуации в компании:

Есть порядка 10 постоянно разрабатываемых информационных систем на Java. Большая часть из них внедрена, внедряется или будет внедряться одновременно у нескольких заказчиков. Т.е. системы в итоге одинаковые, но для разных заказчиков сконфигурированы по-разному, ну и управлять проектами надо и в разрезе модулей соответствующих систем (видеть все задачи всех заказчиков), и в разрезе заказчиков (чтобы каждый видел только свои задачи по соответствующему модулю).

Разработка ведется по Scrum, но в качестве инструментального средства ведения Backlogs сейчас используется Excel
Тоже хотелось бы, чтобы это было внутри PM-системы.

Разработчиков и тестеров в районе 40 человек.

Внутренний учет задач разработчикам, чекерам и тестерам ведется в самописной Web-системе, тоже на Java. Она же позволяет автоматически считать время, потраченное каждым сотрудников на конкретную задачу (при начале работы нажимается кнопка в системе на этой задаче, при остановке другая кнопка). Хотелось бы от этой системы отказаться или в крайнем случае с ней сынтегрироваться.

Теперь чего бы хотелось от новой системы, и какие есть при этом ограничения:
1. Бесплатная или относительно недорогая (примерно до 1000 евро, единоразово, разумеется
2. Web-система с установкой на одном нашем сервере. Платформа по большому счету не важна, хотелось бы конечно Java, но можно и с чем-то другим разобраться).
3. Поддержка минимум русского и английского языков интерфейса. Украинский и немецкий были бы плюсом.
4. Возможность ведения описанной выше структуры проектов в разрезе модулей и в разрезе заказчиков (какие-то представления или фильтры?)
5. Настройка видов обращений заказчиков и шаблонов полей для каждого вида (для новой фичи одни, для проверки быстродействия другие, баг в расчетах - третьи и т.д.), в том числе для различных статусов обращений (для предварительно оцененной новой фичи появляется поле "предварительная оценка", для сделанной - еще и "реальное время").
6. Поддержка настраиваемых workflow с правами перевода заявок в различные статусы для различных ролей, назначением различных ответственных (и в том числе неответственных, но задействованных в работе с заявкой на этом этапе) для каждого статуса.
7. Гибкая настройка прав доступа, чтобы каждый заказчик видел только задачи своей компании, и только определенного типа, в определенном статусе, причем только определенные поля
8. Поддержка Milestones или версий систем, к которым можно прикреплять определенные задачи, а после выхода новой версии - перемещать их все в архив. Идеально, чтобы это был Sprint Backlog, в который можно было бы перемещать задачи из основного Product Backlog по всей системе (для всех заказчиков), но с возможностью потом детализации, какие задачи какому заказчику будут включены.
9. Возможность создания подзадач либо другой механизм прикрепления задач написания документации и исправления найденных багов к основным задачам.
10. Настраиваемые рассылки по email уведомлений о новых задачах, переходах состояний и др.
11. Хранение и просмотр истории редактирования (хотя бы кто и когда, не обязательно все предыдущие версии), просмотров пользователями и переходов состояний по каждой задаче.
12. LDAP-аутентификация пользователей
13. Календарь, в котором автоматически размещались бы планируемые даты релизов, даты, до которых нужно сделать ту или иную задачу, а также заказчики могли размещать различные важные для них даты (отчет акционерам, запуск нового продукта и т.д.) для информации нам.
14. Автоматический учет времени, потраченного каждым сотрудником на задачу (по аналогии с описанными выше кнопкам начать/закончить работать).
15. Статистика по всему, что есть в системе Чем больше и гибче, тем лучше
16. Диаграммы Гантта хотелось бы, но не обязательно
17. Интеграцию с SVN тоже хотелось бы
18. Система должна быть живой, т.е. обновления должны быть в этом году, в крайнем случае в конце прошлого.

Для решения задачи просмотрел достаточно много систем:
http://www.redmine.org/
Пока что фаворит. Бесплатный, наиболее часто упоминаемый. Функционал вроде в основном наиболее полно соответствует моим требованиям, но смотрел мало, поэтому могу ошибаться. Есть много плагинов. Хотелось бы услышать мнение людей, которые его используют. Из минусов - Ruby on Rails. Но вроде для чайников есть простой путь к установке - http://bitnami.org/stack/redmine. Попробую.

http://trackstudio.ru/
Очень навороченный продукт, на Java. Управлять проектами можно в любой сфере Есть полноценная иерархия задач, но не уверен, что мне это нужно. Одного уровня (не учитывая подпроекты=модули) мне было бы достаточно. Нет диаграмм Гантта, хотя есть экспорт в MS Project. Навороченная система безопасности (есть целая презентация по этому поводу . По цене хотя и укладываюсь в ограничения, но все-таки бесплатное предпочтительнее... Разве что найдутся весомые аргументы против Redmine или за Trackstudio. Плагинов нет, но можно писать свои скрипты. Не нашел milestones, календаря и учета времени. В общем опасение такое, что заплатив деньги получу избыточный функционал, хотя устраивал бы и бесплатный Redmine. Большая просьба разработчиков Trackstudio и тех, кто его использует прокомментировать и поделиться опытом.

http://www.activecollab.com
PHP, простенько, но что-то в нем есть. Информации мало, хотелось бы услышать побольше отзывов

http://www.countersoft.com/products/gemini
По инструкции пробежался, интересно, но русского нет, да и информации очень мало. Насколько он вообще с русским дружит? Кто пользуется, отзовитесь?

http://jtrac.info/
Последний релиз 2008 г

http://www.comindwork.com/
Отечественная разработка, Честно признаюсь, что вначале посмотрел, чем-то интуитивно не понравилось, и отложил. А теперь, когда пишу, решил второй раз глянуть - выглядит навороченно, иногда даже слишком для заказчиков, насколько он настраивается под мои требования, не знаю. Может кто поможет узнать?

!http://clockingit.com/
проблемы с русским, нет контактов

http://www.opengoo.org (Feng Office)
дорого

http://trac.edgewall.org/
Очень много всего про него пишут. И хорошего, и плохого. Пока что у меня сложилось мнение, как о "классике" ВАЗа. Одни любят и кричат, что все новое - барахло, а это - вещь, и все остальное от него пошло и является слабым подобием оригинала. А другие предпочитают новое и навороченное. Я отношусь к последним. Может быть я не прав, и это действительно лучшая система. Расскажите, пожалуйста

http://www.bestpractical.com/rt/
2008 год

http://www.project-open.org/documentati ... chitecture
Пишут, что проблемы с русским. А жаль, интерфейс понравился. И ссылок на него мало, видно непопулярен.

http://www.solvermate.ru/
чисто для хелпдеска

http://dotproject.net/
убогий интерфейс, последнее обновление 2008

http://goplan.info/
Не подходит, только хостинг

http://worksection.com/
Не подходит, только хостинг

А также прочитал ряд интересных статей:
http://en.wikipedia.org/wiki/Comparison ... ng_systems
http://habrahabr.ru/blogs/pm/75004/
http://habrahabr.ru/blogs/pm/44008/
http://lib.custis.ru/Agile-tools-2010
http://www.trackstudio.ru/products-comparison.html

В общем, буду рад Вашим комментариям и советам, основанным на реальном опыте использования систем. Убедите меня купить TrackStudio

С уважением,
Антон

[admin]

1. Бесплатная или относительно недорогая (примерно до 1000 евро, единоразово, разумеется

Все бесплатные системы (и значительная часть платных) построены по одной схеме, проблемы с этой схемой описаны в нашем сравнении с JIRA. К redmine все это относится в полной мере (кроме цены).

2. Web-система с установкой на одном нашем сервере. Платформа по большому счету не важна, хотелось бы конечно Java, но можно и с чем-то другим разобраться).

Это есть.

3. Поддержка минимум русского и английского языков интерфейса. Украинский и немецкий были бы плюсом.

Русский и английский есть, в 3.5 есть также немецкий и украинский (в 4.0 тоже будет).

4. Возможность ведения описанной выше структуры проектов в разрезе модулей и в разрезе заказчиков (какие-то представления или фильтры?)

Заказчики - это верхний уровень иерархии задач, модули - нижний. Права можно выставить как угодно.

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

Да, для разных категорий задач можно указать разные кастом-поля, заполнять можно и при создании задачи, и при обработке.

6. Поддержка настраиваемых workflow с правами перевода заявок в различные статусы для различных ролей, назначением различных ответственных (и в том числе неответственных, но задействованных в работе с заявкой на этом этапе) для каждого статуса.

У нас это есть (ключевая особенность продукта), а вот в других продуктах с этим обычно проблемы. Или workflow нельзя менять, или workflow общий для всех задач, или правила перехода между состояниями настраиваются плохо (например, нельзя сказать "ресолвить задачу может только тот разработчик, который за нее отвечает, при этом он должен заполнить поле build #").

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

У нас это можно, в open source системах с поддержкой системы прав традиционные проблемы, особенно назначение прав на отдельные задачи (не проекты) и отдельные поля.

8. Поддержка Milestones или версий систем, к которым можно прикреплять определенные задачи, а после выхода новой версии - перемещать их все в архив. Идеально, чтобы это был Sprint Backlog, в который можно было бы перемещать задачи из основного Product Backlog по всей системе (для всех заказчиков), но с возможностью потом детализации, какие задачи какому заказчику будут включены.

Можно просто версии как подпроекты сделать. Например, у нас есть проект TrackStudio и подпроекты TrackStudio 3.5, TrackStudio 4.0. Перемещение задач делается через cut/paste, видимостью проектов и отдельных задач управлять можно.

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

И подзадачи есть, и ссылки на задачи - через кастом-поля типа Task.

10. Настраиваемые рассылки по email уведомлений о новых задачах, переходах состояний и др.

Тоже есть, можно настроить кто, по каким задачам и каким переходам должен получать оповещения.

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

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

12. LDAP-аутентификация пользователей

Есть.

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

Календаря в классическом понимании нет, но у задач можно выставить поле "сделать До" и выводить его в фильтрах.

14. Автоматический учет времени, потраченного каждым сотрудником на задачу (по аналогии с описанными выше кнопкам начать/закончить работать).

Есть, причем есть учет времени по видам деятельности. Например, можно определить сколько времени ушло на разработку и сколько на тестирование (полезно если разработка и тестирование оплачиваются заказчиком по-разному). Посмотрите тут
http://www.trackstudio.ru/node/153

15. Статистика по всему, что есть в системе Чем больше и гибче, тем лучше

Статистику собирать можно самую разную, посмотрите тут примеры
http://download.trackstudio.com/doc/en/ ... ution.html

16. Диаграммы Гантта хотелось бы, но не обязательно

Есть экспорт в MS Project, который умеет такое, но практической пользы от этого мало. Подробнее описано тут
http://www.trackstudio.ru/node/154

17. Интеграцию с SVN тоже хотелось бы

Есть.

18. Система должна быть живой, т.е. обновления должны быть в этом году, в крайнем случае в конце прошлого.

Минорные обновления выходят раз в 2-3 недели.

В общем опасение такое, что заплатив деньги получу избыточный функционал, хотя устраивал бы и бесплатный Redmine. Большая просьба разработчиков Trackstudio и тех, кто его использует прокомментировать и поделиться опытом.

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

Второй момент - вам уже необходимо разрешить доступ клиентам к системе, причем доступ нужно контролировать на уровне проектов и даже полей. Этого тоже нет в open source, field level в security в JIRA прикрутить задним числом так и не смогли, хотя очень хотели. В redmine такого не заметил.

Третий момент - вам (вроде бы) уже нужна группировка проектов по клиентам (фактически это уровень иерархии "группа проектов") и уровень иерархии "версия", плюс собираетесь использовать систему для управления проектами. Скорее всего это значит, что вам потребуется более продвинутая иерархия задач, чем та, что есть (будет) в Redmine.

Как мне кажется, в вашем случае главный риск при выборе redmine и других open source систем состоит в том, что через неделю, месяц, год вылезет потребность в какой-то фиче, а ее нет и сделать нельзя (плагины обычно делаются просто, но изменить ядро таким способом нельзя).
Т.е. хорошо бы взять какой-нибудь список фич, которых нет в бесплатных трекерах и почитать комментарии пользователей о том, зачем им эти фичи и почему их отсутствие мешает. Умозрительно представить зачем может потребоваться несколько уровней иерархии и кому это вообще надо довольно сложно, а в комментариях приводятся конкретные use cases.

Хотя подобные списки можно найти в любом open source багтрекере, мне очень нравится список в JIRA
http://jira.atlassian.com/browse/JRA#se ... sues-panel

Он хорош тем, что
- JIRA весьма продвинутая система с огромными бюджетами на разработку. Если уж их пользователи чего-то хотят, а они сделать не могут - значит причины серьезные, сами вы эту проблему каким-нибудь простым хаком тоже не решите.
- У них много пользователей среди коммерческих компаний. Используют они трекер по-другому, не как разработчики open source, так почитать об их проблемах может быть интересно.
- На сайте есть голосовалка и задачи сортируются в порядке убывания голосов, так что начинаем читать сверху - это и будет самое главное.

Например, берем самый верхний баг про необходимость иметь свои собственные приоритеты, резолюции и типы сообщений для каждого проекта:
http://jira.atlassian.com/browse/JRA-3821
и начинаем читать с конца (там обычно самые эмоциональные комментарии и пользователи разъясняют зачем оно им надо).

Видим следующее:
"We are currently revamping the way we track issues and are wanting to use Jira as a Helpdesk system using separate priorities and resolutions per project (via a scheme) is the only thing really holding us back." - ага, т.е. оно зачем-то надо для Helpdesk.

"We as a company have the same problem. one of over 40 customers wants a 4th priority. i am not willing installing a second Jira only for him." - ага, т.е. если разные клиенты хотят разные уровни приоритета, то это может потребовать инсталлировать еще один экземпляр, а это много лишних проблем с использованием и администрированием.

"Priority Schemes are urgent! I think everyone will find it very useful when able to have separate schemes for different projects." - это может быть важно при использовании нескольких существенно разных проектов

"In order to support multiple departments, we NEED different priority schemes... Without this feature, our ability to expand usage of Jira is very limited right now." - а еще это может быть важно, если в компании несколько отделов

"As seems to be the case for many users, we (would like to) use JIRA for many things, from bug tracking to task management and Q&A.
Those represent different Issue Types (Bugs, Tasks, Questions,...) belonging to the same project, and needing different resolutions." - это нужно если трекер используется для управления разными типами задач

"As I'm using jira in large organizations, I think that Priorities are more important. If you implement HelpDesk,development and other projects in Jira, you must use different priorities." - опять help desk в крупной организации и опять нужны разные наборы приоритетов для разных проектов

"We are running a multitude of development projects which can have different priorities depending on the clients priority scheme which in most cases we have to follow." - при общении с клиентами набор приоритетов зависит от клиента, не всегда получается навязать всем свою схему

"This is very much needed so we can start using JIRA on the "business" side of our company - We're pretty much keeping it to IT for now. " - оно зачем-то нужно если к системе имеют доступ не только IT-шники

И т.п. Но уже сейчас понятно, что фича особенно полезна для компаний, имеющих несколько клиентов, отделов, трекающих задачи разного типа и использующих трекер не только для IT. Если это не ваш случай - можем рассматривать следующую проблему из top 50 с целью убедиться, что и она для вас не актуальна

Обратите внимание, мы за 5 минут собрали кучу информации и о фиче, и о возможных вариантах ее использования. Если бы мы просто так стали рассматривать систему управления задачами, то с вероятностью 99% вообще бы не обратили внимание на возможность создания своих приоритетов для каждой категории задач, а уж зачем и кому оно может быть нужно - вообще бы не догадались. В redmine фичи нет, как видно из скриншота
http://www.redmine.org/wiki/redmine/RedmineEnumerations - список приоритетов глобальный.

В TrackStudio, надо сказать, подобная фича есть, хотя мы не делали ее специально - она естественным образом следует из другой архитектуры системы. Open source системы обычно ставятся по экземпляру на один open source проект, никаких особых "клиентов" там нет, возможность создавать разные резолюции для разных проектов или клиентов там совершенно не нужна. 90% граблей с open source системами происходит именно по этой причине - они изначально были написаны для решения других проблем в других условиях, в "их" картине мира никаких клиентов, отделов и "bussiness" side of company нет.

PS. А в целом соглашусь с тем, что из open source Redmine - наиболее приличная система.

[admin]

Есть полноценная иерархия задач, но не уверен, что мне это нужно.

Хочется остановится вот на этом моменте. Действительно, возможность создания вложенных субтасков - этого довольно популярное требование, в JIRA это #2 по популярности среди нереализованных фич, а в redmine 1.0 вроде даже сделали:
http://www.redmine.org/issues/443

Но кому и зачем нужны вложенные баги ? Какая от них польза ?

Если посмотреть комментарии пользователей, которым нужна это возможность, то варианты использования предполагаются следующие:

• использование продукта для управления проектами или интеграция с ms project. В продукте в данном случае хранится не иерархия задач для программистов, а иерархия целей (результатов) проекта. В wikipedia по этому поводу написано:
  http://en.wikipedia.org/wiki/Work_breakdown_structure
  

  If the Work Breakdown Structure designer attempts to capture any action-oriented details in the WBS, he/she will likely include either too many actions or too few actions. Too many actions will exceed 100% of the parent's scope and too few will fall short of 100% of the parent's scope. The best way to adhere to the 100% Rule is to define WBS elements in terms of outcomes or results.
  

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

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

Кроме того, практически во всех этих случаях нам нужна иерархия не однотипных, а разнородных задач. В багтрекинге мы имеем проекты, баги, компоненты, версии. В управлении тестированием это test case и test suite. Для бизнес-задач это будут подраздления и клиенты.
Если для багтрекинга проекты, компоненты и версии обычно явно реализуются в коде и интерфейсе системы, то для других областей применения необходимых типов задач в Redmine/JIRA нет.

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

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

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

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

[a-b-c]

Как пользователь хочу заметить, что когда стоимость системы (в версии Single) сопоставима с месячной зарплатой одного из 40 непосредственных пользователей - можно считать ее условно-бесплатной. К тому же у вас основной ЯП - Java - имеет смысл посмотреть на максимальную лицензию, которая даёт возможность получить исходники.
У нас нет Java специалистов, поэтому нам хватает скриптов, сейчас планируем заинтегрироваться с другими внутренними и внешними системами за счет SOAP интерфейса.

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

[angestar]

Большое спасибо за такие подробные ответы на мои вопросы и за ссылки на типичные проблемы, с которыми сталкиваются пользователи других систем (с сомнительными надеждами на их решение, как я понял). Ваш продукт внушает уважение хотя бы из-за того уровня абстракции, которым нужно было обладать, чтобы продумать структуру системы на таком уровне! Впечатляет и подсистема доступа, наверное, лучшая среди конкурентов. Смущает отсутствие истории просмотра (привык в нашей системе, что это есть, и сразу видно, кто и когда читал и читал ли вообще), диаграмм Гантта (обоснование почему читал, но один из заказчиков их хочет как часть процесса...) и общего календаря (все-таки полезная была бы штука, может быть сделаете когда-нибудь, должно быть не слишком сложно? Однако, понимая, что идеального для моей ситуации продукта, скорее всего, не существует, и нужно чем-то жертвовать, думаю, что лучшим критерием принятия решения будет попробовать настроить необходимые мне бизнес-процессы в обеих системах и понять, достаточно ли мне функционала Redmine на данном этапе и сделать какие-то прогнозы на будущее. Чем в ближайшее время и займусь.

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

[a-b-c]

Поддерживаю FR по календарю - но не в виде родного календаря в TrackStudio, а в виде прикрученного к Outlook или Google Calendar (чтобы наложить события из TrackStudio на уже используемые календари).
У нас это календари Outlook, есть механизмы прикручивания напрямую (как это сделали в корп. портале от битрикса), можно и через посредника типа google calendar.
Создание отдельной реализации календаря считаю бессмысленным, т.к. вряд ли TrackStudio будет главным и единственным источником событий, а одновременное ведение нескольких календарей в разных местах вряд ли будет удобным.

[admin]

Спасибо!

Да, 3-х месячный триал есть на сайте после регистрации, реально из-за ряда особенностей там часто даже больше получается. Попробуйте все настроить, запустить, посмотреть что пользователям понравится. Если все пойдет, то можно покупать После покупки поддержка та же.

Истории просмотра нет, т.к. задачи можно просматривать разными способами:
- кто-то смотрит почти все из страницы со списком задач, в этом списке почти все вывести можно
- кто-то через RSS
- кто-то через e-mail notification
т.е. мы можем отслеживать кто перешел на страничку с информацией о задачи, но практической пользы от этого не много, т.к. пользователь мог посмотреть все что ему нужно другим способом.

Диаграмму Гантта, надеюсь, мы все-таки сделаем. Хотя у меня есть очень большие сомнения в ее практической полезности, но часто спрашивают, полезно будет сделать "для галочки", наверное.
Про календарь тоже посмотрим, если там не сложно - сделаем быстро.

[admin]

Если будем делать интеграцию, то с Google Calendar. Но я с ним не работал, можете описать use cases, что вообще от этой интеграции надо ?

[Евгений]

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

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

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

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

Насколько понял после беглого знакомства с Redmine, workflow и статусы задач могут настраиваться отдельно для каждого трекера. Трекеров можно создать сколько угодно, иерархия может состоять из задач разных трекеров.
В общем, не убедили. Пока пришел к выводу, что Redmine лучше не только бесплатных, но и некоторых платных систем. Диаграммы Ганта там худо-бедно есть

С уважением, Евгений.

[admin]

Насколько понял после беглого знакомства с Redmine, workflow и статусы задач могут настраиваться отдельно для каждого трекера. Трекеров можно создать сколько угодно, иерархия может состоять из задач разных трекеров.
В общем, не убедили. Пока пришел к выводу, что Redmine лучше не только бесплатных, но и некоторых платных систем.

Я дописал: http://www.trackstudio.ru/comparison-redmine.html
Теперь более убедительно ?

Диаграммы Ганта там худо-бедно есть

Главная проблема с диаграммами Ганта состоит в том их строить надо на основе иерархии целей, а не задач. А как раз цели никто в трекерах не хранит, т.к. для этих целей есть системы управления проектами. Вот подробности:
http://www.trackstudio.ru/node/154