Разделы

Введение

Rational Unified Process (RUP) - это структура процесса обработки, которую компания Rational Software развивала на протяжении многих лет, используемая во всех типах проектов разработки программного обеспечения - от маленьких до больших. Все большее число процессов "agile", таких как eXtreme Programming (XP), SCRUM, Feature-Driven Development (FDD) и Crystal Clear Methodology, получают сегодня признание как эффективные методы построения малых систем. (На сайте www.agilealliance.org можно найти подробную информацию о Agile Alliance.)

Следующие разделы призваны помочь коллективам разработчиков оценить некоторые инструкции "agile", описанные в одном из этих методов, чтобы понять, как они могут быть использованы в процессе разработки более сложного программного обеспечения, определенного в RUP (более подробная информация о RUP находится в разделе Введение в RUP).

Обзор

Сообщество agile синтезировало некоторое количество "наилучших инструкций", наиболее подходящих для малых, компактных коллективов разработчиков. Хотя RUP предназначено для коллективов разработчиков любого размера, эффективно оно может применяться только в малых проектах. Вообще, RUP и процессы сообщества Agile имеют сходный подход к вопросу о том, какие ключевые инструкции должны выполняться для разработки качественного программного обеспечения. Примерами таких инструкций являются применение повторяющейся разработки и ориентация на пользователей.

