Agile: различия между версиями

Материал из О цифровизации и вообще
Нет описания правки
 
Строка 1: Строка 1:
== Что такое Agile ==
== Что такое Agile ==
Слово Agile часто используют как наименование одной из методик гибкого ведения проектов, или напротив обобщают под названием Agile все гибкие методы. Это не очень корректно и похоже на то, как все копировальные машины начали называть "Ксероксами".
Слово Agile часто используют как наименование одной из методик гибкого ведения проектов, или напротив обобщают под названием Agile все гибкие методы.


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


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


== Ценности ==
== Ценности ==

Текущая версия от 23:02, 18 апреля 2026

Что такое Agile

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

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

Agile является одной из гибких методик управления разработкой, но не единственной.

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

Ценности

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

Принципы

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

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

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

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

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

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

Источник

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