Agile vs Waterfall – два разных подхода к разработке проектов на примере WordPress

Существует 2 принципиально разных метода разработки проектов в мире WordPress. Условно их можно назвать Waterfall (Водопад) и Agile (Гибкость). Пора разбираться…

Сравниваем два подхода по основным особенностям

#	Waterfall	Agile
Популярность	Высокая	Низкая
Эффективность	Низкая	Высокая
Возможность быстрых результатов	Нет	Да
Возможность контроля качества	Низкая	Высокая
Возможность уточнять решения и снижать затраты по ходу разработки	Низкая	Высокая
Иллюзия гарантий результатов	Высокая	Низкая
Вероятность успешных результатов	Низкая	Высокая
Формирование цены и затрат	По этапам (цена за этап или за проект)	По итерациям (цена за неделю, за месяц или за год)
Базовая декомпозиция и распределение задач	По этапам	По итерациям
Визуализация плана работ	Диаграмма Ганта	Дорожная Карта
Проектный треугольник (срок, бюджет, спецификация)	Да, в целом тут все строится на базе треугольника	Нет, но могут быть сроки по отдельным целям внутри потока
Акцент на коде и программировании	HighCode	LowCode
Уровень использования модульных подходов	Низкий	Высокий

Разработка плагинов или тем

Тут даже не стоит думать. Waterfall тут в 99% случаев приведет к провалу. Любые попытки оценок и планирования почти всегда идут в провал.

Если нужна разработка уникального функционала – всегда надо брать метод Agile.

Типичная разработка сайта по методологии Waterfall

Метод очень популярный из-за своей природной иллюзии гарантия результатов. Клиенту кажется что он получит ожидаемый результат. Но в 99% случаев начинаются какие то приключения.

Готовимся к тому что первый результат получим через 3-4 месяца. А потом сильно удивимся и испугаемся.

• Клиент находит какое-то агентство или фрилансеров, просит сделать сайт и спрашивает, сколько это стоит.
• Разработчики начинают процесс оценки и выдают смету по этапам, таким как: Дизайн > Верстка > Разработка > Тестирование > Запуск > Поддержка.
• В этой истории сама оценка может длиться недели или месяцы, затем дизайн длится месяц или два, затем верстка и разработка еще может занимать 3-4 месяца, и вот спустя полгода или год образуется некий результат, который как-то работает (если повезет).
• Любые ошибки дизайна и проектирования дорого обходятся и часто ведут к росту затрат и заметному снижению качества.
• По ходу образуется множество споров и дискуссий о том, как понимать то или иное требование и как это решать (причем обнаруживается, что решение может стоить как 100 долларов, так и 10 000 долларов, а бюджет то фиксированный).
• Очень сложно поменять решение по ходу проекта, даже если это явно принесет больше пользы (потому что надо будет пересогласовать весь контракт, требования, сроки, цены).
• На этапе разработки оказывается что дизайн сделан мягко говоря на абум, и при наполнении контентом все приходится подгонять кувалдой и напильником. Иногда сильно отклоняясь от первичного дизайна.
• Разработчики зная и понимая все эти риски вынуждены сильно перестраховываться и закладывать в проект “подушки”. Иногда размер этих подушек может быть выше себестоимости проекта в 3-4 раза.

Типичная разработка сайта по методологии Agile

Тут можно быть готовым к тому что первый результат можно получить за 1-2 дня. А далее можно развиваться через искусство маленьких шагов.

• Сайт запускается за 1-2 недели (иногда 1-2 дня) с использованием готовых модулей (тема + плагины).
• Сразу собирается структура сайта с учетом контента.
• Контент собирается через блоки, паттерны и шаблоны.
• На первых итерациях достигается минимальный, но рабочий функционал.
• После достижения первых результатов могут выполняться работы по стилизации и постепенному развитию функционала.
• Стороны договариваются на равномерный объем работ и затрат помесячно с горизонтом планирования на несколько месяцев или год и более.
• По ходу работ стороны могут передоговориться как на сокращение потока, так и на увеличение:
  • Если задач стало меньше, можно договориться снизить объем работ и затрат.
  • Если задач становится больше, можно договориться повысить объем работ и затрат.
  • В любом случае в этой схеме планирование происходит итерациями, чаще всего по месяцам или годам.

