[БЕЗ_ЗВУКА] В предыдущем видео мы рассмотрели общую теорию процессов, практик, методологий и моделей. В данном видео мы рассмотрим историю возникновения методологий гибкой разработки, а именно их прародителя — манифест гибкой разработки. Что же это такое? Манифест гибкой разработки программного обеспечения, или, от английского, Agile Manifesto, — это основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения. Он был подписан в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования, именующих себя Agile Alliance. Среди подписавших манифест специалистов были, в том числе, такие именитые люди, как Кент Бек, автор методологии Extreme Programming (на русском известна как «Экстремальное программирование»), а также автор целого направления разработки Test-driven development, TDD, то есть разработка, основанная на предварительном тестировании; Алистер Кокберн, автор методологии Crystal Clear, Кен Швабер и Джефф Сазерленд, авторы наиболее известной методологии Scrum. Также были и другие специалисты, но перечисленные выше являются авторами основных популярных методологий гибкой разработки. Текст манифеста доступен на более чем 50 языках, в том числе на русском, и включает в себя четыре основные ценности и 12 принципов. Ознакомиться с оригиналом вы можете на сайте по ссылке. Сейчас я хочу рассмотреть ценности и принципы, перечисленные в Agile-манифесте, более подробно. Первая ценность: люди и взаимодействия важнее процессов и инструментов. Вторая ценность: работающий продукт важнее исчерпывающей документации. Третья ценность: сотрудничество с заказчиком важнее согласования условий контракта. И четвертая ценность: готовность к изменениям важнее следования первоначальному плану. Таким образом, не отрицая важности того, что справа, все-таки больше ценится то, что слева. И давайте рассмотрим 12 основных принципов, перечисленных в Agile-манифесте. Первый принцип: наивысшим приоритетом является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения. Второй принцип: изменение требований приветствуется, даже на поздних стадиях разработки. Третий принцип: работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. Четвертый принцип: на протяжении всего проекта разработчики и представители бизнеса должны работать ежедневно вместе. Пятый принцип: над проектом дожны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Шестой принцип: непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Седьмой принцип: работающий продукт — это основной показатель прогресса. Восьмой принцип: инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Девятый принцип: постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Десятый принцип: простота — это искусство минимизации лишней работы — крайне необходима. 11-й принцип: самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. 12-й принцип: команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Звучит несложно. Но как все это применить на практике? Как внедрить это в свои проекты? Именно это мы и будем рассматривать в последующих видео: как найти соответствие принципу и конкретному инструменту, или церемонии.
