Extrémní programování - Extreme programming

Smyčky plánování a zpětné vazby v extrémním programování
Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Cvičení
Nástroje
Standardy a orgány znalostí
Glosáře
Obrysy

Extreme programming ( XP ) je metodika vývoje softwaru, která má zlepšit kvalitu softwaru a schopnost reagovat na měnící se požadavky zákazníků. Jako typ agilního vývoje softwaru obhajuje častá „vydání“ v krátkých vývojových cyklech, která mají zlepšit produktivitu a zavést kontrolní body, na kterých lze přijmout nové požadavky zákazníků.

Mezi další prvky extrémního programování patří: programování ve dvojicích nebo rozsáhlá kontrola kódu , jednotkové testování veškerého kódu, nikoli programování funkcí, dokud nejsou skutečně potřeba , plochá struktura správy, jednoduchost a srozumitelnost kódu, očekávání změn v požadavcích zákazníka v průběhu času a problém je lépe pochopen a častá komunikace se zákazníkem a mezi programátory. Metodika odvozuje svůj název od myšlenky, že prospěšné prvky tradičních postupů softwarového inženýrství jsou přeneseny do „extrémních“ úrovní. Jako příklad lze uvést, recenze kódu jsou považovány za prospěšné praxe; až do extrému, kód lze průběžně revidovat (tj. praxe párového programování ).

Dějiny

Kent Beck vyvinul extrémní programování během své práce na mzdovém projektu Chrysler Comprehensive Compensation System (C3) . Beck se stal vedoucím projektu C3 v březnu 1996. Začal upřesňovat metodiku vývoje použitou v projektu a napsal knihu o metodice ( Extreme Programming Explained , publikováno v říjnu 1999). Chrysler zrušil projekt C3 v únoru 2000, po sedmi letech, kdy společnost získala společnost Daimler-Benz . Ward Cunningham měl další zásadní vliv na XP.

Mnoho extrémních programovacích postupů existuje již nějakou dobu; metodologie posouvá „ osvědčené postupy “ do extrémních úrovní. Například „praxe vývoje testů, plánování a psaní testů před každým mikroinkrementem“ byla používána již v projektu NASA Merkur , na počátku 60. let minulého století. Aby se zkrátila celková doba vývoje, byly některé formální testovací dokumenty (například pro akceptační testování ) vyvíjeny souběžně (nebo krátce před) se softwarem připraveným k testování. Nezávislá testovací skupina NASA může napsat testovací postupy na základě formálních požadavků a logických omezení, než programátoři napíší software a integrují jej s hardwarem. XP posouvá tento koncept na extrémní úroveň, píše automatizované testy (někdy uvnitř softwarových modulů), které ověřují provoz i malých částí softwarového kódování, nikoli pouze testování větších funkcí.

Původy

V devadesátých letech ovlivnily vývoj softwaru dva hlavní vlivy:

Rychle se měnící požadavky vyžadovaly kratší životní cykly produktů a často se střetávaly s tradičními metodami vývoje softwaru.

Komplexní kompenzační systém Chrysler (C3) byl zahájen s cílem určit nejlepší způsob využití objektových technologií, přičemž jako předmět výzkumu byly použity mzdové systémy společnosti Chrysler, přičemž jazykem byl Smalltalk a GemStone jako vrstva přístupu k datům . Chrysler přivedl Kenta Becka , prominentního praktika Smalltalk, aby provedl ladění výkonu v systému, ale jeho role se rozšířila, když si všiml několika problémů s vývojovým procesem. Využil této příležitosti, aby navrhl a implementoval některé změny ve vývojových postupech - na základě své práce se svým častým spolupracovníkem Wardem Cunninghamem . Beck popisuje rané pojetí metod:

Když jsem byl poprvé požádán, abych vedl tým, požádal jsem je, aby udělali trochu věcí, které jsem považoval za rozumné, například testování a recenze. Podruhé bylo na řadě mnohem více. Říkal jsem si: „Zatraceně torpéda, alespoň z toho bude dobrý článek,“ [a] požádal tým, aby zvýšil počet knoflíků na 10 u věcí, které jsem považoval za zásadní, a vynechal všechno ostatní.

Beck pozval do projektu Rona Jeffriese, aby pomohl vyvinout a zdokonalit tyto metody. Jeffries poté působil jako trenér, aby vštípil postupy jako návyky v týmu C3.

Informace o principech a postupech za XP šířené do širšího světa prostřednictvím diskusí o původní wiki , Cunningham's WikiWikiWeb . Různí přispěvatelé diskutovali a rozšiřovali své nápady a výsledkem bylo několik metodik spin-off (viz agilní vývoj softwaru ). Také koncepty XP byly několik let vysvětlovány pomocí mapy hypertextového systému na webových stránkách XP na adrese http://www.extremeprogramming.org kolem roku 1999.

Beck upravil řadu knih o XP, počínaje vlastním Extreme Programming Explained (1999, ISBN  0-201-61641-6 ), šířící své myšlenky k mnohem širšímu publiku. Autoři v sérii prošli různými aspekty účasti na XP a jeho postupech. Série obsahovala knihu kritickou vůči praktikám.

Aktuální stav

XP generovalo značný zájem mezi softwarovými komunitami na konci devadesátých a na počátku dvacátých let minulého století, přičemž viděl přijetí v řadě prostředí radikálně odlišných od jeho původu.

Vysoká disciplína vyžadovaná původními postupy často šla stranou, což způsobilo, že některé z těchto postupů, jako například ty, které byly považovány za příliš rigidní, byly na jednotlivých místech zastaralé nebo omezené nebo dokonce ponechané nedokončené. Například praxi integračních testů na konci dne pro konkrétní projekt lze změnit na rozvrh na konec týdne nebo jednoduše omezit na testování ve vzájemně dohodnutých termínech. Takový uvolněnější rozvrh by mohl zabránit tomu, aby se lidé spěchali generovat umělé pahýly, jen aby prošli testováním na konci dne. Méně rigidní plán místo toho umožňuje vývoj komplexních funkcí po dobu několika dnů.

Mezitím se jiné agilní vývojové metody nezastavily a od roku 2019 se XP stále vyvíjí, přičemž získává více zkušeností ze zkušeností v této oblasti a používá jiné postupy. Ve druhém vydání Extreme Programming Explained (listopad 2004), pět let po prvním vydání, Beck přidal více hodnot a postupů a rozlišoval mezi primárními a důsledkovými praktikami.

Pojem

Cíle

Extreme Programming Explained popisuje extrémní programování jako disciplínu vývoje softwaru, která organizuje lidi, aby produkovali software vyšší kvality produktivněji.

XP se pokouší snížit náklady na změny požadavků tím, že má více krátkých vývojových cyklů než dlouhých. V této doktríně jsou změny přirozeným, nevyhnutelným a žádoucím aspektem projektů vývoje softwaru a měly by být plánovány, místo aby se pokoušely definovat stabilní soubor požadavků.

Extrémní programování také zavádí řadu základních hodnot, zásad a postupů nad rámec agilního programování.

Činnosti

XP popisuje čtyři základní činnosti, které jsou prováděny v rámci procesu vývoje softwaru: kódování, testování, poslech a navrhování. Každá z těchto činností je popsána níže.

Kódování

Zastánci XP tvrdí, že jediným skutečně důležitým produktem procesu vývoje systému jsou instrukce kódu - softwaru, které počítač dokáže interpretovat. Bez kódu neexistuje funkční produkt.

Kódování lze použít k nalezení nejvhodnějšího řešení. Kódování může také pomoci sdělit myšlenky o problémech s programováním. Programátor, který se zabývá složitým programovacím problémem, nebo je obtížné vysvětlit řešení kolegům programátorům, by jej mohl kódovat zjednodušeně a pomocí kódu ukázat, co znamenají. Říkají zastánci této pozice, že kód je vždy jasný a stručný a nelze jej interpretovat více než jedním způsobem. Ostatní programátoři mohou poskytnout zpětnou vazbu k tomuto kódu také kódováním svých myšlenek.

Testování

Hlavní článek: Vývoj na základě testů

Testování je ústředním bodem extrémního programování. Přístup extrémního programování spočívá v tom, že pokud malé testování může odstranit několik nedostatků, mnoho testů může odstranit mnoho dalších nedostatků.

  • Testy jednotek určují, zda daná funkce funguje podle očekávání. Programátoři napíší tolik automatizovaných testů, kolik by je napadlo, že by mohly „rozbít“ kód; pokud všechny testy proběhnou úspěšně, je kódování dokončeno. Každý kus kódu, který je zapsán, je testován, než přejdete na další funkci.
  • Přijímací testy ověřují, že požadavky, jak je chápou programátoři, splňují skutečné požadavky zákazníka.

