Сообщений в теме: 9

[Патрик]

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

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

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

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

Сделал вначале соответствующие статусы в воркфлоу, но реально работает только одна фаза Resolved, а потом все остается, по сути, в этом "начальном" Resolved -- разработка ФС. Все остальные фазы считаются как единый для всех статус Fixed, что не верно.

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

Не смог сделать автоматическое "проталкивание" запроса на следующую фазу с назначением ответственного после успешного завершения текущей фазы.

А когда подумал, что еще есть промежуточные задачи типа "Согласование ТЗ", "Повторная доработка ТЗ после согласования", "Утверждение ТЗ", так вообще стало грусно...

Смотрел я и пермишены, и скрины, но не складывается все это в стройную красивую картинку. :( Может быть я слишком многого хочу от систему багтреккинга? Создается впечатление, что я хочу пластмассовым калькулятором гвозди заколачивать. Помогите советом, пожалуйста!

[maximkr]

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

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

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

ИМХО гуманнее к пользователям сделать чтоб разным группам пользователей выводились разные задачи с помощью фильтрации, но были доступны все.

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

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

Сделал вначале соответствующие статусы в воркфлоу, но реально работает только одна фаза Resolved, а потом все остается, по сути, в этом "начальном" Resolved -- разработка ФС. Все остальные фазы считаются как единый для всех статус Fixed, что не верно.

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

Не смог сделать автоматическое "проталкивание" запроса на следующую фазу с назначением ответственного после успешного завершения текущей фазы.

А когда подумал, что еще есть промежуточные задачи типа "Согласование ТЗ", "Повторная доработка ТЗ после согласования", "Утверждение ТЗ", так вообще стало грусно...

Ну в общем да, workflow в JIRA не предназначен для сильной кастомизации, если хочется что-то отличное от стандартного workflow - в морг, особенно это касается permissions и e-mail notification rules.

Вообще JIRA-шная (и не только) модель когда смена статуса/резолюции/ответственного/внесение времени или комментария делаются отдельными действиями представляется довольно дурацкой. Обычно эти действия связаны самым непосредственным образом - программист resolve-ит багу и меняет ей статус/резолюцию (1), в комментарии указывает что именно он сделал (2), сколько времени это заняло (3), заполнить значения кастом-полей типа номера билда (4), плюс указывает что следующим ответственным должен быть тестировщик (5).
Или пришел от пользователя ответ на какой-то вопрос и саппортер должен переоткрыть багу (1), указать комментарий пользователя (2), указать что дальше ей должен заниматься разработчик (3) и выставить ему Deadline (4).

Зачем это нужно было разносить по пяти разным действиям и думать потом как обратно соединить - не понимаю.

Смотрел я и пермишены, и скрины, но не складывается все это в стройную красивую картинку. :( Может быть я слишком многого хочу от систему багтреккинга? Создается впечатление, что я хочу пластмассовым калькулятором гвозди заколачивать. Помогите советом, пожалуйста!

[реклама]
Да, так и есть, посмотрите тут вторую табличку:
http://www.trackstud...comparison.html

Альтернативный подход к реализации workflow тут (пункты 3 и 4):
http://www.trackstud...n-tutorial.html
[/реклама]

[Патрик]

Спасибо, Максим, за ваш ответ.
За это время я в целом разобрался в JIRA и нашел ответы практически на все вопросы сам. Нужно было сделать все своими руками. Вначале выстроил длинную цепочку (не особо разобравшись, а нужно ли мне это), потом спрямил и объединил некоторые звенья процесса - стало короче и понятнее. Остались два вопроса, на которые не могу найти времени, чтобы установить плагин (точнее хак) и проверить его - ограничение множества возможных assigner'ов при transition в зависимости от роли и ограничение на видимость (выполнимость) transition в завимости от роли.
В остальном же система оказалась вполне приемлемой. Настривать, правда, с нуля ее довольно муторно, после первичной настройки приходится еще докручивать какие то мелочи, которые не видны сразу при просмоте workflow. Проше оказыватеся выгрузить в XML и прикрутить там с последующим импортом из XML.
За ваши ссылики спасибо. Я читал ваши статьи еще до этого.
Пару вопросов по вашей системе. Возможен ли в вашу систему импорт данных из JIRA? Есть ли триальная версия вашей системы, чтобы ее установить импортнуть из JIRA и посмотреть, насколько это будет удобнее. Сравнительная таблица - это лишь таблица, а вот когда пару ошибок/требований проведешь через систему - впечатление совсем другое может быть... :)))

