Это вам не небоскребы строить…

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

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

Безграничные возможности имеют обратную строну. Очень малую часть программ можно формализовать при помощи математического аппарата, а значит и автоматически генерировать, автоматически верифицировать, отыскивать ошибки и т.д. Как следствие этого проблема неопределенности. О программе нельзя сказать ничего определенного до тех пор, пока она не будет реализована! Программирование, это не детерминированный и эвристический процесс. Программу, обладающую фиксированным набором выходных характеристик всегда можно реализовать множеством различных способов. И это вносит своего рода piece of art в труд программиста и роднит его, если не с художником, то с исследователем.

Безграничные возможности и многовариантность путей реализации, это сама по себе проблема, когда программист – перфекционист начинает устраивать бесконечный рефакторинг своего кода. Или когда случается «недержание креатива» в дизайне, которое мы обсуждали здесь.

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

Безграничные возможности – это нарастающая как снежный ком сложность программных систем и весь ворох проблем с этим связанных.

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

Со временем появился и другой путь для решения проблем разработки программ. Первоначально появился он в виде откровения XP, и за его шокирующей по началу атрибутикой смысл угадывался с трудом. А идея оказалась очень продуктивной. Суть в том, чтобы превратить проблемы в преимущества. Проблема в том, что требования меняются? - отлично, давайте будем менять их постоянно. Готовый продукт не соответствует потребностям? – хорошо, посадим заказчика рядом с программистами, пусть участвует в процессе. Сроки постоянно срываются? – не будем определять сроков, продукт всегда будет готов к использованию. Это кажется странным, но XP использует все характерные особенности программирования, которые отличают его от других видов инженерии. Ведь, правда, мы же не в бетоне кодируем, мы всегда можем вносить изменения в код. И программа начинает работать не перед самой сдачей. Написали функцию – компилируем, запускаем, проверяем - работает. Так почему это не показать заказчику. Методика называется «экстремальной» потому, что доводит до крайности вполне очевидные вещи. И это работает.

Хорошо. Но почему тогда XP не появилась раньше? Почему столько лет тысячи проектов успешно заваливались водопадным методом?
Говоря об XP мы часто забываем о том, что она базируется на самых передовых инженерных практиках в разработке софта, которые были созданы за предыдущие десятилетия. Я говорю о непрерывной интеграции, об автоматическом тестировании, рефакторинге и прочих вещах. Сами средства разработки сделали огромный шаг вперед. Почему Брукс в IBM не мог применять XP во время эпопеи разработки OS/390? Да просто инструменты не позволяли. Компиляция шла прогонами, прогон занимал несколько часов, а код предварительно вычитывали на наличие ошибок.

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

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

«Чтобы обеспечить их эффективное применение на практике вы должны использовать их все одновременно».

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

Недавно прокатилась волна публикаций про Post Agile. Но правда без существенных последствий, как прокатилась, так и стихла. А серебряной пули как не было так и нет. Как нет и золотой методики. Ни CMMi, ни PMBook, ни RUP ни XP пока не могут гарантировать успешного исхода нового программного проекта просто самим фактом своего использования. Все в наших руках.