6 главных различий между DevOps и Scrum

На занятиях DevOps в прямом эфире и курсах подготовки к сертификации мы заметили, что один вопрос звучит неизменно. Поэтому сегодня я решил ответить на него в короткой статье. Вопрос звучит так: «Чем отличается DevOps от Scrum?» Иными словами, сравним DevOps и Scrum.

Сегодня я разберу шесть главных различий. Начнём!

Различие № 1 В DevOps вы развёртываете код в рабочей среде в конце каждой итерации (спринта), а в Scrum ваша цель — только подготовить код, пригодный к поставке, к концу каждой итерации.

Это один из главных недостатков Scrum. И одна из самых важных, если не главная, причина, по которой Scrum терпит неудачу во многих организациях. Если вы не развёртываете код в конце каждой итерации, то обычно оставляете его на промежуточных серверах или, что ещё хуже, в системе управления версиями (CVS), пока руководитель проекта, который зачастую ничего не знает о разработке ПО, не решит, когда код можно выпускать в рабочую среду. Я знаю крупные банки и телекоммуникационные компании, которые развёртывают код раз в полгода. Звучит как шутка, но это правда. Такие одномоментные развёртывания обходятся им множеством инцидентов наивысшего приоритета и серьёзности в рабочих системах, падением боевого духа и тем, что сотрудники чаще обновляют резюме. И это без учёта взаимных обвинений и интриг между людьми, далёкими от технологий, которые ищут виноватых, чтобы оправдать свои неудачи.

Различие № 2 В DevOps автоматизация тестирования и непрерывная интеграция ПО, необходимые для непрерывной поставки, заложены в саму разработку. В Scrum о поставке ПО вспоминают позже, а планировать и проводить её приходится людям, которые не участвуют в разработке.

Это ещё один из главных недостатков Scrum. Сам процесс Scrum практически не помогает наладить поставку ПО. В DevOps же обязательны конвейер поставки, автоматизация тестирования и архитектура рабочих систем, позволяющая командам развёртывать код одним нажатием кнопки. Подход Scrum к поставке ПО существует с 1986 года. Hirotaka Takeuchi и Ikujiro Nonaka впервые представили его в статье «New Product Development Game» в Harvard Business Review. За более чем 30 лет после появления Scrum способы поставки ПО значительно изменились к лучшему. Теперь DevOps отвечает на вопросы, которые Scrum оставил без ответа.

Различие № 3 В DevOps проекты ориентированы на продукты и услуги, которые приносят пользу бизнесу, тогда как Scrum не обладает необходимой зрелостью, чтобы улучшать бизнес-результаты.

DevOps воспринимает инженерные команды как самостоятельные подразделения, которые доводят работу до конца, поставляют работающие продукты и услуги, обслуживают клиентов и приносят организациям выручку. К сожалению, Scrum ничему не учит участников в отношении зрелости бизнеса. Возможно, вам тоже казалось, что эти «неприкосновенные» ритуалы Scrum, например запрет сидеть на ежедневной планёрке, по-своему привлекательны, но высококвалифицированные и высокооплачиваемые инженеры ведут себя так, словно попали в детский сад, а Scrum-мастер играет роль воспитателя. Это происходит потому, что Scrum не учит инженеров быть профессионалами. С DevOps каждый в инженерном подразделении, независимо от фактического опыта и знаний, действует профессионально и создаёт ценность для бизнеса. Больше нет лишних и бессмысленных споров на нелепые темы, например можно ли сидеть на ежедневной планёрке. В DevOps вы тратите энергию совместного обсуждения на поиск и улучшение лучших программных решений, чтобы бизнес больше зарабатывал!

Различие № 4 В DevOps все инженеры команды отвечают за качество услуг и ПО и за высокий уровень эксплуатации. В Scrum обеспечение качества ПО и эксплуатация достаются другим.

