Miért gondoljuk, hogy a senior fejlesztőknek nem frissítési rutinnal kellene tölteniük az idejüket

Néhány évvel ezelőtt ezt a kérdést valószínűleg mi magunk is másképp válaszoltuk volna meg.

Egy összetett TYPO3-frissítéshez természetesen tapasztalt fejlesztőkre van szükség. Aki már modernizált egy sok éven át növekvő enterprise platformot, tudja, hogy közben folyamatosan olyan technikai döntéseket kell hozni, amelyek sem nem automatizálhatók, sem nem foglalhatók teljesen egy ellenőrzőlistába.

Ma ezt az állítást mégis kiegészítenénk.

Egy frissítési projekten belül nem minden feladat igényli ugyanazt a fajta tapasztalatot.

És megítélésünk szerint éppen ez a megkülönböztetés változtatja meg azt, ahogyan az ügynökségeknek a nagyobb modernizációs projekteket szervezniük kellene.

A tapasztalat ott a legértékesebb, ahol a döntések születnek

Amikor ügynökségekkel dolgozunk együtt, gyakran nagyon erős fejlesztőcsapatokkal találkozunk. Sokan rendelkeznek tapasztalt TYPO3-architektekkel, senior fejlesztőkkel és technical leadekkel, akik évek óta kísérik ügyfeleiket, és részleteiben ismerik azok üzleti folyamatait.

Éppen ezek a fejlesztők gyakran a legfontosabb oka annak, hogy egy projekt hosszú távon sikeres.

• Architektúrákat terveznek.
• Ügyfeleket tanácsolnak.
• Új követelményeket vitatnak meg.
• Döntéseket hoznak a jövőbeli bővítésekről.
• A technikai kockázatokat gyakran már jóval azelőtt felismerik, hogy láthatóvá válnának.

Mindezek a feladatok közvetlen értéket teremtenek.

Egy enterprise frissítés azonban nem kizárólag ilyen tevékenységekből áll.

Egy nagyobb migrációs projekt jelentős része olyan munkából áll, amely ugyan nagy technikai gondosságot igényel, lefolyása mégis meglepően hasonlóan alakul sok projekten keresztül.

Számunkra pontosan itt kezdődik a tulajdonképpeni vita.

Egy frissítés nagyon különböző feladatokból áll

Kívülről nézve egy TYPO3-frissítés gyakran egyetlen technikai feladatnak tűnik.

A gyakorlatban azonban inkább nagyon különböző diszciplínák gyűjteménye.

Mindenekelőtt ott vannak a tulajdonképpeni architekturális döntések.

• Melyik célverziót érdemes hosszú távon üzemeltetni?
• Mely extensionök maradnak meg?
• Melyeket váltjuk le?
• Hogyan változik a rendszerarchitektúra?
• Mely üzleti logikát kellene modernizálni?

Ezek a kérdések nem szabványosíthatók.

Tapasztalatot, technikai megértést és gyakran az ügyféllel folytatott intenzív beszélgetéseket is igényelnek.

Emellett azonban létezik egy második terület is.

• A kódot migrálni kell.
• Az upgrade wizardokat elő kell készíteni.
• A deployment-folyamatokat reprodukálhatóan kell felépíteni.
• Regressziós teszteket kell végrehajtani.
• Ismert migrációs minták újra felbukkannak.

E feladatok közül sok korántsem triviális.

Alapvetően azonban különböznek az architekturális munkától.

Minél gyakrabban kísér egy csapat ilyen projekteket, annál inkább szabványosíthatók és rendszerezhetők éppen ezek a területek.

A specializáció megváltoztatja a gazdaságosságot

Képzeljünk el két ügynökséget.

Az első egyedi TYPO3-projekteket fejleszt, digitalizációs kezdeményezéseket kísér, új funkciókat fejleszt, és időnként nagyobb frissítéseket hajt végre.

A második szinte kizárólag TYPO3-frissítésekre összpontosít, és több migrációt kísér párhuzamosan.

Mindkettő kiváló fejlesztőket foglalkoztat.

Néhány év múlva kompetenciáik mégis különbözni fognak.

Nem azért, mert a fejlesztők eltérően tehetségesek, hanem mert a specializáció elkerülhetetlenül megváltoztatja a folyamatot.

Egy csapat, amely minden héten frissítési projekteket kísér, egy idő után már nem csupán problémákat old meg.

Elkezdi felismerni a mintázatokat.

• Mely deprecationök fordulnak elő rendszeresen?
• Mely bővítmények okozzák újra és újra ugyanazokat a nehézségeket?
• Mely tesztesetek hiányoznak szinte minden projektből?
• Mely deployment-lépések szabványosíthatók?

Ezekből a megfigyelésekből eszközök születnek.

• Ellenőrzőlisták.
• Automatizálás.
• Belső tudásbázisok.
• Saját Rector-szabályok.

És pontosan ettől változik meg a jövőbeli projektek gazdaságossága.

Miért nem hisszük, hogy a tapasztalat önmagában elegendő

Egyszerű lenne azt állítani, hogy a tapasztalt fejlesztők automatikusan jobb frissítéseket hajtanak végre.

