?

Log in

No account? Create an account
 
 
05 Март 2008 @ 13:07
TrackStudio vs JIRA ? А может быть стоит интегрировать TrackStudio и JIRA ?  
Недавно мы переделали описание титульной странице на trackstudio.ru и добавили там (среди прочего) фразу "В отличие от Atlassian JIRA, оптимизированной для работы с внешними клиентами, TrackStudio позволяет эффективно организовать работу внутри компании (например, обработку обращений клиентов)." На самом деле это и есть главное отличие между TrackStudio и JIRA, у него исторические корни: основатели Atlassian до создания JIRA имели большой опыт работы в open source проектах (opensymphony) с большим количеством пользователей и неформальными внутренними процессами, а мы больше занимались заказной разработкой, где внутренних сотрудников с разными ролями и правами хватает, но вот с конечными пользователями общались не часто.

А уж все остальное следует отсюда:

JIRA проявляет себя с лучшей стороны именно в качестве продвинутого форума. Т.е. если мы на форуме сообщаем, что бага будет исправлена в 3.5.x, публикуем список изменений в 3.5.20 или план работ на следующую версию, спрашиваем, что клиентам хотелось бы видеть в следующих версиях - мы именно общаемся с клиентами, а не планируем. И Atlassian использует JIRA именно для общения с клиентами, для организации внутренней работы у них довольно необычный процесс, который описан тут:
http://maximkr.livejournal.com/8942.html
Грабли же начинаются, когда их клиенты пытаются использовать JIRA для внутренней разработки или (что еще хуже) для внутренней разработки и общения с клиентами одновременно. Если глянуть 50 их наиболее серьезных нерешенных проблем, то практически все они относятся к попыткам использовать JIRA для внутренней разработки:
- сокрытие полей нужно именно для сокрытия внутренней информации (которой там вообще быть не должно) от клиентов
- подзадачи нужны для организации внутренней работы, клиенты обычно не готовы вникать в глубокие иерархии и как там все расположено
- проблемы с учетом рабочего времени - аналогично, клиенты не учитывают свое рабочее время, это актуально только для внутренних работников
- пользовательские поля для проектов и компонентов, хранение вложений к проектам - аналогично, для общения с пользователями это не нужно, потому и не было вовремя сделано. У меня, например, никогда не возникало желание прилепить к форуму "TrackStudio Support" вложение с описанием TrackStudio :-)

Аналогично, вещи нужные для общения с клиентами (голосование, RSS, анонимный доступ к базе, генерация "что нового?" и т.п.) были сделаны в самых первых версиях JIRA, жалоб на них мало.

В TrackStudio ситуация обратная: еще в первых версиях была сделана функциональность, важная для управления работами внутри компании (иерархия всего и пользовательские поля для всего, ограничение доступа к полям,  очень гибкий учет времени), а вот голосований, анонимного доступа к базе (без регистрации) или генерации "что нового?" в пригодном для публикации на сайте виде нет до сих пор.

Впервые мы с этой принципиальной разницей столкнулись несколько лет назад, когда пытались забесплатно раздавать TrackStudio open source проектам. Оказалось, что анонимный доступ к базе и багзилла-подобный интерфейс для них просто критически важная вещь, а вот поддержка сложных процессов или ограничение доступа к данным не нужны совершенно - процессы очень простые, а данные открыты всем. Т.к. для коммерческих организаций приоритеты обычно прямо противоположные, то мы на идею продвижения TrackStudio в open source быстро забили, хотя рекламные возможности тут просто огромные. По той же причине JIRA так плохо выглядит в сравнении http://www.trackstudio.ru/products-comparison.html - это повылезали проблемы корпоративных пользователей, попавшихся на слова "issue tracking" и "project management" в описании продукта. Де-факто это не целевая аудитория Atlassian, а задним числом можно исправить далеко не все, даже если очень захотеть (JRA-1330).

Может быть, вместо TrackStudio vs JIRA стоит попробовать интегрировать продукты: JIRA как frontend и TrackStudio как backend ? Ведь bug report и change request все равно должны быть разными сущностями и линковаться между собой (м.б. через permanent URL?), пользователи там и там будут существенно разные (в JIRA - клиенты и саппорт, в TrackStudio - саппорт и разработчики), типы задач/процессы - вообще не пересекаются. Имеет это какой-то смысл ?
 
 
 
