И. А. Кудрявцев аучный (стр. 2 из 9)

Однако у команд всегда была альтернатива - использовать методологию разработки, которая превращает создание программного продукта в упорядоченный процесс, с помощью которого можно сделать работу программиста более прогнозируемой и эффективной [1]. Для достижения этой цели создается детальное описание процесса, важное место в котором занимает планирование. Казалось бы - вот решение проблемы непредсказуемости разработки и выхода за рамки установленных сроков. Однако в подобных методологиях есть один существенный недостаток, из-за которого большинство команд программистов от них отказываются. Чтобы сделать процесс разработки предсказуемым, необходимо наладить дисциплину внутри коллектива, а для этого нужно точно следовать предписаниям методологии и выполнять множество различных вспомогательных действий, что зачастую замедляет весь темп работ. И в итоге использование такого подхода часто становится бессмысленным. Именно поэтому такие методологии разработки программного обеспечения называют тяжеловесными, или, согласно термину Джима Хайсмита, - монументальными.

Несколько лет назад такое положение дел натолкнуло методологов на мысль, что нужно как-то менять процесс создания программных продуктов, и на свет появилась группа новых, облегченных методологий, которые коренным образом отличаются от монументальных. В настоящее время наиболее распространенный для них термин - гибкие (agile). Они являют собой нечто среднее между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу [1].

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

"- Гибкие методологии адаптивны, а не предсказуемы. Для тяжеловесных методологий необходимо детальное планирование большого объема разработок, и такой подход работает - но до тех пор, пока не начнутся изменения. Следовательно, для этих методологий сопротивляться всяким изменениям совершенно естественно. Гибкие же методологии, напротив, изменения приветствуют. В отличие от тяжеловесных, они были задуманы как процессы, которые адаптируют изменения и только выигрывают от них, даже в том случае, когда изменения происходят в них самих.

- Гибкие методологии ориентированы на человека, а не на процесс. В них ясно заявлено о необходимости учитывать в работе природные качества человеческой натуры, а не действовать им наперекор. Кроме этого в гибких методологиях особо подчеркивается, что работа по созданию программных продуктов должна приносить удовольствие. " [1].

1.2 Итеративность и формализованность

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

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

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

Итеративный подход оказывается эффективнее по нескольким показателям.

• Он приспособлен к меняющимся требованиям. Изменение требований и добавление новых свойств, определяемое заказчиком или нуждами технологии всегда было самым главным источником бед проектов. Оно приводило к опозданию с выпуском, нарушению графиков, неудовлетворению заказчиков и раздражению разработчиков [2]. Однако, это нормальная практика в разработке программного обеспечения, и было бы глупо этому удивляться. Конечно, можно считать, что часто меняющиеся требования – результат плохой проработки требований, однако дела обстоят далеко не всегда таким образом. Ведь сразу определить все возможные варианты требований непросто. Только получив какую-то версию системы, можно оценить, какие ее свойства важны, а какие абсолютно ненужные и неудобные. Выполнить проект без изменений можно, но это грозит выпуском продукта, который не будет иметь никакой коммерческой ценности. К тому же, не стоит забывать о таком важном факторе, как время. В мире бизнеса и информационных технологий не стоит на месте, а движется вперед стремительными темпами, поэтому то, что актуально сегодня, через полгода окажется устаревшим. А если проект рассчитан не на один год, то с самого начала проекта следует готовиться к меняющимся требованиям со стороны заказчика.
• Интеграция – это не один «большой взрыв» в конце проекта. Оставить интеграцию на самый конец означает получить переработки с большими затратами времени – иногда до 40% всего объема проекта [2]. Чтобы этого не допустить, итеративный подход предлагает разбить весь процесс разработки на небольшие итерации, в конце каждой из которых должна быть готова полноценная рабочая версия системы, полностью оттестированная и интегрированная. А значит, переработка минимизируется.
• Риски обычно обнаруживаются и устраняются на ранних итерациях. Итеративный подход минимизирует риски на ранних стадиях, когда тестируются все компоненты [2]. Он позволяет вовремя понять, является ли предполагаемый риск реальным, и выявить новые. В начале проекта это сделать гораздо легче и несильно дорого.
• Менеджеры имеют возможность внесения тактических изменений в продукт. Итеративная разработка быстро создает исполняемую архитектуру (хотя и с ограниченной функциональностью), которую можно использовать для быстрого выпуска продукта с некоторыми ограничениями [2].
• Облегчается повторное использование. Гораздо легче определить общие части тогда, когда они уже частично спроектированы или реализованы в итерациях, чем распознать их при планировании. Рецензирование проектных решений на ранних итерациях позволяет архитекторам указать на потенциальные возможности для повторного использования и затем разработать в последующих итерациях зрелый общий код для реализации таких возможностей [2].
• Дефекты можно найти и исправить за несколько итераций, что обеспечивает создание четкой архитектуры и высококачественного приложения. Узкие места обнаруживаются еще на ранних итерациях, а не в конце проекта при глобальном тестировании.
• Лучшее использование персонала в проекте. Многие организации совмещают использование каскадного подхода с организацией по типу конвейера: аналитики посылают готовые требования проектировщикам, которые отсылают свой продукт программистам, которые посылают компоненты специалистам по интеграции, которые отсылают систему тестировщикам. Такие многочисленные переходы являются источниками ошибок и недопонимания и заставляют людей меньше чувствовать ответственность за конечный продукт. Итеративный процесс расширяет области компетенции членов группы, разрешая им выполнять много ролей, позволяя менеджеру проекта лучше использовать имеющийся персонал, и одновременно убирает вредные передачи. [2]
• Члены команды учатся на ходу. Участники проекта на протяжении цикла разработки получают возможность учиться на своих ошибках от итерации к итерации.
• Улучшается процесс разработки сам по себе и становится по ходу работы более совершенным. В конце каждой итерации участники проекта могут оценить организацию процесса и внести в него необходимые корректировки, если что-то не будет подходить их команде.

1.3 Обзор гибких методологий

Существует много гибких методологий разработки, однако остановимся только на некоторых из них, наиболее известных и развитых: