Плани змінюються, як тільки вони починають розходитися з дійсністю чи побажаннями замовника. p align="justify"> Часта зміна версій (small releases)
Найперша працююча версія повинна з'явитися якомога швидше, і тут же повинна почати використовуватися. Наступні версії підготовляються через досить короткі проміжки часу (від декількох годин при невеликих змінах і невеликий програмі, до місяця-двох при серйозній переробці великої системи). p align="justify"> Метафора (metaphor) системи
Метафора в досить простій і зрозумілій команді вигляді повинна описувати основний механізм роботи системи. Це поняття нагадує архітектуру, але повинно набагато простіше, все у вигляді однієї-двох фраз описувати основну суть прийнятих технічних рішень. p align="justify"> Прості проектні рішення (simple design)
У кожен момент часу система повинна бути сконструйована так просто, наскільки це можливо. Не треба додавати функції заздалегідь - тільки після явної прохання про це. Вся зайва складність віддаляється, як тільки виявляється. p align="justify"> Розробка на основі тестування (test-driven development)
Розробники спочатку пишуть тести, потім намагаються реалізувати свої модулі так, щоб тести спрацьовували. Замовники заздалегідь пишуть тести, демонструють основні можливості системи, щоб можна було побачити, що система дійсно запрацювала. p align="justify"> Постійне переробка (refactoring)
Програмісти постійно переробляють систему для усунення зайвої складності, збільшення зрозумілості коду, підвищення його гнучкості, але без змін в його поведінці, що перевіряється прогоном після кожної переробки тестів. При цьому перевага віддається більш елегантним і гнучким рішенням, у порівнянні з просто дають потрібний результат. Невдало перероблені компоненти повинні виявлятися при виконанні тестів і відкочуватися до останнього цілісного стану (разом з залежними від них компонентами). p align="justify"> Програмування парами (pair programming)
Кодування виконується двома програмістами на одному комп'ютері. Об'єднання в пари довільно і змінюється від завдання до завдання. Той, у чиїх руках клавіатура, намагається найкращим способом вирішити поточну задачу. Другий програміст аналізує роботу першого і дає поради, обмірковує наслідки тих чи інших рішень, нові тести, менш прямі, але більш гнучкі рішення. p align="justify"> Колективне володіння кодом (collective ownership)
У будь-який момент будь-який член команди може змінити будь-яку частину коду. Ніхто не повинен виділяти свою власну область відповідальності, вся команда в цілому відповідає за весь код. p align="justify"> Постійне інтеграція (continuous integration)
Система збирається і проходить інтеграційне тестування якомога частіше, по кілька разів на день, кожного разу, коли пара програмістів закінчує реалізацію черговий функції.
40-годинний робочий тиждень
Понаднормова робота розглядається як ознака великих проблем у проекті. Не допускається понаднормова робота 2 тижні поспіль - це виснажує програмістів і робить їх роботу значно менш продуктивною. p align="justify"> Включення замовника в команду (on-site customer)
У складі команди розробників постійно перебуває представник замовника, який доступний протягом усього робочого дня і здатний відповідати на всі питання про систему. Його обов'язком є ​​досить оперативні відповіді на запитання будь-якого типу, що стосуються функцій системи, її інтерфейсу, необхідної продуктивності, правильної роботи системи в складних ситуаціях, необхідності підтримувати зв'язок з іншими додатками і пр.
Використання коду як засобу комунікації
Код розглядається як найважливіший засіб спілкування всередині команди. Ясність коду - один з основних пріоритетів. Дотримання стандартів кодування, обеспечівающімтакую ​​ясність, обов'язково. Такі стандарти, крім ясності коду, повинні забезпечувати мінімальність виразів (заборона на дублювання коду та інформації) і повинні бути прийняті всіма членами команди. p align="justify"> Відкрите робочий простір (open workspace)
Команда розміщується в одному, досить просторому приміщенні, для спрощення комунікації та можливості проведення колективних обговорень при плануванні та прийнятті важливих технічних рішень.
Зміна правил за необхідності (just rules)
Кожен член команди повинен прийняти перераховані правила, але при виникненні необхідності команда може поміняти їх, якщо всі її члени дійшли згоди з приводу цієї зміни.
Як видно із застосовуваних технік, XP розраховане на використання в рамках невеликих команд (не більше 10 програмістів), що підкреслюється і авторами цієї...