Махатма Бугогандиmeatreach on Март, 5, 2008 10:59 (UTC)
Тот человек, которого вы на меня перекинули, хочет в результате примерно того же, только с Лотусом. Лотус фронт-эндом для юзеров, ТС - бек-эндом для разработчиков. Пока непонятно, будет ли там что-то - уж очень постановка задачи пока сырая, конкретики никакой - но заход похожий.

Альтернативный подход - делать в ТС отдельный конструктор интерфейсов для "простых пользователей". Обрезать все сложное, оставлять только основные операции, вынимать их наверх (вместо последовательности "добавить сообщение" -> выбор радиокнопкой "закрытие задачи" делать сразу ссылку "закрыть задачу") и формулировать на языке предметной области.
Максим Крамаренкоmaximkr on Март, 5, 2008 11:09 (UTC)
> Альтернативный подход - делать в ТС отдельный конструктор интерфейсов для "простых пользователей".
> Обрезать все сложное, оставлять только основные операции, вынимать их наверх (вместо
> последовательности "добавить сообщение" -> выбор радиокнопкой "закрытие задачи" делать сразу
> ссылку "закрыть задачу") и формулировать на языке предметной области.

Да, именно по этому пути мы идем в TrackStudio 4.0, но быстрый рост интереса к 3.5 заставляет придумывать что-то прямо сейчас.
(no subject) - meatreach on Март, 5, 2008 11:13 (UTC) (Развернуть)
(no subject) - maximkr on Март, 5, 2008 11:16 (UTC) (Развернуть)
(no subject) - meatreach on Март, 5, 2008 11:22 (UTC) (Развернуть)
(no subject) - maximkr on Март, 5, 2008 12:06 (UTC) (Развернуть)
kolomeetz on Март, 5, 2008 11:19 (UTC)
Готов поставить эксперимент у нас.
Максим Крамаренкоmaximkr on Март, 5, 2008 11:24 (UTC)
Замечательно :-) А какая именно интеграция нужна ? Видимо, нужно будет перенести в TrackStudio структуру проектов и пользователей, а еще ?
(no subject) - kolomeetz on Март, 5, 2008 11:25 (UTC) (Развернуть)
(no subject) - mou_ngaged on Март, 5, 2008 11:32 (UTC) (Развернуть)
(no subject) - kolomeetz on Март, 5, 2008 11:51 (UTC) (Развернуть)
(no subject) - mou_ngaged on Март, 5, 2008 12:18 (UTC) (Развернуть)
(no subject) - netklon on Март, 7, 2008 10:57 (UTC) (Развернуть)
Larionov "MOU" Andrewmou_ngaged on Март, 5, 2008 11:31 (UTC)
Срестить ужа с ежом? Связка тяжела в управлении будет. IMHO
Макс Васенковwinzard on Март, 5, 2008 11:35 (UTC)
А главное, как же это все будет тормозиииить.
(no subject) - maximkr on Март, 5, 2008 12:10 (UTC) (Развернуть)
(no subject) - winzard on Март, 5, 2008 12:23 (UTC) (Развернуть)
(no subject) - maximkr on Март, 5, 2008 12:01 (UTC) (Развернуть)
Макс Васенковwinzard on Март, 5, 2008 11:34 (UTC)
В TrackStudio 4.0 уже есть и анонимный доступ, и простой интерфейс. Голосования, генерацию what's new и т.п. можно сделать хотя бы с помощью скриптов и триггеров (тем более, что они теперь компилируются, т.е. по производительности должны быть эквивалентны обычному коду.
Не, вычеркиваем Jira.
netklonnetklon on Март, 7, 2008 11:02 (UTC)
Есть сомнения в необходимости такой интеграции. Перекидывать из фронтенда в бекенд данные (скриншоты например) требуется, но вот формулировку задач при постановке конечному исполнителю зачастую приходится менять.

P.S. У нас сейчас стоит джира на бекенде и на фронтенде GoPlan (hosted-приложение)
Максим Крамаренкоmaximkr on Март, 7, 2008 12:16 (UTC)
А зачем перекидывать, можно просто URL на оригинальный вопрос во frontend указать.

По поводу необходимости смены формулировки - 100% согласен. Иначе возникают ситуации типа: клиент что-то захотел, как-то сформулировал, начальству лень думать как это правильно/лучше делать и задача прямо в исходной формулировке перекидывается на разработчика. Через несколько лет такого customer driven development разобраться в проекте будет очень сложно, так что если процесс будет заставлять переписывать формулировки - это даже плюс.

