Waterfall – привычный подход к управлению проектом

Когда компании впервые столкнулись с разработкой софта, они использовали привычный для строительства или промышленного производства подход – Waterfall.

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

У Waterfall подхода есть несколько достоинств: простота и интуитивная понятность; легкость планирования; минимум затрат, что связано с простотой Waterfall-подхода и отсутствием переделок выполненных работ. Waterfall хорошо работает только при выполнении нескольких условий: клиент точно знает, какой продукт хочет; исполнитель хорошо понимает клиента и принимает правильные решения; ничто из созданного клиентом или командой (требования, архитектура, проектные решения) не изменится в ходе работы; заказчик готов ждать завершения проекта, чтобы начать получать пользу от продукта.

Проблемы Waterfall подхода рождаются при появлении изменений в процессе разработки: команда разрывается между реализацией новых фич и исправлением багов; документация не обновляется (на это просто не хватает времени); код становится более запутанным, исправление одной ошибки приводит к новым; cроки горят и клиент нервничает.

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

12 основополагающих принципов Agile-манифеста:

1) Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

2) Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

3) Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

4) На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

5) Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

6) Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

7) Работающий продукт — основной показатель прогресса.

8) Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

9) Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

10) Простота — искусство минимизации лишней работы — крайне необходима.

11) Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

12) Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

Cynefin модель помогает определить как и когда можно применять AGILE методы

Cynefin модель помогает выбрать оптимальный подход к выполнению проекта в зависимости от сложности продукта и понятности предстоящих задач (Основатель – Дэйв Сноуден). Согласно модели Cynefin все ситуации по Cynefin делятся на 4 вида: простые, сложные, запутанные и хаотические.

  1. Простые ситуации (simple situation) — создание продукта не вызывает вопросов, потому что понятны цель проекта и путь к её достижению (то есть какой именно продукт нужно создать). В этом случае всё сводится к операционному менеджменту, в основе которого лежат чек-листы и жёсткие регламенты.
  2. Сложные ситуации (complicated situation) — есть понятная цель, но путь к её достижению не определён изначально: либо у команды несколько вариантов, между которыми нужно сделать выбор, либо пока ни одного. Но заранее известно, что такой путь точно есть. В этом случае мы имеем дело с классическим проектным управлением, и здесь Waterfall (применительно к продукту в целом).
  3. Запутанные ситуации (complex situation) — нет чёткой и понятной цели (не говоря уже о пути к её достижению). В этом случае на начальном этапе всё ограничивается набором идей для будущего продукта. После проверки какие-то из них придётся переосмыслить, а от некоторых даже отказаться.
  4. Хаотические ситуации (chaotic situation) — тот случай, когда вообще ничего непонятно. Причиной ситуации являются внешние условия, слабый менеджмент, неправильно выбранный подход. Лучшее, что можно предпринять — не стоять на месте и делать то, у чего есть шанс пусть даже на малейший успех.

The Cynefin модель категоризации ситуаций

Отсутствие понимания (disorder) – это большинство случаев, когда мы начинаем управление процессом не определив ситуацию (без категоризации) и не определив корректно способ управления ситуацией.

AGILE методы управления проектом (ситуацией)

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

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