Кэтрин Дэниелс - Философия DevOps. Искусство управления IT

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

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

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

Рис. 4.1. Каскадная модель

Гибкая методология разработки ПО

Эпитет «гибкий» (agile) относится к целой группе методологий, применяемых при разработке программного обеспечения. Эти методологии являются более «легкими» и гибкими по сравнению с более ранними методиками (например, с каскадной моделью). В 2001 году был опубликован Agile-манифест (см. главу 2), в котором были изложены основные принципы гибкого программирования.

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

• отдельных людей и взаимодействий выше ценности процессов и инструментов;

• рабочей документации выше ценности исчерпывающей документации;

• сотрудничества с заказчиками выше ценности переговоров, проводимых в процессе заключения контракта;

• реагирования на изменение ситуации выше ценности точного следования плану.

Как видите, компоненты, находящиеся в левой части списка, оцениваются выше компонентов, расположенных в правой части списка.

К гибким методологиям относится Scrum, которая будет рассмотрена в одном из следующих разделов, и другие методы, при использовании которых во главу угла ставится сотрудничество, гибкость и конечный результат в виде работоспособного программного обеспечения.

ЯВЛЯЕТСЯ ЛИ DEVOPS ПРОСТО ОЧЕРЕДНОЙ ГИБКОЙ МЕТОДОЛОГИЕЙ?

Методология devops имеет много общего с гибкими методиками разработки программного обеспечения, особенно если учитывать фокус на отдельных людях, взаимодействиях и сотрудничестве. В связи с этим у вас, наверное, уже возник вопрос о том, не является ли devops просто «ребрендингом» гибких методик. Несомненно, методология devops сформировалась на основе гибких методик, но все же она является самостоятельным культурным движением. Это движение связано с историей компьютерной индустрии и включает гораздо больше, чем разработчики программ. Движение devops адаптирует и расширяет принципы гибкой разработки программ и применяет их на уровне организации в целом, а не только в процессе разработки программ. Как будет подробно показано в следующих главах, devops приводит к культурным последствиям, выходящим за пределы области гибкой разработки. Изменения, вызванные внедрением devops, гораздо шире, чем банальное увеличение скорости доставки новых версий программ.

Scrum

В середине 1990-х годов Кен Швабер и доктор Джефф Сазерленд, принимавшие участие в создании Agile-манифеста, объединили усилия с целью формирования нового процесса создания программного обеспечения под названием Scrum. В методологии Scrum основной упор делается на максимизации способностей команды разработчиков к быстрому реагированию на изменение требований к самому проекту и со стороны заказчиков. При этом используются предопределенные циклы разработки, называемые спринты . Обычно длина циклов варьируется от одной недели до одного месяца. Процесс разработки ПО начинается с совещания по планированию спринтов, на котором определяются цели, выполняется обзор спринтов и производится ретроспектива спринтов. Это нужно для оценки степени выполнения спринтов и каких-либо проблем, которые могут возникнуть в процессе выполнения спринта.