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

SCRUM

Этот процесс предназначен для маленьких команд.

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

Итеративность

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

Важно отметить, что запланированная дата окончания итерации должна жестко соблюдаться. Команда может не реализовать некоторые из выбранных для итерации функций, но дату окончания итерации переносить нельзя.

Ход проекта

Отличительной чертой SCRUM является проведение ежедневных 15-30 минутных совещаний, которые так и называются scrum (потасовка). В ходе этих совещаний лидер команды задает каждому следующие вопросы:

1. Что удалось сделать из выбранных для данной итерации функций за прошедший день?
2. Были ли какие-либо проблемы с реализацией?
3. Что планируется сделать за сегодняшний день?

Это позволяет четко отслеживать ход проекта, быстро обнаруживать возникающие проблемы и, соответственно, быстро реагировать на них. Кроме того, такие ежедневные совещания укрепляют командный дух, что немаловажно.

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

Crystal

Crystal - это не просто методология, это целое семейство методологий, разработанное Алистером Коберном. Коберн - весьма незаурядный человек, который отличается оригинальными взглядами на создание ПО.

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

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

Итеративность и адаптация

Ну, конечно, семейство методологий Crystal построено на итеративной разработке. Продолжительность итерации может изменяться в пределах от 1 до 4 месяцев. Чем меньше итерация, тем лучше.

Важной особенностью Crystal является непрерывная настройка методологии. Это позволяет постепенно адаптировать ее для конкретной команды и конкретного проекта. Пожалуй, ни в одной другой методологии настройке не уделяется такого внимания.

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

Семейство методологий Crystal

Семейство методологий построено по нескольким принципам. Коберн классифицирует проекты по двум параметрам: критичность и величина команды. Под критичностью понимается величина ущерба, нанесенного в результате использования продукта. Например, ошибка в ПО для космического корабля или для аппарата искусственного дыхания несравнима с ошибкой в ПО для форума на сайте. Жизненно важные проекты имеют категорию L, а те, ошибка в которых обозначает потерю удобств, категорию C.

Степень важности нарастает по вертикальной оси. Величина команды нарастает по горизонтальной оси. В результате получается семейство методологий, которые можно изобразить так:

Названия методологиям даются по величине команды. Например, методологию Crystal Clear можно использовать в проектах класса C-D для команд с численностью до 6 человек. Методологию Crystal - для проектов класса C-E с численностью до 40 человек.

Чем ниже критичность и чем меньше команда, тем более "легкую" методологию нужно использовать. Самой легкой из всего семейства является методология Crystal Clear.

Crystal Clear

Подходит для команд численностью до 6 человек. Главные принципы:

• Вся команда в одном помещении. Это позволяет сократить временные затраты на коммуникацию.
• Частые поставки продукта позволяют выработать "ритм" проекта. Ничто так не вдохновляет команду, как поставленный вовремя продукт.
• Обмен информацией с реальными пользователями позволяет быстро получать обратную связь и ликвидировать недостатки на ранних стадиях.
• Средства контроля версий кода обеспечивают коллективное владение кодом.

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

Практики проекта:

• Релизы выпускаются каждые два-три месяца
• Применяется автоматическое регрессионное тестирование
• Пользователи дважды просматривают каждую версию
• Собрания по адаптации продукта и методологии проводятся в начале и в середине каждой итерации
• Деятельность, зависящая от какого-либо промежуточного продукта, начинается сразу же, как только промежуточный продукт становится достаточно стабильным. Например, проектирование зависит от требований. Как только собраны главные требования, надо начинать проектирование, то есть нельзя ожидать момента, пока требования не станут совершенно стабильными.

Может показаться, что данных практик маловато для нормального процесса. На самом деле существует достаточно много примеров успешного применения Crystal Clear.

Отличительные черты

Гибкие методологии имеют свои особенности. Они закреплены в манифесте быстрой разработки программного обеспечения, который был принят в 2001 году группой Agile Alliance. Небольшая цитата: "Мы открываем новые способы разработки ПО, создавая его сами и помогая другим. Благодаря этой работе мы стали ценить:

Индивидуумов и взаимодействия выше процессов и инструментов

Работающее ПО выше всеобъемлющей документации

Сотрудничество с заказчиками выше согласования условий договора

Реагирование на изменения выше соблюдения плана".

Нельзя не согласиться с этими утверждениями.

Большое количество интересной информации по гибким методологиям можно найти на сайте www.agilealliance.org. Недавно в продаже появилась книга Алистера Коберна "Быстрая разработка программного обеспечения", очень советую. Пока ее можно купить в интернет-магазине Rodina.by (rodina.by/book/info/go/6047.html).

Михаил ДУБАКОВ,
wa.artel.by