Testování integrace celého systému bylo zpočátku doporučováno jako každodenní aktivita na konci dne pro včasnou detekci nekompatibilních rozhraní, aby se znovu připojily, než se oddělené sekce široce lišily od koherentní funkčnosti. Testování integrace celého systému však bylo omezeno na týdenní nebo méně často v závislosti na stabilitě celkových rozhraní v systému.

Naslouchání

Programátoři musí poslouchat, co zákazníci potřebují, aby systém dělal, jaká „ obchodní logika “ je potřebná. Musí těmto potřebám porozumět natolik, aby zákazníkovi poskytli zpětnou vazbu o technických aspektech toho, jak může být problém vyřešen nebo nelze vyřešit. Komunikace mezi zákazníkem a programátorem je dále řešena v plánovací hře .

Projektování

Z hlediska jednoduchosti by se samozřejmě dalo říci, že vývoj systému nepotřebuje víc než kódování, testování a poslech. Pokud jsou tyto činnosti prováděny dobře, výsledkem by měl být vždy systém, který funguje. V praxi to nebude fungovat. Člověk může projít dlouhou cestu bez navrhování, ale v daném čase se zasekne. Systém se stává příliš složitým a závislosti v systému přestávají být jasné. Tomu se lze vyhnout vytvořením návrhové struktury, která organizuje logiku v systému. Dobrý design zabrání mnoha závislostem v systému; to znamená, že změna jedné části systému neovlivní ostatní části systému.

Hodnoty

Extrémní programování původně v roce 1999 rozpoznalo čtyři hodnoty: komunikaci, jednoduchost, zpětnou vazbu a odvahu. Ve druhém vydání Extreme Programming Explained byla přidána nová hodnota, respekt . Těchto pět hodnot je popsáno níže.

Sdělení

Vytváření softwarových systémů vyžaduje sdělování systémových požadavků vývojářům systému. Ve formálních metodikách vývoje softwaru je tento úkol splněn prostřednictvím dokumentace. Extrémní programovací techniky lze považovat za metody pro rychlé budování a šíření institucionálních znalostí mezi členy vývojového týmu. Cílem je poskytnout všem vývojářům sdílený pohled na systém, který odpovídá pohledu uživatelů systému. Extrémní programování za tímto účelem upřednostňuje jednoduché návrhy, běžné metafory, spolupráci uživatelů a programátorů, častou verbální komunikaci a zpětnou vazbu.

Jednoduchost

Extrémní programování doporučuje začít s nejjednodušším řešením. Později lze přidat další funkce. Rozdíl mezi tímto přístupem a konvenčnějšími metodami vývoje systému je zaměření na navrhování a kódování pro dnešní potřeby místo pro zítřejší, příští týden nebo příští měsíc. To je někdy shrnuto jako přístup „ Nebudete to potřebovat “ (YAGNI). Zastánci XP uznávají nevýhodu, že to někdy může znamenat větší úsilí zítra o změnu systému; jejich tvrzení je, že je to více než kompenzováno výhodou neinvestování do možných budoucích požadavků, které se mohou změnit, než začnou být relevantní. Kódování a navrhování nejistých budoucích požadavků s sebou nese riziko vynakládání zdrojů na něco, co nemusí být potřeba, a možná zpoždění klíčových funkcí. Vzhledem k hodnotě „komunikace“ by měla zlepšit kvalitu komunikace jednoduchost v designu a kódování. Jednoduchý design s velmi jednoduchým kódem by většina programátorů v týmu snadno pochopila.

Zpětná vazba

V rámci extrémního programování se zpětná vazba týká různých dimenzí vývoje systému:

  • Zpětná vazba ze systému: Díky psaní testů jednotek nebo spouštění pravidelných integračních testů mají programátoři po implementaci změn přímou zpětnou vazbu o stavu systému.
  • Zpětná vazba od zákazníka: Funkční testy (aka přejímací testy ) jsou psány zákazníkem a testery. Získá konkrétní zpětnou vazbu o aktuálním stavu svého systému. Tato kontrola je plánována jednou za dva nebo tři týdny, aby zákazník mohl vývoj snadno řídit.
  • Zpětná vazba od týmu: Když zákazníci v plánovací hře přijdou s novými požadavky, tým přímo odhadne čas, který bude implementace trvat.

