Pull to refresh

Почему я не люблю DevOps (и современное ПО)

Reading time 4 min
Views 32K

Предисловие


Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…

Что такое DevOps


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

С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).

Как DevOps убивает качество


Если вернуться в 90-ые и 00-е, то для создания продукта необходимо было несколько ролей в команде: аналитик, проектный менеджер, разработчик и тестировщик и внедренец. Каждая из этих ролей важна для создания качественного продукта: аналитик собирает требования и ограждает разработчиков от излишнего взаимодействия с заказчиком/пользователями, менеджер координирует работу команды и решает организационные и финансовые вопросы, разработчик — пишет код и правит баги, тестировшик эти баги находит и проверяет соответствие требованиям, внедренец — устанавливает ПО и является первой линией поддержки пользователей, огорождая разработчиков от лишних вопросов. Эта система хоть и слегка громоздка, но в ней есть чёткое разделение ролей в команде и новый функционал проходит через несколько человек, что повышает качество и позволяет взглянуть на проблему с нескольких точек зрения, что в результате даёт хороший и стабильный результат.

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

Сейчас Agile превращается в DevOps. Под слоганом повышения ответственности за продукт из команд почти полностью выпиливается тестирование, а внедрение существенно урезается и превращается в часть разработки. Роль разработчика повышается, но фактически в команде остаются только они, а само тестирование частично уходит в автоматизацию, частично ложится на плечи бета-тестеров и заказчиков. Сейчас многие компании (в особенности на Западе, где стоимость рабочей силы намного выше) с гордостью заявляют, что у них в командах нет тестировщиков, а разработчики владеют продуктом и отвечают за его качество. Но в чём же тут проблема?

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

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

Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей. Поэтому и качество программных продуктов за последнее время сильно упало и они стали менее удобными для пользователей (взять к примеру последнюю версию Skype, хотя примеров намного больше...).

Есть ли решение?


С моей точки зрения — решение есть, и оно достаточно простое. Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте). Притом всё это легко интерировать в процесс DevOps. Вот моя идея: аналитики собирают требования клиентов и заказчиков и являются product-owner-ами для разработчиков, роль тестировщика и разработчика понятна, внедрение либо сливается с аналитиками, либо тесно с ним взаимодействует (тем самым замыкая цикл DevOps-а). От DevOps-а остаётся высокая степень автоматизации тестирования и внедрения, постоянное наличие стабильной версии продукта и частота релизов (вернее я бы сказал, что каждый билд — это релиз в данном случае). Ещё одно важное правило — быть клиентоориентированным и клиенто-центричным. Т.е. потребности клиентов должны быть превыше всего. Как не странно оба этих принциа успешно используются уже много лет в таких аутсорс компаниях, как EPAM (привет бывшим коллегам!) и отлично себя зарекомендовали там. Правда раньше автоматизация не была так развита, но надеюсь они восполнили уже этот пробел…
Only registered users can participate in poll. Log in, please.
Как вы относитесь к DevOps
16.47% Прорывной подход — будущее за DevOps 109
49.7% Идея хорошая, но не всегда реализуется правильно 329
16.47% Ещё один способ уменьшить затраты в ущерб качеству 109
17.37% Хайповая вещь, которая умрёт через несколько лет 115
662 users voted. 184 users abstained.
Only registered users can participate in poll. Log in, please.
Применяете ли вы DevOps
31.66% Активно использую и буду использовать в будущем 170
2.98% Активно использую, но не стал бы использовать в новых проектах / планирую отказаться 16
21.42% Использую только частично, планирую внедрять оставшиеся части 115
14.53% Использую только частично и не планирую внедрять дальше 78
9.12% Не использую, но хотел бы внедрить 49
20.3% Не использую и не планирую внедрять / не хочу участвовать 109
537 users voted. 211 users abstained.
Only registered users can participate in poll. Log in, please.
Нужны ли тестировщики/QA-специалисты в современном мире разработки?
76.67% Да, они выполняют важную роль и будут также важны в будущем 506
17.27% Да на текущий момент, но будут вытеснены автоматизаций/ИИ в будущем 114
3.94% Нет, их роль отошла на второй план и они могут быть заменены автоматизированным тестированием/бета-тестированием на стороне заказчика 26
2.12% Нет, разработчики сами могут протестировать продукт (например тестируя код коллег). 14
660 users voted. 125 users abstained.
Tags:
Hubs:
+14
Comments 85
Comments Comments 85

Articles