… tette fel a kérdést Sipos Tamás az AgileHungary rendezvényén. Tényleg, hova tűnt?

… tette fel a kérdést Sipos Tamás az AgileHungary rendezvényén. Tényleg, hova tűnt?

Az eredeti kérdést a következő linken lehet megtekinteni: http://www.meetup.com/AgileHungary/ideas/493046/

Mint látható, eredetileg a SCRUM-hoz és az agilis módszertanokhoz kapcsolódik a felvetés, hiszen ott ilyen szerepkör nincsen, illetve a programozók/egyéb szereplők veszik át.

Hosszan lehetne arról vitatkozni, hogy szükség van-e BA-ra, illetve a programozók, vezető fejlesztők képesek-e átvenni a feladatait. Nem szeretnék ezen vitázni, inkább egy egészen más megvilágításba helyezném a kérdést.

Szerintem a BA szerepének megértéséhez nem a tipikus fejlesztési projektet kell tekinteni (5-8 fejlesztő, 4-8 hónap munka) hanem a nagy projekteket és a projektek utóéletét.

Nagy projektek és a BA

Ugyebár eltérő a „nagy projekt” definíciója – ami az egyiknek nagy, az a másiknak még kicsi. Igazából úgy definiálnám a nagy projektet, ahol már elég sok csapat és fejlesztő dolgozik ahhoz, hogy senki emberfia nem látja át a munkát. Mondjuk úgy 40 fejlesztőnél már ez a helyzet.

Egy ilyen méretű csapatnál pedig már a kommunikáció lesz a legfőbb kihívás: hogyan lehet a felhasználói igényeket (amik esetleg egy több százas méretű felhasználói bázisból lesz összegyűjtve) világosan elmagyarázni a fejlesztőknek?

Ami konkrétan a közös terminológia kialakítását, a fogalmi rendszer felállítását, illetve a fogalmi rendszer segítségével a leendő szoftver meta-szintű definiálását jelenti.
Feltehetőleg ennek a meta-szintű definíciónak az összeállítása tovább tart és több vitát övez, mint a leprogramozása.

Minél nagyobb a méret, az egyes fejlesztők és vezető fejlesztők annál kevésbé látják az egészet, annál nagyobb lesz a vakvezető kutyaként funkcionáló BA-k felelőssége.

Mi történik a szoftver átadása után?

A legtöbb szoftverfejlesztő abban a tévhitben él, hogy a kész szoftver átadása és elindítása után a munka véget ért. Az igaz, hogy a kész szoftver átadása után jön a számlázás, a pénz átutalása, a projekt záró buli, és a jól megérdemelt 2 hét Hawaii nyaralás.

Pedig a munka nem áll meg, sőt folytatódik!

Az élet változik, az üzlet változik, tehát a kész szoftver is folyamatosan változtatni kell. A szoftver üzemeltetés velejárója a változáskérelmek (CR) áradata, amiket valakinek valahol el kell készítenie. A kész szoftver átadása nemcsak a vége valaminek, hanem a folyamatos változtatások kezdete.

A változtatások esetén a legnagyobb kérdést azt jelenti, hogy
a) Hogyan lehet a legegyszerűbben a kért változtatást megtenni
b) Milyen hatást okoz ez a szoftver többi részére

Ezekre a kérdésekre olyan ember tud választ adni, aki metaszinten átlátja a szoftver működését, a szoftver belső folyamatait, az alkalmazott fogalmi rendszert. Sőt nem csak átlátja, de úgy hozzá tud nyúlni – például új fogalmakat létrehozni – hogy attól a szoftver kerek egész maradjon, annak integritása ne sérüljön.

Miért ne tudná ezt megcsinálni egy fejlesztő? Mert a fejlesztő csak az adott változtatást látja. Ugye tipikusan itt olyan szoftverről beszélünk, ami mondjuk 50 mérnökév munkával állt elő. A fejlesztő a szoftver akármelyik moduljába, részletébe bele tud nézni, meg tudja mondani hogy adott ponton mit csinál a kód, és adott ponton bele is tud javítani – de nem látja a teljes képet. Ha pedig kód alapján követi vissza a folyamatot akkor az sok munka is lesz, és nem is biztos hogy sikerült minden részletet feltérképeznie.

Ezzel szemben a Business Analyst csuklóból megmondja, mi hogy van és mit hogy kell csinálni.

Igazából az ilyen emberre van egy másik kifejezés: Subject Matter Expert (SME). Aki ismeri a szoftvert, a fogalmi rendszert, a fogalmi rendszer szintjén tud becsléseket adni a változtatásokra, és a változtatásokat a fogalmi rendszeren végrehajtva instrukciókat (specifikáció) tud adni a fejlesztőknek a változtatás tényleges megvalósítására.

És most eljutottunk egy fontos kérdéshez: ki fontosabb a szoftverfejlesztés szempontjából, az SME/BA vagy a fejlesztő?
Bizony hogy az SME/BA!

Fejlesztők jöhetnek-mehetnek, nem gond. Ha új fejlesztő jön, akkor majd beletanul a szoftverbe, a szoftver fogalmi rendszerébe, és máris tud dolgozni. De ha egy SME-t elveszítünk, akkor a tudást veszítettük el. Amikor arról beszélünk, hogy a „szoftverfejlesztő csapat kemény magja”, akkor én ezalatt az analyst-ot értem.

Talán meglepő lehet, de nálunk majdnem annyi analyst dolgozik, mint fejlesztő. Pontosan azért, mert a változtatások előkészítése, a fogalmi rendszer kezelése legalább akkora munka, mint maga a fejlesztés, és ráadásul sokkal fontosabb is.

Átveheti-e, elláthatja-e a programozó az analyst feladatait?

Igen, sőt az a jó, ha az analyst már látott kódot közelről. Az lesz a jó analyst, akinek van affinitása az informatikához, plusz még ért a rendszerszervezéshez (és az ahhoz szükséges képességekhez).

Mindazonáltal a programozó nem rendszerszervező – a két tevékenység egész mást jelent, és egész más készségek kellenek hozzá. A tipikus programozó nem rendszerszervező. A váltást tudatosan kell megtenni.

Az átlépés legnagyobb gátja az, hogy a rendszerszervező a technológián felülemelkedve absztrakt fogalmi szinttel és folyamatokkal foglalkozik, beszélnie kell a felhasználók nyelvét, ja és jól kell tudnia dokumentumot készíteni (sokkal nehezebb, mint Móricka gondolja).

A programozó tipikusan kézzel fogható dolgokkal dolgozik (kód), távol tartja magát üzleti folyamatoktól és felhasználóktól, ezen felül utál dokumentumot írni.

Igazából én úgy látom, hogy a BA nem tűnt el sehova, továbbra is ott van. Annyi történt, hogy a programozók jelentősége csökkent (pont úgy ahogy megírtam az IT jövője című cikkben), ezért megpróbálják átvenni egyéb szerepkörök feladatait. Ilyen a BA, de megpróbálják elvenni a tesztelők kenyerét (lásd automatizált teszt) illetve a projektvezetőét (lásd SCRUM master). A helyes kérdés nem az, hogy hova tűnt a BA, hanem hogy a programmer/analyst-ok eléggé felkészültek-e az analyst feladatok ellátására?