?

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 нужно было тянуть столько лет ? Закрывать безнадежные задачи подобным образом мне кажется не очень правильным решением.

 

 
 
 
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)
Написали так написали
Ох Вы написали, так написали... Всё разложили по полочкам :)