Здравствуйте, hrynchuk, Вы писали:

h> GIV>Репортер — это репортер, то есть тот кто создал issue. А все остальные его обязанности определяется установленным в данном проекте workflow. Репортеру может и не пофиг но нет вот у него доступа/квалификации/времени чтобы заниматься этим.

h> Тогда меняется репортер на другого и делов. Раз один репортер не может выполнить свою задачу то он делегирует ее другому репортеру.

Очень странное действие. Репортер может понадобиться, например, чтобы выяснить более детально как воспроизвести баг.

Здравствуйте, hrynchuk, Вы писали:

.>>Задачи разные могут быть. Может быть задачи для тестеров, например, "подготовить тестовые данные", открывает девелопер, а фиксится тестером.
H>Что значит разные задачи? Задача атестера не ставить задачу разработчику, и ни кому бы то ни было. Все что что может тестер савить (и тут действительно вопрос кому? — скорее всего менеджеру заассайнить) — это багу, или импрувемент. А менеджер решит стоит эта "постановка" внимания или нет.
Не понял возражение. Я пишу, что всякое бывает — разработчик может создать задачу для тестера. Тестер должен её пофиксить, а разработчик закрыть. Роли у статусов меняются.

H>Если меняется статус — все четко и прозрачно понятно — если нет — приводите конкретно пример, а то очевидность ответа на этот вопрос и то что другие (Вы) прикидываются что его нету начинает слегка рахдаражать. Задача которая опен и заасайнена на менеджера — предстоит к расмотрению — эта задача или пойдет на девелопера или удалится к черям. Задача которая на разработчике в статусе опен — принимается к обработке разработчиком и никем другим, она может только зарезолвится и больше ничто другое. Резолв может быть или Fixed или Wont Fix (и здесь в коментах нужно указать с какой радости разраб не хочет ее фиксить) и по статусу легко понять кто должен принять таску (без переасайна). Например Wont fix — смотрит менеджер, Fixed — смотрит тестер и проверят пофикшено или нет.
Когда 20 разработчиков и 30 тестеров, пара менеджеров (скажем гуй и сервер), б-аналитики. Кто за что отвечает, если таска open/fixed/wont fix? Кто ответит на вопрос в каком состоянии идёт её разработка/тестирование/уточнение требований? Подходишь к одним — "ну тестовые данные корявые", другие "ну это бага в коде", "ну это гуй", "ну это сервер сайд", "да вообще оно так и должно быть, наверное". И пошло по кругу. И что делать? Собирать совещание на 50 человек, чтобы выяснять кто виноват, что делать и когда это всё наконец-то кончится?

.>>Т.е. у вас по статусу и паре других соседних полей можно неявно вывести кто же именно должен работать над таском. Если народу много, да ещё и сидят в разных офисах, то статусов станет не хватать. Возникает ситуация, won't fix, но непонятно — толи тест кривой, толи требования надо менять, толи тупо по ошибке дев жмакнул не ту кнопку.
H>Каких именно и кому не хватает статусов? Примеры в студию — Это раз, во вторых статусы можно добавлять для тех кому их не хватает. На самом деле не так уж и много. Кстати есть еще и типы задач, которыми тожно можно дополнительно определять кто должен заниматься задачей.
Когда кол-во статусов одного порядка с числом участников проекта, то ещё жить можно, а дальше — хаос.

H>А вот ответьте мне — зачем статусы вообще если на каждый чих переассайнивать задачу?
Статус говорит о том, в каком состоянии находится задача — сделана|не сделана|непонятно что делать|не понятно как делать|делать не надо|т.п. А ассайнмент говорит о том, кто в данный момент над ней должен работать и кто отвечает за её выполнение (прогресс). Я понимаю эти поля так. А твоё какое понимание?

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

Здравствуйте, hrynchuk, Вы писали:

H>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...

Собственно вопрос — у кого какой workflow а jira?

Здравствуйте, hrynchuk, Вы писали:

H>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например...
H>Что мне кажется несколько нелогичным...

А что менеджер с этой задачей дальше должен делать?

Здравствуйте, robin_of_the_wood, Вы писали:


___>А что менеджер с этой задачей дальше должен делать?

Переассайнить дальше по цепочке... например на тестера.

Здравствуйте, hrynchuk, Вы писали:

H>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...

Да нормально, а что не так с этим?

Здравствуйте, GarryIV, Вы писали:

