XP (Extreme Programming) to metodyka zwinna skoncentrowana na praktykach inżynierskich: programowanie w parach, TDD (najpierw test, potem kod), ciągła integracja, refaktoryzacja, wspólna własność kodu, krótkie cykle wydawnicze i stała obecność klienta przy zespole (on-site customer). Stworzył ją Kent Beck pod koniec lat 90.
Analityk biznesowy spotyka XP rzadziej niż Scruma, ale jego praktyki przesiąkły do większości dojrzałych zespołów - TDD i continuous integration to dziś standard niezależnie od metodyki. Dla analityka najciekawsza jest rola on-site customer: ktoś z wiedzą biznesową ma być stale dostępny dla zespołu i odpowiadać na pytania w minutach, nie tygodniach. W polskich realiach tę rolę bierze często właśnie analityk albo product owner.
W MediFlow zespół rozwijający moduł rezerwacji przejął z XP trzy praktyki: TDD dla logiki slotów (czternaście testów do funkcji wyliczania terminów powstało przed jej kodem), ciągłą integrację z automatyczną regresją oraz zasadę dostępności analityka - pytania o reguły biznesowe („czy wizytę NFZ można przełożyć na komercyjną?") dostawały odpowiedź tego samego dnia, zamiast czekać na cotygodniowe spotkanie. Tempo dowożenia wzrosło zauważalnie, bo developerzy przestali zgadywać.
Częsta pomyłka: utożsamianie XP ze Scrumem. Scrum to ramy organizacji pracy (role, wydarzenia, artefakty) i nie mówi nic o tym, jak pisać kod; XP to praktyki inżynierskie. Świetnie działają razem - Scrum porządkuje pracę, XP pilnuje jakości technicznej. Druga pomyłka: wybiórcze wdrażanie („bierzemy pair programming, ale tylko czasami, jak jest luźniej"). Praktyki XP wzmacniają się nawzajem; pojedynczo dają ułamek wartości.