Има ли смисъл някога да има няколко възложители за проблем в инструмент за проследяване на проблеми?

Полето Назначение означава много неща за много хора. По-добро име може да бъде „Отговорен потребител“. Има три случая, които обсъждам с моите клиенти:

A. брой правоприемници = 0 JIRA има опция Allow Unassigned issues, но аз не препоръчвам използването й, защото ако даден работен елемент не е собственост на никого, той обикновено се игнорира от всички.

Б. брой правоприемници = 1 Случаят по подразбиране

C. брой на назначените > 1 Кой е отговорен за работния елемент, представен от проблема? Най-добрият случай, който съм виждал за това, е, че когато даден проблем може да бъде обработен от всеки един човек в екип, така че преди сортирането проблемът се възлага на всички в този екип. Мисля, че по-добрият подход е да създадете потребител на JIRA с имейл адрес, който изпраща до целия екип, и да го присвоите на този потребител. След това член на екипа може да възложи проблема конкретно на него.

Промяната на един случай на възложител записва хронологията в раздела История. Нищо не се губи в този случай.

Често ще имам история/функция, която може да бъде разделена между множество разработчици. Те ще имат индивидуално зададени подзадачи, но би имало смисъл да се присвои родителят на всички участващи, освен ако няма водещ разработчик. Всъщност не знаех, че мога да изпълнявам множество задачи, така че благодаря за съвета!

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

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

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

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

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

С други думи, въпреки че не искам множество възложени лица за дадена стъпка, искам да има „упълномощено лице за поддръжка“, „упълномощено лице за разработчици“, „упълномощено лице за тестване“ и т.н.

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

В моята компания имаме подобен работен процес като Nikhil. Ние работим по модел на схватка, с разработчици, тестери и технически писател във всеки екип.

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

Разработка -> Преглед от разработчици -> QA тестване -> Приемане на поръчка -> Готово

Работният процес на QA задача е

QA пише тестов случай / автоматизиран тест -> QA преглед -> Готово

Имахме инструмент, който JIRA замени, който ни позволи да назначим няколко души за задача, което намерихме за много полезно за нашия работен процес. При QA задача можех лесно да видя дали другият тестер от моя екип вече е свършил работа и трябва да направя следващата стъпка.

Без това ми е трудно бързо да идентифицирам задачи, написани от другия тестер в моя scrum екип, които са готови за преглед (в сравнение с тези, които съм написал, които те трябва да прегледат).

Толкова много хора поискаха възможността да имат множество правоприемници поне от 2007 г. насам. Те имат различни валидни случаи на употреба. Бях разочарован, че екипът за разработка на JIRA едностранно каза, че няма да приложи това и ще ги помоли да преразгледат.

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

1. Докато работите в група по двойки (програмиране по двойки и т.н.), би било хубаво да назначите и двамата лица за проблема.

2. Задачите преминават през различни стъпки чрез разработка (пример: разработка, преглед, тестване). Различни лица могат да бъдат отговорни за всяка стъпка. Въпреки че задачата може да е в процес на преглед или тестване, рецензентът ще има неща, които разработчикът трябва да коригира. Разпределянето на различни роли би помогнало при организирането на работата.

В нашия екип обикновено развиваме 1 или 2 човека заедно. След това кодът се преглежда от около 2-5 души индивидуално или по двойки. След това се тества първоначално от 1-2 души, накрая се тества от целия екип.

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

Какво се случва, ако на Джон е възложена задача и той не може да я завърши и тя бъде преместена в списъка на Джейн, защото Джон е бил мързеливец?

Съгласни ли сте със загубата на история на кого е била първоначално възложена и часовете, които са изразходвани/таксувани за нея?

В сценарий за електронно обучение има смисъл проблемът да бъде възложен на множество потребители. Ето какво искам да направя: Имам сценарий, който искам да възложа на 3-ма души едновременно - аниматорите, звукозаписните артисти и графичните дизайнери. След като тези хора завършат задачите си, те ще го предадат на общ проверяващ, който ще прегледа и затвори проблема. Графично би изглеждало така:

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

Трите работни роли зависят само от един сценарий. Компилацията от трите трябва да отиде при рецензент. Блъскам мозъка си, за да накарам това да работи на redmine. Все още не съм намерил решение.

Получих този отговор от партньор на Atlassian https://www.isostech.com/solutions/ и след това по-късно от Атласиан

Цел: Искате да зададете кой да върши работата за всяка стъпка по даден проблем

Резюме: Използвайте плъгин, за да копирате стойности от потребителски полета в полето за възложител, когато проблемът премине към нова стъпка.

Как: 1. Инсталирайте добавката Suite Utilities: Тази добавка добавя куп нови функционалности към работните процеси.

Ще използвате приставката, за да копирате стойността на персонализирано поле на получателя:

2. Създайте персонализирано поле като инструмент за избор на един потребител за всяка роля, т.е. разработчик, тестер, рецензент, които да бъдат присвоени на различни стъпки в проблема

3. Добавете тези полета към екрана на типа проблем

4. Променете пост-функцията при прехода на работния поток между всяка стъпка Добавете пост-функция „Копиране на стойност от друго поле“ и я настройте да копира стойността от съответното персонализирано поле на потребителя в полето на получателя.