GIV>Здравствуйте, hrynchuk, Вы писали:

H>>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...

GIV>Да нормально, а что не так с этим?

Ну а разве не достаточно просто зарезолвить? А тот кто reporter дальше сам примет решение что делать дальше с задачей. Да и представьте себя в роли менеджера — сидеть и оперативно реассайнить таски...

Здравствуйте, hrynchuk, Вы писали:

___>>А что менеджер с этой задачей дальше должен делать?

H>Переассайнить дальше по цепочке... например на тестера.

Ну если менеджера такой вариант устраивает, то проблемы может и нет.
Или Вы и есть этот менеджер?

Здравствуйте, hrynchuk, Вы писали:

H>>>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...

GIV>>Да нормально, а что не так с этим?

H>Ну а разве не достаточно просто зарезолвить? А тот кто reporter дальше сам примет решение что делать дальше с задачей. Да и представьте себя в роли менеджера — сидеть и оперативно реассайнить таски...

Все сильно по-разному в разных воркфлоу. Репортер вообще может быть не причем. Я вон периодически репорчу баги во open source и не очень проектах — мне теперь ассайнить их прикажете?

У нас разработчики назначают задачи:
* когда отправляют их на code review
* когда отправляют их на тестирование (еще до коммита в транк)

GIV>Все сильно по-разному в разных воркфлоу. Репортер вообще может быть не причем. Я вон периодически репорчу баги во open source и не очень проектах — мне теперь ассайнить их прикажете?

В том-то и суть — Вы пишете ошибку — Вам ее и проверять Ассайнить не нужно.

___>Ну если менеджера такой вариант устраивает, то проблемы может и нет.
___>Или Вы и есть этот менеджер?

К счастью или не счастью я не есть тот менеджер. Просто интересно как правильнее а не как "привык".

Здравствуйте, hrynchuk, Вы писали:

GIV>>Все сильно по-разному в разных воркфлоу. Репортер вообще может быть не причем. Я вон периодически репорчу баги во open source и не очень проектах — мне теперь ассайнить их прикажете?

H>В том-то и суть — Вы пишете ошибку — Вам ее и проверять

Ты ведь пошутил да?

H>Ассайнить не нужно.

Здравствуйте, hrynchuk, Вы писали:

H>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...
Мы понимаем поле "assignment" как человека ответственного за прогресс задачи. Поэтому, после того, как разработчик пофиксил, то нужно реассайнить на следующего ответственного — тестер, если разработчик знает которому, или менеджер, если не знает, менеджер должен выбрать тестера и реассайнить на него. Тестер должен протестить, закрыть таск и установить "Not assigned".

Кстати, поэтому assignment может быть только один. Если за что-то отвечает более одного человека, то это означает, что не отвечает никто.
И алгоритм "горячей картошки" — если на тебя что-то заасайнено, то ты должен перебросить следующему как только понимаешь, что ты не можешь делать что-то по задаче.
Т.е. если ты как разработчик пофиксить не можешь, т.к., например, неясны требования, ассайнишь на бизнес-аналитика с вопросом, и т.п.
Или, например, у твоего таска дедлайн завтра, а ты занят чем-то более приоритетным — ассайнишь на менеджера, комментируя что не можешь сделать. Менеджер сразу увидит, что что-то не то.

GIV>Ты ведь пошутил да?

H>>Ассайнить не нужно.
GIV>


Ну не совсем, если кто-то хочет чтоб выполнили его просьбу — то это нужно именно ему а не кому-то другому, всем пофигу выполнено это требование или нет — а вот репортеру...

Здравствуйте, hrynchuk, Вы писали:


GIV>>Ты ведь пошутил да?

H>>>Ассайнить не нужно.
GIV>>


H>Ну не совсем, если кто-то хочет чтоб выполнили его просьбу — то это нужно именно ему а не кому-то другому, всем пофигу выполнено это требование или нет — а вот репортеру...

Репортер — это репортер, то есть тот кто создал issue. А все остальные его обязанности определяется установленным в данном проекте workflow. Репортеру может и не пофиг но нет вот у него доступа/квалификации/времени чтобы заниматься этим.

Здравствуйте, hrynchuk, Вы писали:

H>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...

