Имеет ли смысл когда-либо иметь несколько уполномоченных на проблему в системе отслеживания проблем?

Question

Я был администратором JIRA и Bugzilla на прошлых работах, и довольно часто пользователи просили предоставить возможность иметь более одного сотрудника на одну проблему.

Я знаю, что это возможно в JIRA, нона мой взгляд, это никогда не имеет смысла;проблема должна представлять часть работы, и только один человек может выполнить часть работы (по крайней мере, в программном обеспечении, я никогда не использовал трекер проблем для бобслейной команды из 2 человек ;-)) Большая часть работы будеточевидно, в нем участвуют более одного человека, но я думаю, что в этом случае его следует разбить на подзадачи, чтобы обеспечить точную отчетность о состоянии.

Есть ли у кого-либо случаи использования, в которых допустимо иметь несколько назначенных лиц?

Answer 1

Поле Assignee означает много вещей для многих людей.Лучшее имя может быть «Ответственный пользователь».Есть три случая, которые я обсуждаю со своими клиентами:

A.число назначенных = 0 JIRA имеет опцию «Разрешить неназначенные проблемы», но я не рекомендую использовать ее, потому что если рабочий элемент не принадлежит никому, он, как правило, игнорируется всеми.

B.количество правопреемников = 1 Регистр по умолчанию

C.число уполномоченных> 1 Кто отвечает за рабочий элемент, представленный проблемой?Наилучший случай, который я видел в этом, заключается в том, что когда проблема может быть решена любым человеком в команде, так что перед сортировкой проблема назначается всем в этой команде.Я думаю, что лучший подход - это создать пользователя JIRA с адресом электронной почты, который будет рассылаться всей команде, и назначить его этому пользователю.Тогда члену команды может быть назначена проблема, в частности ему.

При изменении одного дела получателя история записывается на вкладке Журнал.В этом случае ничего не потеряно.

Answer 2

У меня часто будет история / функция, которую можно разделить на несколько разработчиков. У них будут индивидуально назначенные подзадачи, но имеет смысл назначить родителя всем вовлеченным, если нет ведущего разработчика. На самом деле я не знал, что могу выполнить несколько заданий, так что спасибо за совет!

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

Answer 3

1. При работе в парной группе (парное программирование и т. Д.) Было бы неплохо назначить для решения оба человека.

2. Задачи проходят различные этапычерез разработку (пример: разработка, обзор, тестирование).За каждый шаг могут отвечать разные люди.Даже если задача находится на рассмотрении или тестировании, у рецензента есть вещи, которые разработчик должен исправить.Наличие разных ролей для назначения поможет в организации работы.

В нашей команде мы обычно развиваем 1 или 2 человека вместе.Затем код проверяется примерно 2-5 людьми по отдельности или парами. Затем он сначала проверяется 1-2 людьми, а затем проверяется всей командой.

В настоящее время наша система позволяет назначать одного человека.в данный момент.Это ограничивает нашу способность следить за тем, кто над чем работает, не просматривая журнал проблем.Для нас было бы полезно иметь возможность назначать нескольких человек.

Answer 4

В моей компании рабочий процесс похож на Nikhil.Мы работаем в scrum-модели, с разработчиками, тестировщиками и техническим писателем в каждой команде.

Рабочий процесс задачи разработки:

Разработка -> Обзор разработчика -> Тестирование качества -> Принятие заказа на поставку -> Готово

Рабочий процесс задачи контроля качества -

QA записывает тестовый пример / автоматический тест -> Проверка QA -> Готово

У нас был инструмент, который заменил JIRA, который позволил нам назначить задачу нескольким людям, что оказалось очень полезным для нашего рабочего процесса,На задании QA я мог легко увидеть, выполнил ли другой тестер в моей команде работу, и мне нужно было сделать следующий шаг.

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

Так много людей просили о возможности иметь несколько сотрудников, по крайней мере, с 2007 года. У них есть разные, действительные варианты использования.Я был разочарован тем, что команда разработчиков JIRA в одностороннем порядке заявила, что не будет реализовывать это, и попросит их пересмотреть.

https://jira.atlassian.com/browse/JRA-12841

Answer 5

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

1. Служба поддержки получает отчет от клиента, создает проблему
2. Спорщик проверяет проблему, чтобы убедиться, что она действительна, а не продублирована, имеет все необходимые данные и т. д.
3. Разработчик реализует / устраняет проблему
4. Тестировщик выполняет все необходимые тесты (в нашем случае, в основном, это расширение нашего автоматизированного набора тестов для дополнительного тестирования функции /исправление)
5. Оператор развертывает новую версию в тестовой среде
6. Служба поддержки информирует клиента, который проводит собственные тесты с новой версией в тестовой среде
7. Оператор выпускает новую версию в производство

Не все проблемы обязательно проходят все этапы.Некоторые проблемы имеют больше шагов (например, проверка кода между шагами 3 и 4).Многие проблемы также будут перемещаться в обратном направлении между этапами (разработчику требуется больше информации, мы переходим с этапа 3 на 1 или 2; тестер обнаруживает проблему, мы переходим с 4 на 3).

На каждом этапе только одинчеловек на самом деле несет ответственность за все, что должно быть сделано.Тем не менее, есть целая группа людей, которые связаны с этой проблемой.Системы отслеживания, которые мы использовали, рады предложить легкие изменения предыдущим владельцам проблемы (отображаются в виде списка), но в идеале я бы хотел пойти дальше, так как владелец автоматически возвращается к правильному предыдущему владельцу в зависимости отстатус вопроса.На шаге 6 первоначальный сотрудник службы поддержки с шага 1 в идеале должен связаться с клиентом.На шаге 7 в идеале должен быть опрашиваемый с шага 5.

Другими словами, хотя я не хочу, чтобы несколько человек были назначены для данного шага, я хочу, чтобы там был «опекун»., «ответственный за разработку», «ответственный за тестирование» и т. д.

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

Answer 6

Что произойдет, если Джону будет назначено задание, и он не сможет его выполнить, и он будет перемещен в список Джейн, потому что Джон был бездельником?

Вы в порядке с потерей истории того, кому он был первоначально назначен, и часов, которые были потрачены / выставлены на счет?

Answer 7

Получил этот ответ от партнера Atlassian https://www.isostech.com/solutions/, а затем от Atlassian

Цель: установить, кто выполняет работы для каждого шага по проблеме

Резюме:Используйте плагин для копирования значений из настраиваемых полей в поле уполномоченного при каждом переходе проблемы к новому этапу.

Как: 1. Установить плагин Suite Utilities: этот плагин добавляет кучу новых функцийв рабочие процессы.

Вы будете использовать плагин, чтобы скопировать значение настраиваемого поля для правопреемника:

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

Добавить эти поля вэкран типа проблемы

Изменить пост-функцию при переходе рабочего процесса между каждым шагом Добавьте функцию публикации «Копировать значение из другого поля» и установите ее для копирования значения из соответствующего пользовательского пользовательскогополе в поле правопреемника.

Answer 8

В сценарии электронного обучения имеет смысл назначить задачу нескольким пользователям.Вот что я хочу сделать: у меня есть раскадровка, которую я хочу назначить 3 людям одновременно - аниматорам, художникам звукозаписи и графическим дизайнерам.Как только эти люди закончат свои задачи, они передадут это общему рецензенту, который рассмотрит и закроет проблему.Графически это будет выглядеть примерно так:

                   Storyboard
                 /     |     \
           graphics animator recording
                 \     |     /
                    reviewer
                       |
                     done

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