Эволюция методологий разработки
Я занимаюсь разработкой софта уже почти 30 лет и на моих глазах происходило развитие отрасли. Рождались и умирали технологии, менялись языки разработки. Причем я наблюдал эти процессы не просто как сторонний наблюдатель. Менялись языки, на которых я писал код, умирали технологии, которые я использовал.
Сегодня я хочу рассказать об эволюции методологии разработки. Как она менялась с развитием отрасли и как это отражалось на работе обычных разработчиков. Я хочу рассказать эту историю простыми словами. Так, как ее видел обычный разработчик.
waterfall
Сначала была модель водопада waterfall. Она зародилась где то в 70-х годах и слава богу я ее не застал. Тогда компьютеры были уделом больших корпораций. Персональных компьютеров еще не существовало и к разработке софт подходили примерно также, как к разработке больших инженерных продуктов, например автомобиля или ракеты.
Работа на продуктом велась строго итеративно. Сначала проводился сбор требований. Затем разрабатывалось ТЗ. После этого разработчики приступали к написанию кода. После завершения наступал этап тестирования. И только поле этого внедрение продукта.
Все было очень жестко регламентировано. Процесс разработки продукта занимал несколько лет. Сама разработка стоила огромных денег. Но почему то на выходе, в отличии от автомобиля, почти всегда получался продукт, который никого не устраивал.
Это происходило потому, что компьютеры и отрасль в целом развивались бешеными темпами. И требования к продукту, которые собирались в начале разработки, успевали устаревать за один, два года. К моменту выпуска готового продукта он уже как правило был безнадежно устаревшим и не устраивал заказчика.
Spiral model
С появлением на рынке персональным компьютеров, программирование перестало быть уделом только больших корпораций. Стали появляться небольшие компании, такие как Apple и Microsoft, которые занимались разработкой программных продуктов.
Жесткая модель водопада уже просто не вписывалась в реалии рынка и отрасли. В 1986 г. была предложена новая, итерационная модель разработки Spiral Model. По сути это был тот же водопад. Но теперь к разработке продукта подходили не как к цельному процессу, а разбивали процесс разработки на этапы, на маленькие кусочки.
Сначала разрабатывался прототип, затем с каждым этапом, этот прототип развивался и чуть чуть улучшался. На выходе из каждого этапа мы каждый раз получали чуть улучшенный продукт.
Сами этапы все также разрабатывались по схеме водопада, но за счет большого числа итераций, появилась возможность адаптировать продукт под меняющуюся реальность.
Появление этой модели дало толчок к бурному развитию отрасли. По ней работали все крупные компании разработчики.
Scrum
Итерационная модель разработки позволяла выпускать адекватные продукты, которые удовлетворяли быстро меняющимся требованиям рынка. И в целом все всех устраивало.
Программистов было немного и программирование все еще было достаточно новым явлением для человечества. И в какой то момент у компаний разработчиков стали возникать проблемы уже не с самими продуктами, а с внутренними процессами их планирования и разработки.
В то время никто еще не понимал, как правильно организовать процесс разработки и как им правильно управлять. Быстро меняющиеся требования нарушали процессы планирования и приводили к постоянным срывам сроков выпуска продуктов. Менеджмент не понимал как рулить этим процессом. Разработчиков бесило, что требования и задачи постоянно меняются. Стало назревать недовольство уже внутри компаний разработчиков.
И в 90-х годах появилась такая методология как Scrum. В ее основу заложен очень простой принцип.
Спринт — это небольшой интервал времени (обычно 2 недели), который полностью управляется разработчиками. Менеджеры могут менять требования и вносить новые задачи только в будущие спринты. Вносить изменения в активный спринт запрещено.
Таким образом разработчики могли спокойно делать задачи в рамках активного спринта и быть уверенными в том, что никто не прибежит к ним с горящими глазами с требованием все бросить и переключится на совсем другую задачу.
В результате, внутри больших этапов, появились еще более мелкие итерации — спринты, которые управлялись только разработчиками. На самом деле эта модель получилась настолько удачной, что с минимальными изменениями она дожила до наших дней. И большинство компаний сейчас работают именно по методологии Scrum.
По сути Scrum — это такой договор между разработчиками и менеджерами. Вы можете менять все что угодно, пока мы не взяли это в работу. Но когда спринт в работе, идите лесом…
XP — Extreme Programming
До этого момента с разработкой все было хорошо. Люди занимались делом и пытались как то организовать свои процессы, чтобы сделать их удобными и рабочими.
Но в 2000-х годах появилась новая, модная методология с броским названием Экстремальное программирование и в мир разработки пришел маркетинг.
По сути своей, это была очень правильная штука, которая описывала разные полезные практики, которые можно было использовать в разработке:
разработка через тестирование (test-driven development)
игра в планирование (scrum poker)
парное программирование (pair programming)
непрерывная интеграция (continuous integration)
простота проектирования (simple design)
и другие полезные практики
Эти практики можно было использовать в конкретных ситуациях, а можно было не использовать, если ситуация не подходит под эту практику. В целом они действительно полезны и многие практики из XP сейчас по сути стали стандартами: continuous integration, code style, scrum poker, small releases.
Но почему то мир воспринял эту методологию как догму. Менеджеры увидели в этой методологии свой святой грааль и спустили на разработчиков эту методологию не как набор полезных практик, а как догму и религию.
Я очень хорошо помню наши шутки того времени про парное программирование.
Отличная штука это парное программирование. Можно сэкономить на дорогих компьютерах, 1 компьютер на 2 разработчика.
В 2000-х годах менеджмент реально заставлял разработчиков сидеть вдвоем за одним компьютером и пытаться писать код.
Все доводы разработчиков про то, что это не догма, а гибкая методология, игнорировались менеджментом. Все ждали от внедрения XP того чуда, которое дало внедрение scrum. Но чуда не случилось по понятным причинам (точнее оно случилось чуть позже, когда все немного успокоились). Причем это помешательство на XP было массовым и так или иначе затронуло пожалуй все компании на рынке.
Agile
Примерно к 2005 году первые страсти по XP спали. Менеджмент успокоился и отстал от разработчиков. Разработчики вздохнули с облегчением и стали внедрять практики XP уже не как догмы, а именно как полезные практики и это довольно сильно изменило подход к разработке софта. Многие элементы XP позволили кардинально изменить подходы к разработке и выпуску продуктов.
Например сейчас уже никого не удивишь тем фактом, что релиз продукта выходит каждые две недели. Но в 2000-х годах это казалось фантастикой. В то время средний релизный цикл продукта занимал 1–2 года.
В 2010–2015 годах в России стал появляться Agile. По сути это было просто обобщение практик XP программирования и дополнение их базовыми принципам:
люди и взаимодействие важнее процессов и инструментов
работающий продукт важнее исчерпывающей документации
готовность к изменениям важнее следования первоначальному плану
самый эффективный метод обмена информацией в команде — личная встреча
работающее программное обеспечение — лучший измеритель прогресса
Agile пропагандирует разработку в виде небольших, максимально независимых и самодостаточных команд. Основной приоритет, максимально частые релизы. Основная ценность — это фича, которая полезна пользователям. Все процессы должны быть максимально простыми. Ничто не должно мешать быстрой разработке и внедрению фичи.
И началось второе пришествие маркетинга в мир разработки софта. Несмотря на то, что в манифесте Agile прямо прописано, что это гибкая методология и ее нельзя воспринимать как догму, менеджмент начал насаждать Agile именно как догму.
Роль скрам мастера стала полноценной профессией. Мы все стали считать часы в попугаях, играть в скрам покер, забивать на документацию и аналитику. А также иногда и на полноценное тестирование.
Сейчас, когда вторая волна маркетинга схлынула, Agile трансформировался в рабочую концепцию. На первое место вышел процесс выпуска регулярных релизов. Крупные компании адаптировались к Agile следующим образом:
Появилось большое количество фича-команд, которые отвечают за очень ограниченные функциональные блоки. Команды самодостаточны и развивают свою функциональную область и зону ответственности. Как правило команда имеет своего собственного аналитика, дизайнера, разработчиков и тестировщиков.
Появились платформенные команды, которые решают общие вопросы и отвечают за технологический стек и архитектуру проекта в целом.
Появились релизные команды, которые отвечают за регулярный выпуск релизов. Они собирают со всех команд финализированные фичи и включают их в плановые релизы. Релизная команда имеет своих тестировщиков, которые занимаются тестированием релиза в целом, а не отдельной фичи. Релизы стали выходить строго по графику, как правило 1 раз в 2 недели.
Появились механизмы фича-рубильников, которые физически, на уровне кода выключают отдельные фичи. Если фича не готова к релизу, то релизная команда просто выключает рубильник, связанный с фичей. Это позволило командам спокойно разрабатывать фичи, не блокируя общий релизный процесс.
В целом бизнес и разработка адаптировались к Agile методологии и переварили ее, слегка изменив по дороге. Ждем следующую волну…
Следующая волна
Сейчас уже очевидно, что следующая волна изменений в методологиях разработки будет связана с появлением LLM моделей и ChatGPT.
Уже сейчас ChatGPT выдает вполне работоспособный код для решения локальных задач. Единственная проблема, что этот код сложно использовать в больших проектах, так как ChatGPT пока не может учитывать контекст большого проекта. Но крупные компании разработчики, такие как Microsoft и Google вполне в состоянии прикрутить исходные коды своих проектов к контексту языковой модели. И в этом случае качество кода и решений, выдаваемое LLM моделями должно кардинально вырасти.
Очевидно, что вектор развития идет именно в этом направлении и очень скоро профессия программист выродится во что то иное. Станет не важно знание языков программирования. Да и сами языки программирования скорее всего исчезнут, так как LLM модели могут переводить аналитику сразу в машинные коды.
Думаю я еще успею застать время, когда профессия программист исчезнет полностью и мы все превратимся либо в аналитиков, либо в безработных.
Ведь что такое программист, программист это просто высокооплачиваемый транслятор кода. Он переводит язык аналитики в язык программных кодов.
ChatGPT делает ровно тоже самое, только дешевле и возможно даже лучше.
Это немного грустно, так как на моих глазах прошла целая эпоха. Программирование развивалось очень бурно и достаточно сильно изменило наш мир. Это было веселое и интересное время и мне повезло, что расцвет моей профессиональной карьеры попал именно на этот период. Но технологический прогресс не остановить и думаю что очень скоро это время станет историей.
