?

Log in

No account? Create an account
 
 
27 Август 2010 @ 00:42
Торговля обещаниями, вторая серия  
3 года назад Atlassian закрыл с won't fix задачу про field level security, которая на тот момент была #1 в их списке. По этому поводу было много недовольства со стороны их клиентов, я тогда писал по этому поводу.

Сегодня история повторилась, Atlassian отложила в долгий ящик задачу про локальные приоритеты и резолюции, тоже задачу #1 в текущем списке. Примечательно, что один из комментариев пользователей по поводу этого события весьма близок по смыслу к страничке нашего сайта, написанной лет 5 назад.

Сравните:
"David Chisholm added a comment - 25/Aug/10 2:27 PM
 

My opinion is that Atlassian would prefer customers solve this issue by purchasing JIRA licenses for each type of environment (e.g. help desk, development, etc.) and run a separate JIRA instance for each, and that they'll never admit this. With separate instances, you can achieve most of the per-project customizations needed by allowing only similar project types in each instance. That is what Atlassian appears to do with its own help desk and development instances. However, this is not suitable where issues need to be linked between these environments; adds additional administrative overhead; and adds substantial licensing costs."

и

http://www.trackstudio.ru/products-enterprise.html
"Nevertheless, the majority of systems available do not allow users to specify a separate workflow for each issue type or for each project. Instead, the workflow is defined only once for all issue types and projects. The common solution is to install several instances of a system, where each of them has workflow configured to track a specific issue type or project.

Often such systems have no facilities to copy users, user groups, filters, and reports between instances, making it difficult to synchronize between multiple instances. The administrators in such companies have to spend their time(lots of time!) on installing, configuring, backing up,and upgrading each the instance of the system. The only one who wins in such a situation is the vendor of the issue tracking software. When per-server licenses are used, more instances means more money for the vendor, more money out of you pocket and your administrators are spending more time configuring the software instead of managing their projects."

Хотя, конечно же, Atlassian закрыл эту задачу не по злому умыслу, я помню как все происходило. В JIRA 1.0 была bugzilla-подобная система приоритетов, прав, резолюций, все настраивалось глобально. В JIRA 2.0 они анонсировали поддержку workflow и я тогда сильно сомневался что у них получится - ведь это нужно теперь из этих глобальных приоритетов/резолюций и состояний сделать локальные, специфичные для workflow. Но в Atlassian придумали хитро - они оставили эти настройки глобальными, но разрешили (частично) управлять их доступностью при настройке workflow.

Например, глобальные состояния задачи называются status и настраиваются тут. Но при определении workflow можно указать некие Steps, которые отображаются 1-в-1 на состояния. Смысл этих steps как раз в том, что statuses глобальные, а steps принадлежат конкретному workflow.

Что в этой истории не понятно - зачем хвост отрубать по частям, закрывая подобные задачи по-одной. Ведь еще в JIRA 1.0 было понятно, что из глобальных приоритетов, состояний и резолюций сделать локальные не получится. Этот вопрос наверняка должен был многократно обсуждаться еще во время разработки JIRA 2.0, когда придумывалась схема с steps/statuses. При обсуждении JRA-1330 они вроде бы согласились с тем, что закрывать подобные задачи нужно сразу: "You're absolutely right; the biggest problem was that we chose to delay response to this issue. As a young company that wants very much to please our customers, it's been a tough lesson learned."

Сейчас Atlassian уже не совсем young company, и если lesson был learned, то зачем с JRA-3821 нужно было тянуть столько лет ? Закрывать безнадежные задачи подобным образом мне кажется не очень правильным решением.

 

 
 
 
Макс Васенковwinzard on Август, 26, 2010 22:02 (UTC)
Пишут, что "имели в виду, что в ближайший год не реализуют" http://business-processes.com/jira-customers-force-atlassian-to-resolve-bpm-limitations-of-jira
Максим Крамаренкоmaximkr on Август, 26, 2010 22:42 (UTC)
Все интереснее и глобальнее - они ввели состояния short term roadmap и long term roadmap и проставили их для ряда задач:
http://jira.atlassian.com/browse/JRA#selectedTab=com.atlassian.jira.plugin.system.project%3Apopularissues-panel

