Avagy mit tegyen a szoftverfejlesztő csapat, ha túl sikeresek és túl nagyra nőttek?

Avagy mit tegyen a szoftverfejlesztő csapat, ha túl sikeresek és túl nagyra nőttek?

Korábban már írtam a fejlesztés és a támogatás szétválasztásáról. Akkor kiderült, hogy több módszer is létezik, és mindenki kiválaszthatja a neki tetszőt. Most ugyanez a téma, de a megközelítés más: mit tegyen egy fejlesztő csapat, ha túl nagyra nőttek, és szükségessé válik a támogatási tevékenység leválasztása?

Alap-probléma a következő:

Kezdetben a szoftvert egy adott célra, (tipikusan) egy adott ügyfél számára fejlesztjük, egy maroknyi kis létszámú programozó segítségével. Ez így igen hatékony és dinamikus fejlesztést tesz lehetővé (tipikus kkv felállás).

Aztán jön a sikeres telepítés, a pénz felmarkolása, és a szoftver élete új szakaszába ért: támogatni kell. Itt rögtön szétválik az éles rendszer, a tesztelési környezet és a fejlesztési környezet.

Az ügyfélnek természetesen további fejlesztéseket kell végezni, sőt egyre többet, a kezdeti egy projekt helyett több projekt fut párhuzamosan – miközben hibákat is javítani kell.

A képet tovább bonyolítja, hogy a jól működő szoftvert sikerült további ügyfeleknek eladni, tehát nem csak fejlesztési hanem testreszabási projektek is futnak, illetve a kód szétválik „A ügyfél”, „B ügyfél” és „C ügyfél” kódbázisra.

Mit tegyen az informatikai vezető, hogy ezt a káoszt az irányítása alatt tartsa?

A munkaszervezés alapja egy jó forráskód-kezelő rendszer, ami képes kódbázisokat és verziókat követni, képes legyen a check-out és check-in funkciókra, az egyes verziók közötti másolásra, release-ek követésére. A code merge csak hab a tortán.

Kell a forráskód-kezelés, ugyanis több forráskódunk lesz!

Fejlesztési, illetve teszt környezetből is többet kell kialakítani.

Szükség van minden egyes ügyfélnek egy fejlesztési környezetre (ahol a fejlesztés zajlik), egy teszt környezetre (ahol a tesztelés zajlik), egy elfogadási környezetre (ahol a UAT zajlik). Nem árt, ha van az éles rendszerről egy másolat (ha az éles rendszerhez nincs hozzáférésünk).

Mivel a fejlesztés zajlik (új funkciók hozzáadása), ezért ahhoz is szükséges egy dev, teszt és UAT környezet.

A kódbázisok kezelésére az a legjobb módszer, ha az egyes ügyfelek számára testre szabott szoftver konfigurációban tér el, tehát a forráskód maga ugyanaz. Vagyis az egyik esetben van egy „CUSTOMER=A” flag valahol a fordítási instrukciók között, ezért a kód „A ügyfélre” fordul. A „B ügyfél” esetén ugyanaz a kód, csak „CUSTOMER=B” beállítás szerepel.

Az biztos, hogy az összes ügyfélt nem lehet ugyanazon a verzión tartani, ezért szükség lesz a különböző verziók párhuzamos vezetése. Például tegyük fel, hogy „A ügyfél” a szoftver 2.1-es verzióját kapta meg, „B ügyfél” a 2.2-est, „C” pedig a 2.3-ast. Eközben a fejlesztés maga gőzerővel halad a 2.4-es verzióval

Az átláthatóság kedvéért itt egy táblázat a különböző környezetekről:

Látható, hogy a „C ügyfél” esetén nem történt hibajavítás, az ügyfél a legfrissebb kódot használja.

Az új fejlesztés folyamatban van, még nem érte el azt a stádiumot, hogy a funkciókat validálni lehetne.

Az „A ügyfél” és „B ügyfél” esetén már történtek hibajavítások, amiket egyenlőre még nem telepítettek az ügyfélnél az éles környezetbe.

A „Következő verzió” még csak tervezett és csak a rajzasztalon létezik. Ide futnak be az új igények.

Ezen felül szükség van egy hibakezelő / ticketing rendszerre, ahol a hibabejelentéseket és fejlesztési igényeket lehet gyűjteni, azonosítani és összegezni. Fontos kitétel, hogy a ticket-ek egyedileg azonosíthatóak legyenek (számmal), a ticket összes története látható legyen, illetve a ticket összekapcsolható legyen (a hivatkozási számon keresztül) a kódváltoztatással.

Tegyük fel, hogy „B” ügyfél bejelent egy hibát!

A hibára generálódik egy ticket, mondjuk 12345

Ekkor a fejlesztő megpróbálja a hibát a 2.2.11-es környezetben reprodukálni. Ha ez sikerül, akkor megkeresi a hiba okát a fejlesztő környezetben (2.2.13) és azt kijavítja. A javításhoz beírja nevét, a ticket számát, illetve jelzi hogy a módosítás hibajavítás miatt történt.

