Agile

Что такое Agile

Слово Agile часто используют как наименование одной из методик гибкого ведения проектов, или напротив обобщают под названием Agile все гибкие методы. Это не очень корректно и похоже на то, как все копировальные машины начали называть "Ксероксами".

На самом деле Agile - это философия разработки продукта, которая базируется на 4 ценностях и 12 принципах, прописанных в Манифесте Agile.

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

Ценности

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

Принципы

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Когда и как использовать

Эта философия хорошо работает при разработке программных продуктов для конечных потребителей, когда целевой образ продукта достаточно туманен и меняется в процессе разработки. Не стоит использовать её при разработке критичных программмных продуктов по твердому техническому заданию, в том случае, если сроки установлены жестко.

Самые частые ошибки при использовании

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

Но на самом деле то, что левая часть ценности важнее, не означает, что правая часть совсем не нужна.

Источник

https://agilemanifesto.org/iso/ru/manifesto.html

Эта страница упоминается здесь: