Ez az írás a napjainkban egyre nagyobb teret hódító Agilis szoftverfejlesztési technikák áttekintése. Az Agilis Fejlesztés egy gyűjtőnév, ami alá több konkrét módszertan is tartozik, ezek egy része szoftverfejlesztési módszertan, más része menedzsment-módszertan, és szinte mindegyiknek része egyfajta hozzáállás is.
Nem célom az, hogy miután ezt bárki elolvassa, zsupsz, fejest ugorhasson bele, és holnaptól már használhassa a neki szimpatikus technikákat, már csak azért sem, mert a hozzáállás nem változik meg egyik napról a másikra. A cél az, hogy egyáltalán az esély meglegyen arra, hogy bárkinek megtetsszen ez vagy az a technika. Aztán ha megtetszett, akkor utána lehet utánanézni alaposabban.
Valamennyire törekedtem arra, hogy a legagilisebb, legrugalmasabb technikáktól haladjak a hagyományosabb, vízesés-szerűbb módszertanok felé.


Az Agilis Kiáltvány

Az Agilis Fejlesztés egy módszertan-család, és nem egy konkrét megközelítése a szoftverfejlesztésnek. 2001-ben 17 ember, az akkor 'pehelysúlyú módszertanok' néven futó módszertanok jelentős képviselői, összeültek, hogy megbeszéljék, mi a közös a módszertanaikban. Megalkották az Agilis Kiáltványt, amit széles körben elfogadtak, mint az agilis fejlesztés kanonikus meghatározását.

Az Agilis Kiáltvány

A szoftverfejlesztés jobb módjait fedezzük fel azáltal, hogy csináljuk, és segítünk másoknak is csinálni. Ennek során az alábbi hangsúly-eltolódásokat találtuk:

Egyének és interakcióik, szemben az eljárásokkal és eszközökkel.
Működő szoftver, szemben a teljeskörű dokumentációval.
Együttműködés az ügyféllel, szemben a szerződésről való alkudozással.
Változásokra való reagálás, szemben a terv követésével.

Ez azt jelenti, hogy a jobb oldalon szereplő értékek is fontosak, de a bal oldalon lévőket fontosabbnak tartjuk.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, a fenti szerzők
Ezt a nyilatkozatot szabadon lehet másolni, de csak egyben, ezzel a jognyilatkozattal együtt.

Összehasonlítás más típusú módszertanokkal

Az Agilis módszertanokat a 'terv-vezérelt' vagy 'fegyelmezett' módszertanok ellentétének szokták nevezni. Ez félrevezető, mert úgy hangzik, mintha az Agilis módszertanok 'tervezetlenek' vagy 'fegyelmezetlenek' lennének. Szerencsésebb megkülönböztetés, ha a számegyenes két végpontjának az 'adaptív' és a 'kiszámítható' módszertanokat tekintjük. Ebben az esetben az Agilis módszertanok a számegyenes 'adaptív' végén lesznek.

Az adaptív módszertanok arra fókuszálnak, hogy a gyakran változó követelményekhez tudjanak alkalmazkodni. Ha egy projektben megváltoznak az igények, akkor egy adaptív csapat képes alkalmazkodni a változásokhoz. Egy adaptív csapat nehezen tudja megmondani, hogy mi fog történni a jövőben. Minél távolabbi pontról van szó a jövőben, annál bizonytalanabb lesz az adaptív módszertan elképzelése arról, hogy mi is fog akkor történni. Egy adaptív csapat hajszálpontosan meg tudja mondani, mit fognak csinálni a jövő héten, de a következő hónapról már csak azt, hogy milyen feature-öket terveztek arra a hónapra. Ha egy hat hónappal későbbi release a kérdés, a csapat már csak a vállalat célkitűzéséről, vagy a tervezett költség-érték arányról tud beszámolni.

A kiszámítható módszertanok ennek ellenkezőjeként, arra fókuszálnak, hogy minél részletesebben megtervezzék a jövőt. Egy kiszámítható csapat pontosan meg tudja mondani bármelyik pillanatban, hogy mikor milyen feladatok és feature-ök lesznek készen a projektben. A prediktív csapatok nehezen váltanak irányt. A terv általában az eredetileg meghatározott cél elérésére van optimizálva, és az irányváltoztatás könnyen azzal a következménnyel járhat, hogy az elkészült munkát el kell dobni, és újrakezdeni. A kiszámítható csapatok gyakran változáskezelő bizottságot állítanak fel (change control board), hogy biztosítsák, hogy csak a legszükségesebb változások érintsék a projektet.

A legtöbb Agilis módszertan egyetért az iteratív fejlesztéssel abban, hogy a szoftvert rövid időközönként ki kell adni. Az Agilis fejlesztésben azonban ez a rövid időköz inkább hetekben mérhető, mintsem hónapokban. A legtöbb Agilis módszertan továbbá szigorú időkeretként tekinti ezt az időközt, és nem pedig tervezett célként. Az időkeret azt jelenti, hogy a határidő kőbe van vésve, és nem változhat. Ha a csapat kicsúszik a határidőből, akkor a feladatot nem sikerült megoldani, és vagy vissza kell vonni, vagy új feladatot csinálni belőle. Van olyan is, hogy a feladatot lehet egyszerűsíteni, hogy a csapat beleférjen a határidőbe.

A vízesés-modellel már kevesebb közös vonása van az Agilis technikáknak. A vízesés a legkiszámíthatóbb modell (elvileg), olyan lépésekből szokott állni, hogy a követelmények kigyűjtése, elemzése, tervezés, kódolás, tesztelés, szigorúan egymás után. A haladást általában eredményként felmutatható dolgok formájában mérik - követelmény-specifikáció, terv-dokumentumok, teszttervek, kódellenőrzési jegyzőkönyvek, és effélék. A vízesés modell néha azon csúszik meg, hogy a ciklus végén komoly integrálási és tesztelési problémák jelentkeznek, és ez a munka eltarthat néhány hónapig vagy évig is. Ez gyakran okozza a modell bukását. Az Agilis módszertanok ellenben teljesen integrált és tesztelt programokat eredményeznek, de mindig csak egy lépést tesznek előre, hétről hétre. A hangsúly egy elnagyolt, de működő rendszer korai kifejlesztésén van, amit aztán lehet finomítgatni.
Vannak olyan Agilis módszertanok is, amelyek a vízesés-modellt használják, de kicsinyítve, minden kis lépésben a teljes lépéssorozatot végrehajtva. Más módszertanok, például az Extrém Programozás, egyszerre több dologgal is haladnak.

Sokan használják a 'cowboyos' kódolás nevű 'módszert' is. A cowboyos kódolás lényege, hogy nincs semmiféle módszer meghatározva, mindenki azt csinálja, amit jónak lát. Az Agilis módszertanok gyakori újratervezése, szemtől-szembe kommunikációja, és viszonylag laza dokumentumkezelése miatt sokan azt hiszik, hogy ez is cowboyos kódolás. Az Agilis csapatok azonban nagyon is használják a maguk jól meghatározott (gyakran fegyelmezett és rigorózus) módszertanját, tehát éles különbség van az Agilis kódolás és a cowboyos kódolás között.

Kritikák

Rengeteg kritika olvasható ezekről a módszertanokról, aminek részben az az oka, hogy ezek többségükben még nem kiforrott, lezárt módszertanok, ráadásul mindenki a maga szája íze szerint értelmezi őket. A jogosnak elismert kritikák három központi érv köré gyűlnek:

• Csak gyakorlott, szenior fejlesztőkkel működik
• Nincs eléggé megtervezve a szoftver
• Túl sok kulturális változás kell ahhoz, hogy jól működjön

Az itt bemutatott Agilis módszertanok

• eXtrém Programozás
• Scrum (ez a név kicsit szójáték, jelent 'kavarodást' is, de a belőle képzett 'scrummy' viszont azt jelenti, hogy remek - ezért nem fordítom le)
• KristályTiszta és más Kristály módszertanok
• DSDM
• Feature Driven Development, vagyis Funkcionalitáson Alapuló Fejlesztés
• Test Driven Development, vagyis Tesztelésen Alapuló Fejlesztés

Az eXtrém Programozás

Az eXtrém Programozás az alábbiképpen foglalható össze:

• Az emberségesség és a hatékonyság összeegyeztetésére tett kísérlet
• Társadalmi jellegű változásokra irányuló mechanizmus
• A fejlődés egyik útja
• Fejlesztési stílus
• Szoftverfejlesztési diszciplína

Az XP fő célja, hogy csökkentse a változások költségvonzatát. A hagyományos rendszerfejlesztési módszertanokban (pl. SSADM), a rendszerrel szemben támasztott követelmények adottak a projekt elején, és gyakran nem is változnak meg. Ez azzal jár, hogy minél később kell változtatni a követelményeken, ami pedig szoftverfejlesztési projektekben a legvégén sem szokatlan, annál magasabbak lesznek a költségek. Ezt a koncepciót mutatja be ez az ábra.

Az XP arra törekszik, hogy ezeket a költségeket csökkentse azáltal, hogy más alapvető értékeket, elveket, és gyakorlatot vezet be. Egy XP-t használó rendszerfejlesztési projekt sokkal rugalmasabb lesz a röptében bekövetkező változásokkal szemben.

Az XP értékei

Nem sokkal ezelőttig csak 4 érték volt fontos az XP-ben, de a második kiadásban bevezettek egy ötödiket is. Ez az öt érték:

• Kommunikáció
• Egyszerűség
• Visszajelzés
• Bátorság
• Tisztelet

Kommunikáció

Az egyik alapvető fontosságú feladat a szoftverrendszer-készítés során, hogy valaki megmondja a fejlesztőknek, hogy mi a feladat. A korábbi módszertanok során ez főként dokumentumok gyártásával történt meg.
Az XP technikákat tekinthetjük gyors információrendszerező és -terjesztő technikáknak is, amelyeknek célja, hogy a fejlesztőcsapat minél gyorsabban szerezze meg a szükséges tudást. A cél az, hogy minden fejlesztő ugyanúgy lássa a rendszert, ahogy a majdani felhasználók is látni fogják. Ezért az XP szereti az egyszerű terveket, metaforákat, a majdani felhasználók és a mostani fejlesztők együttműködését, a gyakori szóbeli kommunikációt, és a visszajelzéseket.

Egyszerűség

Az XP azt a megközelítést támogatja, hogy kezdjük el a lehető legegyszerűbben, és folyamatosan dolgozzuk át a programot, hogy egyre jobb és jobb legyen. A különbség eközött a megközelítés között, és a hagyományos megközelítések között, hogy a mai igényeknek megfelelő programot tervezünk és írunk, nem pedig a holnapi, a jövő heti, vagy a jövő hónapi igényeknek megfelelőt. Az XP ellenzői ezt hátrányként fogják fel, mondván, hogy így megeshet, hogy a következő hónapban több munkába fog kerülni átdolgozni a rendszert, ha nem készültünk fel előre új követelményekre, és azt állítják, hogy ez az időveszteség kitesz annyit, mint a megvalósított, de később szükségtelennek bizonyuló feature-ökre fordított idő. Az egyszerűség elve viszont pontosan azt mondja, hogy a program túlbonyolódik, ha tele lesz mindenféle feature-rel, amiről már rég mindenki elfelejtette, hogy mire való, és a bonyolultság okozta többletmunka viszont sokszorosan meghaladja a folyamatos átdolgozás által generált munkát.
Az előző értékhez, a kommunikációhoz kapcsolódóan, az egyszerűség megkönnyíti és elősegíti a kommunikációt, mert egy egyszerű tervet és a hozzátartozó egyszerű kódot a csapat minden programozója könnyen megért.

Visszajelzés

Az XP-ben a visszajelzés a fejlesztés több területére is vonatkozik:

• Visszajelzés a rendszertől: a részegység-tesztek készítésével a programozók közvetlen visszajelzést kapnak arról, hogy milyen állapotban van a rendszer egy-egy módosítás után.
• Visszajelzés az ügyféltől: a funkcionális teszteket a programozók együtt készítik az ügyféllel, így mindketten konkrét visszajelzést kapnak arról, hogy milyen állapotban van a rendszer funkcionalitása. Ilyenfajta közös tesztelést 2-3 hetente célszerű végezni, így az ügyfélnek megvan a lehetősége a fejlesztés irányítására.
• Visszajelzés a csapattól: amikor az ügyfél új igényekkel áll elő, a csapat rögtön tud rá reagálni, és visszajelzést tud adni, hogy mennyi ideig fog tartani a dolog, és mennyibe fog kerülni.

A visszajelzés szorosan összefügg az egyszerűséggel és a kommunikációval. A rendszerhibákat könnyű jelenteni, hiszen egy részegység-teszt megírása simán megmutatja, hogy mi nem jó a rendszerben, így a rendszer maga mutatja meg a javításra szoruló részeket. Az ügyfél is rendszeresen tudja tesztelni a rendszert, a saját igényeinek megfelelően, amiket az XP-ben 'felhasználói történet'-nek hívnak. Hogy Kent Becket idézzük, 'Az optimizmus szakmai ártalom a programozóknál, és a visszajelzés rá a gyógyír.'

Bátorság

Az XP bátorságra buzdító doktrínáját a legjobban gyakorlati példákkal lehet megvilágítani. Az egyik, hogy mindig a mai igények kielégítésére kell a programot tervezni és megírni. Ez az erőfeszítés azért szükséges, hogy ne gabalyodjunk bele a tervezésbe, és nehezítsük meg saját magunknak a hosszútávú munkát. (Értelemszerűen a 'mai igények' az összes olyan igényt jelentik, amiket ma ismerünk.) Bátorság kell ahhoz is, hogy ne ijedjünk meg attól, hogy a kódot folyton át kell dolgozni. Az átdolgozás azt jelenti, hogy átnézzük a kódot, és olyan változtatásokat eszközölünk rajta, amik egyszerűbbé és átláthatóbbá teszik. Bátorság kell ahhoz is, hogy eldobjunk már megírt kódot. Ahhoz is kell bátorság, hogy felismerd, hogy nincs tovább értelme körbe-körbe járni egy adott problémán, mert valószínűleg ha másnap visszajössz és újrakezded, egy perc alatt meglesz a megoldás, csak ki kell zökkennie az agyadnak a rossz kerékvágásból.

Tisztelet

Az XP-ben a tiszteletnek is többféle aspektusa van. Tiszteljük a többi csapattagot, mert dacára a folyamatos változásoknak és integrációnak, sosem csekkelünk be olyan kódot, ami nem fordul le, vagy hibás abban az értelemben, hogy a részegység-teszt elhasal rajta. Úgy általában semmit nem teszünk, ami a többiek munkáját hátráltatja. Magunkat is tiszteljük annyira, hogy csak jó minőségű munkát adunk ki a kezünk közül, és mindig a legjobb tervet igyekszünk kitalálni, és az átdolgozásokat is lehető legjobban megtervezni.

Elvek

Az elvek, amelyek az XP alapját képezik, következnek a fent leírt értékekből, és arra valók, hogy segítsenek döntéseket meghozni. Az elvek konkrétabbak, mint az értékek, és jobban használhatók iránytűként konkrét helyzetekben.

Gyors visszajelzés

A visszajelzés akkor a leghasznosabb, ha hamar megérkezik. A konkrét esemény és a róla érkező visszajelzés között eltelt idő kritikus fontosságú a tanulság levonásának és az esetleges változtatások tekintetében. Az XP-ben, a hagyományos módszertanokkal ellentétben, az ügyféllel való kapcsolattartás sok pici esetben fordul elő, hogy az ügyfélnek tiszta képe legyen arról, hogy mi történik a fejlesztésben. Így a visszajelzései alapján lehet a projektet irányítgatni.
A részegység-tesztek is fontosak a gyors visszajelzés érdekében. Amikor az ember a kódot írja, a részegység-teszt a leggyorsabb közvetlen visszajelzés arra, hogy milyen hatása lett az új kódnak. Továbbá, ha a változás olyan funkcionalitást érint, ami nincs a programozó látóterében, és álmában sem gondolja, hogy arra hatása lehet az ő kódjának, a részegység-tesztek ezeket is észre fogja venni, és a bug nem akkor derül ki, amikor a rendszer már élesben üzemel.

Inkrementális változtatások

Az XP fáklyavivői azt mondják, hogy Rómát sem egy nap alatt építették. Nem lehet egyszerre nagy változtatásokat csinálni egy rendszeren. Az XP fokozatos változtatásokat javasol. Megeshet, hogy ettől egy rendszernek három hetente lesz új kiadása, mindig csak apró változásokkal. A sok kis lépéssel az ügyfél is jobban látja, hogy merre halad a projekt.

Örömmel fogadott változások

Tuti, hogy semmi sem tuti. Ez az elv azt mondja ki, hogy nem elég, hogy ne tegyünk semmit a változások ellen, pont ellenkezőleg, örüljünk nekik. Ha az egyik szokásos napi találkozó során kiderül, hogy az ügyfél igényei drámaian megváltoztak, akkor a programozók örüljenek neki, és kezdjék el tervezgetni az új iterációhoz szükséges terveket.

Tevékenységek

Az XP-ben alapvetően négyféle tevékenység van.

Kódolás

Az XP már emlegetett fáklyavivői szerint a rendszerfejlesztés egyetlen igazán hasznos végterméke a kód, bár a 'kód' kifejezést szélesebb értelemben használják, mint a hagyományos szemlélet hívei. Kódolás nélkül nincs semmi.

A kódolás jelentheti diagramok megrajzolását is, amikből aztán program lesz, vagy scriptek írását egy webalapú rendszerhez, vagy egy C#-ban készülő objektum megírását, amit majd aztán le kell fordítani.

A kódolás néha ahhoz is kell, hogy a legjobb megoldást megtaláljuk. Az XP szerint előfordulhat az, hogy ha egy problémának több, látszólag ugyanolyan jó megoldása van, akkor mindet meg kell írni, és automatizált tesztekkel kell eldönteni, melyik a legjobb.

A kódolás az egyik eszköz a gondolatok kifejezésére, konkrétan a programozási problémákról keletkező gondolatok kifejezésére. Egy programozó, aki egy bonyolult programozási problémával küszködik, lehet, hogy nem tudja elmagyarázni rendesen a megoldás lényegét a kollégáinak, de meg tudja írni, és meg tudja nekik mutatni a kész kódot. (Adott esetben ez lehet akár pszeudokód is.) A kód, mondják eme álláspont hívei, mindig tiszta és egyértelmű, és nem lehet többféleképpen értelmezni, csak úgy, ahogy a számítógép. A többi programozó pedig úgy fejezheti ki a véleményét a témával kapcsolatban, hogy beleírnak a kódba, vagy hozzátesznek.

Tesztelés

Semmiben sem lehetsz biztos, amíg nem próbáltad ki. A tesztelés általában nem az ügyfél kérése, sőt nem is jól felfogott érdeke. Rengeteg szoftvert adnak ki rendes tesztelés nélkül, ami működik, többé-kevésbé. Az XP azt mondja, hogy nem lehetsz biztos a kódod működőképességében, amíg alaposan ki nem próbáltad. Ez felveti azt a kérdést, hogy pontosan mi is az, amiben nem lehetsz biztos.

• Nem biztos, hogy azt kódoltad le, amire gondoltál. Ennek a bizonytalanságnak az eloszlatására vannak a részegység-tesztek. Ezek automatizált tesztek, amik a kódot tesztelik. A programozónak annyi tesztet kell írnia, amennyit csak tud, hogy lehetőleg minden ágát letesztelje a kódnak. Ha minden teszt sikeresen lefut, akkor a kódolás készen van.
• Nem biztos, hogy amire gondoltál, az tényleg az, amit az ügyfél akar. Ezért kellenek az elfogadási tesztek, amiket az ügyféllel kell elvégezni, a release-tervezés felfedező fázisában.

Meghallgatás

A programozók nem feltétlenül tudnak az üzleti oldaláról annak a projektnek, amin dolgoznak, noha a rendszerrel támasztott követelményeknek az üzleti oldalról kell érkezniük. Annak érdekében, hogy a programozók megértsék, hogy mire akarják a programjukat használni, meg kell hallgatniuk az üzleti oldal mondanivalóját is. Azt kell belőle meghallaniuk, hogy mire van szüksége az ügyfélnek. Ezenfelül jó, ha azt is megértik, hogy miért van rá szüksége az ügyfélnek, hogy visszajelzést tudjanak adni az ügyfélnek a saját problémájáról, és ezáltal ő maga is jobban értse, hogy mi kell neki.

Az ügyfél és a programozók közötti kommunikáció a Tervezési Játékban van kifejtve, amit az XP leendő és újdonsült hívei a vonatkozó szakirodalomban találnak kifejtve.

Tervezés

Csupán az egyszerűséget véve alapul, mondhatnánk, hogy a rendszert nem is kell tervezni, elég, ha kódolunk, tesztelünk, és odafigyelünk az ügyfélre. Ha ezeket jól csináljuk, a végeredmény egy tutira működő rendszer lesz. A gyakorlatban ez nagyon nincs így. Messzire el lehet jutni tervezés nélkül, de a végén biztos, hogy zsákutcába fogsz kerülni. A rendszer túl bonyolulttá válik, és a belső függőségek átláthatatlanná válnak.

Ezt úgy lehet elkerülni, hogy logikus részekre kell a rendszert bontani. Ha logikus, és jól elkülönülő részekre sikerül a rendszert szétszedni, akkor a függőségek nem fognak gondot okozni, vagyis a rendszer egy részének megváltoztatása nem teszi tönkre a rendszert, és az egyes részegységek bonyolultsága sosem fogja túllépni a kritikus küszöböt.

