Всем привет! Вопрос тем, у кого на проектах есть/была практика

возвращения на доработку плохо поставленных задач и/или плохо написанного тз - какие критерии вы для этого использовали? Те не просто абстрактно: это хорошо - это плохо, а что-то, что можно оценить - например, definition of done для аналитика на передачу тз/задачи в разработку, какой-то конкретный порядок действий qa при приеме задачи/тз, чтобы четко оценить - эту берем, эту нет. Чтобы данные критерии использовать в настройке этого процесса

Оно - https://www.leadingagile.com/2014/09/acceptance-criteria/ ?

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

Ну конкретно в AC польза следующая - если все критерии выполняются, то задачу можно закрывать (и создать follow-up на прочие обнаруженные баги) вместо переоткрытия. Если критерии не выполняются - тут точно reopen. На этапе обсуждения задачи - позволяет понять, что именно в данной задаче хотим получить как результат. Если девелоперу/QA что-то неясно по критериям - на стендапе можно обсудить, критерии переформулировать, добавить новые...

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

30-40 замечаний по ТЗ - "это так не работает", - "это не совместимо с тем", - "это нарушает принцип такой-то", - "это не совпадает с терминологией проекта", - "это неоднозначно" - "откуда пользователь должен понять что это" Например :)

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

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

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

Как минимум, желательно описать финальный результат и дизайн. Отталкиваясь от этого продумывается реализация под капотного добра, главное, чтобы это не шло в разрез с тем, как принято в компании. Например, нет нужды писать свою собственную систему показа капчи, если есть готовая и используемая

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

Нет универсальных критериев. Это работает в духе митингов-грумингов. Допустим рассылаются задачи или ТЗ с описанием. Задаются вопросы -- - всё ли тут понятно? - понимаем ли мы как это будем разрабатывать? - как тестировать? - как это оцениваем - есть ли тут что-то чего нам не хватает? - есть ли зависимости? - риски?

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

А есть ли практика универсального сидения на стуле?

не понимаю, к чему тут этот пример

К совершенной бессмыслености поиска универсального в мире разных компаний, команд и потребностей

Думаю тут все зависит от заказчика. Чего хочет бизнес итд

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

Ну я выше и написал про опыт.

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

Вы просили про опыт, вы получили опыт.