Agile vs. Waterfall: суть и отличия методологий разработки

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

WATERFALL

Waterfall — технология разработки программного обеспечения, известная еще с 1970 года. Ее описал Уинстон Ройс. Он разделил процесс создания продукта на логические этапы, которые могут наслаиваться друг на друга по времени, чтобы придать технологии немного гибкости. Но последовательность их не меняется. Если визуализировать это все, то получим модель, похожую на водопад — соответственно названию методологии.

Структура и ТЗ во главе процесса

Waterfall — жесткая структура, которая фиксируется на бумаге и в которую нельзя вмешиваться. Следующий этап можно начать только после завершения предыдущего. Поэтому документы с требованиями и инструкции в этой методологии практически священны. Клиент не вмешивается в создание продукта после утверждения ТЗ. Оно должно быть продуманным, а документация качественно составленной. Чем подробнее документация — тем больше уверенности в результате.

У методологии и по сей день остаются поклонники — это люди, которые любят стабильность и контроль. Им пришлось по душе раз и навсегда определять порядок вещей в разработке. Благодаря этому модель Waterfall обеспечила строгий контроль качества и прозрачный процесс. Вы с самого начала будете знать, что он вас требуется. И в конце концов вы получите полноценный продукт, а не какую-то его работающую часть (но об этом далее). Заказчик, в свою очередь, точно будет знать, когда проект завершится и какой бюджет требуется. Через систему отчетности можно будет проанализировать потраченное время, бюджет и ресурсы.

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

Курсы по управлению проектами в IT: IT Project Management, IT Project Management (offline in UNIT.City, Kyiv)

Стадии разработки в Waterfall:

  • Анализ требований, составление ТЗ и планирование процессов.
  • Проектирование. На этом этапе разрабатывают прототип ПО. 
  • Подготовка дизайна.
  • Интеграция. Объединение частей в один продукт.
  • Тестирование. Готовый продукт проверяют на наличие программных ошибок, ищут недочеты функционала. После этого важно исправить обнаруженные баги.
  • Выпуск продукта. Релиз готового проекта и окончание разработки. Возможна также работа по адаптации проекта к другим системам.
  • Техническая поддержка. 

Популярные методики Waterfall:

  • Сашими — в ней этапы работы идут по порядку и перекрываются одна другой по времени. То есть заканчивая работу на первом этапе, вы уже начинаете работать над вторым.
  • Waterfall с субпроектами — методика работы с тремя крупными стадиями: разработка концепции, проектирование и структурирование продукта. Каждый из этих блоков имеет свои этапы. После окончания работ в каждой стадии их интегрируют между собой.
  • Модель снижения риска — проект разделяется на более мелкие проекты, которые направлены на выявление недочетов до релиза программного продукта. 

«Нам нужна была ложка — мы ее и сделали. Мне нравится определенность». 

© Геннадий, руководитель проекта

«Фух, вау. Спустя год получили готовый продукт. Он все еще кому-то нужен?». 

© Софья, продакт-менеджер

AGILE

Agile (с англ. гибкий) — это термин, объединяющий ряд современных методологий гибкого управления проектами. Суть гибкого управления в том, что оно основывается не на правилах, а на принципах, которыми команда руководствуется в принятии решений. В Agile есть план, но нет строгой внутренней структуры. Люди решают, в каком направлении будет двигаться проект дальше, поэтому творческий поток здесь поощряется. К гибким методам управления относятся популярные фреймворки Scrum и Kanban. 

Главный здесь продукт. Важнее получить результат, чем неделями писать документации. Лучше сделать неидеально — но сделать. В Agile процесс создания и изменений не прекращается, цикл за циклом исправляются недочеты и внедряются новые идеи. 

Главной книгой считается Agile Manifesto, который разработали в феврале 2001 года. В манифесте описали 4 ценности и 12 принципов, которыми стоит руководствоваться при разработке ПО.

4 ценности для Agile-методологий

  • Общение важнее инструментов. 

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

  • Сотрудничество с заказчиком важнее условий контракта.

Здесь речь идет о том, чтобы удовлетворить реальный спрос, а не биться за букву. Именно заказчик определяет видение, он знает целостную картину. Команда стремится к качеству и сотрудничает с заказчиком, чтобы реализовать его идею и виденье. 

  • Работающий продукт важнее детальной документации.

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

  • Готовность к изменениям важнее следования первоначальному плану.

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

Но есть другая сторона монеты: рассчитать конечные затраты практически невозможно — требования по проекту могут постоянно меняться. Важно учесть, что слишком кардинальные перемены могут разрушить проект. Здесь нужна мера.

Как Agile работает

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

Управлять продуктами в IT учим на курсе IT Product Management

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

И конечно же, процесс развития продукта невозможен без команды. В ней могут быть разработчики, дизайнеры, райтеры, тестировщики, UX-специалисты, аналитики и т.д. Лидеры и команда — взаимосвязанная система, которая должна работать сообща. 

Здесь и кроется еще одна опасность — продукт очень зависит от команды. Agile требует большой вовлеченности в процесс, поэтому к подбору команды нужно подходить ответственно.

Отношение к риску

Гибкие методологии помогают работать в полной неизвестности. В большинстве из них разработка ведется короткими циклами — итерациями по 2-3 недели. Каждая итерация позволяет сделать проект в миниатюре, протестировать и оценить его возможности. И пусть не каждая итерация позволяет выпустить полноценную новую версию, все же они дают возможность быстро адаптироваться, узнавать рынок и подкручивать проект так, чтобы сделать его жизнеспособным. Agile поможет сделать продукт сильным, но нужно осознать, что гонка будет продолжаться очень долго. И во время этого пути могут быть как прорывы, так и откаты. В целом, многие менеджеры сходятся в мысли, что риски выгорания на Agile гораздо выше, чем на Waterfall. 

“Да, это гонка, но зато скучно не будет. Рынок меняется, и мы не должны отставать.” 

© Наталья, Scrum-мастер

“Ребята, я передумал. Давайте переделаем.” 

© Петр, заказчик

Какой подход подойдет вашему проекту?

Нет правильной или неправильной методологии. Есть методология, правильно выбранная и примененная именно для вашего проекта. Мы разобрали плюсы и минусы двух подходов. Исходя из их особенностей, можно сказать что Agile хорош для IT-продуктов, стартапов, которые работают в неопределенной, часто меняющейся среде. Это ваш подход, если вы не знаете, где окажетесь завтра. Waterfall же подойдет для небольших проектов с высокой степенью определенности. Если вы точно знаете, какой проект нужен в итоге, либо вы уже делали аналогичный проект, вы сможете продумать четкую последовательность этапов.

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

Agile подходит кросс-функциональным командам, которые объединяют специалистов разных сфер. Здесь важен профессионализм всех участников. Waterfall — подход с четкой структурой, которая подойдет как опытным специалистам, так и новичкам. Проект по методологии Waterfall может быть реализован in-house командой разработчиков и другими специалистами на аутсорсе.

Советуем почитать:

0
0
SAVE