я исхожу вот из чего: есть функционал, его пилили трое, каждый свою часть, вот, к каждой такой части девлид назначает ответственного, вот, берём и фиксируем

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

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

а девлид незнает что ли - кто и что пилит?

Ты вообще внимательно прочитал что я написал? :)

Что назначать тестировщику? :) Курс лечения после таких "методологий"?

Ричард, согласна с тем, чтот вы писали - ассайнить на девлида, в моем случае пиэма пока что вопрос вот еще в чем: мне не хочется плодить кучу тикетов и терять потом все тестерские комменты, так как если пиэм напишет разрабу «вот тебе тикет 2, посмотри, что написал тестер в тикете 1» (тикеты 1 и 2 связаны) в этом случае вряд ли разраб будет прямо уж так детально читать все по тикету 1, так как это ему надо полезть в связанный тикет, что не оч удобно а затем смотрите - он пофиксил свой тикет 1 и мне вернул, мне надо тоже лезть в этот же связанный тикет 2 и перечитвать свои комменты, а затем писать их в тикет разраба 1 после его фикса %) это норм или нет?

Ричард, согласна с тем, чтот вы писали - ассайнить на девлида, в моем случае пиэма пока что вопрос вот еще в чем: мне не хочется плодить кучу тикетов и терять потом все тестерские комменты, так как если пиэм напишет разрабу «вот тебе тикет 2, посмотри, что написал тестер в тикете 1» (тикеты 1 и 2 связаны) в этом случае вряд ли разраб будет прямо уж так детально читать все по тикету 1, так как это ему надо полезть в связанный тикет, что не оч удобно а затем смотрите - он пофиксил свой тикет 1 и мне вернул, мне надо тоже лезть в этот же связанный тикет 2 и перечитвать свои комменты, а затем писать их в тикет разраба 1 после его фикса %) это норм или нет?

баг назначать разрабу

Да, еще есть вопрос насчет налаживания процессов тестирования. Пример: у вас есть большая фича и вы нашли баги фронтенда и бекенда, записали это в один большой тикет, который стоял на вас как «исследование фичи и проведение ее полного тестирования». Вы свою работу сделали - протестили все, что могли. Что делаем дальше? а) переводим тикет на пиэма, далее пиэм сам раскидывает баги по новым тикетам - кому фронтенд, кому бекенд + обсуждает с заказчиком что фиксить, а что нет б) либо сам тестер создает отдельные тикеты (новые) на соответствующих разрабов? в) либо текущий тикет ассайнится на одного девелопера, фиксится, тестится, потом после фикса ассайнится на следующего? г) или ваши варианты? действительно важный вопрос, хочу сделать удобно для всех, так что ваш опыт мне очень поможет)

Да пусть назначает, я не против. Если области ответственности проргаммистоы распределены давно и надолго. Что ж вы до конца-то не читаете.

прочёл, но получается в вашей команде через девлида всё идёт по сути, в моём, да и практически так получалось, всегда назначал отдел тестирования ответственного

Один большой тикет - уже неайс. Почему один? Проблемы лучше решать по одной.

Ну, я очень рад, что у вас это работает. Пусть удача вас не покидает. А зачем вам тогда девлид?

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

Зачем, если это может делать ПМ? :)

Ричард, 1 баг = 1 тикет, дадада, но пиэм и разрабы такой подход не приветствуют и предпочитают по одной фиче все баги в один тикет такие дела, брат (с)

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

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

Чёто у вас бардак какой-то. когда ПМ делает задачу на тестирование - это Task. К задаче на тестирование прикрепляются найденные баги - Bugs По итогам исследованиия багов - создаются задачи на доработку, к которым прикреплены баги из-за которых доработки потребовались. Когда задача на доработку выполнена - она отдается на тестирование. При завершении тестов задача закрывается. Баг проверяется и проводится верификация. По её итогам закрывается бага. В итоге закрывается таска на тестирование. Так чтоли?

ребятишки, реально бардак, поэтому и српашиваю совета) Ричард, в этом самом Task -пишутся все баги, отдельных тикетов на баги нет пиэм смотрит Task и мои комменты затем ставит два тикета 1) с темой фронтенд фикс 2) и бекенд фикс Task - переностися в done

По идее все должно жить в одном таске вообще

Не увольняйте, пригласите его сюда.

Почему два тикета. Там два бага?