Múlt héten felraktam egy idézetet – „Successful software development project is more than a successful software development" – most jöjjön a magyarázat és a részletek.

Múlt héten felraktam egy idézetet – „Successful software development project is more than a successful software development" – most jöjjön a magyarázat és a részletek.

„Successful software development project is more than a successful software development."

Az ominózus idézet egy prezentációból való, amit annak kapcsán készítettem, hogy cégünk egyik fontos szoftverével komoly gondok vannak, és hogy ezeket a problémákat meg kellene oldani.

Már ott nehézségbe ütköztem, hogy megfogalmazzam a problémát. A helyzet az, hogy a szoftveren dolgozó fejlesztők magas szinten képzettek, és mindent megtesznek a sikerért, azonnal ugranak minden igényre és nagyon gyorsan dolgoznak. Műszakilag jó döntéseket hoznak, az alkalmazás architektúra logikusan felépített.

A fejlesztést koordináló menedzserek is odatették magukat, hiszen számos operatív folyamatot, riportot, eljárást kidolgoztak a fejlesztési folyamat gördülékennyé tétele miatt, és majd megszakadnak hogy minden jól menjen.

Ennek ellenére ez a szoftver rendszeresen nem elérhető (rendszerösszeomlás, teljesítmény problémák, üzemeltetési problémák), hajmeresztő rémtörténetek forrása, és már mindenkinek a hócipője tele van, hogy megint krízist kell kezelni.

A fejlesztők és menedzserek mindent megtesznek a sikerért, saját elmondások szerint ők teljesítették a feladataikat. Ugyanakkor értetlenül állnak a válsághelyzetek előtt, és ők is szeretnék ezeket megoldani.

Tehát egyik oldalon ott van egy operatív szinten 100%-osan jól működő szoftverfejlesztés egy maximálisan rugalmas és hozzáértő fejlesztő csapattal, a másik oldalon pedig ennek a munkának az eredménye bizony rossz.

Hogyan lehet az, hogy ugyanarról a szoftverről, ugyanarról a csapatról beszélünk? Miért rossz a szoftver, miközben a szoftverfejlesztés jó?

Az került tehát a prezentációba, hogy a sikeres szoftverfejlesztési projekt több, mint a sikeres szoftverfejlesztés – arra célozva, hogy a csapat ugyan sikeresen fejleszt szoftvert, de projekt szinten hibák vannak.

Mi a különbség a szoftverfejlesztés és a szoftverfejlesztési projekt között?

A szoftverfejlesztés az maga a kivitelezés, tehát amikor elindulunk az üzleti igényekből, és elérkezünk a kész, működő szoftverhez, beleértve a tesztelést és a telepítést.

A szoftverfejlesztési projekt ennél sokkal több. A különbségeket hosszasan lehetne ecsetelni, most a teljesség igénye nélkül felsorol néhányat – amiket az adott csapat figyelmen kívül hagyott:

Előkészítés: A legmarkánsabb különbség a szoftverfejlesztés és a projekt között az előkészítés. Projekteket csak megfelelő előkészítéssel, megfelelő kötelezettségvállalással indítunk, ahol felépítjük a csapatot, megszerezzük az erőforrásokat és kialakítjuk a kereteket. Egyesek túlzott bürokráciát emlegetnek, de tény, hogy az adminisztratív körök futása közben jól körbejárjuk a projekt megvalósíthatóságát.
Ha pusztán a szoftverfejlesztésről beszélünk, ott nincsenek a programozók rákényszerítve a megvalósíthatóság vizsgálatába vagy a munka körülményeinek megteremtésére.
Olyan párhuzamra meg rá se világítok, hogy miközben a projekt része az erőforrások és a budget megszerzése, addig az informatikus nem érzi feladatának a pre-sales tevékenységet.

