Scrum – это фреймворк итеративно-инкрементальной разработки продуктов. И прежде чем двигаться дальше в Scrum, предлагаю разобраться, что же такое итеративно-инкрементальная разработка, и чем она отличается от классической каскадной разработки, известной еще под названием waterfall.
Каскадная модель разработки тебе скорее всего хорошо известна, даже, если ты не знаешь, что она называется именно так
В ней разработка продукта разбивается на последовательные этапы, такие как сбор и анализ требований, проектирование, разработка, тестирование, внедрение. И каждый следующий этап не может начаться, пока не закончен предыдущий.
Проблемы при использовании такой модели мы все хорошо знаем. Очень часто, хоть требования и были согласованы с заказчиком на раннем этапе, на стадии внедрения он обязательно захочет что-то поменять. Или вообще в ходе реализации выясняется, что требования перестали быть актуальны или их нужно поменять, но каскадная модель очень болезненно воспринимает такие сценарии, и всячески им сопротивляется. Это не удивительно, она не предназначена для работы в запутанном домене, когда весь мир вокруг постоянно меняется, модель любит предсказуемость.
Как же можно попробовать решить озвученные проблемы?
А давай попробуем почаще общаться с заказчиком и показывать даже промежуточны результаты, с кокой-то фиксированной частотой? Такой подход называется итеративным. Через каждый фиксированный промежуток времени (его еще называют итераций или спринтом) мы встречаемся заказчиками и собираем с них Обратную Связь, чтобы на более ранних этапах понять, правильно ли мы двигаемся. То есть итеративный подход - это изменение того, что делалось на предыдущих этапах.
Правда, тут есть одна проблема, если мы показываем промежуточный, но не еще неработающий результат, конечно, некоторую напряженность и риски мы снимаем, но далеко не все. Ведь если что-то нельзя пощупать, то и обратная связь будет скорее теоретической, а не практической. Так что эту модель надо немного докрутить.
Что, если мы будем поставлять раз в спринт не промежуточный, недоделанный результат, а новую версию продукта, которая содержит пусть одну, пусть маленькую, но работающую функцию? Тогда наши заказчики и пользователи смогут уже ее пощупать и дать более содержательную обратную связь – это ли они хотели получить, можно ли этим пользоваться, помогает ли эта функция решить проблему пользователя? И если ответ ДА – мы откладываем эту функцию в ящичек с готовыми и в следующем спринте идем делать следующую функцию. Такой подход называется Инкрементальным. То есть инкрементальный подход - это добавление того, чего ранее не существовало.
Если совместить эти два подхода вместе, по получим итеративно-инкрементальный подход, когда мы двигаемся вперед короткими фиксированным промежутками времени (итерациями или спринтами), и в конце выдаем новую версию продукта (или инкремент), в которой есть минимум одна новая работающая функция, готовая для повседневного использования.
Чтобы данный подход работал, очень важно нарезать элементы бэклога вертикально, а не горизонтально.