Agile & Waterfall: что это и как помогает в обычной жизни?

для амбиций

16 января 20235 минут на прочтение

Есть два способа разработки проектов — Agile и Waterfall. С ними точно знакомы выходцы из IT-сферы, но они могут пригодиться и в других сферах — от фитнеса и до воспитания детей. Разбираем эти термины на составные и подсказываем, как их можно применить в жизни.

Что такое Waterfall?

Это способ управления проектами, который подразумевает плавный переход с одного этапа на другой. Такой метод менеджмента еще называют «каскадным».

Waterfall был создан директором Lockheed Software Technology Center Уинстоном Ройсом, одним из ведущих первопроходцев в области программного обеспечения. Задуманная им модель разработки состояла из 6 пунктов:

Определения программных требований;
Анализа данных, которые получены через схемы и модели;
Дизайна, предполагающего архитектуру ПО;
Кодинга создаваемого программного обеспечения;
Тестирования продукта;
Адаптации продукта под операционные системы.

Waterfall существует с 1970-го года, и с тех пор его принципы остались неизменными: одно должно перетекать в другое. Нельзя перейти к шагу «три», не завершив шаг «два».

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

Waterfall нельзя назвать гибкой системой. Нельзя перескочить из стадии «четыре» в стадию «три», потому что это уже пройденный этап — увидимся с ним только после того, как весь проект будет завершен. Прокомментировать макеты или прототипы тоже не получится — увидеть результат можно только в конце проекта. Да и вольности тут недопустимы — все процессы должны быть задокументированы.

Монолитность Waterfall заставляет любителей гибкости обратиться к другому методу разработки — Agile.

Что это за Agile такой?

Это набор принципов, в котором общение важнее процессов и инструментов, рабочий продукт важнее документации, а диалог с заказчиком — важнее составления договора с ним. Это не четкая последовательность действий, как при работе по Waterfall, а целая концепция, построенная на адаптации продукта и его улучшении.

И если Waterfall можно представить в виде стрелки, мчащейся вперед, то Agile — это возможность оглянуться назад, а то и навернуть кружок-другой. Этот метод позволяет кружить между станциями «планирование» → «разработка» → «тестирование» → «демонстрация» до тех пор, пока в моменте не будут довольны и заказчики, и исполнители.

Звучит как философия. Она как-то отражена на практике?

Да, например, с помощью методик Scrum или Kanban.

Scrum — способ гибкой разработки, в основе которого лежит «спринт» — отрезок от одной до четырех недель, в конце которого заказчик видит конкретный результат и может внести коррективы.

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

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

Постоянно? Они что, никогда не спят?

Спят, просто не забывают про ограничение объема незавершенной работы (work in progress, он же WIP). В Agile-разработке этот способ позволяет ограничить максимальное количество задач на каждом этапе работы, чтобы залатать все проблемные места, не завалив себя новой работой.

Звучит супер. Где минусы?

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

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

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

Все это хорошо, но как применять эти методы вне IT?

Например, вы решили построить себе дом, приготовить новое блюдо или пройти чек-ап. Эти кейсы — отличный повод применить Waterfall, где нужно следовать методике step by step.

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

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

Так что глобально можно и не задумываться над тем, где применять Waterfall или Agile — вы давно пользуетесь ими вне рамок монитора.

Agile, Waterfall, Scrum и Kanban — обязательные элементы IT. А если вы хотите, чтобы уже IT стало вашим элементом, переходите по ссылке — там вакансии на любой уровень навыков и интересов, даже если не хотите учить код.

Герман Клименко