History. Немного о том, как разрабатывается ПО

Это значило, что условная кнопка «А» могла выполнять только одно действие, зашитое в железо. Самый первый пример, который приходит в голову — калькулятор. 2 это 2, знак «=» это =. И то не всегда:) Ученые быстро поняли, что это не сильно эффективно, и тогда же было положено начало эре программного и аппаратного обеспечения. Совсем скоро начали появляться первые языки программирования и первый софт. Кстати, термин софт как раз оттуда — software и hardware.

С тех пор много воды утекло, и в 70-х годах появилась одна из первых моделей разработки ПО — Code and fix (пиши код и исправляй). Выглядела она примерно так:

Мягко говоря, было у нее пару недостатков. Для начала, требования (спецификации, документация — не важно) почти всегда отсутствовали. Т.е. еще тогда процесс разработки был похож на современный стартап — ничего не проработано, архитектура не продумана, просто начинайте делать, а там походу разберемся. И соответственно, чтобы добавить функционала, или пофиксить баги, приходилось начинать все сначала. Ну и если кто заметил, тестирования в этой модели нет от слова совсем.

Прошло немного времени, люди поумнели и в модель code and fix внесли некоторые доработки, и свет увидела новая модель разработки ПО — каскадная ( Waterfall). По сути, это были те же яйца, только сбоку

Уже появились обязательные требования (то, как должна работать программа), появилась стадия проектирования архитектуры и тестирования. Но! К каждому следующему этапу можно было приступить лишь тогда, когда был закончен предыдущий.
Из плюсов:

— доступная понимаю людей с низким IQ
— есть тестирование
— четкое понимание и планирование сроков работ
Из минусов:

— большая стоимость ошибки (поскольку тестируют целиком готовый продукт, когда разработчики уже пропили всю зп, им нужно платить еще раз столько же, потому что делать они будут опять все сначала)
— не Scrum
— очень большое внимание нужно уделять планированию и срокам
В общем, тоже не сильно эффективно. Хотя находятся динозавры, использующие эту модель разработки в 2к18.

Потом была улучшенная версия каскадной модели — V-model. Отличалась от классики в основном внедрением тестирования на каждом шаге.

Тут для каждого уровня есть своя стратегия тестирования, тест-план.

Из википедии: «Основной принцип V-образной модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы.»

Далее умные люди изобрели инкрементную модель (Incremental Model). Инкрементум (с латыни) — рост, увеличение). Главное ее отличие от каскада и v-модели — последовательная разработка в несколько версий, поэтапная.

Спроектировали отдельный модуль, написали, протестировали — отправили в прод (боевая среда). Далее спроектировали следующий модуль, написали, протестировали, протестили — и в прод. Продолжается этот сериал до тех пор, пока продукт полностью не будет готов, пока все инкременты (модули) не будут собраны в один:)

Плюсы и минусы похожи на те, что есть у предыдущих моделей. Отличие в том, что успешные люди, заказавшие разработку ПО, получают хоть какую-то версию раньше, чем в waterfall или v-model.

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

Выглядит она немножко страшно.

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

— сначала планируют
— потом (важно!) анализируют риски
— потом реализуют и тестируют
— потом анализируют полученный результат, и если все ок, то переходят на новый цикл.

Итак, плюсы:
— позволяет после первого круга показать работающий продукт
— большая вариативность по сравнению с каскадной моделью или v-model
— маленькие риски получить серьезные баги, т.к. к следующему витку переходят только протестировав предыдущий

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

Гибкие модели разработки

Agile (или Сберджайл у Сбербанка) — одна из гибких моделей разработки ПО. Почему гибкая — ну, все просто. После каждой итерации (спринта) заказчику показывают то, что сделали, и он уже думает — подходит ему функционал, или нет. Ну и + к этому, у Agile много всяких фишек, которые, скорей напоминают некую секту.

Например у этой модели есть свой манифест, который гласит, что: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану»

Вообще Agile был своего рода бунтом против классики в моделях разработки, в которых были тонны документации, плохие продукты и погрязшие в бюрократии, как в болоте, сотрудники.

Интересно, кстати, что этот манифест был принят во время променада по горнолыжному курорту. Понятное дело, там не до бумаг и документов.

Выглядит гибкий процесс вот так:

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

— К, качество. Поскольку тестирование регулярно и введено на всех этапах — минимизация рисков.

— К, команда. Вовлеченность дикая, все в курсе, кто что делает. Кстати, есть там такой замечательный bus factor — автобусный фактор. Чем он выше, тем лучше. Означает он то кол-во человек, которое может сбить автобус, и после этого команда будет продолжать работать. Чем больше автобус сможет сбить, тем лучше.
— К, короткие спринты (итерации). После коротких (2-5 недель, везде по-разному) спринтов заказчик получает конкретный продукт.

Из минусов:

— Проект на Agile может очень быстро меняться. Прям как любой стартап.
— Отсутствие (полное или частичное) документации. Ну тут это и + и -.
— Сама «философия Agile». Поскольку она не дает конкретных инструкций, формулировки там можно трактовать по-разному.
— Не очень понятно, сколько денег придется подарить команде разработки, поскольку Г — гибкость во всем)

Уф, вроде по основным методам все.

Кстати, если что, подробно про все модели, методологии и вообще много чего другого интересного — в нашем курсе по тестированию ПО. Заходите- qaqc.ru

До встречи!