Какие аспекты управления релизами помогают объяснить разницу между Waterfall и Agile?

Когда кто-то объясняет DevOps, возникает вопрос:

Чем Управление релизами, использующее Agile методологию, отличается от Waterfall?

Итак, какие критерии вы можете использовать, чтобы объяснить эти различия такой аудитории?

IMO DevOps - это культура, очень похожая на Agile (без выбора гибкой методологии.) Поэтому вы не «делаете» DevOps.

Вы «делаете» методологию выпуска под названием «Непрерывная доставка» как часть культуры DevOps. (полное раскрытие, я не думаю, что раньше когда-либо упоминал CD как методологию релиза, но в моем состоянии с меткой я думаю, что это работает)

Если вы купите это, то вот определение Непрерывной Доставки от одного из людей, которые написали книгу с тем же названием, Джез Хамбл .

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

Наша цель - сделать развертывания - будь то крупномасштабной распределенной системы, сложной производственной среды, встроенной системы или приложения - предсказуемыми, рутинными операциями, которые могут быть выполнены по требованию.

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

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

Вы получите что-то вроде этого:

Таким образом, программное обеспечение (вероятно) будет лучше, когда вы закончите, тогда, если у вас не было какого-то итеративного подхода, но вы не знаете, потому что реальные пользователи никогда не видели его.

То, что вы действительно хотите, это то, что выглядит примерно так:

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

Какого черта!? Я спросил о DevOps! Никто не спрашивал о непрерывной доставке !!

Какое отношение DevOps имеет к этому?

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

Примечание :

О части комментария, опубликованной к этому ответу, которая была такова:

О вашем "... программном обеспечении в состоянии, в котором вы можете развернуть его, когда захотите ...": это напоминает мне о программном обеспечении "автопилот" (в самолете) ... Мой любимый вопрос по этому поводу: " Вообразите обновление применяется к такому программному обеспечению ... Как бы вы относились к такому полету ... Пока вы на борту? ".

Мне нравится этот вопрос (выделено жирным шрифтом в приведенной выше цитате)! Идея "это действительно готово?" это то, о чем я постоянно болтаю - блог . IMO жизненно важно, чтобы вы были уверены в безопасности, производительности и других слишком часто «вторичных» тестах, чтобы практиковать CD. Функции сделаны, когда они сделаны, но хакеры всегда рядом.

Не уверен, что других нет, но вот критерии, которые я использую:

+-------------------+-----------+-----------+
! Criteria          ! Agile     ! Waterfall !
+-------------------+-----------+-----------+
! Release Events    ! Frequent  ! Rare      !
! Risk              ! Less      ! High      !
! Required Effort   ! Smoother  ! Peaks     !
! Volume of changes ! Small     ! Huge      !
+-------------------+-----------+-----------+

И если вы действительно хотите почувствовать разницу как пользователь некоторого программного обеспечения, подумайте об использовании некоторого программного обеспечения (например, дистрибутива Linux), когда у вас есть выбор между использованием любого из этих выпусков:

• " Rolling" релиз (==> Agile).

• " Long Term Support" выпуск (==> Водопад).