Участник:ArmorAdmin/Гибкие методы разработки — различия между версиями
Материал из Бронетанковой Энциклопедии — armor.kiev.ua/wiki
(Новая: '''Оригинал:''' http://agilemanifesto.org/ '''Перевод:''' ~~~~ == Манифест гибкой методологии разработки == Мы открываем ...) |
м (LostArtilleryMan переименовал страницу Участник:ГОВНЮК/Гибкие методы разработки в Участник:ArmorAdmin/Гибкие методы разработки поверх перенапр…) |
||
| (не показано 11 промежуточных версий 2 участников) | |||
| Строка 1: | Строка 1: | ||
| + | {{DISPLAYTITLE:Манифест гибкой методологии разработки}} | ||
'''Оригинал:''' http://agilemanifesto.org/ | '''Оригинал:''' http://agilemanifesto.org/ | ||
| − | '''Перевод:''' [[Участник:ArmorAdmin|Чобиток Василий]] | + | '''Перевод:''' [[Участник:ArmorAdmin|Чобиток Василий]], 10 июля 2009 (и я данный манифест полностью разделяю) |
== Манифест гибкой методологии разработки == | == Манифест гибкой методологии разработки == | ||
| − | Мы | + | Мы ищем лучшие подходы к разработке программного обеспечения, используем их и помогаем использовать другим. |
| − | В своей работе мы | + | В своей работе мы применяем такие правила: |
| − | ''' | + | * '''Люди и взаимодействие''' над процессами и инструментами |
| − | + | * '''Работающее программное обеспечение''' над полнотой документации | |
| − | '''Работающее программное обеспечение''' над полнотой документации | + | * '''Сотрудничество с заказчиком''' над договорными отношениями |
| − | + | * '''Реакция на изменения''' важнее следования плану | |
| − | '''Сотрудничество с заказчиком''' над договорными отношениями | + | |
| − | + | ||
| − | '''Реакция на изменения''' важнее следования плану | + | |
Пункты в правой части этих утверждений имеют значение, но пункты слева важнее | Пункты в правой части этих утверждений имеют значение, но пункты слева важнее | ||
| Строка 66: | Строка 64: | ||
Мы следуем следующим принципам: | Мы следуем следующим принципам: | ||
| − | Наш наивысший приоритет — удовлетворить заказчика ранней и непрерывной поставкой полезного программного обеспечения. | + | * Наш наивысший приоритет — удовлетворить заказчика ранней и непрерывной поставкой полезного программного обеспечения. |
| − | + | * Приветствуются изменения требований, даже на поздних стадиях разработки. Гибкие процессы берут изменения на вооружение для предоставления заказчику конкурентных преимуществ. | |
| − | Приветствуются изменения требований, даже на поздних стадиях разработки. Гибкие процессы берут изменения на вооружение для предоставления заказчику конкурентных преимуществ. | + | * Регулярный выпуск работоспособного ПО, от пары недель до пары месяцев, отдавая предпочтение более коротким интервалам. |
| − | + | * Специалисты в предметной области и разработчики должны ежедневно, на протяжении всего проекта работать вместе. | |
| − | Регулярный выпуск работоспособного ПО, от пары недель до пары месяцев, отдавая предпочтение более коротким интервалам. | + | * Строить проект на мотивированных личностях. Создать им условия, предоставить необходимую поддержку и довериться им в достижении результата. |
| − | + | * Самый продуктивный и эффективный метод передачи информации к и от команды разработки — личное общение. | |
| − | Специалисты в предметной области и разработчики должны ежедневно, на протяжении всего проекта работать вместе. | + | * Работающая программа — основной показатель успешности работы. |
| − | + | * Гибкие методы способствуют устойчивой разработке. Инвесторы, разработчики и пользователи должны быть способны неограниченно поддерживать постоянный темп. | |
| − | Строить проект на мотивированных личностях. Создать им условия, предоставить необходимую поддержку и | + | * Постоянное внимание техническому совершенству и хорошему проектированию повышает гибкость. |
| − | + | * Необходима простота — искусство минимизации объемов выполненной работы. | |
| − | Самый продуктивный и эффективный метод передачи информации к и от команды разработки — личное общение. | + | * Лучшие архитектуру, требования и дизайн рождают самоорганизующиеся команды. |
| − | + | * Команда регулярно размышляет над тем, как работать ещё эффективнее, и соответствующим образом корректирует свою последующую работу. | |
| − | Работающая программа — основной показатель успешности работы. | + | |
| − | + | ||
| − | Гибкие методы способствуют устойчивой разработке. Инвесторы, разработчики и пользователи должны быть способны неограниченно поддерживать постоянный темп. | + | |
| − | + | ||
| − | Постоянное внимание техническому совершенству и хорошему проектированию повышает гибкость. | + | |
| − | + | ||
| − | Необходима простота — искусство минимизации объемов выполненной работы. | + | |
| − | + | ||
| − | Лучшие архитектуру, требования и дизайн рождают | + | |
| − | + | [[Категория:Личные заметки|Гибкие методы разработки]] | |
| + | [[Категория:Программная инженерия|Гибкие методы разработки]] | ||
Текущая версия на 05:47, 20 декабря 2015
Оригинал: http://agilemanifesto.org/
Перевод: Чобиток Василий, 10 июля 2009 (и я данный манифест полностью разделяю)
Манифест гибкой методологии разработки
Мы ищем лучшие подходы к разработке программного обеспечения, используем их и помогаем использовать другим.
В своей работе мы применяем такие правила:
- Люди и взаимодействие над процессами и инструментами
- Работающее программное обеспечение над полнотой документации
- Сотрудничество с заказчиком над договорными отношениями
- Реакция на изменения важнее следования плану
Пункты в правой части этих утверждений имеют значение, но пункты слева важнее
|
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
this declaration may be freely copied in any form,
but only in its entirety through this notice.Основные принципы гибкой методологии разработки
Мы следуем следующим принципам:
- Наш наивысший приоритет — удовлетворить заказчика ранней и непрерывной поставкой полезного программного обеспечения.
- Приветствуются изменения требований, даже на поздних стадиях разработки. Гибкие процессы берут изменения на вооружение для предоставления заказчику конкурентных преимуществ.
- Регулярный выпуск работоспособного ПО, от пары недель до пары месяцев, отдавая предпочтение более коротким интервалам.
- Специалисты в предметной области и разработчики должны ежедневно, на протяжении всего проекта работать вместе.
- Строить проект на мотивированных личностях. Создать им условия, предоставить необходимую поддержку и довериться им в достижении результата.
- Самый продуктивный и эффективный метод передачи информации к и от команды разработки — личное общение.
- Работающая программа — основной показатель успешности работы.
- Гибкие методы способствуют устойчивой разработке. Инвесторы, разработчики и пользователи должны быть способны неограниченно поддерживать постоянный темп.
- Постоянное внимание техническому совершенству и хорошему проектированию повышает гибкость.
- Необходима простота — искусство минимизации объемов выполненной работы.
- Лучшие архитектуру, требования и дизайн рождают самоорганизующиеся команды.
- Команда регулярно размышляет над тем, как работать ещё эффективнее, и соответствующим образом корректирует свою последующую работу.
