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

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

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

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

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

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

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