Это или jira такая, или, что скорее всего, её не настроили.
Цель понятна — чтобы, если задачу переоткроют, менеджер разобрался, на кого её свалить. Но нужно ли для этого использовать именно поле текущего ответственного? Точно так же можно применять и статус, и хуки на открытие...
Скорее всего, описанное Вами правило вызвано текучкой кадров (к моменту переоткрытия задачи владелец или на другом проекте, или вообще уволился, и всё равно менеджеру заново решать, кто этим займётся). Я привык к более стабильной обстановке и ответственности каждого (видишь, что не твоя задача — сам и сразу перебрось на начальство).

GIV>Репортер — это репортер, то есть тот кто создал issue. А все остальные его обязанности определяется установленным в данном проекте workflow. Репортеру может и не пофиг но нет вот у него доступа/квалификации/времени чтобы заниматься этим.

Тогда меняется репортер на другого и делов. Раз один репортер не может выполнить свою задачу то он делегирует ее другому репортеру.

Здравствуйте, ., Вы писали:

.>Здравствуйте, hrynchuk, Вы писали:

H>>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...
.>Мы понимаем поле "assignment" как человека ответственного за прогресс задачи. Поэтому, после того, как разработчик пофиксил, то нужно реассайнить на следующего ответственного — тестер, если разработчик знает которому, или менеджер, если не знает, менеджер должен выбрать тестера и реассайнить на него. Тестер должен протестить, закрыть таск и установить "Not assigned".

.>Кстати, поэтому assignment может быть только один. Если за что-то отвечает более одного человека, то это означает, что не отвечает никто.
Отвечает ОДИН человек за задачу в определенном состоянии — девелопер за Open, тестер за Fixed, ..., ...

.>И алгоритм "горячей картошки" — если на тебя что-то заасайнено, то ты должен перебросить следующему как только понимаешь, что ты не можешь делать что-то по задаче.
Перебросить кому следующему? Я выполняю свою работу, а кто там "следующий" я могу и не знать, особенно когда их больше одного

.>Т.е. если ты как разработчик пофиксить не можешь, т.к., например, неясны требования, ассайнишь на бизнес-аналитика с вопросом, и т.п.
Я ставлю статус Won't fix — incomplete — таким образом репортер четко понимает почему таска не фиксится

.>Или, например, у твоего таска дедлайн завтра, а ты занят чем-то более приоритетным — ассайнишь на менеджера, комментируя что не можешь сделать. Менеджер сразу увидит, что что-то не то.
Нет, я ставлю Wont fix или Postponed или менеджер должен и так понимать что времени на сегодня не хватит.

Здравствуйте, Dziman, Вы писали:

D>Здравствуйте, hrynchuk, Вы писали:

h>> GIV>Репортер — это репортер, то есть тот кто создал issue. А все остальные его обязанности определяется установленным в данном проекте workflow. Репортеру может и не пофиг но нет вот у него доступа/квалификации/времени чтобы заниматься этим.

h>> Тогда меняется репортер на другого и делов. Раз один репортер не может выполнить свою задачу то он делегирует ее другому репортеру.

D>Очень странное действие. Репортер может понадобиться, например, чтобы выяснить более детально как воспроизвести баг.

Я ставлю статус Won't Fix — Incomplete — пусть текущий репортер парится. Он обязан знать как проверять задачу.

Здравствуйте, hrynchuk, Вы писали:

h> D>Очень странное действие. Репортер может понадобиться, например, чтобы выяснить более детально как воспроизвести баг.

h> Я ставлю статус Won't Fix — Incomplete — пусть текущий репортер парится. Он обязан знать как проверять задачу.

Не обязан В общем, все зависит от процесса принятого на проекте.

полагаю на каких-то проектах имеет смысл, но это микроменеджмент какой-то, и никак не способствует проактивной работе команды

типовой процесс которому команды в которых я работал пытались следовать и который лично меня вполне устраивал выглядел примерно так (он фактически исключает необходимость ассайнить что-либо)

1. планирование — составляется набор джир которые будут выполнены в данном 2-3х недельном спринте, эти джиры помещается в соответствующую версию продукта в джире в состоянии TO DO (*)
2. основная визуализация прогресса — гринхопперовские таскборды (гринхоппер это плагин к джире чтоли?)
3. разработчики смотрят на таскборд и берут любые понравившиеся задачи (**), помещают их в состояние IN PROGRESS (тут на самом деле джира проассайнит автоматически на того кто кнопку нажал), была ли задачи проассайнена на кого-нибудь в состоянии TO DO — на важно, джиры в состоянии IN PROGRESS же никто трогать не может, по выполнении джиры ресолвятся в DEV DONE
4. тестировщики по обнаружении джиры в столбце DEV DONE, начинают тестирование, переводят джиры в IN QA и затем в CLOSED (тут видел 2 варианта, некоторые тестировщики любят ассайнить джиры на себя, а некоторые оставлять на разработчиках, чтобы было лучше видно кому задавать вопросы)

