Каков предлагаемый подход к организации спринтов на этапе тестов? Предположим, мы закончили спринты разработки, внутренние тесты (аналитики и разработчики) закончились. Приложение развертывается в тестовой среде для приемочных тестов пользователей. Эти тесты покрываются бизнес-пользователями приложения.
Что нам теперь делать?
В идеальной ситуации вы должны развертывать новую версию после каждого спринта, когда вы создаете приложение, чтобы фаза тестирования была распределена на более длительный период времени.
Сказав это, я понимаю, что есть клиенты, которые ожидают, что этап приемочного тестирования будет завершен в конце, после доставки всей функциональности.
В этой ситуации я считаю, что исправление ошибок имеет более высокий приоритет, чем разработка новых функций. Здесь у вас есть несколько вариантов:
Начните новый спринт, запланируйте меньшую скорость, чем обычно. В первом спринте вы можете следовать своей интуиции, чтобы установить ожидаемую скорость. Затем вы исправляете ошибки по мере их появления, что негативно влияет на объем новой работы, которую вы можете выполнить. Таким образом, вы сможете исправлять ошибки и делать новую работу. Однако вы рискуете сильно переключиться на контекст, так как люди перестанут работать над новыми задачами, чтобы исправлять старые ошибки.
Начните новый спринт, но уберите часть команды из группы поддержки старого проекта. Таким образом, у вас есть стандартный спринт, хотя и с меньшей группой людей, и еще несколько человек, которые должны заниматься отправленными ошибками. Вы можете регулировать количество людей в обеих группах после каждого спринта в зависимости от загруженности, связанной с ошибками. Скорость команды, работающей над новыми функциями, будет плавающей, но вы ограничите переключение контекста. Однако вы рискуете разочароваться в людях, занимающихся ошибками, поскольку они будут иметь дело с ошибками, сделанными ими самими и другими, которые в настоящее время работают над новыми интересными задачами. Если возможно, рекомендуется смешивать людей из этих команд после каждого спринта.
Установите счастливые часы/дни для устранения ошибок — время дня/недели, когда все занимаются устранением ошибок. Кроме того, они создают новые функции. Вы можете настроить продолжительность «счастливых часов» в зависимости от объема вашей работы по исправлению ошибок. Опять же, вы рискуете, что люди будут исправлять код, написанный другими, особенно когда кто-то создает довольно низкокачественный код с большим количеством ошибок. Однако это вводит один за всех, все за одного, отношение в команде, которое обычно работает нормально.
Если исправления ошибок достаточно, чтобы заполнить все дни всей команды, я бы подождал с запуском нового спринта, пока не появится хотя бы кто-то, кто может справиться с новыми задачами, независимо от того, какой метод вы выберете.
В описываемой вами среде идеальным способом было бы предоставление функциональности небольшими приращениями. В каждом спринте должны быть представлены новые функции или расширенные функции для тестирования пользователями.
Не стоит ждать, пока закончится вся фаза разработки, и только потом приступать к пользовательскому тестированию. Это как бы упускает из виду суть итеративной разработки.
В компании, в которой я работаю, у нас есть команды разработчиков (которые также отвечают за функциональное тестирование), а затем у нас есть группа тестирования решений. Команды разработчиков доставляют контент спринтами. У группы тестирования уровня решения есть последующие спринты, в которых они тестируют новые функции.
Таким образом, вы можете получить обратную связь от пользователей на ранней стадии, на которой вы все еще можете вносить изменения и сосредоточиться на наиболее важных функциях.
Если вы используете Scrum, вы должны проводить тестирование во время спринта, в котором происходила разработка. Функция разрабатывается, функция тестируется, и то, и другое учитывается в плане спринта — функция не «готова», пока она не будет разработана и протестирована.
Если вы не можете завершить тестирование в одном спринте, вероятно, вы не разбиваете свои истории на достаточно мелкие части. В худшем случае тестируйте каждую историю в спринте сразу после ее разработки.
Если у вас есть «этап» разработки (количество X спринтов) и «фаза» тестирования (количество спринтов Y), это водопад (или итеративный водопад).
Я участвовал в приемочном тестировании пользователей при использовании scrum. Наши циклы UAT были определены контрактом и вне нашего контроля. Обычно у нас было 3 дня UAT, за которыми следуют 2 дня на исправление ошибок, каждый выпуск продукта должен был иметь по крайней мере три таких цикла UAT.
Так наша команда разбила весь период UAT — около двух недель на несколько мини-спринтов. Не строго в рамках Scrum, но в этом и заключается красота Scrum, вы можете и должны адаптировать его к своей среде. Когда клиент запирал продукт и среду для тестирования, мы кодировали исправления ошибок. Когда среда была возвращена нам для исправления ошибок, мы развернули исправления ошибок из предыдущего мини-спринта по исправлению ошибок и выполнили тестирование окружающей среды.
Мы обнаружили, что обычно у нас было несколько запасных циклов во время UAT, если мы хорошо выполняли свою работу и не было много ошибок. Мы использовали это время для любых запущенных домашних дел.
Алан Лаример