Agile: различия между версиями
Материал из О цифровизации и вообще
| (не показано 6 промежуточных версий этого же участника) | |||
| Строка 1: | Строка 1: | ||
== Что такое Agile == | |||
Слово Agile часто используют как наименование одной из методик гибкого ведения проектов, или напротив обобщают под названием Agile все гибкие методы. | |||
На самом деле Agile - это философия разработки продукта, которая базируется на 4 ценностях и 12 принципах, прописанных в Манифесте Agile. | |||
Agile, | |||
Agile является одной из гибких методик управления разработкой, но не единственной. | |||
Большинство практик (фреймворков) гибкого управления проектами в той или иной степени базируются или перекликаются с Agile, но не идентичны ему. | |||
== Ценности == | == Ценности == | ||
| Строка 17: | Строка 17: | ||
== Принципы == | == Принципы == | ||
# Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. | |||
# Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. | |||
# Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. | |||
# На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. | |||
# Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. | |||
# Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. | |||
# Работающий продукт — основной показатель прогресса. | |||
# Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. | |||
# Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. | |||
# Простота — искусство минимизации лишней работы — крайне необходима. | |||
# Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. | |||
# Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. | |||
== Когда и как использовать == | == Когда и как использовать == | ||
Эта философия хорошо работает при разработке программных продуктов для конечных потребителей, когда целевой | Эта философия хорошо работает при разработке программных продуктов для конечных потребителей, когда целевой образ продукта достаточно туманен и меняется в процессе разработки. Не стоит использовать её при разработке критичных программмных продуктов по твердому техническому заданию, в том случае, если сроки установлены жестко. | ||
== Самые частые ошибки при использовании == | == Самые частые ошибки при использовании == | ||
Наиболее частой проблемой при использовании этой философии является то, что члены команд | Наиболее частой проблемой при использовании этой философии является то, что члены команд разработчика расценивают слово "важнее" в ценностях как "замещает". Это в результате приводит к анархии и хаосу. Чаще всего это относится к документации и архитектуре. | ||
Но на самом деле то, что левая часть ценности важнее, не означает, что правая часть совсем не нужна. | |||
== Источник == | == Источник == | ||
https://agilemanifesto.org/iso/ru/manifesto.html | https://agilemanifesto.org/iso/ru/manifesto.html | ||
{{Backlinks}} | |||
[[Категория:Цифровизация]] | |||
[[Категория:Менеджмент]] | |||
Текущая версия от 23:02, 18 апреля 2026
Что такое Agile
Слово Agile часто используют как наименование одной из методик гибкого ведения проектов, или напротив обобщают под названием Agile все гибкие методы.
На самом деле Agile - это философия разработки продукта, которая базируется на 4 ценностях и 12 принципах, прописанных в Манифесте Agile.
Agile является одной из гибких методик управления разработкой, но не единственной.
Большинство практик (фреймворков) гибкого управления проектами в той или иной степени базируются или перекликаются с Agile, но не идентичны ему.
Ценности
- Люди и взаимодействие важнее процессов и инструментов
- Работающий продукт важнее исчерпывающей документации
- Сотрудничество с заказчиком важнее согласования условий контракта
- Готовность к изменениям важнее следования первоначальному плану
Принципы
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Когда и как использовать
Эта философия хорошо работает при разработке программных продуктов для конечных потребителей, когда целевой образ продукта достаточно туманен и меняется в процессе разработки. Не стоит использовать её при разработке критичных программмных продуктов по твердому техническому заданию, в том случае, если сроки установлены жестко.
Самые частые ошибки при использовании
Наиболее частой проблемой при использовании этой философии является то, что члены команд разработчика расценивают слово "важнее" в ценностях как "замещает". Это в результате приводит к анархии и хаосу. Чаще всего это относится к документации и архитектуре.
Но на самом деле то, что левая часть ценности важнее, не означает, что правая часть совсем не нужна.
Источник
https://agilemanifesto.org/iso/ru/manifesto.html
Эта страница упоминается здесь:
