Метафора (Metaphor)

Метафора системы (system metaphor). Хорошая метафора системы означает простоту и единый стиль именования объектов системы. Единый стандарт именования объектов системы определяется при помощи метафоры или набора метафор, которые принимаются как требования, понятные любому новому члену команды.

Стандарты кодирования (Coding Standards)

Стандарты кодирования (coding conventions). Стандарты разработки нужны для обеспечения других практик: коллективного владения кодом, парного программирования. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Стандарты разработки складываются из требований по именованию объектов SAP BW/BI, требований по реализации типовых задач, требований по организации потоков данных внутри системы (примером такого стандарта на верхнем уровне может служить LSA архитектура). Если стандарт разработки будет отсутствовать, то процесс контроля качества реализации может оказаться бесконечно итерационным.

Игра в планирование (Planning Game )

Планирование процесса (planning game). Практика планирования основывается на итерационном подходе который определяет конечные задачи понятные разработчикам с четкими критериями их выполнения и оценками трудоемкости (оценку делает сам разработчик). Вся команда, раз в неделю, собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации (итерация может длиться от одной до нескольких недель). В практике ХР предполагается что программисты реализуют только те функции, которые необходимы для возможностей, выбранных на данной итерации Заказчиком. В реалиях внедрения BW/BI проектов взаимодействие и участие Заказчика на этапах разработки, как правило, минимально, но  возможность Заказчику самому определять приоритеты реализации функционала и задач проекта под чутким управлением ожиданий силами РП помогает делать реализацию более гибкой и востребованной.

Заказчик в команде разработки (On-site Customer)

Постоянное участие заказчика (on-site customer). Представитель заказчика в период работы над системой находится в команде разработчиков, причем требования к квалификации этого человека или команды весьма высоки. Если заказчик не согласился предоставить персонал уровня экспертов, то проект попадает в группу наиболее высокого риска. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

Парное программирование (Pair Programming)

Парное программирование (pair programming) — одна из самых известных XP-практик. Все консультанты должны работать в парах: один пишет код, настраивает BW-объекты, другой смотрит. Человеческий фактор в данном случае играет определяющую роль: пара или работает или нет, третьего не дано. Из этой практики вытекает потребность размещения проектной команды в одном месте. Наибольший эффект достигается и наглядно виден при обучении стажеров: скорость «вливания» нулевого сотрудника не превышает 3-х месяцев, после чего вчерашний стажер может самостоятельно выполнять задачи в системе.

Простота проектирования (Simple Design)

Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Разработчики в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое наипростейшее работающее решение,