Célkitűzés: A szoftverfejlesztés célja az igényspecifikáció megvalósítása – módszertantól függetlenül. A tesztelés ennek az igényspecifikációnak a megvalósítását ellenőrzi vissza.
A projekt célja viszont nem az igényspecifikáció megvalósítása, hanem az üzleti probléma megoldása, a benefit statement-ben foglaltak elérése. Vagyis a projekt és a fejlesztés célja eltérő.
Például tegyük fel, hogy egy új autómodell bevezetése miatt 10 helyen változtatni kell a szoftveren, tehát a funkcionális igénylista 10 elemű. A szoftverfejlesztők erre a 10 változtatásra összpontosítanak, pedig lehet, hogy ez még kevés lesz az új modell értékesítéséhez. A kétféle cél nem egyenlő, lehetnek eltérések, és ezen eltérések felderítése legalább annyira fontos, mint magának a programkódnak a megírása.

(A felesleges kommentek elkerülése végett: a történetben szereplő csapat agilisan fejleszt – de mint látható itt nem a fejlesztési módszertannal van baj.)

Minőségbiztosítás: Az informatikusok és a projekt auditorok másképp definiálják a minőséget és más eszközökkel biztosítják azt. (Sajnos akadnak még informatikusok, akik nem az ügyfélelégedettségben mérik a minőséget.)

Vannak bizonyos sztenderd eljárások, amiket a fejlesztés során követni illik, de ezek kevesek egy projekt minőségének a biztosításához.

Ebben történetben a fejlesztők megtettek mindent a megfelelő minőségért: unit test-ek és felhasználói validálás, ahol a felhasználók előre kidolgozott teszt esetekkel dolgoztak.
Azonban egy komoly fejlesztési projektnél ez kevés.
A felhasználói tesztek minőségben és mennyiségben nem érték el a szükséges szinten. A felhasználók „lusták” voltak, és senki sem ellenőrizte őket.
Nem voltak integrációs tesztek. (erről mindjárt részletesen)
Nem voltak code review-k. Nem volt design review. Senki sem ellenőrizte, hogy a minőségbiztosításhoz szükséges dokumentumok elkészüljenek – ezért azok nem is készültek el. Projekt szintjén sem ellenőrizték, hogy a projekt tervben leírt feladatok ténylegesen elkészültek-e. Ha a fejlesztő azt mondta, hogy készen van, akkor azt elhitték, és senki sem gondolt bele, hogy ez valós státusz-e – például előfordult, hogy a kód hamarabb került kifejlesztésre, mintsem hogy architektúrális kérdésekre választ sikerült volna találni. A fejlesztő előreszaladt, és ezzel kész helyzet elé állította a projektet.
Ja, és igazából a projekt dokumentumai sem voltak meg.

Összességében tehát azok az alapok megvoltak, amiket egy fejlesztő meg tud tenni a minőségért, de azok hiányoztak, amiket egy projektvezetőnek vagy fejlesztési vezetőnek meg kell tennie.

Rendszerintegráció hiánya: Nagyvállalati környezetben a szoftver nem szigetszerűen működik, hanem szükségszerűen kapcsolódik más rendszerekhez, ezért a fejlesztéseknek is összehangoltan kellene történnie. Ezt a műszaki koordinációs tevékenységet nevezem rendszerintegrációnak.
Ahogy a szoftver egyre nagyobb és egyre bonyolultabb lesz, egyre több csapattal kell/kellene együtt dolgozni. Ezek között feltehetőleg több „külső” csapat is lesz, tehát olyanok akiknek nem tudnak a fejlesztők „parancsot” adni az interfészelés kapcsán.
Központi koordináció nélkül a fejlesztések szétesnek, és a külön-külön fejlesztett szoftverek összeillesztve nem fognak működni.
Számomra alapvető különbség a szoftverfejlesztés és a szoftverfejlesztési projekt között, hogy ez utóbbi tartalmazza a műszaki koordinációs, rendszerintegrációs feladatokat is, többek között az integrációs teszteket.

