Надо сказать, что экстремальное программирование несет не только ряд преимуществ, но и содержит некоторые достаточно спорные или может быть не простые в освоении техники и практические приемы. В частности парное программирование. Ряд разработчиков, не может себя заставить участвовать в парном программировании, просто потому-то они считают, что их код самый надежный, самый хороший, самый безопасный, самый быстрый, самый документированный, то есть достаточно одного взгляда на код, что бы понять, как он работает. Таким разработчикам, как правило, достаточно сложно взаимодействовать с кем-то в паре и, как правило, такое взаимодействие не приводит к быстрому созданию лучшего по качеству кода. Важным недостатком, особенно при разработке корпоративных систем, является необходимость обеспечить постоянное присутствие заказчика в команде или заказчика в команде по вызову. Ну, достаточно представить себе, насколько проблематично, предположим, осуществить вызов топ-менеджера корпорации для внесения каких-то существенных изменений в программный продукт или для обсуждения этих изменений. Сильная зависимость от устного общения, к сожалению, ряд артефактов не формализован и в ряде случаев устные договоренности играют роль документов. Это достаточно сложно проверить, это достаточно сложно контролировать на уровне команды, и поэтому если команда не является высокоадаптивной и действительно внимательной к проблемам соседей, достаточно сложно в ряде случаев обеспечить поддержку эффективного устного общения. Еще одно важное замечание. Те 12 практик, о которых мы говорили, они включают, в частности, парное программирование, очень сильно взаимосвязана. То есть, вообще говоря, рекомендуется использовать их все вместе, если хоть одна какая-то практика не применяется или в недостаточной степени уделяется внимание, есть риск того, что продукт, который будет создан, будет не вполне качественным. Отсутствие стандартного способа описания дизайна, не смотря на то, что есть метрики, не смотря на то, что есть внутренние способы описания стандартов, вообще архитектурному проектированию может уделяться недостаточное внимание, есть риск того, что крупномасштабный проект будет, не вполне корректно спроектирован. То есть, есть риск того, что его качество будет из-за этого страдать. Кроме того, надо сказать, что помимо кода, артефакты не достаточно хорошо описаны и, так сказать, на совести наставника и на совести менеджеров процессов экстремального программирования остается то, каким образом будут реализованы стандарты разработки, на это нужно обратить особое внимание. Ну и проста, как подход, как принцип XP, может привести к тому, что архитектурная проработка достаточно сложных, корпоративных систем будет произведена в недостаточной мере, на это надо, опять-таки, следует обратить внимание. Мы рассмотрели то, какие образом осуществляется разработка программных систем в кризис по методологии экстремального программирования, рассмотрели, основные принципы, практики экстремального программирования, то каким образом реализуется жизненный цикл и те возможности и те проблемы, которые предоставляет эта методология для кризисной разработки.