Основная идея RUP – максимально четко распределить работу каждого участника процесса разработки. Самая большая проблема, по моему мнению, заключается в том, что трудно (или даже невозможно) найти таких людей, которые будут делать только то, что им сказано. Как скоро им надоест заниматься одним и тем же? Не теряется ли чувство ответственности (и как следствие – удовлетворение от результата) за выполненную работу при жестком фиксировании участков работ? Служит ли наличие согласованных интерфейсов по обмену информацией гарантией качества и эффективности работы?
Продукты, поддерживающие методику – в первую очередь, это продукты самой компании Rational. Основной продукт Rose (используется практически на всех этапах разработки), SoDA (автодокументирование), RequisitePro (управление требованиями), ClearQuest (запросы на изменения), ClearCase (версионность), Administrator (управление репозиторием проекта), WorkBrench (настройка корпоративных процессов), Quantify (тестирование скорости кода), Purify (определение утечек памяти), PureCoverage (тест охвата кода), Robot (автоматизированное тестирование), SiteLoad (нагрузочное тестирование), SiteCheck (проверка «мертвых» Web-ссылок). В настоящее время доступен RUP, интегрированный в среду разработки Microsoft .NET (под названием Rational XDE).
XP
Extreme Programming – Экстремальное программирование.
Рождением (а точнее датой «официальной» регистрации) можно считать 2001г., когда в США, штате Юта 17 сторонников «легковесных» процессов разработки выработали манифест с основными постулатами. Идеологами методики можно считать Кента Бека, Уорда Каннингема и Рона Джеффриса.
Основные принципы: тесная коммуникация, постоянное тестирование, минимум документации и максимум гибкости. Впрочем, лучше привести текст манифеста (см. книгу [4]):
«Мы открываем лучшие способы разработки ПО, создавая его сами и помогая другим. Благодаря этой работе мы стали ценить:
Индивидуумов и взаимодействия выше процессов и инструментов
Работающее ПО выше всеобъемлющей документации
Сотрудничество с заказчиками выше согласований условий договора
Реагирование на изменения выше соблюдения плана
Это означает, что, хотя элементы в правой части также имеют свою ценность, но больше мы ценим элементы, расположенные слева».
Довольно краткие и понятные формулировки, делающие доступными высказанные идеи самым широким массам. ХР впервые озвучила некоторые совершенно революционные принципы разработки. «Это вам не понадобится», «Ищите самое простое решение, которое может сработать», «Любые сидящие рядом два разработчика могут поменять всё что угодно в системе», «Заказчик в любой момент может изменить требования» и др.
Однако я уже высказывал свою критику по поводу ХР. Большая часть претензий к ХР снимается, вследствие более детального знакомства с ней. Можно считать, что последние проекты, в которых я участвовал, были «в духе ХР».
Осталась следующая критика:
1. Идея «нахождения представителя заказчика в одной комнате с программистами» по моему мнению, мягко говоря, является фантастическим пожеланием. Никто не спорит, что коммуникация с заказчиком жизненно необходима. Но решение проблемы скорее находится, во-первых, в сфере разработки стандартных форм документов по взаимодействию (ТЗ, ТП). Во-вторых, в более быстрых итерациях (нужно помочь заказчику сформулировать и откорректировать своё видение системы)
2. Отрицание этапа «большого предварительного проектирования» допустимо только при разработке тривиальных систем (несложные сайты с уклоном в сторону дизайна, а не программирования, простейшие однопользовательские программы с минимумом бизнес-логики и т.п.). Цитируя одного из авторов: «Я рассматриваю здесь решения, полезные при разработке