Történetek Esettanulmány: Egy Fortune 100-as pénzügyi cég
XP coaching 300+ Fortune 100-es csapatnál
Két év, nagyjából 1 000 coacholt ember, és körülbelül 10%-kal jobb átfutási idő (lead time) és hibás változtatások aránya (change failure rate)
Írta: Fejér Attila Megjelent:
Egy Fortune 100-as pénzügyi cég azt szerette volna, ha minden fejlesztőcsapata úgy dolgozik, ahogy a legjobb csapatai már dolgoztak: Scrum helyett extreme programminggal (XP). A program több mint két évig futott, és a cég több ezer fejlesztőjének nagyjából a felét érte el. Ezek körülbelül felében én voltam a coach, így mintegy 300 csapatból nagyjából 1 000 emberrel dolgoztam: két hétig tanteremben, hat hétig pedig a mindennapi munkájuk mellett.
Az első hat hónap után a programban részt vevő csapatok átfutási ideje (lead time) és a hibás változtatások aránya (change failure rate) nagyjából 10%-kal javult. Ami megmaradt: hatékonyabb standupok, retrospektívek és párban programozás.
- Lépték
- 600+ csapat és több ezer fejlesztő a teljes programban, ebből 300+ csapattal és nagyjából 1 000 emberrel én dolgoztam
- Időtartam
- 2024 májusától 2026 augusztusáig
- Hat hónap utáni eredmény
- nagyjából 10%-kal jobb átfutási idő és hibás változtatások aránya
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.
Amit tettünk
- 1
Két hét tanteremben, egyszerre fél csapattal
Minden csapat két hullámban érkezett, így minden csapat fele mindig elérhető maradt a hibajavításokhoz és a beérkező kérésekhez. A fejlesztők és a product managerek ugyanabban a teremben ültek, és ugyanazt az anyagot vették át: egészséges backlog, jó user story-k, elfogadási kritériumok Gherkinben, ceremóniák, párban programozás, TDD, refaktorálás és legacy kód. Kezdetben diasorokból tanítottunk, végül Mural-táblára írt cetliknél és beszélgetéseknél kötöttünk ki, mert ezek hatékonyabbnak bizonyultak.
- 2
Hat hét a csapatok mellett
A tanterem után a coachok hat hétre beültek a csapatokhoz. Figyeltük, hogyan dolgoznak, folyamatosan visszajelzést adtunk, és kijavítottuk, ami félrement, mielőtt szokássá vált volna. Mindent a saját backlogjukhoz és termékükhöz igazítottunk. Én két régióért feleltem, így ebben a szakaszban más emberekkel is találkoztam, mint a tanteremben.
- 3
Módszertan a technológia helyett
A program nem a miénk volt, hanem egy másik cégé. Én tartottam a képzéseket, és a program fejlesztéséért is feleltem. A legnagyobb változás, amelyet javasoltam (és el is fogadtak): ne technológiát tanítsunk, hanem módszertant és szemléletet. Egy mocking library használatát bárki megtanulja. A TDD-t rendesen csinálni viszont csak segítséggel lehet megtanulni. Többek között felvettem teljes TDD- és refaktorálási demókat, amelyeket mindenki a saját idejében nézhetett meg, és a tesztpiramist is beépítettem a tananyagba. Így a tantermi órák felszabadultak a gyakorlásra.
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.
További történetek
Minden esettanulmány Minden történet
Továbbiak fejlesztőcsapatoknak
Korábbi munka 2026
Feltétel nélkül
Feature flagek interfészként és osztályként, hogy a hívás helyén látszódjon, mit csinál a kód, a többit pedig a fordító ellenőrizze
Miért kezdtem el fejleszteni a FlagZent, egy nyílt forráskódú dispatch réteget Java feature flagekhez: mi a szétszórt feltételek ára, mit ellenőrizhet helyettük a fordító, és hol tart ma a projekt.
ElolvasomKorábbi munka 2020–2022
Kerékcsere menet közben
Egy több tíz terabájtot archiváló monolit migrálása microservice architektúrára, miközben a rendszer zavartalanul üzemelt
Hogyan került át egy több tíz terabájtnyi érzékeny adatot archiváló és kereső rendszer egy monolitból és egy asztali kliensből microservice-ekre, az egész rendszer egy lépésben való újraírása nélkül: a sorrend, a számok, és hogy mikor csinálnám újra így.
ElolvasomKorábbi munka 2017–2019
Oszd meg és cache-elj
Egy kezdőoldal, amely 300 felhasználónál 10 másodperc alatt töltődött be, majd egy lekérdezés négyre bontása után 2000 felhasználónál 20 ms alatt
Közvetlenül egy közszféra-platform első élesítése előtt a kezdőoldal nem bírta a terhelést. Hogyan találtuk meg a profilozással az okot, miért nem segített az indexelés, és mi lett a megoldás.
ElolvasomMely szokások maradnának meg az Önök csapataiban?
Egy rövid beszélgetés arról, hogyan dolgoznak ma. Javaslattal távoznak arról, hol érdemes kezdeni.