вся команда должна ежедневно работать с/мониторить таскборд (что обычно делается на стендапах),
"владелец" джиры в целом тут нигде не обязателен, лишь позволяет проще определять подвисшие джиры и их статус (всегда можно по хистори поднять все переходы из состояния в состояние)

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

(*) гринхоппер также удачно позволяет группировать джиры под какой-либо story, что отлично структурирует таксборд
(**) разработчики обычно все таки берут джиры из своей области компетенции

Здравствуйте, hrynchuk, Вы писали:

H>К счастью или не счастью я не есть тот менеджер. Просто интересно как правильнее а не как "привык".

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

Здравствуйте, hrynchuk, Вы писали:

GIV>>Репортер — это репортер, то есть тот кто создал issue. А все остальные его обязанности определяется установленным в данном проекте workflow. Репортеру может и не пофиг но нет вот у него доступа/квалификации/времени чтобы заниматься этим.

H>Тогда меняется репортер на другого и делов. Раз один репортер не может выполнить свою задачу то он делегирует ее другому репортеру.

Чтоб запутать что ли?

GIV>Чтоб запутать что ли?


Кого?

Здравствуйте, hrynchuk, Вы писали:

.>>Кстати, поэтому assignment может быть только один. Если за что-то отвечает более одного человека, то это означает, что не отвечает никто.
H>Отвечает ОДИН человек за задачу в определенном состоянии — девелопер за Open, тестер за Fixed, ..., ...
Задачи разные могут быть. Может быть задачи для тестеров, например, "подготовить тестовые данные", открывает девелопер, а фиксится тестером.

.>>И алгоритм "горячей картошки" — если на тебя что-то заасайнено, то ты должен перебросить следующему как только понимаешь, что ты не можешь делать что-то по задаче.
H>Перебросить кому следующему? Я выполняю свою работу, а кто там "следующий" я могу и не знать, особенно когда их больше одного
Ты должен знать кому передать ответственность. Если не знаешь — перебрось тому, кто ты думаешь должен знать/назначить ответственного, если не туда бросишь — перебросят куда надо. В этом случае в процессе передачи ответственности участвуют ровно 2 человека — ты, и тот на кого ассайнишь. Делаешь что-то не то, сразу понятно с кого спросить. А если просто меняется статус — кто конкретно должен подхватить таску — непонятно. Ты отказался от ответственности, а "после нас хоть потоп" — бросил таску, а никто не ловит.

H>Я ставлю статус Won't fix — incomplete — таким образом репортер четко понимает почему таска не фиксится
H>Нет, я ставлю Wont fix или Postponed или менеджер должен и так понимать что времени на сегодня не хватит.
Да... тоже можно. Но это годится только если маленькая команда, десяток человек и все друг-друга знают. И если "incomplete", всем очевидно, что действие должен делать Вася, т.к. он тестер, статус Open и связано с UI, значит Петя, т.к. он яваскрипт лабает, и т.п.
Т.е. у вас по статусу и паре других соседних полей можно неявно вывести кто же именно должен работать над таском. Если народу много, да ещё и сидят в разных офисах, то статусов станет не хватать. Возникает ситуация, won't fix, но непонятно — толи тест кривой, толи требования надо менять, толи тупо по ошибке дев жмакнул не ту кнопку.

Здравствуйте, hrynchuk, Вы писали:

H>Например обнаружил что у нас в компании когда разрабочик пофиксил задачу он должен после резолва заассайнить ее на менеджера например... Что мне кажется несколько нелогичным...

У нас сделано по разному. Баги\улучшения ("задачи программистов") всегда назначены программисту, а статус меняется по мере деятельности над задачей. В частности есть статус "на проверке", по которому они вытаскиваются тестером.
Какой тестер будет эту задачу тестировать решается отдельным запросом "Задание на тестирование", который имеет отдельный воркфлоу и уже назначен на тестера.

С другой стороны есть воркфлоу, в которых назначенный меняется по мере изменения статусов

