Основополагающие принципы «Agile» и его история


1 минут чтения

Методология и принципы «Agile» (от англ. agile – проворный) сейчас встречаются повсеместно, а не только в кругах разработчиков программного обеспечения. 
Приверженцами такого рода формата разработки и «непрерывной поставки» конечного продукта всё больше и больше.

«Непрерывная поставка» — это больше, чем модная фраза.
Если все сделано правильно, непрерывная поставка, к примеру, программного обеспечения — это святой Грааль практики разработки такого рода продукта, удержания клиентов, и это причина того, что DevOps так популярна сегодня.
Чтобы понять важность непрерывной доставки, вам нужно кое-что узнать об истории гибкости и о том, откуда пришли гибкие методы.

Примечание:
DevOps (Development Operation) – это набор практик для повышения эффективности процессов разработки (Development) и эксплуатации (Operation) программного обеспечения (ПО) за счёт их непрерывной интеграции и активного взаимодействия профильных специалистов с помощью инструментов автоматизации.


«Agile Manifesto»

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

agile.igo


История гибкой разработки начинается не с «Agile Manifesto» - его корни уходят в прошлое.
В этой статье описывается эволюция практики разработки программного обеспечения за более чем три десятилетия, включая истоки гибкости и то, как более свежие знания позволяют нам быстрее и быстрее выполнять циклы.

«Сначала наступил кризис»

В начале 1990-х годов, когда компьютерные вычисления начали распространяться на предприятиях, разработка программного обеспечения столкнулась с кризисом.
В то время это называлось «кризисом разработки приложений» или «задержкой доставки приложений».
По оценкам отраслевых экспертов, время между подтверждённой необходимостью и фактическим применением в производстве составляло около 3 лет.

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

В некоторых отраслях отставание превышало 3 года.
В аэрокосмической и оборонной сферах может пройти 20 или более лет, прежде чем сложная система вступит в фактическое использование.
В качестве крайнего, но отнюдь не необычного примера, программа "Space Shuttle", запущенная в эксплуатацию в 1982 году, использовала информационные и обрабатывающие технологии 1960-х годов. Сверхсложные аппаратные и программные системы часто проектировались, разрабатывались и собирались в сроки, охватывающие десятилетия.

«Лидеры мысли были разочарованы»

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

Трансформации претерпевали и другие отрасли.
На разработку нового автомобиля заводу требовалось шесть или более лет, а в 1990-х годах это время сократилось почти вдвое.
AT&T распалась, и так называемые «Baby Bells» (региональная телефонная компания США) резко сократили расходы на телефоны и обслуживание.

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

«И родился Agile»

Эти разочарования по поводу кажущейся непродуктивной деятельности по разработке программного обеспечения, разделяемые профессионалами-единомышленниками, привели к теперь известной встрече "Snowbird" в Юте в начале 2001 года.
Но это была не первая встреча этой конкретной группы лидеров программного обеспечения.
Они собрались годом ранее в "Rogue River Lodge" в Орегоне весной 2000 года.

В эту группу вошли Керн, пионеры экстремального программирования Кент Бек и Уорд Каннингем, Ари Ван Беннекум, Алистер Кокберн и еще двенадцать человек, хорошо известных сегодня в сообществе «Agile».
Практика «Agile» не была конечной целью. Фактически, до того времени, «Agile» ещё не использовалось в официальных темах и разговорах.

В частности, эти лидеры мнений искали способы быстро создать работающее программное обеспечение и передать его в руки конечных пользователей.
Такой подход к быстрой доставке даёт несколько важных преимуществ.
Во-первых, это позволило пользователям быстрее получить некоторые бизнес-преимущества нового программного обеспечения.
Во-вторых, это позволило команде разработчиков программного обеспечения быстро получить обратную связь о масштабах и направлениях разработки программного обеспечения.

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

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