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

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

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

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

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

Тут даже не стоит думать. 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. Но нужно уметь готовить такие проекты. При нехватке практики и опыта – даже в этой схеме можно наломать дров.

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

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *