Что происходит между спринтами?

Я работаю над проектом, свободно следуя модели Scrum. Мы делаем двухнедельные спринты. Что-то, что мне неясно (и у меня нет книги для консультации), это именно то, что должно происходить между спринтами: должен быть какой-то процесс «обертки», когда продукт собирается и доставляется, но:

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

Есть три разработчика, добавив около 1 FTE. Так что спринты действительно очень короткие.

Я работаю над проектом, свободно следуя модели Scrum.

Чтобы было понятно: ваши менеджеры, вероятно, рассказывали вам о Scrum, но то, что вы делаете, это не Scrum.

Как долго это обычно занимает?

Совещание по рассмотрению спринта + ретроспективное собрание по спринту завершает текущий спринт. В коротких спринтах они должны занять что-то между 30 минутами - 1 часом вместе. На следующий рабочий день начинается новый спринт с выполнения 1 и 2 совещания по планированию спринта. В зависимости от размера команды и продолжительности спринта это собрание может занять от 2 до 4 часов.

Должна ли быть задействована вся команда?

Вся команда должна участвовать в собраниях, упомянутых в предыдущем ответе.

Должен ли он закончиться, прежде чем разработчики начнут работать над элементами следующего спринта?

Да, потому что до тех пор, пока не будет проведено обзорное собрание, вы не знаете, примет ли клиент результат предыдущего спринта, и не знаете, какие истории пользователей будут зафиксированы при планировании собраний.

Это когда происходит проверка и проверка кода?

Нет. Проверка и тестирование кода является частью спринта. Разработчики должны сделать все необходимое для предоставления рабочего кода, удовлетворяющего требованиям. Это может включать в себя проверки кода и всегда должно включать в себя какие-то автоматические тесты, подтверждающие, что код работает и выполняет то, что он должен делать, в противном случае пользовательская история не может считаться выполненной.

Основной психический сдвиг связан с QA. Многие разработчики считают, что QA предназначен для проверки того, что код работает и делает то, что должен. Определенно нет. Это работа разработчика.

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

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

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

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

Есть некоторые накладные расходы (много встреч, вопросов и ответов и оценки требований), но в целом это работает - мы добиваемся стабильного прогресса с небольшим временем простоя. Спринты обычно длились две или три недели. QA обычно проводится после завершения истории. Однако у команды QA могут быть другие задачи, которые они могут выполнить. Что касается подготовки сюжета, задачи могут быть выплачены старшим членам команды или всей команде. Это может варьироваться в зависимости от размера команды и согласованного процесса. Обзоры кода обычно проводятся во время проверки качества или в конце спринта, если время сокращено. И если не хватает времени, чтобы закончить рассказы, на практике эти истории переносятся к следующему спринту. Правильный размер и оценка здесь очень важны.

... а когда оценка? планирование?

Истории должны быть действительно легкими, чтобы не было времени между спринтами.

И я не знаю, о каком тесте вы говорите, но разработчики проведут тестирование модулей и интеграций, не более того.

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