[Патрик]

[

Максим, не в той ветке дал ответ вам. Смотрите на уровень выше в этой же теме.

[APC]

А вот у меня опыт работы с JIRA очень положительный, удалось организовать в ней практически все что хотелось. Сначала настроили трекинг ошибок, потом группа разработки решила задачи на разработку там же вести. Ну и последним аккордом завели проект "Авто-тесты", который видит только группа тестирования, удобно вести задания разработки автотестов...
Могу лишь удивиться, что Патрику не удалось сразу совладать с системой... Хелпы у них вроде неплохие.

[maximkr]

Спасибо, Максим, за ваш ответ.
За это время я в целом разобрался в JIRA и нашел ответы практически на все вопросы сам. Нужно было сделать все своими руками. Вначале выстроил длинную цепочку (не особо разобравшись, а нужно ли мне это), потом спрямил и объединил некоторые звенья процесса - стало короче и понятнее. Остались два вопроса, на которые не могу найти времени, чтобы установить плагин (точнее хак) и проверить его - ограничение множества возможных assigner'ов при transition в зависимости от роли и ограничение на видимость (выполнимость) transition в завимости от роли.

Тут ничего подсказать не могу, не экспериментировали с эти.

За ваши ссылики спасибо. Я читал ваши статьи еще до этого.
Пару вопросов по вашей системе. Возможен ли в вашу систему импорт данных из JIRA? Есть ли триальная версия вашей системы, чтобы ее установить импортнуть из JIRA и посмотреть, насколько это будет удобнее. Сравнительная таблица - это лишь таблица, а вот когда пару ошибок/требований проведешь через систему - впечатление совсем другое может быть... :)))

У нас есть мощный CSV Import, им можно импортировать практически все, но сначала нужно сконфигурировать систему (категории, workflow, права, проекты и т.п.). Импортировать конфигурацию нельзя и смысла не имеет - получим ту же JIRA с другим интерфейсом (это как если переименовать текстовый файл в .html и смотреть в браузере - и не так удобно, и дополнительных преимуществ HTML никаких не видно).

Если интересно - если в TrackStudio залогинится под именем itadmin/itadmin, то получим примерно стандартную конфигурацию JIRA (те же фильтры, workflow, типы задач и т.п.), можно с этим поиграться.

Вообще по опыту на JIRA хорошо ложатся проекты типа самой JIRA (и большинство open source проектов) - ориентация на продукт, маленькая команда или маленькая группа внутри большой организации, простые внутренние процессы и царящий в них "творческий беспорядок", максимальная открытость внутренних процессов для внешнего мира, большое количество внешних пользователей. Конечно, у них есть и другие клиенты, но их опыт использования JIRA не столь удачен (есть доказательства и их много).

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

[Патрик]

Да совладал, совладал... :)))
Но вот только в штатной поставке нет официальной поддержки следующей функциональности: есть несколько проектов, в каждом проекте есть по две группы: программистов и тестировщиков. Причем состав этих групп для этих двух проектов различный. После завершения этапа разработки при переводе запроса на этап тестирования хочется, чтобы для проекта А отображались тестировщики проекта А, а для проекта Б - тестировщики проекта Б. Отображать весь перечень assignable users для того или иного проекта не интересно. Это делается путем установки хака, с которым я пока не разобрался до конца.
Кроме этого хочется, чтобы определенный transition, например, "перевести запрос в тестирование", видели и могли исполнить только члены определенной группы, например, руководители программистов, которые для проекта А и для проекта Б различные. Опять же в штатной поставке этого нет и нужно ставить очередную "приблуду". :)))
А в остальном проблем вроде не было.

[barancev]

