?

Log in

No account? Create an account
 
 
04 Сентябрь 2010 @ 15:48
Сравнение с Redmine  
Первый вариант писался по мотивам изучения сайта/документации, получилось не очень убедительно, как мне кажется. Но интерес к теме есть, поэтому вчера поставили Redmine локально и поигрались с ним, по итогам сравнение в значительной степени переписал.

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

Вообще какой-то идейный застой в области трекеров наблюдается: все инновации обычно заключаются в том, чтоб взять Jira, выкинуть из нее "лишнее" и добавить что-то постороннее (wiki, хранение файлов, форум и т.п.), о реализации каких-то новых архитектурных идей обычно речи не идет. Например, можно было бы сделать:
- полноценную версионность объектов. Чтобы можно было "листать" предыдущие версии задачи, безболезненно менять workflow (старые задачи используют старую версию workflow, новые - новую), смотреть snapshot-ы проекта в прошлом.
- наследование workflow. Сейчас если в системе десяток похожих workflow, то создавать и поддерживать их довольно утомительно.
- использование для хранения задач не плоской или иерархической модели, а гиперкуба (как в OLAP). Т.е. значения каждого поля - это размерности, ячейки гиперкуба - задачи. Сейчас бывают проблемы если задачу нужно уложить в несколько иерархий: иерархию проектов и иерархию компонентов проекта, например, решаются ссылками на задачи, что не очень удобно.
- можно попробовать интегрировать project management и issue tracking в одной системе, сейчас с этим практически везде плохо.

В общем, не понимаю я этих open source-ников. Охота же им одно и то же по 100 раз переписывать.
 
 
 
mekhosmekhos on Сентябрь, 6, 2010 06:09 (UTC)
Comindwork
Мы сейчас исследуем варианты комплексного решения для управления проектной деятельностью. На данный момент Comindwork в фаворитах. По соотношению цена/возможности он один из лучших на наш взгляд. Было бы интересно узнать Ваше мнение, Максим, по поводу преимуществ TrackStudio в сравнении с данным конкурентом.
P.S.: на русскоязычном сайте есть полноценная демка http://demo.comindwork.com/?language_code=ru-RU
Максим Крамаренкоmaximkr on Сентябрь, 6, 2010 06:57 (UTC)
Re: Comindwork
В качестве комплексного решения Comindwork наверняка будет лучше, т.к. мы даже не пытались сделать комплексное решение, у нас просто "классический" трекер.

Если брать в целом, то в Comindwork есть много чего еще - управление проектами (с двунаправленной интеграцией с MS Project), wiki, todo, blog и т.п. Мы сами для аналогичных целей используем другие продукты - drupal, phpbb, livejournal (хотя в drupal, теоретически, есть и трекер, и форум, и блог).

Если же сравнивать трекер внутри Comindwork с TrackStudio, то трекер там ничем не примечательный. Я глубоко не смотрел, но на первый взгляд
- иерархий нет, project и issue - это разные сущности
- детальной настройки ролей пользователей и их прав вроде нет
- нет скриптов/триггеров и прочей обработки на стороне сервера

Подозреваю, что подобные фичи не совсем согласуются с идеологией Comindwork. Обычно если продукт интегрированный, тем более SaaS, то быстрота развертывания очень важна, поэтому тратить неделю на настройку прав и workflow типичный клиент все равно не будет. В итоге выигрываем в быстроте инсталляции, но теряем в гибкости и фичах (я практически уверен, что wiki там будет проигрывать по функциональности Conflucene, например).

Что тут лучше - сложно сказать, есть "ужасные истории" про оба подхода. Можно поставить много специализированных продуктов и потом мучиться с их инсталляцией и интегрированием. А можно поставить интегрированный продукт, а потом страдать от нехватки настроек и функциональности. Причем проблемы с настройкой и интеграцией видны все и сразу, а проблемы с функциональностью - обычно уже в ходе работы.