maximkr

Но всё-таки JIRA плохо подходит. Вот если бы версии были древовидными...

Это потому, что JIRA в первую очередь для общения с клиентами делалась, а уж внутренняя кухня разработчиков - как получилось. А клиентам разбираться с глубокими деревьями версий/проектов сложно, особенно если они багтрекер в первый и последний раз видят.

После этого багтрекер на основе всей этой информации вычисляет приоритет ("вес" мнения у разных участников процесса может быть разным) и все участники процесса должны ориентироваться именно на этот вычисленный приоритет.

То есть вместо того чтобы полагаться на одно решение, вносим фактор ошибки многих решений. Бр-р-р.

Т.е. если мне кажется, что нужно делать X, а всем остальным - что нужно делать Y, то лучше втихаря делать свое X, даже не спрашивая почему у остальных другое мнение ?

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

В качестве примера - посмотрите приоритеты багов по JIRA 3.12.x. Там critical-ом оказалась "Unclear error message when bulk moving issues whose reporter cannot create issues", а что-нибудь типа "Moving portlet up reults in IndexOutOfBoundsException" оказалось minor.

Ситуация, когда все подряд назначают "своим" багам приоритет повыше, конкурируя за время команды похожа на "трагедию общих ресурсов":
http://www.seed.slb....nge/tragedy.htm

===
Термин трагедия общих ресурсов появился в 1968 году в статье Гаррета Хардина. Он считает, что проблемы, попадающие под эту категорию, технически решения не имеют. Они требуют изменения поведения и привычек человека.
...
Проблема в том, что большинство из нас действует лишь в собственных интересах, желая получить немедленный эффект. Но потери от влияния этих действий на климат планеты мгновенно не ощущаются. Я могу ездить на большом автомобиле, потому что мне так удобно. Дискомфорт от повышения уровня моря или количества штормов может появиться лишь через несколько десятилетий. Я не вижу прямой взаимосвязи между своими действиями и этими последствиями. Фактически, если бы на большой машине ездил один человек, то негативных последствий не было бы. Так же и пастух, который добавляет одну овцу к стаду – преимущества очевидны и мгновенны, в то время как потери пространны и растянуты по времени. Когда все пастухи поступают так, то в результате в проигрыше оказываются они вместе.

Решение требует взаимодействия людей, вместе принимающих решение об изменении поведения всех, включая себя.
===

Описанная система не отвечает на вопрос: что делать в случае, когда багов сотни? Да, вы получите более тщательную разбивку по весам, но в каждом весе опять будет несколько десятков багов.

Так весов может быть хоть тысяча или даже десять тысяч. Параметры, влияющие на вес тоже могут быть самыми разными: состояние счета клиента, время до дидлайна, группа автора сообщения и время его работы в организации и т.п.

У нас у одного из клиентов был интересный подход к решению проблемы priority/severity.

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

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

Решение: нужно дать возможность высказаться каждой стороне в своем отдельном поле. Т.е. пусть клиент выставляет поле Severity как ему хочется, большое начальство - выставляет приоритет целым проектам, саппорт - заполняет поле "важность" для клиента, менеджер продукта - оценивает насколько ему удобно исправлять это прямо сейчас. После этого багтрекер на основе всей этой информации вычисляет приоритет ("вес" мнения у разных участников процесса может быть разным) и все участники процесса должны ориентироваться именно на этот вычисленный приоритет.

Важно, что все видят откуда у задачи взялся такой приоритет. Например, если саппортер не согласен с низким приоритетом бага, он не просто меняет ему "priority" на high, а смотрит из-за чьей оценки багфикс получил низкий приоритет и идет разговаривать с этим человеком. Удалось его переубедить и человек изменил оценку - отлично, приоритет задачи поднимется автоматически. Саппортер чего-то не знал и его самого переубедили - еще лучше.

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

Интересное обсуждение. По поводу суперпопулярности weblogic/websphere - мы году в 2000 круто попались на эту удочку :-) До того мы занимались заказной автоматизацией, преимущественно Weblogic/ORACLE, поэтому первые версии TrackStudio работали исключительно под WebLogic/ORACLE - это же (теоретически) очень популярная платформа. Так вот, пока не сделали поддержку других СУБД и контейнеров типа Tomcat (на это ушло еще полгода) - продажи были 0 целых 0 десятых.

Если смотреть на нынешних клиентов (а среди них стартапов - процентов 10, наверное, им подобные системы просто не нужны), то
- в качестве сервера приложений большинство используют Tomcat или Jetty, дорогие коммерческие сервера (weblogic/websphere/etc) - процентов 10 клиентов.
- По СУБД - в процентном отношении ORACLE используется российскими клиентами раза в 3 чаще, чем у иностранцев. Есть несколько инсталляций на мэйнфреймовой DB2, а все остальное - MS SQL Server, mysql, PostgreSQL, дефолтный HSQLDB.

С чем связана такая разница между нашими данными и официальной статистикой - я точно не знаю. Версий 2:
- при оценке популярности дорогих продуктов их сравнивают между собой, какое соотношение инсталляций ORACLE и PostgreSQL никого не интересует.
- ORACLE используется для тяжелых продуктов типа SAP, где без ORACLE совсем нельзя. Все остальное стараются туда не ставить чтоб не грузить лишний раз БД, не иметь проблем с доступом к БД для апгрейдов/ручной правки.

Кстати, еще одна ошибка молодости - сначала сильно переоценили квалификацию иностранных пользователей/админов. В России из-за распространенности пиратства системы типа ClearQuest/TeamTrack (были) очень популярны, а их концепции понятны довольно широкому кругу пользователей. По той же причине опыта работы со сложными системами у российских пользователей в целом больше.

На западе ситуация во-многом отличается. Если у той же Serena, например, 3000 клиентов TeamTrack, то только 3000 человек в мире (админы) понимают как подобные системы настраивать и что там нужно крутить, это капля в море. У большинства иностранных клиентов опыт разве что с bugzilla и (реже) mantis, изучение TrackStudio идет тяжело. Хотя в последние годы ситуация улучшилась (наверное, из-за популярности JIRA), вопросы типа "а зачем нужен настраиваемый workflow и иерархия задач" у пользователей возникают на порядок реже.