Следующие разделы описывают применение некоторых "наилучших инструкций", выработанных сообществом Agile для проектов на основе RUP, и преимущества их использования. В этом случае, внимание сосредоточено на инструкциях, основанных на методологии eXtreme Programming (XP). (Более подробная информация о XP находится на web-сайте: http://www.extremeprogramming.org.)

Инструкции XP

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

• Игра планирования: Быстро определить рамки следующего выпуска, комбинируя бизнес-приоритеты и технические предположения. Как только реальность обгонит план, изменить план.
• Быстрые выпуски: Быстро произведите простую систему, затем выпускайте новые версии с очень коротким циклом.
• Метафора: Руководит всей разработкой с помощью простого короткого изложения способа работы всей системы.
• Простой проект: Система должна быть спроектирована максимально просто в любой момент времени. Избыточная сложность устраняется по мере обнаружения.
• Тестирование: Программисты постоянно пишут тесты для модулей, которые должны безупречно выполняться перед продолжением разработки. Пользователи пишут тесты, которые демонстрируют работоспособность определенных функций.
• Рефакторинг: Программисты реструктурируют систему без изменения ее поведения для удаления повторений, улучшения связи, упрощения и повышения гибкости.
• Программирование в парах: Весь рабочий исходный код пишется двумя программистами в одной системе.
• Коллективное владение кодом: Каждый может внести изменение в исходный код в любом месте системы в любой момент времени.
• Непрерывная интеграция: Интегрировать и компоновать систему много раз в день при завершении каждой задачи.
• 40-часовая неделя: Как правило, не работать больше 40 часов в неделю. Никогда не работать сверхурочно две недели подряд.
• Заказчик в группе: Включить действительного заказчика в коллектив разработки, чтобы он был доступен в любое время для ответов на вопросы.
• Стандарты кодирования: Программисты пишут весь исходный код в соответствии с правилами, акцентированными на связности кода.

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

Инструкции XP в RUP

В дисциплинах, в которых пересекаются XP и RUP, следующие инструкции, описанные в XP, могут быть применены RUP (а иногда уже применяются):

• Игра планирования: Для очень маленьких проектов при планировании могут быть применены правила XP, позволяющие достичь многих целей, показанных в дисциплине RUP Управление проектом. Это особенно полезно в случаях плохо формализуемых проектов, когда не требуется создавать формальные промежуточные артефакты управления проектом.
• Рефакторинг и тестирование: Эти техники могут быть успешно применены в дисциплине реализации RUP. Инструкция тестирования XP, для которой требуется проект первого тестирования, особенно хорошо может быть применена для прояснения требований на уровне детализации. Как будет видно в следующем разделе, рефакторинг не очень хорошо масштабируется для больших систем.
• Непрерывная интеграция: RUP поддерживает эту инструкцию посредством построения подсистем и уровней систем (с повторением). Протестированные на уровне модуля компоненты интегрируются и тестируются в контексте объединяющей системы.
• Заказчик в группе: Многие из действий RUP могут быть выполнены намного эффективней при наличии в составе группы разработчиков представителя заказчика, которое может сократить количество необходимых промежуточных детализирующих документов. XP делает упор на диалог как предпочтительную форму коммуникации заказчика с разработчиком, которая требует непрерывного и непосредственного общения. Однако, при необходимости развития систем, независимо от их величины, необходимо больше, чем только диалог. XP позволяет, например, создавать документы дизайна при завершении проекта. Не запрещая создавать документы или другие артефакты, XP говорит, что создавать нужно только то, что действительно необходимо. RUP соглашается с этим, но не описывает, что является необходимым, когда непрерывность и непосредственность коммуникации не обеспечена полностью.
• Стандарты кодирования: RUP имеет артефакты, нормативы программирования, которые почти всегда считаются обязательными. (Большая часть профайлов проектного риска, будучи главным движущим механизмом адаптации, должны придерживаться этого.)
• 40-часовая рабочая неделя: Как и в XP, RUP предлагает исключить ситуацию постоянной внеурочной работы. XP не выдвигает жесткого 40-часового ограничения, допуская отклонения в режиме работы. Общеизвестно, что разработчики программного обеспечения склонны работать внеурочно без дополнительной оплаты, только ради удовлетворения от совершенства создаваемого ими продукта, и менеджерам не обязательно это прекращать. То, чего никогда не должны делать менеджеры, - это пользоваться такой практикой или навязывать ее. Они должны всегда отмечать количество фактически отработанных часов, даже если они не возмещаются. Если журнал проработанного кем-либо времени выглядит превышенным, это необходимо исследовать. Однако, менеджер и работник должны решить это с учетом имеющихся условий, установив, какое отношение к остальному коллективу это может иметь. 40-часов - это только рекомендация, но твердая.
• Программирование в парах: XP утверждает, что программирование в парах повышает качество исходного кода, и будучи единожды приобретенным, этот навык становится более привлекательным. RUP не описывает в подробностях процесс написания исходного кода, хотя программирование в парах, несомненно, может быть использовано в процессах на основе RUP. Некоторая информация о программировании в парах, также как рефакторинг и тестирование, сейчас предоставляется вместе с RUP в виде официальных документов. Конечно, использование каких-либо из этих инструкций в RUP не является требованием, однако мы рискнем выдвинуть предположение, что в коллективной среде с культурой открытой коммуникации преимущества программирования в парах (в терминах эффективности и стоимости общего жизненного цикла) будет нелегко различить. Люди в слаженном коллективе естественно и без принуждения будут приходить к обсуждению и совместному решению проблем.

Предположение о том, что хороший процесс должен быть навязан на "микро-уровне", часто является отталкивающим и не соответствует некоторым видам корпоративной культуры. Поэтому, RUP не поддерживает строгое принуждение. Однако, в определенных обстоятельствах, работа в парах и некоторые другие инструкции, основанные на принципах коллективной работы XP, являются очевидно выгодными, поскольку каждый член команды может помочь другому. Например:

• на ранних стадиях формирования коллектива, когда люди приобретают знания
• в коллективах, не имеющих опыта в какой-либо новой технологии
• в коллективах, состоящих как из опытного персонала, так и новичков

Инструкции XP, которые плохо масштабируются

Следующие инструкции XP плохо масштабируются для больших систем (XP не требует их применения), так что при этом условии мы не настаиваем на их использовании в RUP.

• Метафора: Для больших и сложных систем не достаточно представить их архитектуру в виде простой метафоры. RUP предоставляет более разнообразную структуру описания для архитектуры, которая не является просто "системой черных ящиков и их связей", как это описано в Объяснении принципов Экстремального программирования. Даже в сообществе XP в последнее время метафора все меньше употребляется. В XP нет более длительной инструкции (до тех пор пока не понятно, как можно описать это хорошо, метафора может помочь).
• Коллективное владение кодом: Полезно, чтобы члены коллектива, ответственные за маленькие системы или подсистемы, были знакомы со всем исходным кодом. Но вопрос о том, имеет ли смысл уполномочивать в равной степени всех членов коллектива вносить любые изменения во всем исходном коде, зависит от его сложности. Часто будет быстрее (и безопаснее) поручить внести исправление тому человеку (или паре), который работает над соответствующим сегментом исходного кода. Ознакомленность даже с идеально написанным кодом, особенно алгоритмически сложным, со временем быстро уменьшается.
• Рефакторинг: В большой системе частый рефакторинг не заменяет недостаток архитектуры. В книге Объяснение принципов экстремального программирования сказано: "Стратегия проектирования XP имеет сходство с алгоритмом поиска экстремума. Вы получаете простой проект, затем немного его усложняете, затем немного упрощаете, потом снова немного усложняете. Цель алгоритмов поиска экстремума состоит в достижении локального оптимума, в котором никакие малые изменения не могут улучшить ситуацию, а большие могут." В RUP архитектура предоставляет перспективу достижения "глобального экстремума", когда большая и сложная система становится легко управляемой.
• Быстрые выпуски: Частота, с которой заказчик может принимать и развертывать новые выпуски, зависит от многих факторов, в том числе от размера системы. Это обычно связано с влиянием на бизнес. Двухмесячный цикл может оказаться слишком коротким для некоторых типов систем, и логистика развертывания может это запретить.

Инструкции XP, требующие осторожности

Инструкция XP, которая на первый взгляд выглядит потенциально полезной в RUP, - Простой проект - требует осторожности и развития в общем случае.

• Простой проект
  XP сильно зависит от функциональности: пожелания пользователя собираются, разбиваются на задачи, а затем реализуются. В соответствии с книгой Объяснение принципов экстремального программирования, проект программного обеспечения в любой момент времени должен удовлетворять всем тестам, не содержать повторяющейся логики, утверждать важность каждой цели для программистов и иметь как можно меньше классов и методов. XP не предполагает добавление к продукту чего-то, что не приносит заказчику пользы в его бизнесе.

  Здесь есть сложность, наподобие проблемы локальной оптимизации, которая в RUP называется "нефункциональными" требованиями. Эти требования также имеют значение для бизнеса заказчика, но их труднее сформулировать. Кое-что из того, что в XP называется ограничениями, попадает в эту категорию. RUP не поддерживает проектирования чего-то, что не является необходимым, любым умозрительным образом, но является сторонником проектирования с архитектурной моделью в уме. Такая модель является одним из ключевых условий удовлетворения нефункциональным требованиям.

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

Преобразование артефактов для небольшого проекта

Когда мы приспосабливаем RUP под малый проект и соответственно этому сокращаем требования к Рабочему продукту, как это можно сравнить с эквивалентными артефактами в проекте XP? В таблице 1 приведен типичный набор артефактов RUP малого проекта RUP.

Таблица 1: Преобразование артефактов из XP в RUP для малого проекта

Хотя уровень дискретности артефактов отличается с двух сторон, в общем, для малых проектов артефакты в RUP очень хорошо преобразовываются в соответствующие артефакты проекта XP.

Обратите внимание, что таблица включает в себя также несколько артефактов, которые не предусмотрены XP, но необходимы во многих проектах. Среди них - Модель данных и артефакты, относящиеся к разработке, такие как Материалы поддержки пользователя.

Группы действий

RUP определяет Задачу как работу, которую выполняет Роль, или используя и преобразовывая входные артефакты, или создавая новые и измененные выходные артефакты. RUP продолжает перечислять эти группы действий и распределять их по категориям в соответствии со своими дисциплинами. Эти дисциплины включают в себя среди прочих: требования, анализ и проектирование, развертывание и управление проектом.

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

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

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

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

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

Имея дело с Группами действий, так же как и с Артефактами, важно не упускать из виду то, чего мы пытаемся достичь. Слепое выполнение действий никогда не является хорошей практикой. Действия и связанные с ними рекомендации даны для использования в тех случаях, когда они могут помочь в достижении поставленных целей, но они не должны применяться для восполнения недостатка в понимании того, что нужно достичь. Этот дух отчетливо выражен в XP, и мы считаем, что его следует применять каждому пользователю RUP.

Роли

В RUP считается, что группы действий выполняются ролями (или, более точно, лицами или группами, исполняющими те или иные роли). Роли также ответственны за определенные артефакты. Ответственная роль обычно создает артефакт и обеспечивает его сохранность при любых изменениях, внесенных другими ролями (если они разрешены). Лицо или группа людей могут выполнять одну роль или несколько ролей. Роль не должна соответствовать только одной должности в организации.

В книге Объяснение принципов экстремального программирования указано семь ролей, применяемых в XP: Программист, Заказчик, Тестировщик, Наблюдатель, Инструктор, Консультант и Руководитель. Там также описана ответственность и правомочность тех лиц, которые выполняют эти роли. В некоторых других Книгах XP также упомянуты эти роли. Различие в числе ролей в XP и RUP легко объяснить:

• XP не охватывает всех дисциплин RUP.
• Роли XP более сопоставимы с должностями в организации (возможно, со многими обязанностями), чем роли RUP. Например, Программист XP фактически выполняет несколько ролей RUP, - Конструктор, Проверяющий кода и Интегратор, - что требует немного разной компетенции.

XP и роли RUP в небольшом проекте

Когда роли RUP применяются в малом проекте, число XP-подобных ролей, которым они соответствуют, сокращается до пяти должностей. В таблице 3 (составленной в RUP) показано это соответствие ролям XP.

Таблица 3: Соответствие ролей XP и ролей RUP в малом проекте.

Использование инструкций XP в RUP

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

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

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

Справочник процесса Agile

• eXtreme Programming (XP) (Более подробная информация находится на web-сайте http://www.extremeprogramming.org/more.html.):
  • Объяснение принципов экстремального программирования. Кент Бэк объясняет концепции и философию экстремального программирования. Эта книга отвечает на вопросы "что" и "почему", но не на вопрос "как".
    
  • Рефакторинг улучшает существующий исходный код. Первый том, написанный Мартином Фавлером, содержит авторитетное описание рефакторинга. Оно построено на примерах. Есть множество примеров на языке Java. Эта книга объясняет, как осуществить рефакторинг и зачем это нужно.
    
  • Установка экстремального программирования. Авторы: Рон Джеффриер, Чет Хэндриксон и Энн Андерсен. Эта книга описывает определенные инструкции XP более детально, чем Объяснение принципов экстремального программирования. Она учит стилю программ XP.
    
  • Планирование экстремального программирования. Авторы: Кент Бэк и Мартин Фавлер. В этой книге приведены самые свежие подходы к планированию программного обеспечения в среде быстрой доставки. Эта книга учит способу выполнения проекта XP.
    
  • Исследование экстремального программирования. Авторы: Жианкарло Сьюзи и Мишель Марчези. Документы представленные в XP2000. Хорошо подобранный набор документов на большую часть тем.
    
  • Экстремальное программирование на практике. Авторы: Роберт Мартин и Джеймс Ньюкерк. Реальный проект, использующий XP, описан в мельчайших подробностях.
    
  • Изучение экстремального программирования. Автор - Вильям Вэйк. Основана на популярном Web-сайте XPlorations. Подробно исследованы определенные темы.
    
  • Применение экстремального программирования: Игра для победы. Авторы: Кэн Ауэр и Рой Миллер. Опыт первопроходцев применения XP. Публикация в сентябре.

Информацию о других участниках Agile Alliance можно найти на Web-сайте http://www.agilealliance.org.