Стремление поставлять ценность быстрее и снижать риски долгого цикла «анализ — проектирование — реализация — тестирование» привело к методологиям, ориентированным на скорость и тесную обратную связь. RAD (Rapid Application Development) и XP (eXtreme Programming) — два представителя такого подхода на уровне команды: RAD концентрируется на прототипировании и вовлечении пользователей, XP — на инженерных практиках и исполняемых требованиях. Для аналитика обе методологии означают переход от обширных документов к непрерывному моделированию через эксперименты. Место RAD и XP в SDLC — в 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC); рутина спринтов, бэклога и роли аналитика в Scrum/Kanban — в 05.02 Scrum и Kanban (аналитик в Agile); при масштабировании на несколько команд логика «обрывается» — см. 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

1. Суть темы

RAD: быстрая разработка через прототип

RAD предложил Джеймс Мартин в 1991 году как ответ на медлительность каскадных моделей. В основе — идея, что требования нельзя полностью определить в начале, поэтому их лучше уточнять через работающий прототип и обратную связь.

Классический Martin-RAD — это timeboxed проект целиком: типично 60–120 календарных дней (для небольших приложений в литературе часто 30–90); каждая из четырёх фаз тоже ограничена сроком. Сегодня «RAD» чаще означают принципы и практики (прототип, JAD, timeboxing), а не отдельный бренд — их переняли Scrum, Kanban и корпоративные гибриды. На долгоживущем продукте RAD-фазы (2–4 недели пользовательского проектирования) встраиваются в бесконечный lifecycle; жёсткий горизонт «весь проект 60–120 дней» относится к классическому проектному RAD, а не к гибриду RAD→XP (см. раздел 3).

DSDM (Dynamic Systems Development Method) выросла из RAD-линейки и стала основой AgilePM.

flowchart LR
    A[Планирование требований] --> B[Пользовательское проектирование]
    B --> C[Разработка / Конструирование]
    C --> D[Внедрение / Переключение]
    D -.->|итерация, если нужно| B

  1. Планирование требований — урезанный начальный анализ: цели, границы MVP, высокоуровневые потребности (→ 02.01.04 Определение границ решения (Scope Modelling)). Аналитик проводит JRP-сессии (Joint Requirements Planning) — согласование видения, приоритетов и границ scope до детального проектирования.

  2. Пользовательское проектирование — главная фаза RAD. JAD-сессии (Joint Application Development): интенсивные воркшопы, где пользователи и аналитики совместно проектируют и прототипируют решение. JRP отвечает на «что и зачем», JAD — «как выглядит и работает». Продукт фазы — одобренный прототип интерфейса и поведения (→ 02.02.04 Прототипирование и UI-UX-исследования, 02.02.02 Воркшопы, фасилитация и совместные сессии).

  3. Разработка / Конструирование — рабочая система на основе прототипов; заказчик участвует эпизодически через демо.

  4. Внедрение / Переключение (Cutover) — переход, обучение, приёмка в реальной среде.

XP: инженерный контур поверх гибкости

XP, сформулированный Кентом Беком в конце 1990-х, исходит из неизбежности изменений. Ценности — коммуникация, простота, обратная связь, смелость, уважение. В отличие от RAD, XP не ставит прототип в центр, а делает исполняемые приёмочные тесты источником истины о поведении системы и опирается на TDD, CI и рефакторинг. XP лёг в основу Agile Manifesto (2001) вместе с RAD и другими подходами. RAD и XP — параллельные ветви эволюции Agile, а не «предшественник и последователь»; детали Scrum/Kanban и роли аналитика в спринте — в 05.02 Scrum и Kanban (аналитик в Agile).

2. Ключевые понятия

2.1 Принципы RAD

2.2 XP: отличия от RAD и от «голого» Scrum

XP не дублирует Scrum: нет жёсткого спринт-ритуала как обязательного каркаса, зато жёстче инженерный контур. Для аналитика значимы три группы отличий:

