Agile Manifesto

Манифест гибкой разработки программного обеспечения (англ. Agile Manifesto) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения.

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

Визуализация модели гибкой разработки программного обеспечения (Agile)

История

Agile-манифест был опубликован 13 февраля 2001 года, став результатом встречи 11-13 февраля на горнолыжном курорте в штате Юта.

Он был 17-ю независимыми практиками различных методик и подходов к организации процессов разработки программного обеспечения, именующих себя «Agile Alliance». Каждый практиковал какую-либо альтернативу тяжеловесным (традиционным) процессам, основанным на культе документации и бюрократизации. «Agile Alliance» принял решение объединить в общий Манифест те особенности и аспекты практикуемых ими методик и подходов (обозначенных lightweight (легковесными)), которые приносили наибольший практический положительный эффект.

Среди авторов, подписавших Манифест, были: Кент Бек, Майк Бидл, Ари ван Беннекум, Алистер Кокберн, Уорд Каннингем, Мартин Фаулер, Джеймс Греннинг, Джим Хайсмит, Эндрю Хант, Рон Джеффрис, Джон Керн, Брайан Марик, Роберт С. Мартин, Стив Меллор, Кен Швабер, Джефф Сазерленд и Дэйв Томас.

Ценности

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

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

Agile Alliance

Основные принципы

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

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

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

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

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

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

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

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

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

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

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

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

Литература

• Роберт Мартин. Чистый Agile. Основы гибкости (рус.). — Питер, 2020. — 352 p. — ISBN 978-5-4461-1552-5.
• Саймон Хейворд. Agile-трансформация. Готовый план перехода к гибкой бизнес-модели организации (рус.). — Бомбора, 2021. — 320 p. — ISBN 978-5-04-121508-8.
• Мещерякова М.М. ЭКОНОМИЧЕСКАЯ СУЩНОСТЬ ФОРМИРОВАНИЯ ПОРТФЕЛЯ ПРОЕКТОВ В ОРГАНИЗАЦИИ, РАБОТАЮЩЕЙ ПО ПРИНЦИПАМ AGILE-МАНИФЕСТА // Инновации и инвестиции. — 2021. — № 12.
• Чуланова Оксана Леонидовна. Технология управления проектами и проектными командами на основе методологии гибкого управления проектами Agile // Вестник евразийской науки. — 2018. — № 1.
• Брусов Александр Сергеевич. КОНЦЕПЦИЯ AGILE: ВОЗМОЖНОСТИ И ПЕРСПЕКТИВЫ ПРИМЕНЕНИЯ В ГОСУДАРСТВЕННОМ УПРАВЛЕНИИ(ОБЗОР ПУБЛИКАЦИЙ) // Вопросы государственного и муниципального управления. — 2022. — № 2.

Ссылки

• Agile-манифест разработки программного обеспечения

Данная статья имеет статус «готовой». Это не говорит о качестве статьи, однако в ней уже в достаточной степени раскрыта основная тема. Если вы хотите улучшить статью — правьте смело!