Здравствуйте, ., Вы писали:

.>Задачи разные могут быть. Может быть задачи для тестеров, например, "подготовить тестовые данные", открывает девелопер, а фиксится тестером.

Что значит разные задачи? Задача атестера не ставить задачу разработчику, и ни кому бы то ни было. Все что что может тестер савить (и тут действительно вопрос кому? — скорее всего менеджеру заассайнить) — это багу, или импрувемент. А менеджер решит стоит эта "постановка" внимания или нет.

.>Ты должен знать кому передать ответственность. Если не знаешь — перебрось тому, кто ты думаешь должен знать/назначить ответственного, если не туда бросишь — перебросят куда надо. В этом случае в процессе передачи ответственности участвуют ровно 2 человека — ты, и тот на кого ассайнишь. Делаешь что-то не то, сразу понятно с кого спросить. А если просто меняется статус — кто конкретно должен подхватить таску — непонятно. Ты отказался от ответственности, а "после нас хоть потоп" — бросил таску, а никто не ловит.

Если меняется статус — все четко и прозрачно понятно — если нет — приводите конкретно пример, а то очевидность ответа на этот вопрос и то что другие (Вы) прикидываются что его нету начинает слегка рахдаражать. Задача которая опен и заасайнена на менеджера — предстоит к расмотрению — эта задача или пойдет на девелопера или удалится к черям. Задача которая на разработчике в статусе опен — принимается к обработке разработчиком и никем другим, она может только зарезолвится и больше ничто другое. Резолв может быть или Fixed или Wont Fix (и здесь в коментах нужно указать с какой радости разраб не хочет ее фиксить) и по статусу легко понять кто должен принять таску (без переасайна). Например Wont fix — смотрит менеджер, Fixed — смотрит тестер и проверят пофикшено или нет.

.>Т.е. у вас по статусу и паре других соседних полей можно неявно вывести кто же именно должен работать над таском. Если народу много, да ещё и сидят в разных офисах, то статусов станет не хватать. Возникает ситуация, won't fix, но непонятно — толи тест кривой, толи требования надо менять, толи тупо по ошибке дев жмакнул не ту кнопку.

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

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

Здравствуйте, ., Вы писали:

.>Здравствуйте, hrynchuk, Вы писали:

.>Не понял возражение. Я пишу, что всякое бывает — разработчик может создать задачу для тестера. Тестер должен её пофиксить, а разработчик закрыть. Роли у статусов меняются.
К сожалению не могу придумать сейчас случая какую это задачу можно дать тестеру кроме как "протести что-то"... или напиши вконец нормальный Steps to reproduce со скринами...

.>Когда 20 разработчиков и 30 тестеров, пара менеджеров (скажем гуй и сервер), б-аналитики. Кто за что отвечает, если таска open/fixed/wont fix? Кто ответит на вопрос в каком состоянии идёт её разработка/тестирование/уточнение требований? Подходишь к одним — "ну тестовые данные корявые", другие "ну это бага в коде", "ну это гуй", "ну это сервер сайд", "да вообще оно так и должно быть, наверное". И пошло по кругу. И что делать? Собирать совещание на 50 человек, чтобы выяснять кто виноват, что делать и когда это всё наконец-то кончится?
Ну так нужно научить всех пользоваться инструментом, и в таком случае нужно провести курсы, как иначе? Или у вас сидит 20 обезьян которые не в состоянии освоить элементарные вещи?

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

.>Статус говорит о том, в каком состоянии находится задача — сделана|не сделана|непонятно что делать|не понятно как делать|делать не надо|т.п. А ассайнмент говорит о том, кто в данный момент над ней должен работать и кто отвечает за её выполнение (прогресс). Я понимаю эти поля так. А твоё какое понимание?

И для кого этот статус? для того на кого заасайнена задача? Типа я поставил статус — не знаю че делать... и задача висит тупо на мне.

Мое понимание простое — ассайни принмается за работу когда на нем задача в статусе опен, репортер принимается за проверку когда задача (не на нем) в статусе Fixed. Менеджер обрабатывает задачу в статусе "Не хочу фиксить" ....

Здравствуйте, hrynchuk, Вы писали:

