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

Потребность в альтернативе классическим (монументальным) методологиям, которые в основном основаны на документации, привела к тому, что в 2001 году был проведен семинар, куда были приглашены представители различных адаптивных (гибких) методологий. Результатом работы стал манифест гибкой разработки ПО (Manifest for Agile Software Development) (см. Приложение 1).

Более подробно остановимся на адаптивных (гибких) методологиях, так как они наиболее активно развиваются и используются в настоящее время.

Методология SCRUM.

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

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

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

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

Что удалось сделать из выбранных для данной итерации функций за прошедший день?

Были ли какие-либо проблемы с реализацией?

Что планируется сделать за сегодняшний день?

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

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

Экстремальное программирование (eXtreme Programming или XP)

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

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

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

Crystal - это не просто методология, это целое семейство методологий, разработанное Алистером Коберном.

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

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

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

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

Вся команда разработчиков (до 6 человек) находится в одном помещении. Это позволяет сократить временные затраты на коммуникацию.

Частые поставки продукта позволяют выработать "ритм" проекта. Ничто так не вдохновляет команду, как поставленный вовремя продукт.

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

Средства контроля версий кода обеспечивают коллективное владение кодом.

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

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

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

Открытый исходный код (Open Source).

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

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

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

Адаптивная методология (Adaptive Software Development или ASD).

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

ASD базируется на принципе непрерывной адаптации, благодаря которой возникает другой жизненный цикл проекта. Постоянные изменения в проекте становятся нормой.

В ASD обычный статический жизненный цикл "Планирование - Проектирование - Конструирование" заменен на динамический "Обдумывание - Взаимодействие - Обучение".

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

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

Функционально-ориентированная разработка (Feature Driven Development или FDD).

Ключевую роль играет понятие функции или свойства (feature) системы. Функция должна реализовываться не более чем за две недели. То есть, если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько, относительно независимых, функций.

FDD включает пять процессов, последние два из которых повторяются для каждой функции:

разработка общей модели;

составление списка необходимых функций системы;

планирование работы над каждой функцией;

проектирование функции;

конструирование функции.

Разработчики в FDD делятся на "хозяев классов" и "главных программистов". Главные программисты привлекают хозяев задействованных классов к работе над очередным свойством. Для сравнения, в ХР нет персонально ответственных за классы или методы. К работе над любым классом может привлекаться любой из участников разработки.

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

Метод разработки динамических систем (Dynamic System Development Method или DSDM).

DSDM - методология, созданная Дженнифером Стаплетоном, позволяющая разрабатывать проект в короткие сроки с использованием ограниченного количества ресурсов, предусмотренного бюджетом. DSDM стремиться сократить связующие звенья между заказчиком и разработчиком, аналитиком и дизайнером, между членима команды и между разными уровнями управления, чтобы обеспечить более эффективные процесс разработки программного обеспечения. Фиксируя время разработки (обычно 6 месяцев) и устанавливая ограничения на используемые ресурсы, намного проще создать процесс разработки, отвечающий требованиям заказчиков.

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

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

DSDM неприменима если:

проект не сводится к итеративному приложению, где функциональность становится очевидна заказчику через пользовательский интерфейс;

Страницы: 1, 2, 3, 4, 5