HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • 232323: Szóval managernek jó lenni, akkor dől a nagy lé, felelősség meg számonkérés sehol. Krém. (2019.10.31. 15:24) Kirúgják-e a menedzsert ha hibázik?
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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

Verzió

Ügyfél

Tevékenység

2.1.10

A

Bug fix

2.2.11

B

Bug fix

2.3.8

C

Bug fix

2.4.0

Új fejlesztés

Új funkciók hozzáadása

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

Típus

DEV

TEST

UAT

PROD

A ügyfél

2.1.11

2.1.11

2.1.11

2.1.10

B ügyfél

2.2.13

2.2.12

2.2.12

2.2.11

C ügyfél

2.3.8

2.3.8

2.3.8

2.3.8

Új fejlesztés

2.4.0

2.4.0

-

-

Következő verzió

2.5.0

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

Címkék: fejlesztés támogatás support szétválasztás

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr375211776

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

takacsot · http://www.qualityontime.eu 2011.11.28. 12:47:58

Nagyszerű szemléletű cikk. Igazából a fejezeteket kiegészítve néhány konkrét tippel/tool-val és már kész egy teljes fejlesztési folyamat leírás. Kiemelem azt a részt, mint legelső leírt, menedzseri megállapítás, hogy az újoncokat nem hibajavításra kell tenni. Nem oda valók. Ráadásul, ha új fejlesztést csinálnak azt már a sajátjuknak érzik. Míg más trehány munkáját javítani nem nagy inspiráció (még akkor sem, ha ő maga alapból sem tudná olyan jól megírni).

BPéter 2011.12.04. 12:33:09

Hi! Új kommentelő vagyok a blogon, bár már viszonylag régebb óta olvasom :) Ezzel a "kezdő/tapasztalt fejlesztő hova való" dologgal egy jottányit sem tudok egyetérteni, nálunk pont fordítva van. Nem kötözködni akarok, biztos több projektet láttál már életedben, mint én, de ahol én vagyok, ennek teljesen az ellentétét alkalmazzuk, szerintem nem véletlenül. "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." Abszolút nem értem mi ezzel a gond, a kulcsszó természetesen a code review. Nálunk minden egyes TR (vagy másképp ticket) kijavításakor el KELL küldeni a megoldási javaslatot egy tapasztalt embernek, aki az adott területen járatos, és véleményezi a megoldást. Ha minden jó, mehet a ticketre a lezárás, ha nem, akkor elmondja, mit kéne módosítani. Tökéletesen működik a módszer. "Ú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." Szerintem egyáltalán nem igaz, hogy kevesebb információ is elég. Egy nagyobb rendszerben hihetetlenül fontos, hogy az új funkció hozzáadásakor betartsuk azokat a design contractokat, helyesen használjuk azokat az interfészeket, amik már megvannak a rendszerben, előre kell látni, hogy az adott megoldás milyen változásokat eredményezhet. Ezt csak az tudja megtenni, aki már jó ideje dolgozik a rendszerrel. Hiába nagyon tehetséges valaki, sokkal kisebb valószínűséggel fogja tudni előre jelezni, hogy az ő változtatása milyen járulékos hatásokkal fog járni, mint az, aki már 5 éve használja. Konkrétan arra gondolok, hogy az adott implementáció természetesen működhet akkor is, ha egy újonc kódolja, de minden SW projektben, ha már elég nagy, kialakulnak bizonyos konvenciók, kódolási szokások, amelyeket végül mindenhol ugyanúgy használnak, mert úgymond az a "helyes", az a bevett. Aki nem látja át a dolgokat, az nagyon valószínű, hogy másképp fogja ezeket csinálni, és emiatt állandóan figyelni kell rá, hogy a helyes utat választja-e. Természetesen ez függhet a változtatás méretétől (meg jellegétől) is, egy ticket megoldás is maga után vonhat egy sor új osztály/metódus/akármi bevezetését, meg egy új feature is lehet összesen 20 sor (mondjuk egy GUI felületén egy új textbox), de általában azért az utóbbi nagyobb szokott lenni. Nálunk teljesen természetes, hogy az új emberek maintenance-ben kezdenek, és a projektet (komplex telekom rendszer) nem nyeretlen tizenévesek irányítják, hanem 10-15 vagy még több év tapasztalattal rendelkező szakemberek.

Ismeretlen_102125 2011.12.04. 14:26:31

Kedves BPéter, üdvözöllek a kommentelők között :) A "kezdő/tapasztalt fejlesztő hova való" egy óriási téma, amiről majd igyekszek valamikor írni. A fenti cikk egyfajta munkaszervezést mutat be, természetesen lehet másképp is jól csinálni. Örülök annak, hogy valaki megosztott egy ilyet.

BPéter 2011.12.04. 16:00:31

Hi! Oké, várom a bejegyzést! :) Így visszaolvasva a kommentemet, kicsit agresszívnak tűnik, remélem nem tűnt bántónak vagy okoskodónak.

Ismeretlen_102125 2011.12.05. 19:11:00

@BPéter: Elkészült a cikk, de túlságosan magasröptű, ezért itt is válaszolok. Nem létezik egyféle jó megoldás, mert sok függ a külső tényezőktől. Amit leírtam, az egyféle modell, ami szerintem (szubjektív) optimális. Ettől függetlenül más modell is lehet jó. "Nálunk minden egyes TR (vagy másképp ticket) kijavításakor el KELL küldeni a megoldási javaslatot egy tapasztalt embernek, aki az adott területen járatos, és véleményezi a megoldást. Ha minden jó, mehet a ticketre a lezárás, ha nem, akkor elmondja, mit kéne módosítani. Tökéletesen működik a módszer." Működni működik, de mennyibe kerül? Nem lenne-e hatékonyabb, ha a javítást egy jobb szakember végezné és nem kellene +1 kört futni? "Konkrétan arra gondolok, hogy az adott implementáció természetesen működhet akkor is, ha egy újonc kódolja, de minden SW projektben, ha már elég nagy, kialakulnak bizonyos konvenciók, kódolási szokások, amelyeket végül mindenhol ugyanúgy használnak, mert úgymond az a "helyes", az a bevett. Aki nem látja át a dolgokat, az nagyon valószínű, hogy másképp fogja ezeket csinálni, és emiatt állandóan figyelni kell rá, hogy a helyes utat választja-e." Összefüggő fejlesztési feladatnál elég csak egyszer megnézni, hogy jól csinálta-e, nem kell állandóan figyelni.
süti beállítások módosítása