Alapvető különbségek az elmélet és a gyakorlat között.

Alapvető különbségek az elmélet és a gyakorlat között.

A különféle szoftverfejlesztési módszertanok célja az, hogy keretet adjanak a szoftverfejlesztésnek, a szoftverfejlesztés „mérnöki” oldalának. A módszertani keret egyszerű folyamatokra és lépésekre bontja a munkát, amit a programozók könnyedén elsajátíthatnak és követhetnek a szoftverfejlesztés során.

A módszertanok kizárólag azzal a tankönyvszagú feltételezéssel indítanak, hogy van az ügyfél és van a szoftverfejlesztő. Az ügyfél valamilyen új funkciót akar, a szoftverfejlesztő pedig a módszertant követve megvalósítja azt.

Ez így elméletben, tankönyvben, a táblára felrajzolva egyszerű és világos.

A hiba ott van, hogy a világ már nem ilyen. 10-15 évvel ezelőtt ilyen volt, de azóta sok idő telt el, sok változás történt. Manapság már nem esik be az utcáról az „ügyfél”, hogy szüksége lenne egy könyvelési szoftverre, vagy hogy fejlesszünk ki egy egyedi nyilvántartási rendszert.
A fejlesztési folyamat sem kétszereplős, hanem további szereplők jelentek meg: projektvezetők, auditorok, üzemeltetési osztály, PMO, minőségbiztosítás, Enterprise Architect, beszerzés, sőt ott van a jogi osztály is.

Az nem változott, hogy a történet két legfontosabb szereplője továbbra is az ügyfél és a programozó, viszont a többi szereplő befolyása a szoftverfejlesztésre nagyobb lett, olyannyira, hogy képesek azt akár teljesen megváltoztatni.

Mondok erre a változásra egy példát!
Az Enron gigacsődjére válaszol az amerikai felügyeletek kidolgozták a SOX előírást. A SOX alapvetően nem informatikai előírás, viszont indirekt módon óriási hatása van a szoftverfejlesztésre. A tőzsdén szereplő cégek ugyanis nem kezelhetik szoftvereik és adatbázisaikat akárhogyan, hanem csak úgy, hogy az adatok helyessége és hitelessége bizonyítható legyen. Különben a könyvelés nem tekinthető megbízhatónak, a tőzsdei jelentés nem megbízható – és a cég nem szerepelhet a tőzsdén.
Vagyis: szoftvert nem lehet akárhogyan fejleszteni. A szoftverfejlesztés többé nem a programozó magánügye.

Fontos változás, hogy míg 10-15 éve a technológiai kérdések jelentették a programozás kihívásait (a projekt akkor indult el, ha műszakilag megvalósítható volt), addig ma már az üzleti érték (a projekt akkor indul el, ha megfelelő a ROI).

A ROI említésével átléptünk a pénzügyi területre, és ha már itt vagyunk, nem árt jobban szétnézni. Változott-e a szoftverfejlesztések pénzügyi kerete? Nagyon is sokat!

Az informatika aranykorában, amikor a fejlesztési módszertanok születtek, a pénz gyakorlatilag számolatlanul ömlött az iparágba – az ügyfelek bármit, bármilyen rossz szoftvert is kifizettek, hiszen az még mindig jobb volt, mint ceruzával kockás füzetbe dolgozni.
Innen nagyot fordult a világ. Ahogyan az IT kezdett csodavilág helyett egyre inkább betagozódni a hagyományos iparágak közé, az IT szolgáltatások pedig megtalálták a helyüket a többi vállalati szolgáltatás mellett, a pénzcsapot is elzárták. Ma már nem lehet akármilyen szoftvert eladni, és a jól fizető IT-s álláshoz nem elég, ha elolvasunk 2 könyvet a JAVA programozásról.
Manapság már minden egyes IT fejlesztésért meg kell harcolni, számszerűleg be kell bizonyítani, hogy megéri azt a befektetést. Mivel pénz nélkül nincs fejlesztés, ezért a szoftverfejlesztés alkalmazkodni kénytelen ezekhez a keretekhez és kényszerekhez.

Rámutatnék a kontrasztokra:
A 20. században alkotott fejlesztési módszertanok célja az volt, hogy a szoftverfejlesztési káoszból rendet teremtsenek, és hogy az IT irányt mutasson.
A 21. században azonban a szoftver fejlesztésnek a körülményekhez való alkalmazkodás jelenti a kihívásokat, az IT vezető szerepből kiszolgáló/támogató szerepbe került, és emiatt a 20. századi módszerek egyre jobban döcögnek.

Most egy vargabetűvel visszatérnék a cikk elején említett szoftverfejlesztési alaphelyzethez – amiről a tankönyvek és a módszertanok hibásan azt írják, hogy az ügyféllel és a fejlesztési igénnyel kezdődik. Nem, a szoftverfejlesztés nem itt kezdődik, hanem sokkal hamarabb, és megpróbálom összeszedni a tipikus alapeseteket:

Megrendelő + kkv beszállító

Klasszikus alaphelyzet: a megrendelőnek (tipikusan multi vagy állami cég) szüksége van egy új szoftverre és/vagy új funkcióra. Ehhez megtalálta a kkv informatikai céget, mint beszállítót.
Együttműködésük a beszerzési folyamattal kezdődik, majd a sikeres tender után jön a szerződéskötés, na és ekkor kezdődhet el a tényleges műszaki munka.
Fontos észrevenni, hogy mire a programozók a feladat közelbe kerülnek, addigra a játékszabályokat kőbe vésték (a pályázat és a szerződés megírásakor).