A javítással létrehoz egy új verziót (2.2.14), amit kirak a teszt környezetbe, ahol a tesztelők ellenőrzik a javítást, majd egy adott ponton átkerül a UAT-be. Ezzel párhuzamosan a fejlesztő átnézi a többi verziót (A ügyfél 2.1.11, C ügyfél 2.3.8, és új fejlesztés 2.4.0) hogy a hiba ott is fennáll-e. Ha igen, akkor azokat is javítja, így létrehozva 2.1.12 és 2.3.9-es verziókat – amiket majd a tesztelők tesztelnek, lesz UAT, stb.

Vagyis egy programhibát nem egy helyen kell kijavítani, hanem több helyen.

Hogyan történik a release?

Habár IT-n belül létezik a „release every day” koncepció, de az ügyfelek nagyon nem szokták ezt szeretni. Release csak ritkán van, azt is előre egyeztetik a különböző üzleti, üzletági vezetőkkel. Lehet, hogy havonta van release, azt is lehet hogy évente 3-szor. A lényeg az, hogy a változtatások összegyűlnek egy csomagba (package), és a release alkalmával egyszerre kerülnek átadásra. (Addig a ticket státusza valami olyasmi, hogy kijavítva + telepítésre vár.)

A release-zel a ticket státusza lezárul, hiszen a javítás át lett adva. (Most feltételezem, hogy nem lép fel semmilyen komplikáció)

Tegyük fel, hogy „B” ügyfél bejelent egy új fejlesztési igényt!

A fejlesztési igény priorizálásra kerül. Üzleti, üzletpolitikai döntés, hogy melyik verzióban kerül megvalósításra. Alapvetően az új igények a következő verzióba (2.5) kerülnek. Ha sürgős, akkor bele lehet nyomni az aktuális fejlesztésbe (2.4). Ha pedig égetően fontos (mondjuk törvényi változás, pl ÁFA változás január 1-től), akkor az a hibajavítás mintájára belekerülhet a 2.2.13-as verzióba (lásd hibajavítási folyamat) – viszont akkor duplán kell dolgozni, hiszen a 2.4-esben is újra kell fejleszteni ugyanazt.

Hogyan zajlik a fejlesztés?

A fejlesztők nagy része az új verzión (2.4) dolgozik. Üzleti szinten már létezik egy terv, hogy az új verzióba milyen új funkciókat kell beépíteni (scope vagy done kritérium) és ezt fejlesztik.

Mi a sales szerepe?

Az értékesítés a tervezett, tehát a 2.5-ös verzióval dolgozik. Ehhez gyűjt fejlesztési igényeket, illetve a szoftver jövőbeli képességeit próbálja meg eladni. Ezzel párhuzamosan igyekeznek meggyőzni a meglévő ügyfeleket, hogy migráljanak a legújabb verzióra (ez szerződéstől függően lehet ingyenes vagy fizetős).

Mi az architekt szerepe?

Az architekt a jövőbeli verziót (2.5) tervezi, támogatja az aktuális fejlesztést (2.4), illetve ha egy hibajegy architektúrális hiba, akkor segít annak kijavításában.

Mi a projektvezető szerepe?

A projektvezető összehangolja a csapattagok munkáját, a verziók kezelését, illetve ügyel a munkafolyamat betartására.

Hogyan válik szét a fejlesztés és a támogatás?

Mindez a méretektől függ. Amíg kicsi a szoftver és kicsi a csapat, addig nem érdemes szétválasztani a szerepeket, hanem az adott szituációtól, az adott hibától és az aktuális leterheléstől függ, hogy ki javít hibákat. Célszerűen az javítsa ki a hibát, akinek a kódjában van.

Amint sok ügyfél használja a szoftvert, a szoftver nagyobb lesz és a csapat is nagy, akkor célszerű valamilyen módon szétválasztani a szerepeket. A „development” nem nyúl a régi verziókhoz, a „support” pedig csak a ticketre összpontosít. A fejlesztők szép lassan specializálódnak, de még lesznek olyanok, akik az adott helyzettől függően ezzel vagy azzal foglalkoznak.

Például van egy 4 fős csapat, ebből 2 új fejlesztéssel foglalkozik és 2 mindennel. Aztán felvesznek +2 embert, 3 fő új fejlesztéssel foglalkozik, 1 főállásban támogat, és 2 mindennel foglalkozik.

Hogyan kezelhető a fejlesztés és a támogatás ütközése?

Akkor ütközik a fejlesztés és a támogatás, ha olyan kódrészen kellene javítani, amit az új verzió fejlesztése érint. Ilyenkor a feleknek (a hibát kijavítani igyekvő fejlesztőnek és a kódot módosítónak) le kell ülni egyeztetni, hogy mi legyen (esetleg az architekt bevonásával). Fontos, hogy ez az egyeztetés megtörténjen, ne csak belerondítsanak a fejlesztők egymás kódjába.

Az egyeztetésnek 2 kimenete lehet:

- a kód módosítását visszavonják (visszaállítják az eredeti kódrészletet), kijavítják a hibát, és utána újra fejlesztik az új funkciót

- vagy az új funkción tesztelik a hibajelenséget, és azon új kódon javítják a hibát – ami regressziós hibát okozhat