Tapasztalataink azonban azt mutatják, hogy a tapasztalat önmagában nem skálázódik.

Ha egy projekt azért sikeres, mert egyetlen senior fejlesztő száz apró részletre emlékszik, akkor a vállalat ugyan kiváló munkatárssal rendelkezik, de még nem reprodukálható folyamattal.

Éppen ezért igyekszünk az egyes projektekből származó visszatérő felismeréseket minél nagyobb arányban tartósan beépíteni a munkamódszerünkbe.

Belső frissítési ellenőrzőlistánk erre jó példa.

Nem egy whiteboard mellett keletkezett, hanem sok projektből.

Minden további ellenőrzési lépés azért létezik, mert egyszer pontosan azon a ponton felmerült egy probléma.

Ugyanez vonatkozik a tudásbázisunkra, a deployment-szkriptjeinkre vagy a Legacy Updaterre.

Mindegyik ugyanazt a célt követi.

A tapasztalat ne maradjon kizárólag az egyes fejlesztők fejében. Az engineering-folyamat részévé kell válnia.

Mit nyernek ezzel az ügynökségek

Amikor ügynökségekkel dolgozunk együtt, ezért nem tekintjük magunkat a fejlesztőik pótlékának.

Ennek aligha lenne értelme.

Azok az emberek, akik évek óta kísérik az ügyfelet, sokkal jobban ismerik annak igényeit, mint mi.

Célunk sokkal inkább az, hogy ezeket a fejlesztőket ott tehermentesítsük, ahol a specializáció a legnagyobb különbséget jelenti.

Miközben csapatunk a tulajdonképpeni frissítési folyamatra összpontosít, az architektek és a technical leadek továbbra is azokkal a témákkal foglalkozhatnak, amelyeknél tudásuk a legnagyobb hatással van a projekt sikerére.

• Új funkciók.
• Architekturális döntések.
• Workshopok.
• Tanácsadás.
• A platform stratégiai továbbfejlesztése.

Megítélésünk szerint pontosan itt keletkezik egy white-label együttműködés tulajdonképpeni értéke.

Nem azáltal, hogy feladatokat szervezünk ki, hanem azáltal, hogy mindkét csapat azt teszi, amiben a legnagyobb hozzájárulást nyújthatja.

Miért nincs ennek köze a sebességhez

Olykor az a benyomás keletkezik, hogy a specializáció elsősorban a sebesség kérdése.

A projektek természetesen gyakran profitálnak abból, ha egy csapat rendszeresen hasonló feladatokon dolgozik.

A tulajdonképpeni cél azonban más.

Csökkenteni szeretnénk a bizonytalanságot.

Minél több visszatérő feladat szabványosított, annál jobban becsülhető a ráfordítás, a minőség és a kockázatok.

Éppen ezért fektetünk annyi időt a folyamatokba, eszközökbe és belső szabványokba.

Nem azért, mert látványosak lennének, hanem mert gondoskodnak arról, hogy fejlesztőink arra a kevés feladatra összpontosíthassanak, amelyek éppen hogy nem szabványosíthatók.

A tapasztalt fejlesztők tulajdonképpeni feladata

Amikor ma visszatekintünk a nagyobb enterprise frissítésekre, újra és újra feltűnik, hogy a legnehezebb döntések ritkán voltak technikai jellegűek.

Nem arról volt szó, melyik API-t kell lecserélni vagy melyik extensiont kell frissíteni.

A tulajdonképpeni kihívások szinte mindig ott rejlettek, ahol a technikai lehetőségek és az üzleti követelmények találkoztak.

• Megmaradjon-e egy meglévő funkció, jóllehet az egy aktuális third-party extensionben már nem létezik?
• Megéri-e hosszú távon egy egyedi bővítés?
• Egyáltalán van-e még ma értelme egy adott folyamatnak?

Megítélésünk szerint éppen ott keletkezik a tapasztalt fejlesztők legnagyobb értéke.

Nem az ismert migrációs lépések ismételt elvégzésében, hanem az olyan döntésekben, amelyek egy platform jövőbeli jellegét meghatározzák.

Mit tanultunk ebből

Talán ezért az elmúlt évek legfontosabb felismerése nem az, hogy a TYPO3-frissítések speciális tudást igényelnek.

Ezt kétségtelenül igénylik.

A tulajdonképpeni felismerés sokkal inkább az, hogy ez a speciális tudás nagyon eltérően használható fel.

Egy része az architekturális döntésekbe tartozik. Egy része az ügyfelekkel folytatott beszélgetésekbe tartozik. Egy meglepően nagy része pedig sok projekt során folyamatokba, eszközökbe és közös szabványokba vihető át.

Ma pontosan ott látjuk a specializáció tulajdonképpeni értékét.

Nem abban, hogy egy csapat gyorsabban programoz, hanem abban, hogy minden befejezett projekttel az egész engineering-folyamatot javítja.

Mert a végén nemcsak a jövőbeli frissítési projektek profitálnak ebből.

Mindenekelőtt azok a fejlesztők profitálnak, akiknek az ideje újra felszabadul azokra a feladatokra, amelyeknél a tapasztalat valóban a legnagyobb különbséget jelenti.