Waterfall VS Agile: выбираем методологию на примере рафтинга
Продолжаем присматриваться к трендам в маркетинге и управлении и рассказываем об этом вам. Сегодня о том, что такое управление проектами с фреймворком Waterfall, чем оно отличается от Agile и есть ли путь взять из каждого «всего понемножку».
Представим, что проект – большая река…
Когда каждую из этих методологий требуется коротко описать, на ум приходит слово «гибкость» для Agile и «постоянство» для Waterfall. Если основная ценность Agile – возможность переиграть на любом этапе проекта, быстро тестировать и отбрасывать гипотезы и передвигаться от спринта к спринту длительностью в две недели, то Waterfall – это про четкое ТЗ и последовательное выполнение всех этапов. Название модели не зря переводится как «водопад»: с Waterfall команда словно сплавляется по реке, где каждый новый порог можно преодолеть только хорошо подготовившись и разобравшись с предыдущим препятствием.
Разработка с использованием водопадной модели – это пять последовательных этапов.
- Аналитика – собираем исчерпывающие требования к проекту и пишем подробнейшее ТЗ. Важно учесть все риски, определить график работ. Роль играют детали. Игра будет вдолгую, и шанса что-то изменить «потом» нет.
- Проектирование – команда создаёт прототип, работает с дизайн-макетами.
- Разработка – код пишется согласно ТЗ, никой самодеятельности.
- Тестирование – самый рискованный этап, именно тут могут проявиться ошибки в первоначальных предположениях. Если команда обнаружит серьезные недочеты в продукте, на исправление может уйти большое количество времени.
- Эксплуатация – на этой стадии продукт логически завершён и передаётся заказчику. Всё выполнено именно так, как было прописано в техзадании.
Применяя Waterfall, заказчик и исполнитель идут по классической модели. Есть задание и его итог. Между этими точками никакой гибкости и самодеятельности: в отличии от правил Agile «люди и взаимодействия важнее процессов и инструментов, работающий продукт важнее исчерпывающей документации, сотрудничество с заказчиком важнее условий контракта и готовность к изменениям важнее следованию первоначальному плану» тут словно бы всё наоборот. Но этому есть объяснение.
Где применим Waterfall и его вариации
Гибкие модели и манифест появились и развились в начале 2000-х как ответ четким фреймворкам середины XX века. Agile и приближенные к нему методы управления отлично прижились в командах разработки. Они помогают создавать продукты под точечные, часто техническо-творческие задачи и должны постоянно учитывать изменения на рынке и в трендах. По этой же причине гибкость приветствуется в работе любого стартапа.
Однако, Waterfall в современности не стоит совсем списывать со счетов: он применим в больших проектах со сложной структурой, например, в банковской и управленческой сферах. В больших компаниях, где важно заранее понимать чёткую стоимость проекта и дату его завершения, требуется детализированная документация, задачи определены и итог ясен, каскадная система может быть предпочтительнее. В корпорациях, берущих проекты на много лет, где довести продукт до обещанного итога обязательно, свобода часто недопустима.
К тому же, и у каскадной системы есть вариации:
- Сашими – одна из самых популярных моделей Waterfall. Этапы тут «наслаиваются» друг на друга и могут перекрываться по времени.
- Waterfall с субпроектами – весь процесс разделен на три крупные стадии: разработка концепции, проектирование и структурирование. В финале проводится интеграция.
- Модель снижения риска – проект разделяется на более мелкие проекты, в каждом анализируются недочёты, всё исправляется до релиза.
Agilefall и Wagile. Гибридные методологии
Несмотря на разницу в идеологии фреймворков, всё чаще в среде разработчиков встречаются попытки комбинировать два подхода. Результат даже получил собственное название: Agilefall либо Wagile, в зависимости от того, какой стратегии всё же немного больше.
В некоторых проектах банки и страховые компании могут традиционно тщательно собрать все исходные данные, прописать требования и ТЗ, а потом не лениться и потратить силы на разговоры с заказчиками, узнав, что осчастливило бы заинтересованные стороны. С момента разработки каскадная система может трансформироваться в гибкую: работа становится итерационной. ПО постоянно показывается заказчику, проблемы и возможные изменения обсуждаются «в процессе».
Стартапы и небольшие компании могут идти частично по пути водопадной системы в самом начале работ: например, чётко определиться с бюджетом и взять обязательства точно закончить проект в определённый срок. Всё зависит от удобства и ситуации. Сегодня никто не мешает отправиться с командой в проектный рафтинг, а по пути понять, что стоит пришвартоваться и изменить маршрут. Обстоятельства изменились.
Waterfall и Agile или их гибриды – чёткого ответа, что выбрать, не существует. В первую очередь, всё зависит от условий работы, контракта и, конечно, внутренней готовности команды к четким правилам или, напротив, любовь к изменениям и некоторой неопределенности. В конце концов, никто не мешает сначала попробовать на себе путь по правилам, чтобы потом, когда надоест и появится такая возможность, свернуть в поток гибкости. Эта единственная мысль, в которой сходятся тренеры по фреймворкам и бизнесу.