Методологические стратегии

Жесткие и гибкие стратегии в методологиях программирования

Определяя стратегии последовательного и итеративного развития проектов, мы исходили из того, что контроль деятельности проекта — задача, требующая специальных организационных подходов. Общей целью является превращение создания программного продукта в упорядоченный процесс, в рамках которого развитие проекта можно сделать более прогнозируемым и эффективным. Для этого обычно создается детальное описание процесса разработки системы, особое место в котором занимает планирование. Иначе говоря, создается метод, с помощью которого предполагается конструировать систему. Удачные методы обобщаются, в результате опыт их применения превращается в методику, или, как сейчас принято говорить, методологию^{2В программировании наблюдается постоянная "возгонка" терминов: там, где должно быть орудие, говорят об инструменте, вместо слова "инструмент" употребляется "метод", вместо метода — методика, а методику заменяют методологией [16]. К сожалению, мы вынуждены пользоваться термином "методология", привычным в данной области настолько, что иное словоупотребление будет непонятным.}. Нередко при таком формировании методики - методологии фиксируются частные и случайные решения, оказавшиеся полезными из-за специфики удачных проектов. Наряду со всем полезным эти решения объявляются обязательными, стандартными, их вынуждены применять и тогда, когда исходные предпосылки утрачены. Чтобы следовать таким методологиям, приходится выполнять множество различных предписаний, что замедляет темп основных программистских работ. Поэтому их называют тяжеловесными, жесткими или, согласно [ 41 ] , монументальными.

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

В настоящее время разработаны стандарты зрелости процессов разработки программного обеспечения в организациях. Среди них наиболее развитым является предложение Института программной инженерии при Университете Карнеги–Меллона — так называемая модель SW-CMM (Capability Maturity Model for Software) [ 18 ] . Эту модель можно считать общепринятой, поскольку на нее чаще всего ориентируются заказчики, в частности из Министерства обороны США, предлагая проекты только тем организациям, которые сертифицированы на уровнях зрелости 4 и 5 (мы еще будем обсуждать эту модель). Как замечено в [ 47 ] , модель CMM была сформирована при существенном влиянии практики военных заказов с их жесткой процедурой контроля и отчетности. Предложения CMM для определения зрелости организации опираются на то, какие процедуры управления программными проектами, отслеживания их развития и другие менеджерские методы приняты в качестве фирменного стандарта. Методологии программирования, построенные на базе этих предложений, часто рассматривают как эталон жесткости.

В противовес жестким методологиям в последнее время сформировался компромиссный подход, методологии которого объединены общим термином agile development. На русский язык его переводят как быстрое развитие, гибкие методологии (см. перевод статьи М. Фаулера [ 24 ] ) и даже "шустрые технологии"^{3Мы предпочитаем называть методологии нового подхода "быстрыми", а не "гибкими", как сегодня часто говорят, по следующим причинам. Во-первых, вся их концептуальная гибкость — это готовность к изменениям вслед за изменениями ситуации, а в остальных отношениях (правила использования определенных методик) они могут оказаться не менее жесткими, чем монументальные подходы. Во-вторых, новые методологии концептуально действительно быстрые, поскольку они ставят перед разработчиками задачу отвечать на нужды пользователей так быстро, как только возможно, пусть даже в ущерб контролируемости процесса, отхода от стандартов и всего прочего, что мешает достижению максимальной скорости.} (см. [ 26 ] ). В новом подходе пытаются предоставить возможность облегченной организованной работы программистских коллективов, когда перегруженность стандартизованного процесса препятствует эффективности. Они претендуют на то, что их применение возможно даже когда не удается достаточно точно представить проект при его зарождении, т.е. в довольно типичной ситуации неопределенности реальной пользовательской потребности. В этих случаях предлагается привлечение заказчика к формированию задач и корректировке предположений в течение всего развития проекта. С его помощью пытаются выявлять наиболее точно и без излишних бюрократических процедур актуальные потребности пользователей, сложившиеся на текущий момент. В результате появляется возможность указать именно те требования, реализация которых необходима и допускает максимально короткие сроки выпуска релиза.

Все методологии быстрого развития ориентируются на стратегию итеративного наращивания возможностей системы, но с частичным отказом от постулата неизменности априорной архитектуры (как следствие, не только допускается, но даже предполагается, что архитектура системы, а значит, и программный код будут меняться при переходе от релиза к релизу). Все они предоставляют разработчикам значительно большую свободу, чем, к примеру, требования стандартов CMM. Но не следует думать, что этот подход полностью отменяет жесткие методологии. Как указывают Боэм и Тюрнер [ 34 ] , необходим баланс между свободой быстрых методологий и дисциплиной.

Более детально охарактеризовать все методологии быстрого развития совместно не представляется возможным — слишком различны их исходные принципы, слишком зависимы они от специфики коллективов, занимающихся разработками программного обеспечения, от зачастую стихийно складывающихся предпочтений, привычек. На стратегическом уровне их действительно объединяет так называемый Agile Manifesto [ 31 ] , принятый энтузиастами в феврале 2001 года в местечке Сноуберд (США), который сводится к четырем постулатам:

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

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