У меня есть постоянный спор — наш менеджер по доставке пытался внедрить в наши команды шаблон «релиз после 3 спринтов». К сожалению, как и во многих других компаниях, фактическая работа может состоять из х спринтов, часто больше 3.
Я утверждаю, что только потому, что прицел фиксирован заранее, это просто наше Министерство обороны. Мы выпускаем в Live, когда завершаем объем и готово. Ничто здесь не нарушает принципов Agile — мы просто признаем, что, хотя теоретически мы можем выпустить «живой» продукт в конце заданного спринта, на самом деле мы никогда этого не сделаем, пока не закончим и у нас не появится настоящий релиз-кандидат.
Он утверждает, что agile может быть agile, только если вы работаете спринтом за раз и у вас есть релиз-кандидат в каждом спринте.
Какая версия правильная, или мы оба правы/неправы?
В любой гибкой структуре, если вы хотите оценить на основе фиксированной области, предполагаемые даты выпуска будут различаться. Если вместо этого вы выберете фиксированную дату выпуска или стандартную частоту выпуска, то объем будет варьироваться. Оба варианта являются законными, но в этом случае ваш менеджер по доставке прав больше, чем вы.
Ваш менеджер по доставке в основном прав. Независимо от того, следуете ли вы Scrum или какой-либо другой среде, в которой просто используется термин «спринт», гибкая итерация всегда должна приводить к потенциально готовому к выпуску продукту. Scrum, в частности, ясно дает понять, что каждый инкремент должен быть выпускаемым :
В конце Спринта новый Инкремент должен быть «Готово», что означает, что он должен быть в пригодном для использования состоянии и соответствовать определению «Готово», данному Скрам-командой... Инкремент должен быть в пригодном для использования состоянии независимо от того, решает выпустить его.
Хотя большинство гибких фреймворков не определяют фиксированную частоту выпуска, они и не запрещают ее. Поскольку каждый спринт приводит к потенциально готовому приращению, нет причин не ориентироваться на трехмесячную периодичность выпуска для проекта, если это повышает ценность для бизнеса.
Более традиционно видеть, как гибкое планирование выпуска оценивает дату выпуска на основе того, сколько итераций, вероятно, потребуется для завершения заданного набора функций. Тем не менее, Lean Flow, культура DevOps и сдвиг отрасли в сторону непрерывной доставки и непрерывного развертывания привели к тому, что некоторые проекты перешли к рутинной частоте выпуска, такой как та, которую хочет ваш менеджер по доставке.
Например, в Ubuntu есть периодичность выпуска выпусков раз в два года для выпусков с долгосрочной поддержкой и периодичность в шесть месяцев для промежуточных выпусков. Напротив, цикл выпуска Debian следует более традиционной модели, которая по своей сути не ограничена во времени.
Надежная каденция, как правило, полезна в рамках управления проектами. Тем не менее, итеративная частота поставки и частота выпуска продукта на самом деле являются двумя разными вещами. Должны ли релизы следовать ритму или нет, — это бизнес-решение для конкретного продукта, и на этот вопрос нет универсального ответа.
Релизы — чрезвычайно важный аспект Agile. Есть много причин их важности, в том числе:
Именно по этой причине Agile-фреймворки, такие как Scrum, подчеркивают необходимость иметь потенциально готовый инкремент в конце каждого спринта.
Может возникнуть соблазн сказать, что вы не хотите выпускать продукт до тех пор, пока законченная работа по разработке не станет многофункциональной и «завершенной» с точки зрения маркетинга продукта. Тем не менее, это упускает из виду два из трех пунктов, упомянутых выше. Если вы ждете, пока продукт не станет полнофункциональным, прежде чем выпускать его, вы откладываете неопределенность выпуска и позволяете своим разработчикам привыкнуть к задержке работы, которая важна только для выпуска.
Стоит отметить, что многие Agile-организации выпускают релизы часто, но не сразу делают свои изменения доступными для пользователей. Например, некоторые команды используют переключатели функций . Это дает лучшее из обоих миров, вы получаете ценность частых выпусков, но также можете позволить вашему бизнесу и маркетологам контролировать, как и когда функции становятся доступными для пользователей.
Тодд А. Джейкобс