.>>Не понял возражение. Я пишу, что всякое бывает — разработчик может создать задачу для тестера. Тестер должен её пофиксить, а разработчик закрыть. Роли у статусов меняются.
H>К сожалению не могу придумать сейчас случая какую это задачу можно дать тестеру кроме как "протести что-то"... или напиши вконец нормальный Steps to reproduce со скринами...
От сложности и размера проекта зависит, очевидно. У нас бывает "приготовьте юзерский аккаунт с такими-то фичами включенными, с такими-то сервисами купленными".

.>>Когда 20 разработчиков и 30 тестеров, пара менеджеров (скажем гуй и сервер), б-аналитики. Кто за что отвечает, если таска open/fixed/wont fix? Кто ответит на вопрос в каком состоянии идёт её разработка/тестирование/уточнение требований? Подходишь к одним — "ну тестовые данные корявые", другие "ну это бага в коде", "ну это гуй", "ну это сервер сайд", "да вообще оно так и должно быть, наверное". И пошло по кругу. И что делать? Собирать совещание на 50 человек, чтобы выяснять кто виноват, что делать и когда это всё наконец-то кончится?
H>Ну так нужно научить всех пользоваться инструментом, и в таком случае нужно провести курсы, как иначе? Или у вас сидит 20 обезьян которые не в состоянии освоить элементарные вещи?
Причём тут это? Я не понимаю как из статуса (которых всего N) вывести человека (которых 20*N) который должен работать над задачей, если поле ассайн всегда висит один и тот же дев, репортер — юзер, которому всё пофиг, и вообще в отпуск укатил. Ассайни-дев, основательно почесав затылок, невнятно вспоминает, что кто-то другой кому-то из тестеров, но кому уже не помнит, 2 недели назад послал письмо с уточняющим вопросом, но тестер не знал ответ, поэтому поговорил по телефону с БА, но тот обещал перезвонить и т.п. А так в истории будет чёткая цепочка реассайнов (обычно с комментами) кто, когда, и что сделал и чего добился в жизни таска.

Теоретически невозможно замапить N элементов однозначно на 20*N элементов.

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

.>>Статус говорит о том, в каком состоянии находится задача — сделана|не сделана|непонятно что делать|не понятно как делать|делать не надо|т.п. А ассайнмент говорит о том, кто в данный момент над ней должен работать и кто отвечает за её выполнение (прогресс). Я понимаю эти поля так. А твоё какое понимание?
H>И для кого этот статус? для того на кого заасайнена задача?
Для описания состояния задачи. Что с задачей происходит на данный момент. Чтобы можно было видеть какие задачи сделаны, запланированы в следующий майлстоун, оценить прогресс по всем задачам в целом.

H>Типа я поставил статус — не знаю че делать... и задача висит тупо на мне.
Значит за провал успешного завершения задачи, за срыв сроков отвечаешь ты. Если ты не знаешь что делать, ты должен найти того, кто знает и заасайнить на него. Если ты не можешь, должен заасайнить на менеджера проекта, чтобы он решал это сам. Что непонятного-то?

H>Мое понимание простое — ассайни принмается за работу когда на нем задача в статусе опен, репортер принимается за проверку когда задача (не на нем) в статусе Fixed. Менеджер обрабатывает задачу в статусе "Не хочу фиксить" ....
А если менеджеров 2, девов 20, 30 тестеров и 100000 юзеров-репортеров?
В общем да, если в вашей команде народу не очень много, то статусом можно обойтись, ибо легко догадаться кто именно сейчас работает над таском просто посмотрев на статус. Но в общем случае это не прокатывает.

Здравствуйте, hrynchuk, Вы писали:

H>Ну не совсем, если кто-то хочет чтоб выполнили его просьбу — то это нужно именно ему а не кому-то другому, всем пофигу выполнено это требование или нет — а вот репортеру...

Такое ощущение, что вы пишете какой-то внутренний продукт

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

Далее уже в работу включится ваш принятый воркфлоу обработки ошибок (классификация, шедулинг, назначение на разработчика и т.п.)

Здравствуйте, hrynchuk, Вы писали:

H>Переассайнить дальше по цепочке... например на тестера.

Крайне неудобно. Теряется связь между разработчиком и его задачей. У нас тестировщик тестирует все, что в его колонке.
Но тестировщик у нас один, так что все, что в колонке на тестирование — его.
Очень неудобно, что нельзя на двоих асайнить одновременно.

В случае содним тестером смысла реассайнить вообще нету. Ана счеи множественного ассайни — можно наверное поднастроить жиру, добавить кастомные поля. Мне идея с реасайном вообще не нравится