Рус 
Қаз Десять лет назад двухнедельный спринт казался быстрым. Команды планировали работу, ставили цели и выпускали программное обеспечение предсказуемыми этапами. По сравнению с длительными циклами выпуска, предшествовавшими гибкой методологии, спринт стал прорывом. Он создал структуру, сфокусированность и регулярные возможности для обратной связи. На самом деле, он был быстрым.
Сегодня разработка программного обеспечения ведется в совершенно иной среде. Разработчики используют ИИ для генерации кода, тестов и документации за считанные минуты. Автоматизированные конвейеры обеспечивают непрерывную обратную связь, интеграцию и развертывание. Функции могут переходить от идеи к производству быстрее, чем когда-либо прежде. Во многих организациях самым большим ограничением является уже не разработка программного обеспечения, а решение о том, что разрабатывать дальше.
Однако многие команды по-прежнему организуют свою работу в рамках спринтов, созданных для более медленной эпохи. В понедельник выявляется проблема с клиентом. Команда соглашается, что её нужно решить. Затем кто-то говорит: «Мы займёмся этим в следующем спринте». Все соглашаются, что это максимально возможный темп работы.
Но в среднем на устранение проблемы уходит как минимум три недели. Задержка редко бывает технической, чаще — процедурной. Это поднимает неудобный вопрос: помогают ли спринты командам по-прежнему становиться более гибкими, или же они превращаются в процесс, которому команды следуют просто потому, что всегда следовали?
Спринт решал важные проблемы. Вопрос в том, остается ли он лучшим решением проблем, с которыми команды сталкиваются сегодня.
Программа Sprint решила реальные проблемы.
До того, как гибкие методологии разработки стали общепринятыми, программные проекты часто имели гораздо более длительные циклы планирования и реализации. Команды тратили месяцы на сбор требований, месяцы на разработку решений и еще больше времени на тестирование и подготовку релизов. К тому времени, когда клиенты видели готовый продукт, приоритеты бизнеса часто менялись.
Методологии Agile, Scrum и двухнедельные спринты решили многие из этих проблем. Организуя работу в короткие, фиксированные итерации, команды получили предсказуемый ритм планирования, выполнения и обратной связи. Вместо того чтобы ждать месяцами, чтобы определить, работает ли идея, заинтересованные стороны могли оценивать прогресс каждые несколько недель. Разработчики получили ясность в отношении приоритетов, владельцы продукта — прозрачность процесса разработки, а руководители — более надежный способ отслеживания прогресса.
Не менее важным было то, что границы спринта обеспечивали концентрацию внимания. Обязательства в рамках спринта защищали команды от постоянно меняющихся приоритетов и бесконечных перерывов. Вместо того чтобы реагировать на каждый новый запрос, команды могли сосредоточиться на выполнении определенного набора задач, прежде чем пересматривать приоритеты в следующем цикле планирования.
Спринт также помог решить проблему координации. Разработка программного обеспечения редко бывает индивидуальной деятельностью. Инженерам, тестировщикам, дизайнерам, менеджерам по продуктам и заинтересованным сторонам из бизнеса необходимы возможности для согласованной работы. Планирование спринтов, обзоры и ретроспективы создали структурированные моменты, называемые церемониями, для проведения таких обсуждений.
Для многих организаций эти методы представляли собой значительное улучшение по сравнению с тем, что было раньше. Команды стали выполнять задачи чаще, обратная связь поступала быстрее, а риски становились более очевидными на ранних этапах. В результате повысилась предсказуемость.
Иными словами, спринт не был создан как ненужный процесс. Он был создан для решения реальных проблем, существовавших в разработке программного обеспечения в то время. Вопрос не в том, приносили ли спринты пользу; они, безусловно, приносили. Вопрос в том, существуют ли сегодня ограничения, которые сделали спринты такими ценными.
Экономика разработки программного обеспечения изменилась.
Спринт возник в период, когда разработка программного обеспечения была относительно дорогостоящей. Циклы разработки были дольше, тестирование часто проводилось вручную, а развертывание влекло за собой значительные риски. Создание работающего программного обеспечения требовало значительного времени и координации, поэтому было целесообразно разделять работу на короткие, но структурированные итерации. Многие из этих ограничений сегодня уже неактуальны.
За последнее десятилетие организации вложили значительные средства в автоматизацию. Конвейеры непрерывной интеграции и развертывания обеспечивают быструю работу системы. Облачные платформы предоставляют инфраструктуру по запросу. Автоматизированное тестирование выявляет проблемы, которые раньше требовали (в идеале) отдельных циклов тестирования. В последнее время инструменты на основе искусственного интеллекта ускорили процесс кодирования, документирования, анализа и устранения неполадок. В результате многие команды могут создавать программное обеспечение быстрее, чем когда-либо прежде.
Это не означает, что разработка программного обеспечения стала легкой. Сложные системы остаются сложными, а крупномасштабные проекты по-прежнему требуют координации. Однако время, необходимое для перехода от идеи к реализации, значительно сократилось для многих видов работ. В результате основное ограничение начинает смещаться.
Для многих команд задача больше не состоит в создании решений; задача состоит в том, чтобы решить, на каких решениях следует сосредоточиться. Разработчик может создать прототип за несколько часов, и функция может быть развернута с помощью флага функции в тот же день. Тем не менее, решения о приоритетах, согласованиях, финансировании, управлении и направлении дорожной карты часто по-прежнему принимаются еженедельно, ежемесячно или ежеквартально. Разрыв между скоростью выполнения и скоростью принятия решений увеличивается.
Это создает интересное противоречие. Организации продолжают оптимизировать механику разработки программного обеспечения, оставляя при этом окружающие процессы практически неизменными. Команды становятся способны непрерывно выполнять работу, но системы, используемые для определения приоритетов и оценки этой работы, остаются привязанными к запланированным событиям и фиксированному ритму. В такой среде границы спринтов могут начать ощущаться иначе, чем раньше.
Когда разработка программного обеспечения требовала недель усилий, двухнедельный горизонт планирования казался естественным и даже быстрым. Когда же значимую работу можно выполнить за дни или даже часы, тот же самый временной промежуток может начать восприниматься не как ускоритель, а скорее как период ожидания.
Всё это вовсе не означает, что спринты сами по себе плохи. Это лишь говорит о том, что среда, в которой они были созданы, изменилась. А когда среда меняется, успешные практики заслуживают пересмотра, а не автоматического сохранения.
Когда границы спринта создают трение
В большинстве гибких команд проблемы возникают не из-за слишком быстрого темпа работы. Чаще всего проблемы возникают из-за того, что их возможности по реализации проектов и операционная модель развиваются с разной скоростью.
Подумайте, как часто команды сталкиваются с запросами, которые, безусловно, ценны, но их выполнение откладывается, потому что они выходят за рамки текущего спринта. Выявляется проблема у клиента или появляется неожиданная возможность. Все согласны с необходимостью действий, но работа часто переносится на следующий цикл планирования, потому что обязательства по спринту уже определены. Никто не хочет «сорвать спринт».
Задержка может составлять всего несколько дней, но причина задержки имеет значение. Работа ждет не потому, что у команды нет возможности ее выполнить, а потому, что этого требует сам процесс.
Границы спринтов также могут способствовать искусственному группированию задач. Функции, которые технически завершены, могут оставаться невыпущенными до обзора спринта. Обсуждение приоритетов может откладываться до плановых сессий. Решения, которые можно принять немедленно, часто группируются в запланированные встречи, поскольку так сложился рабочий ритм команды.
Ни одна из этих практик сама по себе не является проблематичной. На самом деле, они часто улучшают координацию и предсказуемость. Проблема возникает, когда стоимость ожидания начинает превышать ценность предоставляемой структуры. Эта проблема становится еще более заметной по мере ускорения сроков выполнения работ.
Команда, выпускающая программное обеспечение раз в месяц, может не испытывать значительных трудностей при двухнедельном спринте. Команда, способная развертывать программное обеспечение несколько раз в день, может воспринимать тот же ритм совершенно иначе. По мере снижения стоимости разработки программного обеспечения относительная стоимость координации возрастает.
Именно поэтому многие организации тратят больше времени на обсуждение работы, чем на её выполнение. Планирование спринтов, уточнение бэклога, обзоры спринтов, ретроспективы, совещания по приоритезации и обзоры дорожной карты — всё это по отдельности приносит пользу. Однако вместе они могут создавать значительные накладные расходы на процессы, связанные с всё более мелкими единицами работы.
Как ни парадоксально, методы, призванные повысить гибкость, иногда замедляют работу тех самых команд, которым они должны были помочь. Это не означает, что церемонии спринта должны исчезнуть. Это означает, что руководители должны периодически проверять, продолжают ли эти церемонии приносить больше пользы, чем задержек. Процесс, улучшающий выполнение задач, — это преимущество, но процесс, который в первую очередь сохраняет традиции, — это совсем другое дело.
Различие становится более очевидным, если мы рассмотрим, как один и тот же объем работы проходит через команду, работающую по спринтовому принципу, по сравнению с командой, работающей с непрерывной приоритизацией и выполнением задач.
Что заменит спринт?
Когда кто-то ставит под сомнение ценность спринтов, разговор часто сразу переходит к другому вопросу: что же командам следует делать вместо них ? Ответ зависит от команды, продукта и среды, в которой они работают.
Для некоторых организаций спринт остается эффективным инструментом. Команды, работающие над крупными проектами, координирующие действия между различными подразделениями или функционирующие в условиях жесткого регулирования, по-прежнему могут извлекать выгоду из структуры и предсказуемости, которые обеспечивают фиксированные итерации. Цель состоит не в том, чтобы отказаться от спринтов только потому, что появились новые подходы.
В то же время многие организации экспериментируют с альтернативами, которые уделяют больше внимания потоку, чем ритму. Вместо организации работы вокруг двухнедельных циклов планирования эти команды сосредотачиваются на непрерывной приоритизации и непрерывной доставке. Работа поступает в систему, когда она становится важной, а не когда календарь достигает определенной даты. Решения принимаются по мере поступления информации, а не в ожидании следующей сессии планирования.
Этот сдвиг часто меняет и то, как команды оценивают успех. Вместо того чтобы делать акцент на обязательствах в рамках спринта и скорости, руководители сосредотачиваются на таких показателях, как время цикла, время выполнения, частота развертывания, результаты для клиентов и измерения потока. Планирование не исчезает; оно просто становится более непрерывным.
Это различие важно, потому что настоящий вопрос, стоящий перед гибкими командами, заключается не в том, следует ли им использовать спринты. Настоящий вопрос состоит в том, соответствует ли выбранный ими темп планирования скорости, с которой они учатся, выполняют задачи и получают обратную связь. Для некоторых команд ответом по-прежнему могут быть две недели; для других — нет.
По мере ускорения процесса разработки программного обеспечения организации, вероятно, будут все чаще проектировать процессы, которые будут определяться потоком работы, а не рамками календаря.
Настоящий вопрос, который должны задавать себе гибкие команды.
Дискуссии об гибких методологиях часто перерастают в споры о процессе:
Должны ли команды использовать Scrum или Kanban?
Должны ли спринты длиться одну неделю, две недели или быть вовсе исключены?
Должно ли планирование проводиться ежемесячно или непрерывно?
Хотя эти вопросы заслуживают обсуждения, они могут отвлекать от более важной проблемы.
Любая гибкая практика изначально была разработана для сокращения циклов обратной связи. Обзоры спринтов создавали возможности для сбора мнений заинтересованных сторон. Ретроспективы помогали командам учиться на собственном опыте. Планировочные сессии позволяли корректировать приоритеты по мере появления новой информации. Целью никогда не было само проведение церемонии; целью было более быстрое обучение и принятие более качественных решений.
Команда, разрабатывающая программное обеспечение для миллионов пользователей, может получать отзывы о продукте в течение нескольких часов после релиза. Команда, занимающаяся платформой и поддерживающая внутренние системы, может учиться медленнее. Регулируемая организация может потребовать дополнительных мер контроля, которые, естественно, удлиняют циклы принятия решений. В каждом случае модель планирования должна поддерживать способность команды учиться и реагировать.
Именно поэтому наиболее эффективные организации все чаще сосредотачиваются на потоке информации, а не на ритме совещаний. Они изучают, как быстро обратная связь от клиентов доходит до лиц, принимающих решения. Они измеряют, сколько времени проходит между этапами работы. Они отслеживают задержки в согласовании, определении приоритетов и координации.
Если установление границ спринта помогает команде учиться, адаптироваться и приносить пользу, значит, оно выполняет свою задачу. Если же оно регулярно задерживает принятие решений или приводит к ненужному ожиданию, руководители должны быть готовы задуматься, не лучше ли другой подход способствовал бы гибкости.
В конце концов, гибкая методология никогда не была направлена на защиту существующей структуры. Она была направлена на улучшение способности команды реагировать на изменения.
Подводя итоги
Спринт заслужил свое место в истории разработки программного обеспечения. Он помог командам освободиться от длительных циклов выпуска, улучшить прозрачность процесса и создать регулярные возможности для обратной связи.
Для многих организаций это по-прежнему обеспечивает структуру и предсказуемость во все более сложной среде. Но гибкая методология никогда не задумывалась как набор постоянных практик; ее основным принципом была адаптивность.
Поскольку автоматизация, непрерывная доставка и искусственный интеллект ускоряют темпы разработки программного обеспечения, командам следует задуматься над тем, помогают ли границы спринтов по-прежнему реагировать на изменения… или же они просто определяют, когда изменения допустимы.
Некоторые команды придут к выводу, что спринты остаются лучшим способом организации работы. Другие могут обнаружить, что более непрерывные подходы лучше соответствуют скорости выполнения задач и обучения. Ни один из вариантов не является по своей сути более гибким, чем другой.
Важно то, помогает ли этот процесс команде создавать ценность, учитывать обратную связь и адаптироваться к новой информации. Если да, то его следует сохранить; если нет, то изменить.
Готовность подвергать сомнению устоявшиеся практики может оказаться самой гибкой из всех практик.
Автор: Bart Gerardi работает в сфере электронной коммерции более 20 лет и не может представить себе лучшей работы. Он интересуется всем, что связано с гибкими методологиями разработки, и всем новым, чему можно научиться.
Источник: https://www.projectmanagement.com/articles/1215104/Are-Your-Sprints-Still-Truly-Valuable-