Привет!
Пора узнать ответ на загадку про Совунью.
Серия:
Лирическое отступление:
Любите пиццу? Наверняка и готовить когда-нибудь пробовали: сначала раскатать основу из теста, потом разместить на ней соус, потом начинку, а потом положить в духовку или печь. Потом разрезать и съесть.
Но, можно ли в готовой пицце:
– изменить муку в тесте на ржаную;
– заменить томатную пасту на соус песто;
– сделать ее в два раза больше,
не прибегая к раскатке новой пиццы?
Основное о каскадном подходе
Каскадная или водопадная (waterfall) была описана (причем не придумана и названа, а именно описана) в конце 20 века американским специалистом в области информатики Уинстоном Уокером Ройсом.
Описывал (и критиковал) он распространённый способ разработки ПО, в котором работа следует четко по этапам, последовательность которых нельзя нарушать.
Как это работает?
Этапы в каскадной модели примерно следующие:
1. Определение требований
2. Проектирование
3. Реализация/Кодирование
4. Тестирование/Отладка
5. Поддержка
Вместо этого Ройс предлагал то, что называется итеративной разработкой, но о ней я расскажу в другой раз.
Например, в случае с пиццей работа по каскадной модели могла бы выглядеть так:
1. Определение требований – спросить у друзей, какую пиццу они хотят (без мяса, например), установить срок приготовления (к ужину, сегодня);
2. Проектирование – определить, что пицца будет квадратной (под противень), готовиться будет в электропечи, в качестве сыра пойдет моцарелла, порванная вручную и пр.;
3. Реализация/Кодирование – замес теста, раскатка основы и т.д.;
4. Тестирование/Отладка – порезать/понюхать;
5. Поддержка – сервировка и дегустация, добавка оливкового масла сверху или зелени по вкусу, сбор обратной связи.
Особенностями работы по каскадной модели являются:
– зафиксированные бюджеты, сроки и технические требования и регламенты выполнения работ;
– наличие четкого плана работ, например, диаграммы Ганта;
– строгая последовательность этапов – нельзя тестировать гипотезы или минимально жизнеспособный продукт, только разработанный до конца;
– поступление обратной связи от заказчика и пользователя только на этапе тестирования, после чего нельзя внести фундаментальные изменения в сделанный проект. Если вдруг заказчик придумал новое требования или рынок поменялся – придется начинать заново.
Исходя из этого, такая модель может быть использована, если:
– заказчик заранее и точно понимает требования к будущему продукту и не будет вникать в процесс разработки;
– есть аналогичные продукты/проекты, работа по которым уже велась и все работы и процессы налажены;
– сроки и бюджет строго ограничены, а значит, их надо согласовать и зафиксировать заранее.
Почему я выбрал Совунью:
– она мудрая и пожилая: эта модель давно известна и широко применялась даже до того, как ей дали название;
– она вспоминает молодость и многочисленных поклонников: сейчас наряду с каскадной моделью часто используются и гибкие подходы, итеративная разработка, фреймворки типа SСRUM и пр.;
– она заказывает соленья на зиму – у нее есть четкие этапы и она понимает, что зимой закатывать банки уже будет нельзя;
– ей очень не нравится, когда нарушают порядок в чем-то.
Материалы по теме:
– Статья про сравнение подходов на Скиллбокс
– Подробнее про подход на Лидстартап
Подписывайтесь на канал:
- Телеграм – @andruhadron
- Тенчат – andruhadron
- Дзен – andruhadron
#Полезное