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

Материал из О цифровизации и вообще
Нет описания правки
 
(не показано 7 промежуточных версий этого же участника)
Строка 1: Строка 1:
{{TBD}}
== Что такое Agile ==
Слово Agile часто используют как наименование одной из методик гибкого ведения проектов, или напротив обобщают под названием Agile все гибкие методы.


== Что такое Agile ==
На самом деле Agile - это философия разработки продукта, которая базируется на 4 ценностях и 12 принципах, прописанных в Манифесте Agile.
 
Agile является одной из гибких методик управления разработкой, но не единственной.
 
Большинство практик (фреймворков) гибкого управления проектами в той или иной степени базируются или перекликаются с Agile, но не идентичны ему.


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


== Принципы ==
== Принципы ==


== Как использовать ==
# Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
# Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику  конкурентного преимущества.
# Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
# На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
# Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
# Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
# Работающий продукт — основной показатель прогресса.
# Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
# Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
# Простота — искусство минимизации лишней работы — крайне необходима.
# Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
# Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
 
== Когда и как использовать ==
Эта философия хорошо работает при разработке программных продуктов для конечных потребителей, когда целевой образ продукта достаточно туманен и меняется в процессе  разработки.  Не стоит использовать её при разработке критичных программмных продуктов по твердому техническому заданию, в том случае, если сроки установлены жестко.
 
== Самые частые ошибки при использовании ==
Наиболее частой проблемой при использовании этой философии является то, что члены команд разработчика расценивают слово "важнее" в ценностях как "замещает". Это в результате приводит к анархии и хаосу. Чаще всего это относится к документации и архитектуре.
 
Но на самом деле то, что левая часть ценности важнее, не означает, что правая часть совсем не нужна.
 
== Источник ==
https://agilemanifesto.org/iso/ru/manifesto.html
 
{{Backlinks}}
[[Категория:Цифровизация]]
[[Категория:Менеджмент]]

Текущая версия от 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