?

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 раз переписывать.
 
 
 
Максим Крамаренкоmaximkr on Сентябрь, 4, 2010 20:04 (UTC)
Тут хочу добавить, что JIRA никогда не задумывалась как толстая и неповоротливая enterprise система.
Сколько их помню, они всегда противопоставляли себе этим enterprise систем, JIRA большую часть своей истории воспринималась/позиционировалась как brilliantly simple, easy for use for non-technical people и т.п.

Куча неудачных решений в JIRA была сделала именно потому, что они хотели сделать систему проще. Пара примеров:

Вот тут http://forums.atlassian.com/thread.jspa?forumID=46&threadID=3388&tstart=0 Jeff Turner пишет, что единую иерархию проектов и задач они не стали делать именно из-за желания сделать систему проще, а кому надо - могут сами ковыряться в исходнике: "Giving users the source (or just JSP source, as illustrated above) lets us err on the side of simplicity."

Второй пример из задачи #1 в их top 50, про локальные состояния и приоритеты:
http://jira.atlassian.com/browse/JRA-3821?focusedCommentId=139565&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-139565
Там Mike пишет, что они не стали этого делать т.к. хотели упростить интерфейс: "It makes the UI just too confusing in too many places." Рекомендуемая альтернатива - поставить несколько экземпляров системы.

Судя по комментариям, это не та простота, которой хотели пользователи.