Что отличает XPОт RADОт Scrum без XP-практик
Уточнение требованийНе JAD и прототип, а Planning Game + On-Site Customer — заказчик в команде постоянно, а не только на фазе проектированияScrum допускает PO «на расстоянии»; XP требует ежедневной доступности decision maker
Форма спецификацииНе UI-прототип, а исполняемые приёмочные тесты (ATDD) и истории (→ 02.04.02 Критерии приёмки (Acceptance Criteria), 04.02 Пользовательские истории (User Stories) и Job Stories)В Scrum тесты и TDD — рекомендация; в XP — обязательная практика
Инженерный контурTDD, CI, рефакторинг не регламентированыTDD, CI, парное программирование, коллективное владение кодом — ядро процесса (→ 07.06 CICD и конвейеры — влияние на требования, 05.04 DevOps и непрерывная поставка — влияние на анализ)

Welcome change в XP стыкуется с 02.05.02 Управление приоритетами в условиях изменчивости: изменения приветствуются, но приоритет пересматривается на Planning Game, а не «бесплатно» вне итерации.

Метафора (Metaphor) — общее видение системы простым языком; на практике это 03.03.03 Словарь данных (описание) или 10.01.14 Шаблон глоссария и словаря данных, а не абстрактный слоган.

В классическом XP явной роли «аналитик» нет; на практике аналитик часто выступает Customer Proxy (с письменным мандатом — → 02.01.03 Анализ заинтересованных сторон (Stakeholder Map), 09.07 Управление ожиданиями заказчика) или помогает формулировать истории и приёмочные тесты до разработки.

2.3 Сравнение RAD и XP

ХарактеристикаRADXP
ФокусБыстрый продукт через прототипы и пользователейКачество кода и адаптивность через инженерные практики
Инструмент уточненияПрототип (throwaway или evolutionary), JADИстории, приёмочные тесты, заказчик на месте
ДокументированиеМинимальное; прототип — спецификация UI/поведенияПриёмочные тесты — исполняемая спецификация
РитмКлассический проект: 60–120 дней целиком; фазы — отдельные timebox'ы. На продукте: RAD-фазы внутри бесконечного циклаИтерации 1–2 недели, непрерывные мелкие релизы
Участие заказчикаИнтенсивное на проектировании, затем эпизодическоеНепрерывное, заказчик в команде
Технические практикиНе регламентируютсяTDD, CI, рефакторинг, парное программирование
ПрименениеUI-heavy приложения, «не знает, пока не увидит»Высокая неопределённость + высокая планка качества кода

3. Как применяется в работе аналитика

3.1 RAD: фаза Construction — минимум для системного аналитика

Когда JAD завершён, заказчик эпизодичен, а источником истины остаётся UI-прототип, прототип не покрывает интеграции, модель данных и бизнес-правила вне экрана. Минимальный набор SA-артефактов на Construction — без раздувания до полного SRS:

  1. Контекст и границы сервисов — 03.01.02 Моделирование контекста системы (Context Diagram): какие системы участвуют, что внутри MVP.
  2. Ключевые контракты интеграций — черновики 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) для критичных API; достаточно happy path + коды ошибок.
  3. Словарь сущностей — 03.03.03 Словарь данных (описание): имена, типы, связи, правила, не видимые в UI.
  4. НФТ вне прототипа — производительность, безопасность, аудит (→ 08.02 Нефункциональные требования (НФТ) — классификация и стандарты).

Изменения после устных демо фиксируйте в бэклоге: история + критерии приёмки, с 02.05.05 Жизненный цикл требования и 02.03.04 Трассировка требований (концепция) на стыке фаз «проектирование → Construction».

3.2 Гибрид RAD + XP

