На самом деле мы очень мало работали с Jira, система писалась под впечатлением от ClearQuest после нескольких лет Mantis. А сравнение на сайте именно с Jira, т.к. она сейчас стала очень популярной и про нее спрашивают. В Jira довольно простое ядро (в целом повторяющее bugzilla), на которое потом навешаны workflow, субтаски, кастом-поля, security, и т.п. - эти фичи писались когда система была уже почти готова. Сложность Jira - это сложность большого количества компонентов (очень много таблиц в БД, экранных форм, понятий и т.п.).

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

Лет 5 назад в Jira был вполне приятный интерфейс, который позволял "читать" багрепорты не вдаваясь в технические детали. Т.е. системные поля (состояние, ответственный, etc) - слева, под ними - операции, а справа описание задачи и комментарии пользователей как один большой документ. По сравнению с дизайном большинства других систем, это был большой шаг вперед - почитайте отзывы о Jira (большинству из них уже несколько лет) - люди выбирали Jira из-за интерфейса, а Atlassian позиционировала систему как "brilliantly simple".
Но со временем количество фич росло, в старый интерфейс оно все не влезало, и сейчас там каша (которая следствие каши в самой системе).
Что они теперь с этим делать будут и что тут вообще можно сделать - не знаю. Вот еще моя небольшая статья в продолжение той же темы.

Basecamp и другие подобные системы - они сейчас в начале того пути, который уже почти прошла Jira. Смогут ли они отбиваться от feature requests и оставить систему простой - посмотрим. Про это Спольский писал - 80% клиентов в самом деле нужны 20% фич, но эти 20% фич для всех разные, поэтому давление пользователей есть и будет.

По поводу крупных команд - весь проект TrackStudio сейчас делают 4 человека (включая меня), больше 5 человек вообще никогда не было. Используем TrackStudio в смежном проекте - там 8 человек. Хотя, конечно, наиболее типичный клиент TrackStudio - компания от 50 пользователей, просто потому что для больших команд преимущества TrackStudio наиболее заметны.




Да, я понимаю. Ну и какой может быть фан, когда текущая версия 3.5.19 - тут только героическая стойкость поможет 
В 4.0 интерфейс будет сильно другой, а многие "ручки" попрятаны - должно помочь в плане удобства и приятности использования.



Это сообщение отредактировал(а) maximkr - 23.9.2007, 09:12

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

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

Да, у issue tracking и project management одна предметная область, но разные "точки фокуса": основа issue tracking - это workflow (состояния, ответственные,...), а основа project management - диаграммы Гантта (иерархия задач, зависимости между работами и календарный план). Issue tracking ориентированы скорее в прошлое, а project management - в будущее.

Есть много систем, претендующих на issue tracking и project management одновременно, но я не знаю ни одной, сочетающий workflow-движок уровня TrackStudio и project management-функциональностью уровня MS Project. TrackStudio - это issue tracking в чистом виде, project management функциональность тут самая минимальная и получилась почти случайно (иерархия задач, экспорт в ms project), но ведь в большинстве issue tracking систем нет и этого. Т.е. я предлагал рассматривать TrackStudio в качестве "интегрированного" решения для issue tracking + project management не потому, что у нас хорошо, а потому что у остальных еще хуже.



Нас просили сделать очередь несколько раз - все упирается в то, что для сортировки задач в очереди нужно гарантировать, что все видят одну и ту же очередь  Если менеджер проекта A указал программисту порядок выполнения задач, менеджер проекта B указал тому же программисту порядок выполнения задач в своем проекте, то кто укажет программисту в каком порядке задачи в этих проектах делать - непонятно.

В TrackStudio для решения этой проблемы используется понятие "ответственного" - если сейчас эту задачу делать не надо, то ответственным за нее является менеджер. Если задачу назначили на программиста - можно делать. Если назначили несколько задач - можно делать в любом порядке. Если какую-то задачу раньше нужно было делать, а сейчас - нет, то менеджер меняет ответственного с программиста на себя (и потом может назначить ее на кого-то другого).
Т.е. программистам не интересна очередь работ на неделю вперед, указания что именно он может/должен делать прямо сейчас вполне достаточно. А вот менеджер уже может организовывать _свою_ очередь как ему удобнее.

Вы пытаетесь решить общую задачу. Принцип хорошего дизайна -- не грузить пользователя обобщённым (крутым, функциональным и удобным после 2 лет использования) решением, а дать ему тот минимум, который необходим в 80% случаев (да, да, помню, что у всех свои 20%, но это не повод не работать над дизайном). У нас в команде нет нескольких менеджеров на одного программиста -- все задачи проходят через тим-лида. Я при этом работал и в ситуации с несколькими менеджерами -- но в этом случае у программиста всегда есть понятие основного проекта. А всё остальное -- чистой воды баг-трекинг. То есть частные решение прослеживаются, и даже примерно понятно, как это организовать. А вы хотите сделать динозавра на все случаи жизни. Не так?



Ошибаетесь. К сожалению, и к счастью, не все люди лемминги.  Я заметил, что программисты работают гораздо эффективнее, если они понимают весь процесс (вероятно, просто растёт чувство отвественности -- не знаю). Сейчас это у нас решается так: "Почитай ТЗ", и ещё общими собраниями (часто спонтанными), на которых я рассказываю общие планы на будущее. Как стратегические, так и тактические. Для тактики очередь была бы очень нужна. 
Кроме того, когда есть свободная очередь (не назначенные никому задачи), разумный программист может сам сориентироваться, чем ему заняться, если он освободился от текущей задачи. Разумеется, это согласовывается с ПМ-ом, но, опять же, растёт общее понимание проекта, ответственность, и, как следствие, отношение к проекту.



Приоритетами? Это же жутко неудобно. 

Тут проблема такая, что если пользоватею в самом деле нужен минимум - он скорее всего возьмет open source. Я где-то видел список имеющегося bug tracking софта (большая часть - open source) - там было больше 300(!) продуктов. 



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



Совсем не хотим. Если такое где-то получается, то это не специально и мы с этим боремся 



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



Я сам просто помню о самых приоритетных задачах, заинтересованные стороны забыть не дают.