4.4 Гибкая методология разработки (Agile)

Agile — целое семейство методологий разработки, а не единственный подход в разработке программного обеспечения, оно определяется Agile Manifesto¹.

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

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

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

• Личности и их взаимодействия важнее, чем процессы и инструменты;

• Работающее программное обеспечение важнее, чем полная документация;

• Главное — удовлетворить клиента и предоставить ему продукт как можно скорее;

• Реакция на изменения важнее, чем следование плану;

Таким образом, эти методы явно ориентированы на итеративную разработку ПО и на минимальную формализацию процесса. Чтобы дальнейшие исследования гибких методологий не были беспредметным, далее я привожу краткие описания нескольких из них.

4.4.1 Экстремальное программирование (xp)

Методология XP, разработанная Kent Beck, Ward Cunningham, и Ron Jeffries, на сегодня является наиболее известной из гибких методологий. На русском языке издано уже несколько книг, посвященных этой методологии. XP это упрощенный, ориентированный на кодирование процесс, для небольших проектов. Также как и RUP, эта технология основана на итерациях, объединяющих некоторые приемы, такие как небольшие релизы, простое проектирование, тестирование и постоянная интеграция. XP предлагает несколько подходов, которые эффективны для соответствующих проектов и обстоятельств, но содержит неочевидные предположения, работы и роли. RUP и XP исходят из различных философских основ. RUP - это система процессов, методов и техник, которые вы можно применить в любом конкретном программном проекте. Предполагается, что пользователь будет адаптировать RUP. С другой стороны XP - более ограниченный процесс, требующий дополнений для того, чтобы соответствовать полному циклу разработки проекта. Эта разница объясняет предпочтения в сообществе разработчиков программного обеспечения. Разработчики крупных систем рассматривают RUP в качестве решения своих проблем, в то время как сообщество разработчиков малых систем решение своих проблем видит в XP.  XP описывается как 12 практик: игра в планирование, короткие релизы, метафоры, простой дизайн, переработки кода, разработка «тестами вперед», парное программирование, коллективное владение кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода.

Основная цель игры в планирование — быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся все более четкими, это позволяет получить приблизительный план работы по выпуску следующих одной или нескольких небольших версий продукта.

При использовании XP тщательное оперативное планирование заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой стороны, регулярными переработками кода (так называемый рефакторинг). При этом основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода.

Данный метод ни в коем случае не отрицает важности предварительного планирования и управления проектом, но предлагает эффективные альтернативы классическим способам выработки оперативного плана разработки и поддержки спецификации проекта. Таким образом, после составления тактического плана и проектирования, можно приступать к работе, без детального оперативного планирования, пользуясь методологией XP.

Парное программирование и 40-часовая рабочая неделя, хотя и являются, возможно, наиболее известными чертами XP, носят все же вспомогательный характер и способствуют высокой производительности разработчиков и низкому количеству ошибок при разработке.

4.4.2 Crystal Clear

Crystal¹ — семейство методологий, определяющих необходимую степень формализации процесса разработки в зависимости от количества участников и критичности задач.

Crystal уступает XP по производительности, зато максимально проста в использовании. Требует минимальных усилий для внедрения, так как ориентирована на человеческие привычки. Считается, что она описывает тот естественный порядок разработки ПО, который устанавливается в достаточно квалифицированных коллективах, если в них не занимаются целенаправленным внедрением другой методологии.

Основные характеристики методологии:

• Итеративная инкрементная разработка;

• Автоматическое регрессионное тестирование;

• Привлечение пользователей к активному участию в проекте;

• Состав документации определяется участниками проекта;

• Как правило, используются средства контроля версий кода.

В целом, при использовании данной методологии, исходный план никак не меняется и применяется итеративная модель разработки. Помимо Crystal Clear в семейство Crystal входит еще несколько методологий, предназначенных для выполнения более крупных или более критических проектов. Они отличаются несколько более жесткими требованиями к объему документации и вспомогательным процедурам, таким как управление изменениями и версиями.