Понимание [закрытой] толпы

Во-первых, не каждый Спринт дает Большой релиз (если вообще). Вполне допустимо, чтобы первые спринты производили ранние прототипы / альфа-версии, которые, как ожидается, не будут свободными от ошибок, но все же способны продемонстрировать что-то клиенту. Это что-то может быть даже не функцией - это может быть просто скелет пользовательского интерфейса, просто для того, чтобы пользователь мог видеть, как он будет выглядеть и работать.

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

Вы определенно не хотите делать всю разработку в первой половине спринта и все тестирование во второй половине. Это просто меньший водопад.

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

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

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

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

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

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

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

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

Определение и создание (автоматических) приемочных тестов будет держать людей с первичными навыками контроля качества / тестирования занятыми и вовлеченными с самого начала спринта. Убедитесь, что это делается в сотрудничестве с Владельцами продуктов, чтобы все были на одной странице и были вовлечены.

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