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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Добавьте эти поля на экран типа задачи

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