Предисловие
Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…
Что такое DevOps
Согласно википедии DevOps набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Т.е. это попытка масштабировать Agile весь процесс разработки ПО включая внедрение и сопровождение. Основное назначение DevOps-а — увеличение частоты релизов и повышение ответственности команды за продукт. Звучит идеально… как и любые маркетинговые слоганы…
С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).
Как DevOps убивает качество
Если вернуться в 90-ые и 00-е, то для создания продукта необходимо было несколько ролей в команде: аналитик, проектный менеджер, разработчик и тестировщик и внедренец. Каждая из этих ролей важна для создания качественного продукта: аналитик собирает требования и ограждает разработчиков от излишнего взаимодействия с заказчиком/пользователями, менеджер координирует работу команды и решает организационные и финансовые вопросы, разработчик — пишет код и правит баги, тестировшик эти баги находит и проверяет соответствие требованиям, внедренец — устанавливает ПО и является первой линией поддержки пользователей, огорождая разработчиков от лишних вопросов. Эта система хоть и слегка громоздка, но в ней есть чёткое разделение ролей в команде и новый функционал проходит через несколько человек, что повышает качество и позволяет взглянуть на проблему с нескольких точек зрения, что в результате даёт хороший и стабильный результат.
В 2000ых на смену этому подходу пришёл Agile, который с одной стороны больше вовлёк заказчиков в разработку, с другой стороны сильно уменьшил или вырезал роль аналитиков и проектных менеджеров. При этом внедрение осталось обособленным от основной части команды. Постепенно развёрнутые постановки стали заменяться фичами в бэклоге. Как разработчик, я всё-же больше люблю Agile, чем не люблю. Он повысил качество взаимодействия членов команды и вовлёк заказчика в процесс. Основным недостатком этого подхода стало потеря виденья проекта в целом. Т.е. понятие цельного продукта было заменено на набор фич, что повлекло к первому провалу в качестве. Разработка стала представлять собой лоскутное одеяло, когда новая фича прибивалась гвоздями к существующей и в результате система теряла целостность (хотя эта проблема не существует в командах с хорошими архитекторами/аналитиками, т.к. контроль позволяет избежать подобных проблем).
Сейчас Agile превращается в DevOps. Под слоганом повышения ответственности за продукт из команд почти полностью выпиливается тестирование, а внедрение существенно урезается и превращается в часть разработки. Роль разработчика повышается, но фактически в команде остаются только они, а само тестирование частично уходит в автоматизацию, частично ложится на плечи бета-тестеров и заказчиков. Сейчас многие компании (в особенности на Западе, где стоимость рабочей силы намного выше) с гордостью заявляют, что у них в командах нет тестировщиков, а разработчики владеют продуктом и отвечают за его качество. Но в чём же тут проблема?
Изначально продукт проходил несколько стадий контроля качества: сначала аналитик отфильтровывал требования заказчика и продумывал реализацию, потом разработчик проверял постановку и взаимодействовал с аналитиком чтобы улучшить её. Далее в ходе реализации рождались идеи по улучшению и они добавлялись в работу. Потом тестировщик проверял продукт и исправлялись ошибки. Далее аналитик демонстрировал работу заказчику и устранялись замечания.
Теперь есть только фича в бэклоге, разработанный функционал и автотесты и приёмка заказчиком (если он есть). Фактически фичей владеет только один человек и больше нет того уровня взаимодействия в команде.
Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей. Поэтому и качество программных продуктов за последнее время сильно упало и они стали менее удобными для пользователей (взять к примеру последнюю версию Skype, хотя примеров намного больше...).
Есть ли решение?
С моей точки зрения — решение есть, и оно достаточно простое. Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте). Притом всё это легко интерировать в процесс DevOps. Вот моя идея: аналитики собирают требования клиентов и заказчиков и являются product-owner-ами для разработчиков, роль тестировщика и разработчика понятна, внедрение либо сливается с аналитиками, либо тесно с ним взаимодействует (тем самым замыкая цикл DevOps-а). От DevOps-а остаётся высокая степень автоматизации тестирования и внедрения, постоянное наличие стабильной версии продукта и частота релизов (вернее я бы сказал, что каждый билд — это релиз в данном случае). Ещё одно важное правило — быть клиентоориентированным и клиенто-центричным. Т.е. потребности клиентов должны быть превыше всего. Как не странно оба этих принциа успешно используются уже много лет в таких аутсорс компаниях, как EPAM (привет бывшим коллегам!) и отлично себя зарекомендовали там. Правда раньше автоматизация не была так развита, но надеюсь они восполнили уже этот пробел…
Комментариев нет:
Отправить комментарий