а у вас тестирование и багфикс в Definition of done не включены?

Хм...простите за глупый (возможно) вопрос. Допустим включены. В таком случае вопрос все так же актуален

Хм...простите за глупый (возможно) вопрос. Допустим включены. В таком случае вопрос все так же актуален

ок, чуть подробнее: Определено, что есть баг, с которым пропустить в релиз нельзя. Возвращать задачу в работу? (1 вариант) И тут же вопрос, если не ошибаюсь в скраме не принято ничего возвращать, чем линейнее, тем лучше Или второй вариант - ставить новую задачу и в новый спринт? (может пострадать дата релиза), или ставить новую задачу и в этот спринт? (тогда это раздувание спринта и добавления задач в текущий, что вроде как тоже «против правил»)

подождите :) у вас баг в какой момент появился?

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

по философии ясно))) это ок)) фича не закончена, че делать та?)

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

но как-то не по фен-шую))) более элегантных решений нет?)

и это да))

и это да))

да я так то уже поступила)) решения надо принимать быстро)) на будущее решила узнать у более опытных коллег))

а к вопросу о возврате задач или созданию новых - как поступаете вы и чем руководствуетесь? у меня вот встретились 2 разных опыта

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

ну нужно работать с людьми. повышать ответственность за продукт, дать им чувство владения продуктом. чтобы они понимали, что если выпустили какашку в одном месте, то какашку выпустила вся команда

просто строгий взгляд и улыбка)))

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

Что не так? Тонкости перевода "must"?

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

Это в принципе невозможно, потому что мир неидеален по определению.

качество - это ответственность всей команды. не только тестировщика

Это в принципе невозможно, потому что мир неидеален по определению.

Что не так? Тонкости перевода "must"?

Вот прям обидно было видеть такие вопросы в PSM. Ощущение что сдаёшь тесты в гаи, где цель не проверить знания, а завалить хитрыми формулировками

Конечно не стоит, но как раз в псм куча подобных вопросов

Конечно, но тогда на этом стоит сделать упор. Уже не помню был ли капс, но confused вопросы точно были в изобилии

Конечно не стоит, но как раз в псм куча подобных вопросов

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

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

Почти уверен, что данная проблема возникла из-за неполного понимания методологии. Прошу подсказать, как правильно делать в рамках Scrum.

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

Не на семантику. Но да, в PSM хватает вопросов на понимание точности формулировки. Особенно в PSM II

Там да. Недавно сдавал, набрал только 73% Ну очень хитрые вопросы.