Как стать автором
Обновить

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

Тестирование IT-систем *Agile *Карьера в IT-индустрии DevOps *

Предисловие


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

Что такое DevOps


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

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

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


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

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

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

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

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

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

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


С моей точки зрения — решение есть, и оно достаточно простое. Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте). Притом всё это легко интерировать в процесс DevOps. Вот моя идея: аналитики собирают требования клиентов и заказчиков и являются product-owner-ами для разработчиков, роль тестировщика и разработчика понятна, внедрение либо сливается с аналитиками, либо тесно с ним взаимодействует (тем самым замыкая цикл DevOps-а). От DevOps-а остаётся высокая степень автоматизации тестирования и внедрения, постоянное наличие стабильной версии продукта и частота релизов (вернее я бы сказал, что каждый билд — это релиз в данном случае). Ещё одно важное правило — быть клиентоориентированным и клиенто-центричным. Т.е. потребности клиентов должны быть превыше всего. Как не странно оба этих принциа успешно используются уже много лет в таких аутсорс компаниях, как EPAM (привет бывшим коллегам!) и отлично себя зарекомендовали там. Правда раньше автоматизация не была так развита, но надеюсь они восполнили уже этот пробел…
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Как вы относитесь к DevOps
16.64% Прорывной подход — будущее за DevOps 109
49.77% Идея хорошая, но не всегда реализуется правильно 326
16.34% Ещё один способ уменьшить затраты в ущерб качеству 107
17.25% Хайповая вещь, которая умрёт через несколько лет 113
Проголосовали 655 пользователей. Воздержались 182 пользователя.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Применяете ли вы DevOps
31.84% Активно использую и буду использовать в будущем 170
3% Активно использую, но не стал бы использовать в новых проектах / планирую отказаться 16
21.54% Использую только частично, планирую внедрять оставшиеся части 115
14.61% Использую только частично и не планирую внедрять дальше 78
8.99% Не использую, но хотел бы внедрить 48
20.04% Не использую и не планирую внедрять / не хочу участвовать 107
Проголосовали 534 пользователя. Воздержались 208 пользователей.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Нужны ли тестировщики/QA-специалисты в современном мире разработки?
76.79% Да, они выполняют важную роль и будут также важны в будущем 503
17.25% Да на текущий момент, но будут вытеснены автоматизаций/ИИ в будущем 113
3.82% Нет, их роль отошла на второй план и они могут быть заменены автоматизированным тестированием/бета-тестированием на стороне заказчика 25
2.14% Нет, разработчики сами могут протестировать продукт (например тестируя код коллег). 14
Проголосовали 655 пользователей. Воздержались 123 пользователя.
Теги: DevOpsDevelopmentуправление проектами и командойразработкаagile
Хабы: Тестирование IT-систем Agile Карьера в IT-индустрии DevOps
Всего голосов 72: ↑43 и ↓29 +14
Комментарии 85
Комментарии Комментарии 85

Похожие публикации

Лучшие публикации за сутки