Спринт (Sprint)
Спринт (от англ. sprint ) — гонки на короткое расстояние.
Статистика регби показывает, что большинство ключевых моментов игры ограниченны дистанцией в 10 метров и что игроки редко ускоряются в одном игровом моменте более чем на 30 метров. Этот факт убедительно указывает нам на ключевой момент в разнице стилей бега игрока регби и бегуна по дорожке — время набора максимальной скорости. Говоря проще, игроку в регби нужно уметь набрать максимум своей скорости гораздо раньше, чем спринтеру на беговой дорожке.
rugbysport.ru
Статистика регби показывает, что большинство ключевых моментов игры ограниченны дистанцией в 10 метров и что игроки редко ускоряются в одном игровом моменте более чем на 30 метров. Этот факт убедительно указывает нам на ключевой момент в разнице стилей бега игрока регби и бегуна по дорожке — время набора максимальной скорости. Говоря проще, игроку в регби нужно уметь набрать максимум своей скорости гораздо раньше, чем спринтеру на беговой дорожке.
rugbysport.ru
Что такое спринт
"Спринты - это сердцебиения Scrum, в которых идеи превращаются в ценность"
, где под ценностью, конечно, имеется в виду работающее ПО, которое покрывает потребность клиента.
Спринт — это итерация разработки, по сути, проект/фаза проекта со многими его/её характеристиками.
Свойства спринта:
Все работы и задачи по разработке выполняются внутри спринта. Все мероприятия Scrum проводятся внутри спринта.
Вне спринтов нет Scrum. Вне спринтов — вакуум, нерегламентированный официальной документацией Scrum.
Во время течение текущего спринта:
В первичных официальных методических пособиях говорится о длине от 3 до 6 месяцев. В современном мире со всеми дарами автоматизации, DevOPS культуры и open source спринты длиннее четырёх недель уже считаются спринтами курильщика.
Когда запускается разработка, фундаментальное представление о цели продукта у всех есть. Длина спринта выбирается в том числе из общего понимания сложности планируемых функций и прогнозируемых задач, которые они породят.
Свойства спринта:
- все спринты одинаковой длины
- новый спринт обязан начинаться после завершения текущего (никакого отдыха!)
Все работы и задачи по разработке выполняются внутри спринта. Все мероприятия Scrum проводятся внутри спринта.
Вне спринтов нет Scrum. Вне спринтов — вакуум, нерегламентированный официальной документацией Scrum.
Во время течение текущего спринта:
- Нельзя менять цель спринта
- Нельзя вносить изменения, которые ставят под угрозу цель спринта;
- Нельзя допускать ухудшения качества инкремента, порождаемого в спринте;
- Состав продукта и его характерных особенностей
- уточняется по мере необходимости;
- уточняется или пересматривается с владельцем продукта по мере поступления дополнительной информации.
- Чем короче тем лучше
- Может быть отменён, если цель спринта стала неактуальной, но право отмены есть только у Владельца Продукта.
В первичных официальных методических пособиях говорится о длине от 3 до 6 месяцев. В современном мире со всеми дарами автоматизации, DevOPS культуры и open source спринты длиннее четырёх недель уже считаются спринтами курильщика.
Когда запускается разработка, фундаментальное представление о цели продукта у всех есть. Длина спринта выбирается в том числе из общего понимания сложности планируемых функций и прогнозируемых задач, которые они породят.
Почему это важно
Итерации равной длительности повышают дисциплину и упрощают планирование, управление рисками и контроль качества.
В проектном управлении как итеративный, так и инкрементный типы жизненных циклов были известны и активно использовались задолго до появления Scrum, но именно он обязал применять инкрементный жизненный цикл проекта в разработке ПО. По сути, это частный вырожденный случай жизненного цикла проектного управления, адаптированный к процессу разработки.
Приведём определения жизненных циклов проектов от PMI:
— В случае итеративного жизненного цикла содержание проекта обычно определяется на начальной стадии жизненного цикла проекта, однако оценки сроков и стоимости проекта меняются в рабочем порядке по мере расширения понимания продукта командой проекта. Итеративность определяет разработку продукта путём выполнения ряда повторяющихся циклов, в то время как инкрементность определяет последовательное наращивание функциональности продукта.
— В случае инкрементного жизненного цикла проекта поставляемый результат производится путём выполнения ряда итераций, которые последовательно наращивают функциональность в рамках заданного временного интервала. Поставляемый результат содержит такие необходимые и достаточные характеристики, чтобы считаться полным только после заключительной итерации.
В проектном управлении как итеративный, так и инкрементный типы жизненных циклов были известны и активно использовались задолго до появления Scrum, но именно он обязал применять инкрементный жизненный цикл проекта в разработке ПО. По сути, это частный вырожденный случай жизненного цикла проектного управления, адаптированный к процессу разработки.
Приведём определения жизненных циклов проектов от PMI:
— В случае итеративного жизненного цикла содержание проекта обычно определяется на начальной стадии жизненного цикла проекта, однако оценки сроков и стоимости проекта меняются в рабочем порядке по мере расширения понимания продукта командой проекта. Итеративность определяет разработку продукта путём выполнения ряда повторяющихся циклов, в то время как инкрементность определяет последовательное наращивание функциональности продукта.
— В случае инкрементного жизненного цикла проекта поставляемый результат производится путём выполнения ряда итераций, которые последовательно наращивают функциональность в рамках заданного временного интервала. Поставляемый результат содержит такие необходимые и достаточные характеристики, чтобы считаться полным только после заключительной итерации.
— Почему они (итерации) обязаны быть одинаковой длины? Нельзя ли сделать разик один спринт чуть длиннее?
— Для того чтобы приблизить процесс к конвейерному производству, которым вдохновлялись авторы. Нет. Нельзя разово делать ни короче, ни длиннее.
— Задачи разной сложности выполняются за разное время, тогда почему они должны быть вмещены в одинаковые итерации? Почему бы не сделать наоборот — итерации разной длины в зависимости от задачи на очереди?
— Авторы фреймворка посчитали, что дисциплина конвейерного характера получаемая от итераций равной длины с мероприятиями в её одних и тех же точках стоит рисков возникновения простоев в конце спринта или невозможности завершить задачу, потому что она слишком большая, чтобы вместиться в спринт.
Считается, что задачи, настолько большие и неделимые, что их нельзя вместить в спринт это исключение, требующее индивидуального подхода.
Считается, что задачи, настолько большие и неделимые, что их нельзя вместить в спринт это исключение, требующее индивидуального подхода.
"Идея заимствования терминов из совершенно несвязанной области "регби" была в том, что они должны были обозначать предельно конкретный элемент фреймворка со всеми его необходимыми свойствами. Но глубочайшая ирония в том, что организации, ровно наоборот, просто начали называть терминами Scrum всё подряд. Спринт — яркий пример такой ситуации, потому что любую итерацию теперь называют спринтом совершенно не осознавая, что отсутствует одно или вообще все его обязательные свойства."
Виталий Новиков
Гл.редактор
Спринты Scrum и проектное управление
— Можно ли использовать процесс разработки Scrum с его итеративной инкрементальной спринтовой основой, если в организации все изменения порождаются на проектной основе, в том числе традиционными водопадами?
— Да, можно.
Для большого проекта этап разработки ПО часто лишь один из многих этапов и, возможно, даже не самый большой и сложный. Каким образом команда разработки делает свою работу может не иметь значения и не зависеть от жизненного цикла проекта, если сроки и бюджет этапа разработки не нарушены, а качество соответствует ожиданиям.
Больше того, опытные руководители проектов всё больше начинают любить инкрементный подход к разработке, потому что в умелых руках это может сильно упростить управление рисками и ожиданиями заказчика.
Для большого проекта этап разработки ПО часто лишь один из многих этапов и, возможно, даже не самый большой и сложный. Каким образом команда разработки делает свою работу может не иметь значения и не зависеть от жизненного цикла проекта, если сроки и бюджет этапа разработки не нарушены, а качество соответствует ожиданиям.
Больше того, опытные руководители проектов всё больше начинают любить инкрементный подход к разработке, потому что в умелых руках это может сильно упростить управление рисками и ожиданиями заказчика.
Диаграмма 1. Пример, когда в проекте только одна команда работает по процессу Scrum
Статьи о Scrum