Типичный сценарий: RAD-пользовательское проектирование (2–4 недели) даёт прототип и границы MVP; далее XP-итерации (1–2 недели) с TDD и приёмочными тестами. На стыке аналитик передаёт: (1) прототип + открытые вопросы по бизнес-правилам; (2) бэклог историй с критериями; (3) список НФТ, не покрытых UI; (4) минимум SA из п. 3.1. Перед стартом Construction — 10.04 Чеклист аналитика перед стартом разработки. Не смешивайте «прототип как спецификацию» и «тесты как спецификацию» без договорённости, что является источником истины на каждой фазе.

3.3 Критерии выбора: RAD, XP или Scrum

Правило: если нужен стандартный ритм спринтов, PO, Review/Demo и роль аналитика в бэклоге — выбирайте Scrum; детальная матрича ролей и событий — в 05.02 Scrum и Kanban (аналитик в Agile). RAD и XP — когда нужны специфические практики, а не «Agile по умолчанию».

СигналВыборПочему
Доминирует UI/UX, заказчик «не знает, пока не увидит»RADJAD и прототип быстрее снимают неопределённость, чем текстовые истории
Прототип уже не нужен; нужны частые релизы и дисциплина TDD/CIXPИсполняемые тесты и инженерный контур важнее визуализации
Команда зрелая в TDD/CI, заказчик доступен ежедневноXPOn-Site Customer и ATDD требуют постоянного decision maker
Нужен предсказуемый ритм спринтов без жёсткого прототипированияScrumФреймворк ролей и событий; XP-практики подключаются опционально
Жёсткий fix-price и фиксированный scope⚠ любой Agile-вариант«Welcome change» конфликтует с контрактом: fixed MVP + T&M на изменения, или [[-02.05.02 Управление изменениями (Change Control Board)

3.4 Практические рекомендации

4. Типовые ошибки и ограничения

Ограничения RAD и XP

  • RAD: плохо для крупных распределённых систем; требует доступа к заказчику на JAD; эволюционный прототип без SA-артефактов из раздела 3.1 — узкое место на Construction.
  • XP: требует зрелости команды в TDD/CI; один On-Site Customer в enterprise часто нереалистичен без явного decision maker.

Типовые ошибки

ОшибкаПоследствиеЧто делать
Customer Proxy без мандатаРешения отвергаются стейкхолдерамиПисьменный мандат, карта стейкхолдеров, эскалация
«Приёмочные тесты = вся спецификация» в regulated-проектеПровал аудита, нет трассировки02.03.04 Трассировка требований (концепция), артефакты для 08.06 Юридические и регуляторные требования РФ (PCI-DSS)
Эволюционный прототип → production без пересмотраТехдолг, смена стекаСписок «переписать vs доработать», НФТ до cutover
Fix-price + «welcome change»Scope creep, конфликт с контрактомFixed MVP + T&M, или 02.05.02 Управление изменениями (Change Control Board)
Throwaway-прототип случайно ушёл в prodНеподдерживаемый код, скрытые дырыЯвно помечать тип прототипа до JAD; после throwaway — новая кодовая база
Смешение JRP и JADХаос в scopeСначала JRP (границы), потом JAD (прототип)
UI-прототип без контрактов и словаря на Construction«Чёрные дыры» в интеграциях и данныхМинимум SA из раздела 3.1
Один «заказчик» в enterprise без decision makerИстории без приоритетаНазначить accountable, RACI на приёмку

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • James Martin. Rapid Application Development (1991) — оригинальное издание методологии RAD.
  • Kent Beck, Cynthia Andres. Extreme Programming Explained: Embrace Change (2-е издание) — канон XP.
  • Steve McConnell. Rapid Development: Taming Wild Software Schedules — обзор RAD, типов прототипов и смежных подходов.
  • Ken Auer, Roy Miller. Extreme Programming Applied: Playing to Win — практическое применение XP.
  • DSDM Consortium / Agile Business Consortium. DSDM Agile Project Framework — https://www.agilebusiness.org/page/ProjectFramework_10

Статьи и онлайн-материалы

Обучение