Гибкая методология разработки
| Процесс разработки ПО | |
| Шаги процесса | |
|---|---|
|
Анализ • Проектирование • Реализация • Тестирование • Внедрение • Сопровождение |
|
| Модели / Методы | |
|
Agile (XP, Lean, Scrum и др.) • Cleanroom • Итеративная (OpenUP) • RAD • RUP • MSF • Спиральная • Каскадная • V-Model • Dual Vee Model • DSDM |
|
| Сопутствующие дисциплины | |
|
Конфигурационное управление • Документирование • Управление проектами • Управление требованиями |
|
Гибкая методология разработки (англ. Agile software development) — это концептуальный каркас, в рамках которого выполняется разработка программного обеспечения. Существует несколько подобных методик.
Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе, иногда называемом bullpen. Как минимум, она включает и «заказчиков» (product owner - заказчик или его полномочный представитель, определяющий требования к продукту; эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.
Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.
Содержание |
[править] История
В феврале 2001 в штате Юта США был выпущен Манифест гибкой методологии разработки ПО. Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время.Данный манифест был одобрен и подписан представителями методологий Extreme programming (XP), Crystal Clear, DSDM, Feature-Driven Development, Scrum, Adaptive Software Development, Pragmatic Programming. Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако именно после этого события произошло вхождение Agile-разработки в массы.
[править] Принципы
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[1]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды.
Agile Manifesto разработан и принят 11-13 февраля 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты. Манифест подписали представители следующих методологий Extreme programming, Scrum, DSDM, Adaptive Software Development, Crystal Clear, Feature-Driven Development, Pragmatic Programming.[2] Agile Manifesto cодержит 4 основные идеи и 12 принципов. Примечательно что, Agile Manifesto не содержит практических советов.
Основные идеи:[3]
- Личности и их взаимодействия важнее, чем процессы и инструменты;
- Работающее программное обеспечение важнее, чем полная документация;
- Сотрудничество с заказчиком важнее, чем контрактные обязательства;
- Реакция на изменения важнее, чем следование плану.
Принципы, которые разъясняет Agile Manifesto[4]:
- удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
- приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
- частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
- проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
- рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
- работающее ПО — лучший измеритель прогресса;
- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
- постоянное внимание на улучшение технического мастерства и удобный дизайн;
- простота — искусство НЕ делать лишней работы;
- лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
- постоянная адаптация к изменяющимся обстоятельствам.
[править] Критика
Многие руководители проектов, работающие в традиционных методологиях вроде "водопада", критикуют Agile.
Один из повторяющихся пунктов критики: при Agile-подходе часто пренебрегают созданием "дорожной карты" развития продукта, равно как и управлением требованиями, в процессе которого и формируется оная "карта". Подход Agile к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации.
Кроме того, считается, что работа в Agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход - "работает, и ладно", при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжелые к воспроизводству дефекты после реального развертывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов.
[править] Методологии
Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto, некоторые из них:
- Agile Modeling (англ.) -- набор понятий, принципов и приемов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения (ПО). Не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML. Основная цель:эффективное моделирование и документирование; но не охватывает программирование и тестирование,не включает вопросы управления проектом, развертывания и сопровождения системы. Однако включает в себя проверку модели кодом[5]
- Agile Unified Process (англ.) (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.
- Agile Data Method (англ.) -- группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд.
- DSDM основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя
- Essential Unified Process (англ.) (EssUP)
- Экстремальное программирование (Extreme programming, XP)
- Feature Driven Development (FDD) функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели». То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.
- Getting Real это итеративный подход без функциональных спецификаций, использующийся для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а потом ее функциональная часть.
- Open Unified Process (OpenUP) это итеративно-инкрементальный метод разработки ПО. Позиционируется как легкий и гибкий вариант RUP OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.
- Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования,
- корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта.
- Бережливая разработка программного обеспечения (Lean Software Development)использует методы концепции бережливого производства.
[править] Продукты
| В этом разделе не хватает ссылок на источники информации.
Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.
Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники. Эта отметка стоит на статье с 9 декабря 2011. |
В качестве примера продуктов, в основе которых лежат принципы гибкой методологии разработки, можно привести следующие:
- BaseCamp[6]
- Bitbucket[7]
- Bugzilla [8]
- CentralDesktop [9]
- ComindWork [10]
- Easy Projects .NET [11]
- Gemini [12]
- GitHub [13]
- Atlassian JIRA [14]
- KommandCore [15]
- Launchpad [16]
- Mantis [17]
- OTRS [18]
- Patch-Tag [19]
- Project Kaiser [20]
- Redmine [21]
- Savane [22]
- TargetProcess [23]
- Trac [24]
- Teamer [25]
[править] Примечания
- ↑ Agile Manifesto (англ.)
- ↑ en:Agile_software_development#History
- ↑ en:Agile_software_development#Principles
- ↑ Agile Manifesto principles
- ↑ Agile Modeling
- ↑ Сайт продукта: basecamphq.com
- ↑ Сайт продукта: https://bitbucket.org
- ↑ Сайт продукта: www.bugzilla.org/
- ↑ www.centraldesktop.com/
- ↑ www.comindwork.ru/
- ↑ www.easyprojects.net/
- ↑ Bug Tracking | Issue Tracking | Project Management
- ↑ GitHub - Social Coding
- ↑ JIRA - Track bugs, projects, issues with software development tools by Atlassian | Atlassian
- ↑ kommandcore.com/ru/
- ↑ https://launchpad.net
- ↑ www.mantisbt.org
- ↑ OTRS.org
- ↑ www.patch-tag.com/
- ↑ www.projectkaiser.com/ru/
- ↑ www.redmine.org
- ↑ gna.org/projects/savane
- ↑ Сайт продукта: http://www.targetprocess.com
- ↑ The Trac Project
- ↑ Teamer и его команда ← Teamer
[править] Ссылки
- Статья 'Введение в гибкую разработку программного обеспечения' (рус.)
- Статья 'Гибкий подход разработки ПО — Scrum' (рус.)
- Статья 'Автоматизация тестирования в Agile' (рус.)
- Статья 'Agile разрушил мою жизнь' (рус.)
- Статья 'Scrum - зачем заказчику знать такие непонятные слова?' (рус.)
- Сообщества
- Сайт гибких методик разработки (www.agiledev.ru) (рус.)
- Agile Community Russia — независимое некоммерческое сообщество, объединяющее ИТ-профессионалов, занимающихся или интересующихся гибкими методологиями разработки ПО (www.agilerussia.ru) (рус.)
- Agile-сообщество Беларуси (www.agile.by) (рус.)
- Agile Ukraine — независимое некоммерческое сообщество сторонников agile подходов на Украине (www.agileukraine.org) (рус.)
- Agile-сообщество Молдовы (www.agilemoldova.com) (рус.)
- AgilePod — первый аджайл подкаст (рус.)
[править] Литература
- Майк Кон Scrum: гибкая разработка ПО = Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series) — М.: «Вильямс», 2011. — С. 576. — ISBN 978-5-8459-1731-7.
| Это заготовка статьи о программном обеспечении. Вы можете помочь проекту, исправив и дополнив её. |
|
|
|
|---|---|
| Известные деятели |
Кент Бек (англ.) • Гради Буч • Фред Брукс • Barry Boehm • Уорд Каннингем • Оле-Йохан Даль • Том Демарко • Эдсгер Вибе Дейкстра • Дональд Кнут • Мартин Фаулер • Чарльз Энтони Ричард Хоар • Watts Humphrey • Майкл Джексон • Ивар Якобсон • Craig Larman • James Martin • Bertrand Meyer • David Parnas • Winston W. Royce • James Rumbaugh • Никлаус Вирт • Эдвард Йордан • Стив Макконнелл |
| Процесс | |
| Концепции | |
| Направления | |
| Модели разработки |
Гибкая методология разработки • Cleanroom • CASE • Итеративная разработка • RUP • OpenUP • RAD • Scrum • MSF • Спиральная модель • Модель водопада • XP • V-Model • Dual Vee Model • DSDM |
| Другие модели |
CMM • CMMI • Модель данных • Function model • IDEF • Information model • Metamodeling • Object model • View model • UML |
| Прочее | |

