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

Question

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

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

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

Answer 1

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

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

B. Количество назначений = 1 случай по умолчанию

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

Изменение случая одного призначателя имеет историю, записанную на вкладке «История». В этом случае ничего не потеряно.

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

В моей компании у нас есть аналогичный рабочий процесс для Нихила. Мы работаем в модели Scrum, с разработчиками, тестерами и техническим писателем в каждой команде.

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

Разработка -> Обзор разработчика -> тестирование QA -> PO Acceping -> Готово

Рабочий процесс задачи QA

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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

2. Создайте пользовательское поле в качестве отдельного пользователя для каждой роли, т. Е., Dev, Tester, Reviefer, который будет назначен на разных шагах в выпуске

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

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