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 вида: простые, сложные, запутанные и хаотические.
- Простые ситуации (simple situation) — создание продукта не вызывает вопросов, потому что понятны цель проекта и путь к её достижению (то есть какой именно продукт нужно создать). В этом случае всё сводится к операционному менеджменту, в основе которого лежат чек-листы и жёсткие регламенты.
- Сложные ситуации (complicated situation) — есть понятная цель, но путь к её достижению не определён изначально: либо у команды несколько вариантов, между которыми нужно сделать выбор, либо пока ни одного. Но заранее известно, что такой путь точно есть. В этом случае мы имеем дело с классическим проектным управлением, и здесь Waterfall (применительно к продукту в целом).
- Запутанные ситуации (complex situation) — нет чёткой и понятной цели (не говоря уже о пути к её достижению). В этом случае на начальном этапе всё ограничивается набором идей для будущего продукта. После проверки какие-то из них придётся переосмыслить, а от некоторых даже отказаться.
- Хаотические ситуации (chaotic situation) — тот случай, когда вообще ничего непонятно. Причиной ситуации являются внешние условия, слабый менеджмент, неправильно выбранный подход. Лучшее, что можно предпринять — не стоять на месте и делать то, у чего есть шанс пусть даже на малейший успех.
Отсутствие понимания (disorder) — это большинство случаев, когда мы начинаем управление процессом не определив ситуацию (без категоризации) и не определив корректно способ управления ситуацией.
AGILE методы управления проектом (ситуацией)
Agile при всей своей гибкости — довольно чёткая система, хоть и весьма простая и понятная. Гибкость достигается за счёт того, что процесс работы не заимствуется в готовом виде из книжек или опыта других проектов, а каждый раз практически создаётся с нуля по рекомендациям конкретного метода. При этом каждый Agile-метод — это набор практик. Agile-методы — Scrum, Kanban — наборы практик, которые можно заимствовать и комбинировать в интересах проекта.
- Scrum метод посвящен организационной стороне дела — как выстроить работу так, чтобы обеспечить частые релизы работающих версий продукта, которые с каждой итерацией становятся всё более функциональными.
- Kanban метод делает акцент на визуализации работ и обеспечению максимальной скорости.
- Экстремальное программирование отвечает на вопрос, как разрабатывать софт в Agile-стиле.
