?

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 Сентябрь, 5, 2010 06:45 (UTC)
Кстати, о документации и файлах. Теоретически в TrackStudio и файлы можно хранить (в виде аттачей), и документацию (сделать особый тип workflow с 1 состоянием). Чем именно этот вариант не устраивает ?

Просто есть идея сделать в настройках категории галочку full view/simple view, где full - это текущий, а simple - только пользовательская информация, без мета-полей вроде состояний, авторов, дат и т.п. Поможет такое или что-то еще надо ?
Allexall_x on Сентябрь, 5, 2010 08:13 (UTC)
Вопрос удобства польовательского интерфейса. Мне кажется, для своих можно договориться, а пользователю со стороны будет непонятно. Стоит ли пытаться впихнуть это в TrackStudio, может быть лучше сделать отдельным модулем с возможностью интеграции?

Мои потребности понять просто - зайдите на SourceForge/SourceForge, RubyForge/GForge, Ruby ITS/Redmine, Google Code/??? и т.п. Трекеры там примитивные, но кроме них ещё много всего.
И трекер не на первой странице - новому пользователю нужны описание проекта, файлы, документация, новости. А уж потом баги. Но коли до багов дело дойдет - хочется, чтобы всё было удобно. Особенно разработчикам.
Максим Крамаренкоmaximkr on Сентябрь, 5, 2010 14:08 (UTC)
У нас тут соображения были такие:

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

2) Примитивную систему управления файлами/документами не стали делать т.к. исходили из предположения, что если процессы пользователя таковы, что его не устраивают "обычные" трекеры и он выбрал TrackStudio, то и в области подготовки документации у него ситуация не лучше и какая-нибудь залепень на коленке его тоже не устроит. Например, есть такая ECM система, Alfresco. У них есть модуль Samba-сервера на Java (т.е. документы внутри этой Alfresco видно как на сетевом диске). Модуль поставляется по лицензии GPL, коммерческая лицензия стоит порядка 20 тысяч долларов, самим реализовывать протокол SMB тоже что-то не хочется. В итоге наша доморощенная реализация не имеет никаких шансов "дотянуть" по функциональности даже по популярных open source аналогов, что уж говорить про коммерческие продукты.

saveug on Сентябрь, 6, 2010 05:08 (UTC)
Разделяю полностью. Долго думали над позиционированием "Облака проектов" и решили, что все выше перечисленные системы хороши для open-source проектов, то есть для разработчиков.

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

Таким образом, на Облаке проектов проектная информация (описание, документация, новости, файлы) представлена в customer-ориентированном виде.

Для разработчиков используется альтернативный UI, в котором они могут управлять проектом и взаимодействовать с пользователем. Само управление проектом построено на базе DEVPROM.

Будем признательны за конструктивные замечания в плане функциональности и возможностей Облака.
Максим Крамаренкоmaximkr on Октябрь, 11, 2010 18:08 (UTC)
Да, наверное это правильный подход - сделать совсем отдельный UI для конечных пользователей. Сделать интерфейс, одинаково удобный/понятный и для пользователей, и для программистов - наверное не реально.