Alapvető eltérés az elméleti modellhez képest:
- Van egy pre-sales folyamat, ami ugyan nem szoftverfejlesztés, de meghatározza azt. Célszerű lenne az elméleti modellekbe ezt is beépíteni, illetve a programozókat erre megtanítani.
- Amikor a tényleges munka elkezdődik, akkor nem csak az ügyfél, a programozó és a követelmények jelentik a kiindulási alapot, hanem létezik egy „megállapodás” a munka körülményeit illetően (szerződés, pályázati anyag, elkötelezettségek, feltételrendszer, stb). A programozónak tudnia kell e megállapodás mentén haladva dolgozni, jó lenne, ha a felsőoktatási rendszer erre felkészítené őket.

Outsourcing

Tipikusan egy nagyvállalat (vagy állami cég) megállapodása egy nagy IT szolgáltatóval, ahol is az IT szolgáltató egy keretmegállapodáson keresztül végez szoftverfejlesztési feladatokat partnerének. Sok projektről, sok csapatról, sok ügyfélről és sok programozóról beszélünk. Tipikusan az ügyfelek és a programozók földrajzilag egymástól távol vannak.

Alapvető eltérések az elméleti modellhez képest:
- Az ügyfél és a programozók közötti kommunikációs kihívások – amit jó lenne a programozóknak megtanítani, és módszertan szintjén kezelni.
- Kulturális különbségek. Szerencsére a felsőoktatási intézmények maguk is multikulturális együttműködésekre törekednek. A módszertanoknak olyan eljárásokat kell javasolniuk, amik alkalmasak különböző kulturális háttérből érkező csapattagok együttműködésére.
- Egy nagy szervezet dolgozik együtt egy másikkal, ahol folyamatok, policy-k és KPI-ok vannak. A programozó idejének nagyobb részét adminisztráció fogja jelenteni. Hasznos lenne ezeket már az iskolapadban megismerni (industry best practice).
- Módszertani változás, hogy a két fő szereplőn kívül megnövekszik a QA és az audit szerepe – gyakorlatilag az ő igényeik is legalább olyan fontosak, mint az ügyfélé.
- Szétválik az üzemeltetés és a fejlesztés – az Üzemeltetés is egy ügyfél, és beleszólásuk van a fejlesztésbe.

Belső fejlesztés

A programozó és az ügyfél is ugyanazon cég alkalmazottai, ugyanazon a lokáción vannak. Sok egymást követő, gyakorlatilag folyamatos fejlesztési munkáról van szó. A programozó és a felhasználók egyenrangúak, sőt a programozóval szemben elvárás, hogy ismerje az üzleti oldalt, beszélje annak nyelvét, sőt tanácsot tudjon adni üzleti problémák megoldására.

Alapvető eltérések az elméleti modellhez képest:
- A fejlesztés célja nem a műszaki tökéletesség, hanem az üzleti érték, üzleti előny megteremtése. Érdemes lenne ezt a szemléletet az egyetemen bemutatni, illetve módszertan szintjén kimondani.
- A fejlesztés folyamatos és hosszútávú, ezért a fontos szempont a fenntarthatóság, az üzemeltethetőség és a továbbfejleszthetőség. Módszertan szintjén kellene ezekkel foglalkozni.
- A fejlesztő aktívan részt vesz az igények azonosításában, kvázi tanácsadóként dolgozik.
- A folyamatos fejlesztés azt jelenti, hogy egy cégtelen ciklusban pörgünk: amint lezárul az előző fejlesztés, kezdődik a másik.

Kutatás-fejlesztés, termék fejlesztés

A fejlesztő nem szolgáltatást nyújt az üzlet részére, hanem terméket fejleszt, amit a cég aztán eladhat ügyfeleinek. Olyan megoldásokat, technikákat kell alkalmazni és kitalálni, amit esetleg előtte még senki más nem tett. Lehet, hogy a megoldás nem lesz teljesen bolondbiztos, de fontos hogy minél hamarabb elkészüljön, és az ügyelek számára előnyös legyen, ami előny miatt a terméket megveszik.

Alapvető eltérések az elméleti modellhez képest:
- Time-to-market mint cél.
- Adminisztráció helyett műszaki megoldások.
- Az tényleges „ügyfél” nem egy konkrét személy, hanem egy piaci szegmens.

(Megjegyzem, hogy az esetek 90%-ában a szoftver szolgáltatás, és nem termék. Lásd „Software as a Service” koncepció. És a programozó nem terméket fejleszt, hanem szolgáltatást nyújt. Kivételek vannak, nagyon is sok.)

Az alapesetek taglalásánál elég jól látszik, hogy a szoftverfejlesztés sokszereplős, és az adott projekttől, az adott cégtől múlik, hogy a hangsúlyok hol vannak. Sajnos a módszertanok kizárólag a programozóval foglalkoznak, kizárólag az ő szemszögéből világítják meg a folyamatot. Ez még azokra az agilis módszertanokra is igaz, amelyek saját állításuk szerint ügyfélközpontúak. Mert ezeknek a fejlesztéseknek is a legnagyobb gátja maga az ügyfél…

És végezetül még egy, nem kevésbé fontos dolog. Vajon melyik fejlesztési módszertan indul ki abból, hogy egy projekt részeként projektmenedzser irányítása alatt, projektmenedzsment módszertant követve kell szoftvert fejleszteni?
Mert ez itt a 21. század, kéremszépen projektszerűen dolgozunk…