Помогите мне понять, как QA работает в Scrum [закрыто]

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

разработчики мечутся, пытаясь выполнить свои задачи. Как правило, задачи занимают большую часть спринта для завершения. QA пристает к Dev, чтобы выпустить что-то, что они могут проверить, Dev наконец выбрасывает какой-то багги-код в QA за день или два до окончания спринта и тратит остальное время на исправление ошибок, которые QA находит. QA никогда не может выполнить задачи вовремя, спринты редко выпускаются время, и у Dev и QA есть несчастные несколько дней в конце спринта.

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

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

(кстати - это лучшее место чтобы поставить это или я должен был поставить его в "ответ"?)

указывает на обдумывание / действие:

• необходимо убедиться, что задачи разработчика являются как можно более мелкими (гранулированными).


• длина спринта должна быть соответствующим образом основана на средней длине задачи (например, спринт с заданиями на 1 неделю должен быть не менее 4 недель)


• команда (включая QA) должна работать над тем, чтобы стать более точной при оценке.


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


• модульное тестирование!