Там еще несколько задач попало в long term roadmap, но по ним все тихо.
Teoteo_bon on Август, 27, 2010 19:09 (UTC)
Второй раз встречаю этот странный сайт (busines-processes.com) в контексте обсуждения JIRA. То ERP системой назовут, то BPM системой... Как до первой, так и до второй JIRA расти и расти. И не только ей, а любому issue tracker'у. Ибо и цели совсем другие, и мощности с гибкостью несравнимые. С ERP ни разу не сравнивал (т.к. было очевидно, что вещи несравнимые), а вот с BPMS вполне - можно посмотреть на Unify NXJ, на бюджетный вариант Elma от Elewise, на open source Intalio BPMS... Другие цели, другие возможности, другие цены.
Максим Крамаренкоmaximkr on Август, 27, 2010 20:56 (UTC)
Ну, не совсем любому issue tracker-у :-) Раньше был такой трекер - TeamShare TeamTrack, хороший трекер. Потом их купила Serena, сначала они мигрировали на него клиентов PVCS, а сейчас обозвали Bussiness Mashups и продают как средство автоматизации бизнес-процессов:
http://www.serena.com/products/sbm/features/process-platform.html

Когда я смотрел их в последний раз, у них из интересного был графический редактор Workflow и возможность наследования Workflow. Security в TrackStudio лучше, в остальном примерно похоже было. Сравнение TeamTrack с JIRA тоже есть: http://www.softmart.ru/ru/nlist/a3686.htm

TrackStudio де-факто очень часто используется для автоматизации разных бизнес-процессов, в том числе мало связанных с IT. Обычно это какие-то сложные или частоменяющиеся процессы, лежащие несколько в стороне от основной деятельности компании, которые не покрываются другим софтом.
Teoteo_bon on Август, 27, 2010 21:25 (UTC)
Позиционировать можно как угодно. И говорить, что "наш продукт - что ни на есть 100% BPM(S) решение" - тоже можно. Только от этого продукт не становится действительно BPMS решением ;) и Workflow решения (в класс которых входят все issue trackers) всё же отличаются от BPMS (которые отлично помогают как в оркестровке, так и в хореографии бизнес-процессов, поддерживают разные версии BPMN, имеют продвинутые дизайнеры процессов, а также визуальный мэппинг к веб-сервисам и т.д. - опять же, сколько людей, столько и определений).

Кстати, мы сами используем TS для организации некоторых бизнес-процессов, не связанных с IT. И чего не хватает - так это пакетных действий (вот это всё запаковать и отправить этим-то рейсом туда-то - то есть не так, как сейчас работают batch скрипты, требуется осведомленность скрипта о том, что он обрабатывает сразу несколько задач), ajax интерфейса в плане быстрого выполнения действий (возможно, прямо из списка задач - сейчас открытие задачи занимает секунды 2 минимум, психологически такое ожидание для каждого шага утомляет - особенно, если с системой работать постоянно и весь день, а не как в разработке софта - открыл TS, получил задание, ушел в работу на два часа, сделал, зашел в TS, отметился),
Антон Сергеевsdelatpravilno on Март, 27, 2017 19:22 (UTC)
Написали так написали
Ох Вы написали, так написали... Всё разложили по полочкам :)
Максим Крамаренкоmaximkr on Август, 27, 2010 22:17 (UTC)
По поводу Batch-скриптов - надо подумать. Идея обрабатывать по-одной задачи возникла исключительно из соображения простоты скриптов. Возможно, стоит реализовать 2 варианта интерфейса и поддерживать оба.

По поводу тормозов - а какая версия TS ? У нас сейчас 4.0.5, в системе порядка 70 тысяч задач, сервер не самый мощный и в штатах (amazon ec2, highcpu/medium instance), открыть задачу из списка занимает как раз 2 секунды (максимум). В 4.0.5 были ускорения, связанные с выводом кастом-полей типа task и обратных ссылок на задачи.

Вообще при обработке большого количества задач мне нравится листалка влево-вправо - т.е. сразу выбираем все интересные задачи фильтром, а потом перемещаемся между ними, минуя список задач.
Макс Васенковwinzard on Август, 28, 2010 06:33 (UTC)
Реализовать на базе bulk обработку нескольких задач совместно довольно просто. Надо интерфейс расширить и передавать список целиком, без обработки. Это несколько строк кода.
Максим Крамаренкоmaximkr on Сентябрь, 3, 2010 13:44 (UTC)
Собственно, сделали. В 4.0.6 будет.