В статье о каскадной разработке мы рассказали о классической модели создания больших программ: там сначала долго собирают все требования, пишут ТЗ, а потом делают всю программу в строгом соответствии с этим ТЗ. Эта модель подходит для создания больших программных комплексов, но для стартапов и небольших команд работает плохо. В 1980-х годах сотрудник IBM Джеймс Мартин придумал другой подход. Вот о нём и поговорим.
Что такое RAD
RAD — это сокращение от rapid application development, «быстрая разработка приложений». В RAD мы идём маленькими итерациями, чтобы получить рабочий продукт за короткое время и в ограниченном бюджете. При этом мы договариваемся, что функциональность приложения может меняться в процессе разработки.
В основе RAD лежат три принципа:
- Высокая скорость — нам нужно получить результат как можно быстрее, например, чтобы новая версия вышла уже на следующей неделе.
- Низкая стоимость — у нас жёстко зафиксированный бюджет, который мы не можем превысить.
- Высокое качество — всё, что мы делаем, должно работать без ошибок. Но объём сделанного может быть меньше, чем изначально планировали.
Этапы разработки
Обычно RAD-разработка проходит по таким этапам:
Сбор требований. Собираем всю информацию от заказчика — о его бизнес-процессах, клиентах, задачах, требованиях к программе, какие нужно поддерживать операционные системы и оборудование, порядок обучения и вообще всё, что нужно для проекта. Это полноценный этап, который может занимать недели и месяцы. Тут никакого волшебства.
Итерация проектирования. Программисты быстро собирают прототип и рисуют к нему дизайн. Смысл этапа в том, чтобы как можно быстрее собрать кирпичик большой программы и довести его до рабочего состояния.
Итерация тестирования. Кирпичик отправляется клиенту и тестировщикам, чтобы они проверили работоспособность этого конкретного блока. Если находят ошибки — исправляем. Допиливаем кирпичик, пока он не будет работать как положено.
Итерация деплоя. В какой-то момент из кирпичиков собирается работоспособный продукт, который можно показывать пользователям. Приложение выкатывают и потом постепенно дополняют.
Так повторяется снова и снова — программисты делают новые кирпичики, пользователи их тестируют, и после тестов они остаются в программе. Так программа постепенно обрастает нужными возможностями, а пользователи дают обратную связь.
Зачем такая сложность
Смысл RAD-подхода в том, чтобы работать с живым продуктом и иметь возможность его переделать на лету. Это особенно нужно, когда выпускают пользовательские приложения — например игры, таск-менеджеры, всякие чаты и соцсети: мы ещё не знаем, как на них отреагирует рынок, поэтому нам нужно получать обратную связь от людей и заказчиков, а не уходить в свою мастерскую на год.
Плюсы и минусы RAD
✅ Можно выпускать программы при малом или гибком бюджете. Сегодня есть деньги на один модуль — пилят его. Завтра появились деньги ещё на три — пилят их. Потом деньги кончились — а модули работают, софтом можно пользоваться. Этой стратегией часто пользуются при создании MVP.
✅ Можно менять возможности программы. В отличие от каскадной разработки, когда всё жёстко зафиксировано на старте, в RAD заказчик в любой момент может сказать «А давайте поменяем вот эту возможность, у нас новые вводные».
❌ Плохо подходит для разработки больших программных комплексов, например для управления производством. В такие программы сложно вносить изменения на ходу, потому что работа одного модуля может повлиять на работу других.
❌ Заказчик должен постоянно участвовать в обсуждении и тестировании. Если заказчик хочет сразу увидеть готовую версию и не тратить время на промежуточные результаты, то команда не сможет проверять все прототипы на соответствие задачам заказчика.
Где применяется и кому подходит
Самое подходящее место для применения RAD — это стартапы и небольшие проекты. Для стартапов будет плюсом высокая скорость разработки и мгновенная обратная связь от пользователей, поэтому большинство новых проектов делается именно так. А в небольших проектах чаще всего важнее уложиться в бюджет, поэтому RAD здесь тоже будет кстати.