(no subject) - netklon on Март, 7, 2008 12:44 (UTC) (Развернуть)
(no subject) - maximkr on Март, 7, 2008 13:01 (UTC) (Развернуть)
(no subject) - netklon on Март, 7, 2008 13:15 (UTC) (Развернуть)
(no subject) - maximkr on Март, 7, 2008 14:02 (UTC) (Развернуть)
(no subject) - netklon on Март, 7, 2008 13:18 (UTC) (Развернуть)
Максим Крамаренкоmaximkr on Март, 7, 2008 14:24 (UTC)
Нашел старый пост на форуме QIP-а:
http://forum.qip.ru/showthread.php?p=195296
===
Господа, я думаю, что многие уже заметили "неработоспособность" трекера. Переход бегтрекера в режим РО обусловлен ярым нежеланием пользователей понять чем отличается багтрекер от форума, и почему не стоит там разводить дискуссий по поводу и без оного. На данный момент мы раздумываем как все-таки сделать багтрекер удобным для авторов проектов, в плане работы, и в то же время оставить его для вас в качестве некоего намека на ToDo List, где автор лично проставляет статус тех или иных багов или предложений. Оставайтесь с нами =)
===
(Удалённый комментарий)
Максим Крамаренкоmaximkr on Январь, 27, 2009 11:38 (UTC)
Re: TrackStudio vs RT
Request Tracker посмотрел, не впечатлило :-) Он (да и другие open source системы) сильно уступает JIRA, т.к. там нет конфигурируемых workflow, довольно бедные настройки security. Многие проблемы можно решить скриптами, но объектно-ориентированный Perl - не самый популярный язык. Скажем, workflow на скриптах можно "эмулировать" так: http://wiki.bestpractical.com/view/WorkFlow

Все эти проблемы с конфигурированием - это следствие изначальных ограничение в архитектуре open source систем, для управления багами в open source проектах это не нужно. Я не думаю, что у какой-нибудь из нынешних open source систем в ближайшее время получится догнать хотя бы JIRA Standard. 99% процентов моей критики JIRA в равной степени относится и к open source системах. Если уж у Atlassian при их ресурсах не получилось это исправить, то в open source проектах искать решение бесполезно :-)

Однако это не означает, что Вам RT не подойдет. Думаю, критерии тут те же - если у Вас много внешних клиентов и 3 разработчика - лучше подойдет mantis, RT, JIRA. Если много разработчиков, сложные внутренние процессы и 3 клиента - лучше TrackStudio и другие "процессные" системы.




dm_kalashnikovdm_kalashnikov on Апрель, 15, 2009 10:44 (UTC)
Добрый день! Случайно нашёл тему в Вашем ЖЖ.
У меня вопрос: существуют ли системы учёта рабочего времени, которые бы успешно интегрировались с Джирой? Т.е. запускается программа, висит себе в трее и показывает сколько времени ты уже потратил на ту или иную задачу в Джире. Можно приостановить выполнение задачи, начать считать время на другую и т.д.

?
Максим Крамаренкоmaximkr on Апрель, 15, 2009 10:47 (UTC)
На счет интеграции с джирой не уверен, а в остальном посмотрите вот эту программу
http://tracker.aklabs.com/
Teoteo_bon on Август, 17, 2009 06:36 (UTC)
Стоит ли сравнивать Trackstudio с JIRA? Ведь в этом посте Вы убедительно показали, что эти продукты заточены под разную целевую аудиторию. Может быть, стоит сравнивать TS именно с "лучшими в отрасли" в области web-based issue tracking и project management, а не bug tracking?
Максим Крамаренкоmaximkr on Август, 17, 2009 12:45 (UTC)
Сравнение с JIRA сделали т.к. про нее много спрашивали. Это же далеко не очевидно, что у продуктов фокус разный, мы сами это поняли не сразу и в общем-то случайно.

Но TrackStudio - это именно issue tracking, project management - это другое:
http://www.trackstudio.ru/forum/bug-tracking-project-management-issue-tracking-issue-1685.html
(no subject) - teo_bon on Август, 17, 2009 14:58 (UTC) (Развернуть)
(no subject) - maximkr on Август, 17, 2009 15:02 (UTC) (Развернуть)
(no subject) - teo_bon on Август, 18, 2009 07:07 (UTC) (Развернуть)