Zpětná vazba úzce souvisí s komunikací a jednoduchostí. Chyby v systému lze snadno sdělit napsáním jednotkového testu, který prokáže, že se určitý kus kódu zlomí. Přímá zpětná vazba od systému říká programátorům, aby tuto část překódovali. Zákazník je schopen systém pravidelně testovat podle funkčních požadavků, známých jako uživatelské příběhy . Cituji Kenta Becka : „Optimismus je profesní riziko programování. Zpětná vazba je léčba.“

Odvaha

Několik postupů ztělesňuje odvahu. Jedním z nich je přikázání vždy navrhovat a kódovat pro dnešek a ne pro zítřek. Toto je snaha vyhnout se zabřednutí do designu a vyžadující velké úsilí k implementaci čehokoli jiného. Courage umožňuje vývojářům cítit se pohodlně s refaktorováním jejich kódu v případě potřeby. To znamená revizi stávajícího systému a jeho úpravu, aby bylo možné snadněji implementovat budoucí změny. Dalším příkladem odvahy je vědět, kdy odhodit kód: odvaha odstranit zastaralý zdrojový kód, bez ohledu na to, kolik úsilí bylo vynaloženo na vytvoření zdrojového kódu. Odvaha také znamená vytrvalost: programátor se může celý den zaseknout na složitém problému, další den problém rychle vyřešit, ale pouze pokud jsou vytrvalí.

Úcta

Hodnota úcty zahrnuje úctu k druhým i sebeúctu. Programátoři by nikdy neměli provádět změny, které narušují kompilaci, způsobují selhání stávajících testů jednotek nebo jinak zdržují práci jejich vrstevníků. Členové respektují svou vlastní práci tím, že vždy usilují o vysokou kvalitu a prostřednictvím refaktoringu hledají nejlepší design pro dané řešení.

Přijetí čtyř dřívějších hodnot vede k respektu získanému od ostatních v týmu. Nikdo z týmu by se neměl cítit nedoceněný nebo ignorovaný. To zajišťuje vysokou úroveň motivace a podporuje loajalitu vůči týmu a vůči cíli projektu. Tato hodnota závisí na ostatních hodnotách a je zaměřena na týmovou práci.

Pravidla

První verzi pravidel pro XP publikoval v roce 1999 Don Wells na webových stránkách XP. V kategoriích plánování, řízení, navrhování, kódování a testování je uvedeno 29 pravidel. Plánování, správa a navrhování jsou volány výslovně, aby bylo možné čelit tvrzení, že XP tyto aktivity nepodporuje.

Další verzi pravidel XP navrhl Ken Auer v XP/Agile Universe 2003. Cítil, že XP jsou definována jeho pravidly, nikoli jeho postupy (které podléhají větší variabilitě a nejednoznačnosti). Definoval dvě kategorie: „Pravidla zapojení“, která určují prostředí, ve kterém může efektivně probíhat vývoj softwaru, a „Pravidla hry“, která definují činnosti a pravidla z minuty na minutu v rámci pravidel zapojení.

Zde jsou některá pravidla (neúplná):

Kódování

  • Zákazník je vždy k dispozici
  • Kód unit test první
  • Pouze jeden pár integruje kód najednou
  • Optimalizaci nechte na poslední chvíli
  • Žádné přesčasy

Testování

  • Veškerý kód musí mít jednotkové testy
  • Před uvolněním musí veškerý kód projít všemi jednotkovými testy .
  • Když je nalezena chyba , vytvoří se testy, než se chyba vyřeší (chyba není logická chyba; je to test, který nebyl napsán)
  • Přijímací testy se často provádějí a výsledky se zveřejňují

Zásady

Principy, které tvoří základ XP, jsou založeny na právě popsaných hodnotách a jsou určeny k podpoře rozhodnutí v projektu vývoje systému. Principy mají být konkrétnější než hodnoty a snadněji převedeny na vedení v praktické situaci.

Zpětná vazba

Extrémní programování považuje zpětnou vazbu za nejužitečnější, pokud se provádí často a rychle. Zdůrazňuje, že minimální zpoždění mezi akcí a její zpětnou vazbou je zásadní pro učení a provádění změn. Na rozdíl od tradičních metod vývoje systému dochází ke kontaktu se zákazníkem v častějších iteracích. Zákazník má jasný přehled o systému, který se vyvíjí, a může poskytnout zpětnou vazbu a řídit vývoj podle potřeby. S častou zpětnou vazbou od zákazníka bude chybné návrhové rozhodnutí vývojáře zaznamenáno a opraveno rychle, než vývojář stráví mnoho času jeho implementací.

