Рассмотрим, как эволюционировали и менялись подходы к разработке программных продуктов и что ждет нас в будущем.
От «водопада» до Agile
Давайте вспомним основные этапы эволюции различных подходов к разработке софта — как менеджеры пытались упорядочить работу программистов, и что из этого вышло.
Эволюция управления проектами в сфере разработки софта происходила от сложного к простому. Сначала разработку программных продуктов пытались вести так же, как разработку какого-нибудь сложного инженерного продукта. Например, как строить самолет или ракету. То есть сначала вы его проектируете, потом производите, затем тестируете и только после этого выпускаете в жизнь. Как раз этот процесс и описывает модель водопада — Waterflow. Все процессы здесь строго последовательны и жестко регламентированы.
Но требования к самолету не меняются с такой же скоростью, как требования к программному продукту. Компьютеры развивались бешеными темпами. Требования, заложенные в продукт в начале его разработки, безнадежно устаревали за два-три года.
Все это вынудило разработчиков внедрять итерационные модели, которые позволяют менять требования к продукту прямо на этапе его разработки. Так родилась спиральная модель — Spiral model.
Еще один важный аспект, который следует учитывать: что разработка программного обеспечения — достаточно новое явление для мира. Никто не знал, как правильно управлять разработкой программного обеспечения. Как правильно и эффективно организовать рабочие процессы. Постепенно методом проб и ошибок закреплялись наборы успешных практик и методик, помогающих организовать процесс разработки и сделать его более эффективным.
Все это привело к появлению в начале
- Разработка через тестирование (test-driven development).
- Игры в планирование (planning game).
- Непрерывная интеграция (continuous integration).
- Частые релизы (small releases).
- Простота проектирование (simple design: dry, kiss, yagni).
- Стандарты оформления кода (code style).
- Парное программирование (pair programming).
Спустя некоторое время все это преобразовалось в манифест Agile, который объединил в себе все удачные практики XP и добавил к ним декларацию базовых ценностей:
- частая поставка работающего программного обеспечения;
- люди и взаимодействие важнее процессов и инструментов;
- работающий продукт важнее исчерпывающей документации;
- готовность к изменениям важнее следования первоначальному плану;
- самый эффективный метод обмена информацией в команде — личная встреча;
- работающее программное обеспечение — лучший измеритель прогресса.
Загвоздка в том, что внедрение гибких методологий разработки часто воспринималось бизнесом не как некая абстрактная концепция, а как панацея, которая позволит им решить все проблемы. В результате методологии XP и Agile внедрялись бизнесом как догмы. Бизнес не разбирался в том, что работает в каждом конкретном кейсе, а что нет. На разработку просто спускался Agile вместе с Agile-коучем, со словами «он вас всему научит».
В результате трансформация процессов разработки проходила с большим скрипом. Разработчики часто относились к такому внедрению Agile, как к повинности, и следовали ее принципам соответствующим образом — для галочки.
Как пример такого внедрения можно привести практику парного программирования. Она появилась вместе с XP и в начале
Актуальные на данный момент подходы к разработке
Сейчас рынок, в целом, уже адаптировался к новым методикам. Компании поняли, что нельзя относится к Agile, как догмам, а разработчики поняли и приняли базовые ценности Agile. В наше время уже никого не удивишь выпуском новых версий раз в две недели. Но в
Современные подходы к разработке хороши тем, что они адаптируются под ваш продукт и процессы. Именно поэтому их называют гибкими методиками разработки. Но важно не воспринимать их как догму и использовать именно как гибкие подходы к разработке. Где-то хорошо работает Scrum, а где-то Kanban. Спринт может быть двухнедельным, а может быть и месячным. Где-то считают сторипоинты в «попугаях», а где-то в эталонных задачах. Нужно просто адаптировать их под конкретный продукт и процессы в компании, а не использовать бездумно.
Agile часто критикуют за то, что он призывает нас отказываться от документации и аналитики в угоду скорости разработки и поставки новых фич. А также за то, что он утверждает, что продукт важнее процесса. Но на самом деле он не принуждает нас делать это. Просто в каких-то продуктах это может быть допустимо, а в каких-то нет. Ты сам решаешь, применимо ли это к твоему продукту и твоей ситуации.
Например, в банковских продуктах очень высокие требования к качеству, надежности и безопасности. Тестирование и приемка одной фичи может занимать длительное время, но это не мешает использовать в банках Agile-подход и выпускать регулярные релизы по короткому релизному циклу.
Современные гибкие методики разработки вобрали в себя все хорошее и полезное из основных моделей, которые использовались ранее. Например, разработка одной атомарной фичи до сих пор, в целом, происходит по модели водопада. Но если мы видим, что требования к фичи меняются, то можем применить итерационный подход, сделать несколько версий фичи и развивать ее постепенно.
Мы можем разрабатывать какую-то часть проекта по итерационной модели с достаточно редкими релизами. Например, такой подход часто применяется к ядру системы, которое может релизиться редко. Но в тоже время разрабатывать другие части проекта по Agile подходу с частыми релизами.
За какими подходами менеджмента в сфере ИТ будущее?
Обычно новые подходы к разработке появляются как ответ на изменяющиеся условия среды. До недавних пор мир разработки жил по вполне устоявшимся правилам. Современные методики разработки отлично подходят под решение текущих задач и проблем отрасли.
Но с появлением ChatGPT стало очевидно, что именно это событие станет причиной для следующих фундаментальных изменений. Мы не можем сказать, как именно изменятся подходы к разработке в будущем, но то что их изменение будет в первую очередь связано с появлением ИИ, уже можно сказать абсолютно точно.
Сейчас часто звучат вопросы, сможет ли ИИ заменить программистов? Я считаю, что да, и это произойдет гораздо раньше, чем мы все ожидаем.
Несколько лет назад я считал, что программирование — это слишком творческий процесс для искусственного интеллекта. Но с появлением ChatGPT мое мнение резко изменилось. Посмотрите на таксистов: возможно 10 лет назад они говорили точно так же — про искусство вождения автомобиля, контраварийную езду и все такое. Но уже сейчас беспилотники на улицах Москвы перестали быть редкостью.
С программированием будет все то же самое: ChatGPT уже сейчас генерирует вполне рабочий код. На мой взгляд, сейчас проблема только в одном: у систем, подобных ChatGPT, пока очень маленький размер контекста. Он не может генерировать код, привязанный к контексту вашего проекта. То есть этот код невозможно встроить в код проекта без существенной адаптации к архитектуре и фреймворкам проекта.
Но как только это ограничение будет снято, я думаю, многим из нас придется стать аналитиками. И мы действительно будем составлять промты для нейросетей, и профессия программиста, скорее всего, выродится во что-то другое.
Ведь что такое программист — по сути, это высокооплачиваемый транслятор кода. Программист переводит язык аналитики в язык машинных кодов. ChatGPT делает тоже самое, переводит одну языковую модель в другую.
И крупные компании уже давно поняли это и активно работают в этом направлении. Так что фундаментальные изменения на рынке разработки не за горами и нам всем уже пора начинать готовиться к этому.
