Применение практик DevOps - стр. 2

В 2001 году К. Швабер, К. Бек и ещё пятнадцать экспертов встретились, чтобы обсудить имевшиеся проблемы и выработать решение. Итогом стал так называемый манифест Agile (http://agilemanifesto.org/), призванный устранить разрыв понимания между бизнесом и разработчиками ПО (дополнительные сведения можно найти в главе «Управление разработкой ПО»).

Последовавшее развитие и принятие идей гибкой разработки сообществом программистов и менеджеров проектов сильно ускорили и перестроили разработку ПО.

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

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

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

Действительно, до начала самой разработки имеется ещё значительный блок работ, направленный на выявление бизнес-потребностей, их проработку, анализ, приоритизацию и т.д.

Далее, по окончании разработки, готовый программный код необходимо быстро развернуть в среде эксплуатации, чтобы заказчики получили всю ту пользу, которую им обещали, а также могли предоставить обратную связь разработчикам относительно качества получившегося продукта. При этом почти во всех организациях, возникших до 2010-х годов, ИТ-инфраструктура является жёсткой, основанной на дорогом аппаратном обеспечении, которое было приобретено достаточно давно, бюджеты на закупку и настройку выделялись непросто, да и бюджетный процесс для новых закупок – долгий.

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

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

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

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