Jednotkové testy přispívají k principu rychlé zpětné vazby. Při psaní kódu poskytuje spuštění testu jednotky zpětnou vazbu o tom, jak systém reaguje na provedené změny. To zahrnuje spouštění nejen testů jednotek, které testují kód vývojáře, ale také spouštění všech testů jednotek na veškerém softwaru pomocí automatizovaného procesu, který lze zahájit jediným příkazem. Tímto způsobem, pokud změny vývojáře způsobí selhání v jiné části systému, o které vývojář ví málo nebo vůbec nic, automatizovaná sada testů všech jednotek okamžitě odhalí selhání a upozorní vývojáře na neslučitelnost jejich změny s další části systému a nutnost odebrat nebo upravit jejich změnu. Podle tradičních vývojových postupů absence automatizované, komplexní sady testů jednotek znamenala, že taková změna kódu, kterou vývojář považoval za neškodnou, by byla ponechána na místě a objevila by se pouze během integračního testování-nebo ještě hůře, pouze ve výrobě; a určit, která změna kódu způsobila problém, mezi všemi změnami provedenými všemi vývojáři během týdnů nebo dokonce měsíců před testováním integrace, byl impozantní úkol.

Za předpokladu jednoduchosti

Jedná se o řešení každého problému, jako by jeho řešení bylo „extrémně jednoduché“. Tradiční metody vývoje systému říkají plánovat do budoucna a kódovat znovupoužitelnost. Extrémní programování tyto nápady odmítá.

Zastánci extrémního programování tvrdí, že dělat velké změny najednou nefunguje. Extrémní programování používá přírůstkové změny: například systém může mít malá vydání každé tři týdny. Když je provedeno mnoho malých kroků, zákazník má větší kontrolu nad vývojovým procesem a vyvíjeným systémem.

Přijímání změn

Princip přijetí změny spočívá v tom, že nepůsobíte proti změnám, ale přijmete je. Pokud se například na jedné z iteračních schůzek zdá, že se požadavky zákazníka dramaticky změnily, programátoři to přijmou a naplánují nové požadavky na další iteraci.

Cvičení

Další informace: Extrémní programovací postupy

Extrémní programování bylo popsáno tak, že má 12 postupů, seskupených do čtyř oblastí:

Jemná zpětná vazba

Nepřetržitý proces

Sdílené porozumění

Programátorský blahobyt

Kontroverzní aspekty

O postupech v XP se intenzivně diskutuje. Zastánci extrémního programování tvrdí, že tím, že se požadavek zákazníka na místě neformálně změní, se tento proces stane flexibilním a ušetří náklady na formální režii. Kritici XP tvrdí, že to může vést k nákladným přepracováním a plížení rozsahu projektu nad rámec toho, co bylo dříve dohodnuto nebo financováno.

Desky řízení změn jsou známkou toho, že existují potenciální konflikty v cílech projektu a omezení mezi více uživateli. Zrychlené metody XP jsou do jisté míry závislé na tom, že programátoři budou schopni zaujmout jednotný pohled na klienta, aby se programátor mohl soustředit spíše na kódování než na dokumentaci kompromisních cílů a omezení. To platí také v případě, že je zapojeno více programovacích organizací, zejména organizací, které soutěží o podíly projektů.

Mezi další potenciálně kontroverzní aspekty extrémního programování patří:

  • Požadavky jsou vyjádřeny spíše jako automatizované přejímací testy než jako dokumenty specifikací.
  • Požadavky jsou definovány postupně, spíše než se je pokoušet získat všechny předem.
  • Od vývojářů softwaru se obvykle požaduje, aby pracovali ve dvojicích.
  • Vpředu není žádný velký design . Většina návrhové činnosti probíhá za běhu a postupně, počínaje„nejjednodušší věc, která by mohla fungovat“ a přidání složitosti pouze v případě, že je vyžadována selháním testů. Kritici to přirovnávají k „ ladění systému podle vzhledu“ a obávají se, že to povede k většímu úsilí při přepracování, než jen k přepracování, když se změní požadavky.
  • K projektu je připojen zástupce zákazníka . Tato role se může stát jediným bodem selhání projektu a někteří lidé ji považují za zdroj stresu. Existuje také nebezpečí mikrořízení netechnickým zástupcem, který by se pokoušel diktovat používání technických softwarových funkcí a architektury.