Hogyan hangolható össze a fejlesztői csapat tevékenysége?

Ennyi ügyféllel, verzióval és fejlesztővel a munka bizony elég komplikált lesz, és ha valaki a saját feje után megy, az sok problémát okozhat. Ezért a csapatnak kell hogy legyen valamilyen belső szabályzata (verziókezelés, kódolási konvenció, kódminőség biztosítás) amihez mindenki tartja magát – kivétel nélkül.

Fontos, hogy az egyes fejlesztők – bármilyen területen is dolgoznak – napi szinten kommunikáljanak egymással, vagy legalábbis azzal a másik fejlesztővel, akinek a kódját javítják vagy továbbfejlesztik.

Fontos, hogy az architekt és a projektvezető részt vegyen a napi munkában, támogassa a fejlesztőket, illetve megoldja azokat a problémákat, amiket a fejlesztők nem tudnak. Fontos továbbá, hogy a komplikált hibákat/fejlesztéseket a maguk szintjén koordináljanak – például strukturális hibák kijavítását ne hagyják a fejlesztőkre.

Ezen felül fontos, hogy a feladatok ütemezése és priorizálása tiszta, világos és átlátható legyen. Legyen minden pillanatban egyértelmű, hogy ki melyik feladaton dolgozik, melyik feladat a kód mely területeit érinti, hogy milyen feladatok vannak függőben és mi a terv a következő hétre, hónapra, a következő release-re. És persze hogy melyik hibának és igénynek mi a prioritása.

Hogyan érdemes a kollégákat szétosztani a támogatás és a fejlesztés között?

Sokan úgy tartják, hogy a hibajavítás csak „kézimunka”, amit kezdő fejlesztők is meg tudnak csinálni, és az új funkciók fejlesztése való a vezető fejlesztőnek.

Ezzel szemben a gyakorlat az, hogy hibajavításra tapasztalt fejlesztők kellenek. Igaz, hogy hibát javítani gyorsabb és egyszerűbb - hiszen a keret már adott és a kód olvasásából lehet tanulni – de ugyanakkor nagyon fontos, hogy a hibajavítás ne okozzon újabb hibákat. Azaz a hibajavítás pontosan történjen. Ez pedig csak úgy lehetséges, ha a javítást végző informatikus magasan képzett, pontosan átlátja a szoftver működését és tisztában van a változtatásai következményével.

Új funkciók fejlesztése szakmailag magasabb presztízsűnek tűnik, de ahhoz kevesebb információ is elég, illetve az új funkció hibáit a tesztelés során jobban el lehet kapni.

Milyen kommunikáció legyen fejlesztés és támogatás között?

Ha a fejlesztés és a támogatás szétválik, akkor mindenképpen szükség van formális átadás-átvételre a fejlesztőstől a támogatás felé. Azaz az új release nem csak az ügyfélnek lesz átadva, hanem a támogatásnak is. Ilyenkor a támogatást végzők meg kell ismerkedjenek az új kóddal, a strukturális változtatásokkal. Ideális esetben az új funkciók új dokumentumokat, illetve a dokumentációk frissítését is jelentik.

Mindez azt jelenti, hogy egy belső információs portálra vagy dokumentáció kezelő rendszerre is szükség van, pl. egy wiki-re, ahová a fejlesztés felrakja az új információkat (szó elszáll, az írás megmarad).

Szükség van-e belső dokumentációra?

Azt szokás mondani, hogy a kód a legjobb dokumentáció. Ez valamilyen szinten igaz is. Viszont a csapat már akkora, hogy ott személyi változások lehetnek (pl. új ügyfél esetén csapat bővítés), és az új kollégáknak szüksége lesz valamilyen kiinduló dokumentációra a kódon felül is. A különböző verziók kezelése már elég bonyolult, hogy létezzen valamilyen belső szabályzat – és ez a szabályzat ne szájhagyomány útján terjedjen.

Hogyan lehet a fejlesztés állapotát jelenteni a vezetőség felé?

Amíg egy ügyfél és egy projekt volt, addig a vezetői jelentés pusztán annyit jelentett, hogy megkérdezték a vezető fejlesztőt: hogy állunk, készen leszünk-e határidőre?

Amint a csapat nagyobb lesz és szétválnak a fejlesztési, illetve támogatási feladatok, az aktuális státuszt is nehezebb átlátni. Például lehet, hogy a fejlesztés határidőre kész lesz, de közben a hibák javítása nem halad. Vagy lehet hogy halad, de túl sok lesz a regressziós hiba.

Ezért szükséges, hogy ne egy-egy ember véleménye jusson el a vezetőség felé, hanem a rész-területeket kell pontosan mérni és jelenteni:

- A ticketing rendszer alapján a beérkezett, javított és nyitott hibákat jelenteni, illetve figyelni a trendeket, az ismétlődő és regressziós hibákat – ideális esetben a különféle metrikákat (pl. ageing)

- Az aktuális release-hez kapcsolódó fejlesztés állapota és ütemezése az üzleti terv alapján

- Jövőbeli release-ek tervezése és azok állapota