И снова привет! Заключительный пост, привезенный из отпуска. | Быстрый Фронтенд

И снова привет!

Заключительный пост, привезенный из отпуска. Статья Винстона Ройса “Managing the development of large software systems”. Написана в 1970 году, недавно юбилей был. Прочитал по совету моего другана Фредерика Брукса. Читал 20 минут - камон, это статья.

Ройс пишет, что фундаментально процесс производства маленькой софтины состоит из двух шагов, “Анализ” и “Производство“. Для большой софтверной системы шагов больше. Пример смотрите на скриншоте 1.

Правда, скриншот что-то напоминает? Не буду томить - это классическое и, вероятно, первое изображение так называемого каскадного (водопадного) процесса. Интересно здесь то, что Ройс приводит это изображение в качестве примера и сразу же пишет, что подобный процесс неминуемо привёл бы к провалу. Вот так новости! Первый раз упомянули водопад и сразу провал? Почему так печально?

Все от того, что обратная связь из поздних этапов разработки имеет высокие шансы уничтожить плоды трудов предыдущих этапов. Так называемые “хвостовые риски” появляются в момент, когда работа вроде бы почти завершена. Эта обратная связь отправляется на предыдущий этап в виде “у вас тут не работает как описано“. Хорошо, если можно поправить и забыть. Но что, если поправить нельзя? Что, если надо менять архитектуру еще выше по потоку? Это уже совсем другие затраты времени и денег! Почему мы не узнали об этом раньше? Смотрите схему реальной обратной связи на скриншоте 2.

Что делать в таком случае? Ройс предлагает знакомый вариант. Если хотите, назовите его MVP. Он говорит, что если бы мы могли ввести стадию “предварительной реализации“, то там мы заранее увидели бы хотя бы намеки на хвостовые риски. Смотрите скриншот 3. Напоминает что-нибудь? Подскажу - вероятно, это одно из самых ранних изображений гибкого процесса с итеративно-инкрементальной моделью.

Так где же мы свернули не туда? Если статья, впервые упомянувшая каскадную модель сразу же разносит ее в пух и прах. Если эта же статья предлагает нам более безопасное итеративное производство - откуда берется спор об эффективности водопадов?

Ответ простой и глупый одновременно. Уже в восьмидесятые, через 18 лет после выпуска статьи, Министерство Обороны США искало себе удобный и логичный метод разработки софта. В статье Ройса, на скриншоте 1, они увидели рекламу каскадной модели. Так этот метод и получил официальное признание - в доктрине DOD-STD-2167A какой-то офисный клерк сказал, что софт надо разрабатывать каскадно. Оттуда это утекло в доктрину НАТО. А оттуда в разработку по всему миру.

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

Прикладываю официальную ссылочку для ознакомления со статьей