Ну в общем да, workflow в JIRA не предназначен для сильной кастомизации, если хочется что-то отличное от стандартного workflow - в морг, особенно это касается permissions и e-mail notification rules.

За что уж Вы их так, Максим? Нормально там настраиваются workflow, можно практически всё, что угодно сделать. Путано очень -- это да, голову сломать можно.

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

[maximkr]

Да совладал, совладал... :)))
Но вот только в штатной поставке нет официальной поддержки следующей функциональности: есть несколько проектов, в каждом проекте есть по две группы: программистов и тестировщиков. Причем состав этих групп для этих двух проектов различный. После завершения этапа разработки при переводе запроса на этап тестирования хочется, чтобы для проекта А отображались тестировщики проекта А, а для проекта Б - тестировщики проекта Б. Отображать весь перечень assignable users для того или иного проекта не интересно. Это делается путем установки хака, с которым я пока не разобрался до конца.

А у нас это штатными средствами делается так:
1) Назначаем что тестировщиками для этого проекта являются пользователи такие-то, а для этого - такие-то.
2) В настройках workflow для соответствующего перехода указываем что tester-ы могут быть назначены при переходе resolve.

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

Кроме этого хочется, чтобы определенный transition, например, "перевести запрос в тестирование", видели и могли исполнить только члены определенной группы, например, руководители программистов, которые для проекта А и для проекта Б различные. Опять же в штатной поставке этого нет и нужно ставить очередную "приблуду". :)))
А в остальном проблем вроде не было.

А у нас это штатными средствами делается так:
1) Назначаем что руководителями программистов для этого проекта являются пользователи такие-то, а для этого - такие-то.
2) В настройках workflow для "перевести запрос в тестирование" указываем что выполнять такие запросы (Can Process) могут только руководители групп программистов.

Все.

Из доп. возможностей:
- можно указать что пользователи будут видеть только transition-ы типа request to customer.
- можно указать что тестировщик может выполнять verify только если он эту багу создал.
- можно указать что программист может делать resolve только если он ответственный, а вот руководитель программистов - в любом случае.

Это все делается без скриптов и хаков, просто кликанием в web UI. Со скриптами делаются более интересные вещи:

- недавно писал скрипт, который вычисляет и выводит как обычное кастом-поле время реакции программистов на саппорт в часах, при этом нерабочие часы и отпуска не учитываются. По мотивам скрипта сделали отчет который считает среднее время ответа для разных программистов за год с соот. внушениями :-)

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

- один клиент любил вносить комментарий в закрытую задачу через e-mail, не переоткрывая ее. После того как комментарии так пару раз потерялись (программисты не мониторят закрытые задачи) - сделали скрипт, который при поступлении комментария от этого клиента в закрытую задачу сам ее переоткрывает.

У нас (и многих наших клиентов) подобный "тюнинг" - практически непрерывный процесс. И на форуме, и в e-mail запросов на написание подобных скриптов (если пользователь сам не может написать) очень много.

[maximkr]

Ну в общем да, workflow в JIRA не предназначен для сильной кастомизации, если хочется что-то отличное от стандартного workflow - в морг, особенно это касается permissions и e-mail notification rules.

За что уж Вы их так, Максим? Нормально там настраиваются workflow, можно практически всё, что угодно сделать. Путано очень -- это да, голову сломать можно.

Когда я смотрел в последний раз, там permissions и e-mail notification events не были связаны с workflow. Т.е. я не могу сделать совершенно новый transition (типа approve by financial approver) и указать что этот тип сообщений может создавать только financial approver, а получать e-mail notification - только project manager. Для стандартных переходов типа resolve это сделать было можно, а для какого-то своего - нет.

Вроде бы они это так и не полечили.

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

Да, я понимаю. До того как начинать делать TrackStudio мы сидели с mantis и все внутренние идеи пытались реализовывать путем правки кода. Где-то через полгода стало понятно что mantis не упрощает нам настройку и контроль процессов, а только мешает. Нововведения сразу упирались в вопрос "и как мы это в mantis реализуем". В итоге идея максимальной гибкости в настройке всего и вся в первые годы работы над TrackStudio была доминирующей, хотя сейчас я понимаю, что мы с этим несколько перестарались :-)