Кстати о Redmine

[pmant]

Давно хотел написать пост про Redmine, да все руки не доходили…вот теперь дошли.

Думаю уже все знают что такое redmine, в последнее время эта система стала притчей во языцах. А в опросе на хабре - http://habrahabr.ru/blogs/pm/91010/ заняла первое место.

Так что я, что бы не тратить время просто опишу что мне понравилось и что нет. А вы в комментариях

Comments

Redmine

[maximkr]

По поводу достоинств 2 и 3: мне кажется, что 2 разные иерархии для проектов и багов - это не такой уж и плюс. Подробнее тут написал:
http://www.trackstudio.com/forum/bug-tracking--issue-3673.html#p16006

Re: Redmine

[pmant]

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

Re: Redmine

[maximkr]

А в чем смысл 2-х иерархий - проектов и issues ? Фактически же это приводит к тому, что одно и то же нужно делать 2 раза (аттачи, кастом-поля, фильтры и т.п

Re: Redmine

[pmant]

Чаво-чаво, классическую WBS никто визуально не реализует в системах трекинга. Она рисуется или в специальных тула или в "тяжелых" solution типа Примаверы или Спайдера.
Иерархия требований живет сама по себе, хотя бы потому что может затрагивать несколько проектов.

Re: Redmine

[maximkr]

Да, но я этот список возможных применений иерархий не сам придумал, а взял из комментариев к соот. задачам JIRA - там пользователи пишут, зачем оно им надо. Хотя для многих применений есть специализированные тулзы, но часто оказывается, что проще/дешевле запихнуть все в один продукт и потерять в функциональности, зато выйграть в интегрированности и цене. В качестве примера - wiki в redmine. Еще системы управления требованиями - они обычно очень дорогие, а функционал там нехитрый, поэтому желание реализовать его прямо внутри трекера возникает у пользователей часто (даже если изначально понятно, что систему придется дорабатывать напильником).

По поводу иерархии issues (не проектов) - можете привести примеры ситуаций, когда оно действительно нужно (особенно если больше 1 уровня вложенности) ? Большинство примеров что я видел были абстрактными, как ваш в пункте #2 :-)