300 csapat, XP és a szokás, amely megmaradt

A kihívás

Néhány évvel korábban a cég a csapatai egy részénél már végigvitt egy XP-átállást. Ezek a csapatok lettek a cég legjobban teljesítő csapatai, ezért a cég mindenkinél meg akarta ismételni. Ez több ezer fejlesztőt jelentett, több kontinensen szétszórva, és mindannyian tanulás közben is folyamatosan dolgoztak a termékükön.

A csapatok, akikkel találkoztam, iparági szempontból átlagosak voltak. A standupok hosszúak és fejetlenek voltak, mindenről szóltak, csak a fontos dolgokról nem. Valódi tesztelés alig volt, TDD és párban programozás egyáltalán nem. A backlogot nem lehetett sem becsülni, sem priorizálni, a user story-kat soha nem írták meg rendesen. Minden nap megtették, ami tőlük telt, de bőven volt hová fejlődni.

Az egyik csapatnak nagyjából ezersoros tesztmetódusai voltak. A fejlesztőkörnyezet generálta őket, a nevük pedig a tesztelt metódus nevéből, egy időbélyegből és annak a nevéből állt, aki a generálást futtatta. Senki nem értette őket, ezért senki nem is tartotta karban őket, és ha valamelyik eltört, a csapatnak fogalma sem volt, miért. A tesztek egy code coverage-küszöb miatt léteztek, de igazából csak haszontalan zajt jelentettek.

Mi változott

A szervezet DORA-mutatókkal mérte a csapatokat. Nagyjából hat hónap után a programon átesett csapatoknál körülbelül 10%-kal jobb átfutási időt (lead time) és hibás változtatások arányát (change failure rate) mért.

A retrospektív az a ceremónia, amelyet a legtöbb csapat elsőként hagy el, mert nem látja az értelmét. Ezek a csapatok elkezdték hetente megtartani, amihez ragaszkodtak is, mert megértették, hogy itt lehet megtalálni a fejlődési lehetőségeket. A legtöbb csapat a párban programozást is megtartotta a munka természetes részeként, bár nem a napjai nagyobb részében. A TDD maradt a legnehezebben átvehető szokás, mert fegyelmet és gyakorlást igényel, hat hét pedig ehhez nem elég.

És az ezersoros tesztek? Az egyiket közösen refaktoráltuk. A végén a csapatot vezető mérnök boldogon kiáltott fel: „Végre értem, mit csinál ez a teszt!”

Amit tanultunk belőle

Két hétig napi nyolc óra tanterem túl sok. Ennyit az emberek nem tudnak megjegyezni, a párban programozás pedig hat hét alatt nem válik szokássá. Máshol már láttam működni egy másik módszert: heti két-három óra egy coach vezetésével, az elmélet kis adagokban, sok gyakorlás (az alkalmak között is), és párban programozás minden feladaton az első lépésektől. A gyakorlóprogramunk, a Judgment Dojo is így működik.

Ugyanez érvényes az AI által írt kódra. Egy kódgenerátor, amelynek a kimenetét nem értjük, semmiben nem különbözik egy AI-tól, amelynek a kimenetét nem értjük: lehet, hogy működik, és nem tudjuk, miért, és lehet, hogy nem működik, és azt sem tudjuk, miért. A megértéshez szilárd alapkészségek és mérnöki ítélőképesség kell. Amikor az ezersoros tesztek csapata elsajátította ezeket, a minőség is javult, és vele a sebesség is.

Az ügyfél nevét nem közöljük, és annak a cégnek a nevét sem, amelyé a program volt. Egy beszélgetés során többet is el tudok mondani arról, mit és hogyan csináltunk.