Waterfall, V-model, Agile

Цена одной и той же ошибки на разных этапах

Возьмём то самое недостающее поле. На этапе требований исправление - абзац в документе и полчаса разговора. На проектировании - правка схемы экрана и модели данных, полдня. В разработке - переписать форму, метод и запрос, пара дней. На испытаниях к этому добавляется миграция уже введённых данных и повторный прогон проверок, и получается три недели.

Ошибка одна и та же, разница только в моменте обнаружения. Каскад устроен так, что первая настоящая обратная связь приходит на испытаниях - в самой дорогой точке. Вся ставка сделана на этап требований, а он делается тогда, когда о системе известно меньше всего.

// Частично лечится прототипами и ранними показами: они не ломают формат, но приближают обратную связь. Полностью риск не снимают, поэтому каскад и живёт там, где требования устойчивы, а поставка неделима: миграция по фиксированному контракту, системы с сертификацией, оборудование.

V-модель: тесты растут прямо из требований

Каскад, сложенный буквой V. На левом склоне уровни проработки: требования, архитектура, детальное проектирование. На правом - зеркальные им уровни проверки: приёмочные испытания против требований, интеграционные против архитектуры, модульные против детального проектирования.

Вывод для аналитика прямой и очень практичный: тест-дизайн начинается вместе с требованием, а не после кода. Если ты не можешь придумать приёмочный тест для своего требования, требование непроверяемо, и узнать это лучше сейчас, чем через полгода. «Интерфейс должен быть удобным» разваливается на этом вопросе за секунду.

// Отсюда же привычка звать тестировщика на разбор требований. Он находит дыры быстрее аналитика и заказчика вместе взятых, потому что профессионально ищет способ сломать, а не способ согласиться.

Итерации: короткий цикл обратной связи

Меняется одно: как часто продукт встречается с реальностью. Вместо одного показа через девять месяцев - работающий кусок раз в две недели. Ошибка, сделанная в марте, всплывает в апреле, когда исправление ещё стоит полдня.

Манифест при этом читают неправильно чаще, чем правильно. Он расставляет приоритеты в парах - работающий продукт важнее исчерпывающей документации, готовность к изменениям важнее следования плану. Это приоритет при конфликте, а не запрет правой части. Планирование остаётся, меняются горизонт и частота.

// Название процесса определяется не словами, а моментом обратной связи. Полгода анализа до первой поставки - каскад, даже если встречи называются стендапами, а доска висит в модном трекере.

Как выбирают на самом деле

Два вопроса. Насколько устойчивы требования? Насколько дорого узнать об ошибке поздно? Устойчивые требования плюс дешёвая поздняя правка - каскад работает и даёт предсказуемость. Неустойчивые требования плюс дорогая поздняя правка - нужны итерации, других вариантов нет.

Ограничения часто внешние, и с ними не спорят: фиксированная цена в договоре, сертификация, поставка железа, регуляторный срок. Тогда модель выбрана за вас, и задача - встроить в неё раннюю обратную связь: прототипы, показы промежуточных сборок, пилот на одном подразделении.

// Гибриды в жизни встречаются чаще чистых моделей: каскадные вехи и договор снаружи, итерации внутри. Это нормально, пока честно отвечено, где именно вы узнаёте о своей ошибке.

Как отвечать: «Заказчик требует каскад, но требования точно будут меняться»

Каскад изменения не запрещает, он делает их дорогими и неявными - вот это и надо расшить до старта. Договорился бы о процедуре: как подаётся запрос на изменение, кто оценивает влияние на сроки и бюджет, за сколько дней даётся ответ, кто принимает решение. Тогда изменение становится управляемым событием, а не конфликтом о том, кто за него платит. Параллельно заложил бы ранние прототипы и показы промежуточных сборок: формат каскада они не ломают, а обратную связь приближают на месяцы - а это и есть его единственная крупная слабость. И отдельно проговорил бы с заказчиком, какие части точно стабильны, а какие мы заранее считаем изменчивыми: вторые лучше планировать позже и описывать крупнее.

Кандидат не спорит с форматом, называет два конкретных механизма против известной слабости модели и предлагает развести стабильное и изменчивое.

На чём валятся

• −− Читают манифест как запрет документации и планирования.
• −− Называют гибким процесс, где до первой поставки полгода анализа.
• −− Идут по каскаду с меняющимися требованиями, не договорившись о процедуре изменений.
• −− Выбирают модель по моде, а не по цене поздней ошибки и устойчивости требований.
• −− Начинают тест-дизайн после разработки и теряют самую дешёвую проверку требований.
• −− Пишут требование, для которого нельзя придумать приёмочный тест.