4.Избор на техники во рамки на процесот

XP не дозволува избор на техники, оваа методологија е најефективна кога се оди “by the book”, слично како и SCRUM. Меѓутоа нешто што би сакал да променам доколку би постоела можност е collective code ownership. Во рамки на XP, сиот напишан код е заеднички на сите девелопери, тоа значи дека било кој може да го промени кодот на другиот. Оваа пракса сметам дека е лоша бидејќи може да води до сериозни последици, може да се доведе кодот до степен да не се знае што се променило и од кој.

Бидејќи XP предвидува користење на одредени техники, во кратки црти ќе ги опишам нивните карактеристики.[7]

• Pair programming – предвидува работа на двајца програмери на еден компјутер на една задача во исто време. Едниот програмер го пишува кодот и се фокусира на него, додека другиот програмер размислува за големата слика и како тој код ќе се вклопи со останатиот.
• Planning game – состанок кој се случува еднаш на итерација, еднаш неделно и се дели на два дела. Првиот дел, release planning служи за определување кои барања се исполнети во кои од releases во блиската иднина. Вториот дел, iteration planning служи за планирања на задачи на програмерите.
• Користење на unit tests за тестирање на одредени функционалности, одреден код, дел од системот. Ова е добро бидејќи овозможува брзо откривање на грешки, но неопходно е acceptance test бидејќи одредените делови од системот можат да функционираат и работат беспрекорно независно од другите делови, но целиот систем како целина да не работи правилно и точно според барањата.
• Small releases – доставување на софтверот преку континуирано доставување на мали releases овозможува клиентот да го види прогресот на развој на системот.
• Coding standard – целиот тим се согласува да програмира според даден стандард
• Collective code ownership – било кој може да го промени кодот на било кој друг
• Simple design – пишување на код на наједноставен можен начин