Gyakorlat

Ezt részletesebben nem fejtjük itt ki, mert komplett könyvek szólnak róla, de alapvetően 12 gyakorlati módszer van, 4 csoportra osztva:

Visszajelzés részletezve:

• Párban programozás
• Tervezési Játék
• Tesztelésen Alapuló Fejlesztés
• Egész Csapat

Folyamatos feldolgozás

• Folyamatos integráció
• Tervek fejlesztése
• Kicsi release-ek

Közös nézőpont

• Kódolási Szabvány
• Közös Tulajdonú Kód
• Egyszerű terv
• Rendszer-metafora

Programozói jólét

• Fenntartható tempó

Az XP ellentmondásos részei

• A legellentmondásosabb, legproblémásabb része a dolognak a változás-menedzsment. Mivel az ügyfél közvetlenül kommunikál a programozókkal, leginkább szóban, így két rossz dolog történhet. Az egyik, hogy az összevissza csapongó változásai költséges átdolgozásokhoz vezetnek, a másik az ún. 'becsúszó featuritis', vagyis hogy az ügyfél szép lassan egyre többet és többet követel. Az XP azért nem szereti lepapírozni az ügyfél kéréseit, mert azt mondják, hogy ez a rugalmasság kárára megy, és az esetek túlnyomó részében tovább tart a papírozás, mint maga a munka. (Ennek elkerülésére mi anno vagy az ügyféllel papíroztattuk le a kérést, vagy volt valaki, akinek az adott időben nem volt más dolga, mint papírozni - a ford.)
• Nincsenek követelmény-listák, és specifikációk, tehát nehéz számonkérni bármit is. Értelemszerűen ennek következményeként olyankor érdemes XP-t használni, amikor vagy eleve szóba sem kerül a számonkérés, mert pl. belső az ügyfél, vagy olyankor, amikor az elszámolásnak kizárólag az eltöltött idő az alapja, és lehet hülye a t. ügyfél, csak fizesse ki.
• Nincs Központi Nagy Terv, ergo megeshet, hogy egy húzósabb változás teljes újratervezéssel jár. Ebből következik az, hogy csak rutinos programozóknak való, mert minél rutinosabb egy programozó, annál nagyobb változás fog kelleni ahhoz, hogy tényleg totál újra kelljen tervezni mindent. Ha meg kiderül, hogy nem krumplipucológép, hanem űrrakéta, akkor naná, hogy újra kell mindent tervezni.
• Az ügyfél képviselője szerves része a projektnek. Ezt sokaknak stresszt okoz, hiszen minden hiba és tévedés azonnal nyilvánvaló az ügyfél számára is. Ugyanakkor ha az ügyfél képviselője rosszul végzi a munkáját, akkor azon az egész projekt megbukhat. Ugyanakkor ha az ügyfél nincs jelen, általában mégis mindenki azt kívánja, hogy bárcsak jelen lenne...
• 2003-ban megjelent egy könyv, amelyik mindenféle javításokat javasolt az XP-be. A vita arról, hogy mi jó ebből, és mi nem, a mai napig folyik a net mindenféle zugában. A könyv központi gondolata az, hogy az XP elemei függenek egymástól, de igen kevés olyan projekt van, ami egyszerre az összes elemet át tudná venni, viszont ha nem veszi át valaki az összes elemet, akkor nem ér semmit az egész. Egy másik gondolat a könyvből, hogy a 'kollektív tulajdon' fogalma már a szocializmusban is ismert volt, és inkább az lett belőle, hogy ami mindenkié, az tutira nem az enyém, tehát hagyjanak vele békén. A vitából valami olyasmi szűrődik ki, hogy az XP elemei között valóban van egy függőségi fa, és valóban vannak kulcsfontosságú elemek, amelyek hiánya összeomláshoz vezet, de ez minden módszertanra igaz, és ahol valamelyik ilyen kulcsfontosságú elem hiányzik, ott általában már az elején látszik, hogy nem jó ötlet XP-vel próbálkozni. Azt meg soha senki nem mondta, hogy ez csodaszer minden problémára. Az XP ezenfelül nem sokmilliós társadalmakra, hanem viszonylag kis létszámú fejlesztőcsoportokra lett kitalálva, és a közös tulajdon gondolata ilyen léptékben még működhet, ha a motiváció megvan hozzá, az viszont már nem az XP feladata, hogy motiváljon.