Хорошие примеры проектов с Waterfall

• shopify и типовые магазины типа продажа одежды или простых товаров
• примерно тоже самое можно делать в РФ на базе InSales
• сборка однотипных сайтов (стоматология или отели) по наработанной схеме в рамках 1 агентства с узкой специлизацией только на таких типах сайтов
• сборка проектов на облачных конструкторах без кода по типовым шаблонам

Хорошие примеры проектов с Agile

• сборка сайта пиццерии за 2 дня на WooCommerce, наполнение за неделю и затем постепенное развитие и добавление модулей
• сборка сайта фотографа за 2 недели на базе WordPress & Gutenberg, затем управление сайтом переходит в руки владельца без дополнительных затрат
• сборка базы знаний для крупной компании, запуск за 1 месяц и затем развитие в течении года с постепенным улучшением функционала
• разработка онлайн школы, запуск базовой версии за 1 месяц, найм 1го разработчика, по мере развития и роста задач расширили команду до 2х разработчиков, с годовым горизонтом планирования затрат

Скрытые причины и затраты из-за которых Waterfall часто приводит к провалам, а Agile чаще позволяет доводить проект до результата

• недооценка важности контента и его интеграция в структуру сайта
• клиенту нужно сразу найти крупную сумму на предоплату и затем готовить крупную сумму по каждому этапу или ближе к завершению проекта
• дьявол кроется в деталях и эти детали часто выскрываются в середине проекта, приводя либо к росту затрат, либо к потере качества, либо зачастую к провалу всего проекта
• дискусси и принятие решений
  • в Agile идет распределение задач в потоке и горизонте времени, что позволяет проще договариваться и разделять ответственность за результат
  • в Waterfall дискуссия идет за бюджет, сроки и требования – что чаще приводит к перетягиванию одеяла друг на друга, каждая сторона начинает видеть обманщика в партнере, что приводит к конфликту и как следствие к провалу проекта
• быстрые результаты и искусство маленьких шагов
  • в Agile первый результаты можно получить очень быстро и далее корректировать ход разработки исходя из реальности и доступных вариантов
  • в Waterfall результата нужно ждать долго, а когда он получается – оказывается что все не так и все не то, а переобуываться уже поздно, что также ведет к росту затрат, конфликтам и часто к провалу
• контроль рисков
  • в Agile если что то пошло совсем не так, можно быстро это понять, зафиксировать траты на ранней стадии, отказаться от проекта и пойти дальше, без больших потерь
  • в Waterfall из за того что результата ждем долго, понять что все пошло не так удается уже слишком поздно, что опять же приводит к потере времени и денег с обеих сторон

Весь секрет в 4 ценностях и 12 принципах Agile манифеста

Причина по которой Agile позволяет лучше достигать результатов при меньших затратах в большинстве случаев кроется в его манифесте https://wpcraft.ru/blog/agile/

Тут важно понимать что этот манифет был придуман сильнейшими умами из мира разработки, как выжимка наиболее важных правил.

Соблюдение этих правил – повышает шансы на успех, снижает риски.

Нарушение этих правил – снижает шансы на успех, повышает риски.

Список очень короткий и обязателен для изучения всем кто заинтересован в успехе проектов https://wpcraft.ru/blog/agile/

Итого

Waterfall – если есть желание сэкономить и получить более-менее надежное решение, стоит выбирать типовые проекты, облачные конструкторы и специализированные агентства. Также важно смириться с тем, что не все задачи получится решить, и у таких решений много ограничений, которые зачастую нельзя обойти. Вы получаете то, что в шаблоне, и ни шагу в сторону.

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

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