Agile Manifesto

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

Манифест гибкой разработки программного обеспечения (англ. Agile Manifesto) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года[1] на встрече 17 независимых практиков нескольких методик программирования, именующих себя «Agile Alliance».[2]

Текст манифеста доступен на более чем 50 языках (в т.ч. русский), и включает в себя 4 ценности, 12 принципов.

Ценности[править | править вики-текст]

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

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

Основные принципы[править | править вики-текст]

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

Примечания[править | править вики-текст]

Ссылки[править | править вики-текст]