В большинстве Scrum-команд качеством ПО занимаются исключительно внешние тестировщики. Развёртывание и эксплуатация поручены системным администраторам. Этот отрыв Scrum-команд от качества поставки и реальной работы ПО — ещё одна из важнейших причин, по которым многие внедрившие Scrum организации сталкиваются с трудностями. В DevOps обеспечение качества — общая обязанность всех сотрудников подразделения разработки ПО. Квалифицированные full-stack-инженеры DevOps следят за поставкой, безопасностью, стабильностью, производительностью, удобством сопровождения, эксплуатацией и другими нефункциональными аспектами ПО с момента появления идеи до завершения жизненного цикла. Команды DevOps, объединяющие все навыки для разработки, обеспечения качества и эксплуатации ПО, имеют всё необходимое, чтобы успешно работать и добиваться выдающихся результатов для бизнеса.

Различие № 5 DevOps помогает проектировать архитектуру ПО так, чтобы обеспечить качество и непрерывную поставку. Scrum не помогает выбрать правильную архитектуру.

Scrum не даёт инженерным командам поддержки или рекомендаций, как задать правильное направление и видение архитектуры. Напомним: прошло больше 30 лет с тех пор, как Hirotaka Takeuchi и Ikujiro Nonaka представили Scrum. В DevOps продукты, услуги и API микросервисов в архитектуре должны быть слабосвязанными. Каждая команда DevOps отвечает за одну часть архитектуры и может самостоятельно проектировать, разрабатывать и развёртывать своё ПО. Встроенный в конвейер механизм раннего оповещения должен автоматически и быстро сообщать командам DevOps о возможных негативных последствиях каждого коммита.

Различие № 6 DevOps охватывает всю организацию разработки ПО, чтобы добиться выдающихся бизнес-результатов. Scrum сосредоточен только на разработчиках ПО.

Scrum ограничивается небольшими командами разработчиков от 5 до 9 человек. Десять нельзя, ответила бы теория Scrum, если бы вы спросили. Почему? Неизвестно! Из-за такого узкого взгляда на разработку ПО Scrum часто не подходит организациям, потому что он не объясняет, как Scrum-команда должна работать в профессиональной организации, чтобы приносить пользу. DevOps предлагает создавать команды, ориентированные на продукты и услуги. Это независимые, кросс-функциональные, автономные, самодостаточные и обычно небольшие команды, которые могут самостоятельно пройти весь инженерный жизненный цикл продукта или услуги, а не временного проекта: от архитектуры, проектирования, написания кода, тестирования и экспериментов до развёртывания, эксплуатации и сопровождения ПО. Да, вы всё правильно прочитали. Кто лучше создателей ПО может его эксплуатировать и сопровождать? Конечно, никто. Поэтому неудивительно, что самые успешные команды DevOps в Amazon и Netflix не бросают свои продукты и услуги после выпуска. Они также отвечают за их эксплуатацию и сопровождение в собственных рабочих системах.

Рассмотрев эти различия, вы уже наверняка понимаете, почему DevOps становится следующим поколением гибких подходов!

Через несколько лет DevOps получит полное признание как подход, охватывающий Scrum, ведь его уже внедрили такие крупные организации, как Google, Amazon, Facebook, Etsy, Netflix и многие другие.

Значит, скоро он будет повсюду!

International DevOps Certification Academy™ предоставит всё необходимое, чтобы вы могли с удобством освоить DevOps и сдать экзамен на сертификацию! Если возникнут вопросы, мы с командой, как всегда, будем рады помочь!

Лучшее предложение для старта (только сегодня!) >>

Перейти на сайт International DevOps Certification Academy™ >>

P.S. Давайте на минуту будем честны! Мы знаем, что сегодня мало кто читает блоги. Но мы всё равно находим время готовить для вас эти материалы. Даже если статью прочитает лишь горстка людей и узнает что-то новое, мы будем считать, что сделали свою работу на благо мирового сообщества DevOps.

Поддержите нас, если цените работу, которую мы вложили в эту статью! Если вы дочитали до этого места и статья оказалась полезной, оставьте отзыв ниже и поделитесь статьёй со знакомыми!

ЗАРАНЕЕ СПАСИБО! :)