Зачем нужны спринты

Спор нужны ли вообще технической команде спринты далеко не нов. Кто-то живет вообще без них и прекрасно справляется. Так зачем тогда вообще нужны спринты? Что они дают команде?

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

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

А зачем обязательно нужно оценивать свою работу раз в какое-то время, почему не делать это от случая к случаю, когда увидели какие-то изменения? Ну во-первых, когда это бывает, чтобы что-то делали от случая к случаю стабильно. Изменения, происходящие в процессе работы, очень сложно заметить, важно специально обратить на них внимание. Но самое главное, что равные промежутки времени дают возможность сравнивать результаты прошлых итераций с текущими и наглядно видеть, как поменялись показатели команды. Подробно работу с показателями команды и итеративное обучение мы разбираем в нашей книге "Гибкие методологии на практике".

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

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

Продолжение в следующем посте ⤵️