Átadás az üzemeltetés részére: Ha valaki azt gondolja, hogy a szoftver fejlesztés végetér a sikeres telepítéssel, az nagyon is téved. A szoftver élete igazából csak ekkor kezdődik – ezt a szakaszt hívjuk éles üzemnek. A letelepített szoftver működéséért az informatikai üzemeltetés felelős. Tehát a sikeres szoftverfejlesztési projekt része – de nem szoktuk a fejlesztéshez hozzáérteni – az a szakasz, amikor a szoftvert átadják az üzemeltetésnek, az üzemeltetőket kiképzik a szoftver kezelésére, átadják a szükség dokumentációt illetve frissítik a meglévőt.
Itt a konkrét esetben a fejlesztői csapat és az üzemeltetők között nem volt semmilyen átadás-átvétel. Csakis akkor beszéltek egymással, amikor valami baj történt, és amikor felelőst kerestek a hibákért.

Hosszú távú stratégia – projekt portfólió tervezés: Nagyvállalatnál a projektek nem csak úgy magukban szoktak megtörténni, hanem aprólékos stratégiai tervezés részeként, ahol nem az egyes projekteket tekintik, hanem az egész üzletágat és az üzletági stratégiát. Ennek megfelelően a projektek között összefüggés és áthallás van.
Ezzel szemben a szoftverfejlesztés mindig az adott feladatra összpontosít, az adott üzleti igényt elégíti ki.
A konfliktusok elkerülése végett szükség van hosszú távú informatikai tervre és annak követésére még akkor is, ha ezek ellentétesek a rövid távú üzleti célokkal.

Megalkuvás: Az informatikai munka során gyakran kerülünk olyan helyzetbe, amikor a legegyszerűbb megoldást a megalkuvás jelenti, például lentebb adunk a minőségből, kevesebb időt töltünk teszteléssel, megvágjuk a célkitűzéseket, vagy egy ideiglenes megoldást alkalmazunk.
Ennek aztán utólag mindig meglesz az ára – ami nem is kevés. És ezt az árat aztán a fejlesztők (is) fizetik.
Egy szoftverfejlesztés során könnyen előfordulhat, hogy az ügyfél „kényszeríti” a fejlesztőket egy hibás szakmai döntésre, de szoftverfejlesztési projektben erre kevesebb a lehetőség. A megfelelően vezetett projektben az efféle döntések – és a következményeik – nem a fejlesztőket terhelik.

Felelősségi körök: A szoftverfejlesztés során feltételezhetően van egy szerződés a két fél között, ami tartalmazza a felelősségeket. Feltételezhetően ez a szerződés inkább a beszállítót szabályozza.
Ezzel szemben egy szoftverfejlesztési projektben nem csak szerződés van, hanem projekt dokumentumok (pl charter) is, ami részletesen leírja ki miért felelős és kinek milyen feladatai lesznek. Emiatt egy projekten belül sokkal tisztábbak a szerepkörök, mint egy kézivezérléses fejlesztésben.

3. fél bevonása: A szoftverfejlesztőt az szokta érdekelni, hogy neki konkrétan mi a dolga. Azonban vannak helyzetek, amikor egy funkció kifejlesztéséhez konzultálnia kell egy 3. féllel, mondjuk egy másik rendszer fejlesztőjével az interfészről, vagy egy 3. csapattal (nem a megrendelő és nem a kivitelező), aki az adott munkát véleményezi.
Kézivezérléses fejlesztésnél előfordulhat, hogy a megrendelő elmaszatolja a 3. fél bevonását, nem válaszol kérdésekre, vagy esetleg önkényesen – a 3. fél bevonása nélkül – hoz döntést. Aztán amikor kész a szoftver, akkor esetleg felbukkan a 3. fél és elmondja, hogy ez az egész rossz.
Projekt esetén ezeket a függőségeket meg kell határozni, tehát nincs lehetőség elmaszatolásra vagy önkényeskedésre. Ha valakinek a szava döntő, akkor ő stakeholder, és ekként is kell kezelni. A projekt keretet ad ezek kezelésére és a helyes megoldás megtalálására.

Összességében tehát a szoftverfejlesztési projekt és a szoftverfejlesztés nem ugyanaz, hanem ugyanannak a történetnek különböző szintjei. Lehet az egyik sikeres, miközben a másik teljes kudarc. Ahhoz, hogy az ügyfél boldog legyen és a fejlesztő megkapja a pénzét, mindkettőnek sikeresnek kell lennie!