Kritici zaznamenali několik potenciálních nedostatků, včetně problémů s nestabilními požadavky, žádných dokumentovaných kompromisů konfliktů uživatelů a nedostatku celkové specifikace návrhu nebo dokumentu.

Škálovatelnost

Společnost ThoughtWorks zaznamenala přiměřený úspěch u distribuovaných projektů XP s až šedesáti lidmi.

V roce 2004 bylo zavedeno průmyslové extrémní programování (IXP) jako evoluce XP. Má přinést schopnost pracovat ve velkých a distribuovaných týmech. Nyní má 23 postupů a flexibilní hodnoty.

Oddělitelnost a reakce

V roce 2003 Matt Stephens a Doug Rosenberg vydali Extreme Programming Refactored: The Case Against XP , který zpochybnil hodnotu procesu XP a navrhl způsoby, jak by jej bylo možné zlepšit. To vyvolalo dlouhou debatu v článcích, internetových diskusních skupinách a chatovacích oblastech na webových stránkách. Hlavním argumentem knihy je, že postupy XP jsou na sobě závislé, ale že jen málo praktických organizací je ochotno/schopno přijmout všechny postupy; proto celý proces selže. Kniha také kritizuje a negativně přibližuje model „kolektivního vlastnictví“ XP.

Některé aspekty XP se od vydání Extreme Programming Refactored změnily ; zejména XP nyní umožňuje úpravy postupů, pokud jsou stále splněny požadované cíle. XP také pro procesy používá stále obecnější výrazy. Někteří tvrdí, že tyto změny ruší předchozí kritiku; jiní tvrdí, že se tím tento proces jednoduše zpomaluje.

Jiní autoři se pokusili sladit XP se staršími metodikami, aby vytvořili jednotnou metodiku. Některé z těchto ZK se snažily nahradit, například metodika vodopádu ; příklad: Životní cykly projektu: Waterfall, Rapid Application Development (RAD) a All That. Společnost JPMorgan Chase & Co. zkoušela kombinovat XP s metodami počítačového programování integrace modelu zralosti schopností (CMMI) a Six Sigma . Zjistili, že tyto tři systémy se navzájem dobře posilují, což vede k lepšímu vývoji, a vzájemně si neodporují.

Kritika

Počáteční hlášky extrémního programování a kontroverzní principy, jako je párové programování a kontinuální design , přitahovaly zvláštní kritiku, například od McBreen a Boehm a Turner, Matt Stephens a Doug Rosenberg. Agilním praktikům však řada kritik věří, že jsou nedorozuměním agilního vývoje.

Extrémní programování bylo zejména přezkoumáno a kritizováno Extact Programming Refactored Matta Stephense a Douga Rosenberga .

Viz také

Reference

Další čtení

  • Ken Auer a Roy Miller. Použito extrémní programování: Hraní na výhru , Addison – Wesley.
  • Ken Auer; Ron Jeffries ; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). „Jsou testeři eXtinct? Jak mohou testeři přispět týmům XP?“. Extrémní programování a agilní metody - XP/Agile Universe 2002 . Přednášky z informatiky. 2418 . Springer-Verlag. p. 287. doi : 10,1007/3-540-45672-4_50 . ISBN 978-3-540-44024-6.
  • Kent Beck : Extreme Programming Explained: Embrace Change , Addison – Wesley.
  • Kent Beck a Martin Fowler : Plánování extrémního programování , Addison – Wesley.
  • Kent Beck a Cynthia Andres. Extreme Programming Explained: Embrace Change, Second Edition , Addison – Wesley.
  • Alistair Cockburn : Agilní vývoj softwaru , Addison – Wesley.
  • Martin Fowler : Refaktoring: Zlepšení designu stávajícího kódu , Addison – Wesley.
  • Harvey Herela (2005). Případová studie: Komplexní kompenzační systém Chrysler . Galen Lab, UC Irvine.
  • Jim Highsmith . Agilní softwarové vývojové ekosystémy , Addison – Wesley.
  • Ron Jeffries , Ann Anderson a Chet Hendrickson (2000), Extreme Programming Installed , Addison – Wesley.
  • Craig Larman a V. Basili (2003). „Iterativní a přírůstkový vývoj: Stručná historie“, Computer (IEEE Computer Society) 36 (6): 47–56.
  • Matt Stephens a Doug Rosenberg (2003). Extreme Programming Refactored: The Case Against XP , Apress.
  • Waldner, JB. (2008). „Nanopočítače a rojová inteligence“. In: ISTE, 225–256.

externí odkazy