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

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

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

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

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

.>Здравствуйте, 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 — пусть текущий репортер парится. Он обязан знать как проверять задачу.

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