Elkészül a szoftver, elküldjük az ügyfélnek, aki azonnal egy rakás hibát küld vissza. Ezeket kijavítjuk, elküldjük az új verziót, mire megint egy rakás hiba jön vissza. Beindul a tenisz, csúszik a projekt, és mindenki a másikat okolja.

Elkészül a szoftver, elküldjük az ügyfélnek, aki azonnal egy rakás hibát küld vissza. Ezeket kijavítjuk, elküldjük az új verziót, mire megint egy rakás hiba jön vissza. Beindul a tenisz, csúszik a projekt, és mindenki a másikat okolja.

Habár konkrétan nem szerepel a fejlesztési módszertanokban, de létezik egy úgynevezett stabilizációs fázis a szoftverfejlesztés során. Ez az a fázis, amikor már funkcionálisan elkészült a szoftver, de még nem elég jó ahhoz, hogy élesbe át lehessen adni. A stabilizációs fázis során hibák javítása zajlik. A „hiba” sokféle lehet: szoftver bug-tól kezdve tervezési hibán át rossz specifikáció, félreértés, új ötletek.

Ez az egész olyan, mint ahogy a repülő dugóhúzóba kerül. Egyre több hibát jelent be az ügyfél, amikre egyre gyorsabban válaszol új release-zel a fejlesztő, amiket az ügyfél aztán csak addig tesztel, hogy találjon megint 15 hibát és visszadobhassa azt. Az együttműködés helyett verseng lesz, ahol a felek egymás ellen dolgoznak és a szoftverrel teniszeznek. A viszony egyre rosszabb lesz, egyre kevesebb a hasznos munka és egyre több a politika. A meeting-ek hangvétele egyre rosszabb. Megindul az ujjal mutogatás, a fenékvédés és a helyezkedés.

Hogyan lehet egy a dugóhúzóból kirántani a gépet és simán landolni a célállomáson?

Úgy nem, ha jobban teniszezünk. Ha a labdát erősebben és gyorsabban átlőjük a másik térfélre, akkor erősebben és gyorsabban fogják visszalőni. A megoldás az, ha kilépünk a teniszjátszmából és rendbetesszük a projektet.

Hogyan lehet a teniszezést leállítani?

A teniszjátszma „üzemanyaga” a szoftverben szereplő hibák. Ha nincs üzemanyag akkor nincs teniszezés. Nem szabad olyan szoftververziót átadni az ügyfélnek, amiben hibák vannak, ami nem elég jó. A legtöbb esetben erre azért kerül sor, mert szorít a határidő és követelőzik a menedzsment – na ezt kell figyelmen kívül hagyni. Nem szabad feláldozni a projektet rövid távú sikerekért.

Hogyan lehet elfogadható szoftvert elállítani?

Úgy, hogy a QA funkciót nagyon komolyan vesszük. A szoftvert átadás előtt nagyon alaposan le kell tesztelni – ami azt feltételezi, hogy létezik egy részletes teszt terv, és megfelelő szándék annak végrehajtására.

A részletes teszt terv azt feltételezi, hogy a szoftverrel támasztott követelményeket pontosan ismerjük.

És van itt még egy dolog: az ügyféllel meg kell egyezni abban, hogy mit nevezünk elfogadható szoftverrel. Ha az ügyfél oldali tesztelés célja az, hogy minél több hibát találjanak, az nem tesztelés. És ha hibát is találnak, az nem feltétlenül jelenti azt, hogy a szoftvert nem lehet elfogadni. Ezeket előzetesen jó alaposan át kell beszélni, és megállapodni a részletekről.

Hogyan lehet a megőrizni az ügyfél bizalmát?

Csakis úgy, ha bízhat bennünk. Ha megcsinálunk mindent, amit ígértünk, és nem teszünk felelőtlen ígéreteket. Ha nem teszünk le egy félkész szoftvert az asztalra pusztán azért, mert jön a határidő. A trükkök duplán ütnek vissza.

Hogyan lehet egyensúlyozni a határidő és a minőség között?

Amikor abba a helyzetbe kerültünk, hogy választani kell a kettő között, akkor már késő. A megoldás kulcsa a megelőzés: legyen egy előzetes tervünk arra nézve, hogy teljesül mindkettő – egy igazi, megvalósítható, reális terv.

Az előre gondolkodás és a jó tervezés a kulcs. Viszont ahhoz, hogy előre tudjunk gondolkodni és jó tervezni, ahhoz tudásra és tapasztalatra van szükség.

Mit lehet csinálni, ha már válság van, és azonnal kell a megoldás?

Csodák nincsenek. Ha elszabadultak az indulatok és a projekt elsüllyedt a stabilizációs fázisban, abból csak úgy jöhetünk ki, ha újratervezzük a projektet. Le kell állítani a munkát (a teniszezést), és új, valós tervet kell csinálni. Ami azt jelenti, hogy vissza kell menni a fejlesztés korábbi szakaszába, és újracsinálni azt, ami nem lett megcsinálva. Ez értelemszerűen csúszást jelent (a projektet kvázi le kell állítani egy időre), de egy kis csúszással még mindig hamarabb lesz kész a szoftver, mint az elhúzódó teniszezéssel.

Ha elúszik a projekt a stabilizációs fázison, akkor azért ki visel jogilag felelősséget?

Amikor a felek szerződést böngésznek és jogásszal konzultálnak, akkor már késő. Ha meg akarnak állapodni, akkor tudomásul kell venni, hogy mind a Beszállító, mind a Megrendelő kénytelen veszteséget elszenvedni. A Megrendelő azért, mert nem készült el a szoftver, amit várt, és mert az üzleti szakértőinek tovább kell a projekttel foglalkoznia. A Beszállító azért, mert ugyanazért a fizettségért sokkal tovább kell dolgoznia (a programozókat fizetni kell hónap végén).

Meg tud-e bukni végérvényesen egy szoftverfejlesztés a stabilizációs fázisban?

Igen. A stabilizációs fázis az, amikor az ügyfél először találkozik a szoftverrel, és szembesül annak minőségével. Ha ez nagyon messzire van az elvárásoktól, akkor az járhat a projekt törlésével.

Éppen ezért kell nagyon alaposan megismerni az elvárásokat, és még a release előtt megismertetni a megrendelőt a szoftverrel, például képernyőtervek készítésével, prototípussal, vagy agilis fejlesztéssel.