- •Rup и другие методологии разработки по. Часть 1. Принципы сравнения методологий разработки по
- •Как «измерить» методологию
- •Итеративная или каскадная разработка
- •Каскадный подход
- •Итеративный подход
- •Почему это важно
- •Уровень формализма Что такое формализм в проекте
- •Почему важна степень формализма
- •Что будем сравнивать
- •Часть 2. Сравнение методологий разработки по
- •Как получится…
- •Структурные методологии
- •Гибкие методологии
- •EXtreme Programming, или xp (экстремальное программирование)
- •Crystal Clear
- •Feature Driven Development
- •Общие черты
- •Модели зрелости процесса разработки (cmm, cmmi)
- •Часть 3. Как выбирать методологию?
- •Сколько формализма нужно? Польза документации
- •Общение вместо документации
- •Как выбирать?
- •Сколько итераций потребуется? Еще раз об итерациях
- •Польза и вред итераций
- •Как выбирать?
- •Подведем итоги
Гибкие методологии
Гибкие методологии базируются на десяти принципах, из которых мы назовем лишь те, которые определяют оценку этих методологий по выбранным параметрам:
главное — удовлетворить заказчика и предоставить ему продукт как можно скорее;
новые выпуски продукта должны появляться раз в несколько недель, в крайнем случае — месяцев;
наиболее эффективный способ передачи знаний участникам разработки и между ними — личное общение;
работающая программа — лучший показатель прогресса разработки.
Таким образом, эти методы явно ориентированы на итеративную разработку ПО и на минимальную формализацию процесса. Впрочем, относительно второго пункта необходимо сделать оговорку: названные методы ориентированы на минимально допустимый для данного проекта уровень формализации. По крайней мере, одна из методологий, входящих в группу гибких, — Crystal — имеет модификации, предназначенные для выполнения процессов с различным количеством участников и разной критичностью разрабатываемого ПО (критичность ПО определяется возможными последствиями ошибок, которые могут меняться в диапазоне от незначительных финансовых потерь на исправление ошибки до катастрофических). Чтобы дальнейшее сравнение с гибкими методологиями не было беспредметным, приведем краткие описания нескольких из них.
EXtreme Programming, или xp (экстремальное программирование)
Методология XP, разработанная Кентом Беком (Kent Beck), Уордом Каннингемом (Ward Cunningham) и Роном Джеффрисом (Ron Jeffries), является сегодня наиболее известной из гибких методологий. Иногда само понятие «гибкие методологии» явно или неявно отождествляют с XP, которая проповедует коммуникабельность, простоту, обратную связь и отвагу. Она описывается как набор практик: игра в планирование, короткие релизы, метафоры, простой дизайн, переработки кода (refactoring), разработка «тестами вперед», парное программирование, коллективное владение кодом, 40-часовая рабочая неделя, постоянное присутствие заказчика и стандарты кода. Интерес к XP рос снизу вверх — от разработчиков и тестировщиков, замученных тягостным процессом, документацией, метриками и прочим формализмом. Они не отрицали дисциплину, но не желали бессмысленно соблюдать формальные требования и искали новые быстрые и гибкие подходы к разработке высококачественных программ.
При использовании XP тщательное предварительное проектирование ПО заменяется, с одной стороны, постоянным присутствием в команде заказчика, готового ответить на любой вопрос и оценить любой прототип, а с другой — регулярными переработками кода (так называемый рефакторинг). Основой проектной документации считается тщательно прокомментированный код. Очень большое внимание в методологии уделяется тестированию. Как правило, для каждого нового метода сначала пишется тест, а потом уже разрабатывается собственно код метода до тех пор, пока тест не начнет выполняться успешно. Эти тесты сохраняются в наборах, которые автоматически выполняются после любого изменения кода.
Хотя парное программирование и 40-часовая рабочая неделя и являются, возможно, наиболее известными чертами XP, но все же носят вспомогательный характер и способствуют высокой производительности разработчиков и сокращению количества ошибок при разработке.
