QA получают всю работу в конце спринта

Вы не должны рассматривать разработку и тестирование как последовательные действия в рамках спринта, или то, что вы описываете, происходит. Разработка и тестирование должны происходить вместе как сотрудничество между разработчиками и тестировщиками. Это требует изменения в том, как вы работаете. Подробнее см. здесь: Что делает команда контроля качества на этапе разработки спринта в Agile Scrum?

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

Да. Общее практическое правило для двухнедельного спринта заключается в том, что большинство элементов невыполненной работы должны выполняться в течение 2-3 дней, включая контроль качества, развертывание и т. д. Однако это просто мудрость для опытных команд, а не жесткое правило. Также потребуется время, чтобы добраться туда. Если команда привыкла к тому, что на выполнение элемента невыполненной работы уходит полных 2 недели, она не собирается сразу переходить к 2 дням.

Есть три практики, которые я бы рассмотрел, чтобы помочь вашей команде:

1. Разбивайте элементы невыполненной работы задним числом. Обычно команда не знает, как разбить элементы невыполненной работы, когда они начинают. Хороший способ научиться — провести короткое обсуждение после завершения задания и задать вопрос: «Если бы я мог вернуться в прошлое, зная то, что знаю сейчас, как бы я мог разбить это на более мелкие части?» Затем вы можете применить эти уроки к аналогичным предметам в будущем.

2. Переместите тестирование и контроль качества на более ранние этапы процесса разработки. TDD, ATDD и BDD — отличные способы перенести большую часть тестирования на этап, предшествующий разработке, и оптимизировать процесс разработки. Это кажется слишком экстремальным, попробуйте простую встречу трех друзей. На этих встречах кодер, тестер и представитель бизнеса/пользователя беседуют перед началом работы. Это позволяет реализовать множество идей по тестированию и функциональности еще до того, как будет написана строка кода, и серьезно сокращает количество операций передачи данных туда и обратно.

3. Сгруппируйтесь! Из всех команд, с которыми я работал, проблема, которую вы описываете, почти всегда связана с тем, что люди применяют в работе подход «разделяй и властвуй». Этот подход обычно более экономичен по времени при первом проходе, но теряет гораздо больше времени на интеграцию, обмен знаниями и тестирование. Выберите один или два предмета и сгруппируйте их так, чтобы быстро завершить несколько дел, а не начинать множество дел.

Любой из них поможет, но их также можно использовать вместе. Удачи!

Есть несколько разных подходов к этой проблеме.

С точки зрения Scrum ваша Команда Разработки не имеет подгрупп. У вас могут быть специалисты, например люди, специализирующиеся на тестировании, но в этом должна участвовать вся команда. Вместо того, чтобы ставить специалистов по обеспечению качества в положение, когда они должны тестировать все в конце спринта, вся команда должна участвовать в тестировании, когда бы оно ни происходило. Специалисты по контролю качества могут помочь обучить остальную часть команды передовым методам тестирования.

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

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

Поскольку этот вопрос является точной копией вопроса об обмене стеками Software Quality Assurance & Testing , это точная копия моего ответа , поскольку он в равной степени применим.

Постарайтесь сначала определить причину проблемы. Могу предположить несколько возможных причин:

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

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

3. Неверная оценка. Во время планирования спринта команда должна прогнозировать, чего они реально могут достичь во время спринта. Избегайте абсолютной оценки (дни и часы). Если команда чувствует необходимость оценить элементы невыполненной работы в числовом выражении, используйте относительную оценку (баллы). Предыдущая скорость спринта является хорошим показателем того, что может быть выполнено, но это всего лишь руководство, и мнение команды важнее, чем цифра, которую они присваивают скорости. Если у вас часто есть незавершенная работа в спринте, это говорит о том, что команда не проверяет и не адаптирует ее на основе своей прошлой работы.

4. Отсутствие автоматизации тестирования. Создание тестов можно и нужно делать параллельно с разработкой кода. Если у вас есть тесты и подходящая среда автоматизации, то автоматическое выполнение займет очень мало времени.

5. Слабая дисциплина Минобороны. Определение «готово» означает, что история готова либо на 100 % (конечно, включая тестирование), либо на 0 %. Команда должна самоорганизоваться, чтобы убедиться, что все они серьезно относятся к DoD.

Мое предложение было бы:

• Инвестируйте больше в автоматизированное регрессионное тестирование
• Сделайте проблему частью процесса планирования: «С какого тикета мы должны начать первым, чтобы мы могли отправить его на тестирование как можно раньше в спринте?»