Но если проблема зацикливания на требованиях может быть успешно решена выбором подрядчиков, уже имевших опыт в построении систем данного типа, то другая, гораздо более значимая проблема несовпадения взглядов заказчика и подрядчика на казалось бы одни и те же вещи стабильно проявляется с ростом проекта. Даже если принять во внимание, что только 20 % требований специфичны для заказчика, тогда как 80 % исходят непосредственно от предметной области инвариантно среде и контексту, то эти 20 % способны угробить весь проект.

Для снижения рисков такого рода в конце 1980-х годов была предложена спиральная модель софтостроения.

...

Необходимо отличать спиральную модель от итеративной . Спиральная модель сходится в точку «система готова», итеративная модель в общем случае не сходится, но обеспечивает реализацию всё новых и новых требований.

Рис. 15. Спиральная модель с двумя витками

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

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

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

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

Таким образом, из научной плоскости мы переходим в область экспертных оценок. Поэтому слово «методология» справедливо вызывает у многих негативное отношение. Правильнее было бы говорить о технологии ведения со-фтостроительных проектов, но исторически появившийся термин так просто из обращения не выкинуть. Да и надо ли?

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

Ключевой особенностью гибкой методики является наличие мифологического титана – владельца продукта ( product owner ), который лучше всех знает, что должно получиться в итоге. На самом деле это просто иная формулировка старого правила «кто платит, тот и заказывает музыку». Именно владелец, за рамками собственно гибкого процесса, гением своего разума проводит анализ и функциональное проектирование, подавая команде на вход уже готовые пачки требований. Размер пачки должен укладываться в интеллектуальные и технологические возможности разработчиков, которым предстоит осуществить её реализацию за одну итерацию.

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

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

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

Для программистов позитив, к сожалению, изрядно разбавлен издержками производственного процесса. Методология, по сути, направлена на увеличение времени работы с клавиатурой и не располагает к размышлениям. Пиши код! Поэтому для стимуляции персонала процесс окружен религиозной атрибутикой, манипуляциями, иносказаниями и метафорами. С другой стороны, требования к уровню программиста ограничиваются знанием конкретных технологий кодирования, стандартных фреймворков, «умением разбираться в чужом коде» и «умением работать в команде», уже упоминавшимся в словаре для начинающего соискателя. Способность решать олимпиадные задачки здесь от вас не требуется. Скорее, наоборот, будет помехой.

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

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

Ничего не напоминает? Всего 15–20 лет назад эти же подрядчики сидели на тех же площадках, но назывались «отделами АСУ» и входили в штат фирмы. Да, теперь сторонние программисты обходятся вдвое-втрое дороже прежних сотрудников, зато в любой момент можно устроить имитацию конкурсного отбора исполнителя, а при необходимости быстро свернуть непрофильную деятельность, не испытывая законодательных и профсоюзных затруднений с сокращением персонала.

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

Как вы заметили, я начал с «водопада» и завершил «гибкой разработкой». Хотя адепты обоих подходов испытывают друг к другу сложные чувства, не бросилось ли вам в глаза их разительное сходство? Обе методологии зацикливаются с увеличением сложности проекта. Только «водопад» замыкается на тотальном анализе и проектировании, а гибкая методика «уходит в себя» на разработке и стабилизации, что, в общем, даже не скрывается, а рисуется на слайдах презентаций. Из этого следует вывод, что успешно выполненный в «водопадной» схеме проект может быть также в большинстве случаев выполнен в «гибкой» разработке. И наоборот, если не касаться вопроса людских ресурсов. Дело в масштабе.