Agile

Страница находится в процессе редактирования

Что такое Agile

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

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

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

Ценности

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

Принципы

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

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

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

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

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

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

Источник

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

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