Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Идеи Agile Manifesto






 

Гибкая методология разработки - серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки (выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы), динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности, известны как гибкие методики, экстремальное программирование, DSDM, Scrum.

 

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

 

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом англ. bullpen. Как минимум, она включает и «заказчиков» (англ. product owner — заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.

 

Основные идеи:

· люди и взаимодействие важнее процессов и инструментов;

· работающий продукт важнее исчерпывающей документации;

· сотрудничество с заказчиком важнее согласования условий контракта;

· готовность к изменениям важнее следования первоначальному плану.

 

28 Принципы, которые разъясняет Agile Manifesto:

· удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;

· приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);

· частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);

· тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;

· проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

· рекомендуемый метод передачи информации — личный разговор (лицом к лицу);

· работающее программное обеспечение — лучший измеритель прогресса;

· спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;

· постоянное внимание улучшению технического мастерства и удобному дизайну;

· простота — искусство не делать лишней работы;

· лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;

· постоянная адаптация к изменяющимся обстоятельствам.

 

Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана («дорожной карты») развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути, управления требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации.

 


Поделиться с друзьями:

mylektsii.su - Мои Лекции - 2015-2024 год. (0.007 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал